Conocer a los desarrolladores donde están 

Las organizaciones que recurren a DevSecOps para realizar lanzamientos más rápidos y seguros conocen la importancia de optimizar la productividad de los desarrolladores con una pila tecnológica integrada. Secure Code Warrior Las integraciones de software de GitHub permiten a los desarrolladores disponer de recursos de desarrollo seguros integrados en las herramientas que utilizan a diario, como GitHub y Jira, entre otras. 

Secure Code Warrior garantiza que su programa de código seguro se incorpore directamente a sus productos preferidos y a los flujos de trabajo de los desarrolladores para permitir una corrección justo a tiempo, así como resultados de aprendizaje más sólidos.

Reduzca las vulnerabilidades con una corrección más rápida

Encontrar y solucionar una vulnerabilidad puede ser como resolver un gran rompecabezas sin algunas de las piezas y el útil arte de tapa, que a veces puede tomar días, semanas o incluso meses para completar con una solución robusta. Esto puede ser particularmente difícil para los desarrolladores cuando no saben cómo solucionar el problema, ya sea porque nunca se han encontrado con el problema antes, o porque dudan en desplegar una solución no probada o no verificada.

El tiempo medio de remediación (MTTR) para una vulnerabilidad localizada en toda la pila, según el informede estadísticas de vulnerabilidad de EdgeScan 2022 fue de 57,5 días (Informe de estadísticas de vulnerabilidad de EdgeScan2022).

Se trata de una ventana crítica en la que se pueden poner en peligro datos valiosos, se pierde la confianza y se desperdicia una valiosa productividad de los desarrolladores, lo que disminuye la velocidad de publicación del código y, en última instancia, acumula más deuda tecnológica con arreglos rápidos o parches chapuceros debido a la falta de conocimiento o confianza en las soluciones desplegadas.

Secure Code Warriorofrecen asesoramiento de confianza para la corrección, lo que permite a los desarrolladores resolver los errores de seguridad con confianza mientras se mantienen en el flujo. Al permitir que los desarrolladores se encarguen de la corrección en el origen, AppSec puede centrarse en la supervisión de los riesgos y en reforzar la postura de seguridad de la organización. 

Con la orientación contextual sobre codificación segura incluida en los elementos de trabajo, los desarrolladores obtienen ayuda inmediata para aprender más sobre las vulnerabilidades detectadas y cómo solucionarlas, reduciendo así el MTTR, además de ofrecer valiosos resultados de aprendizaje adheridos que reducen proactivamente las vulnerabilidades en el origen: el código.

Amplíe el aprendizaje en sus equipos 

Integración de SCORM LMS

SCORM significa Sharable Content Object Reference Model y es un estándar internacional para e-courses. Si su curso se publica en formato SCORM, puede estar seguro de que casi cualquier sistema de gestión del aprendizaje (LMS) lo reconocerá. Con SCORM, puede gestionar fácilmente un programa de formación en código seguro junto con sus otras plataformas de formación en un solo lugar.

Compruebe la competencia antes de enviar el código 

Secure Code Warrior Connector for Okta Workflows ayuda a evitar que se introduzca código inseguro en su base de código con el poder de una comprobación de competencia de seguridad que puede incorporarse a su flujo. Al trabajar en bases de código, como en un repositorio de GitHub, puede establecer lecciones y evaluaciones requeridas como calificadores para codificar en la base. Esto permite a sus líderes asegurarse de que cada desarrollador está preparado para trabajar en la base de código correspondiente, lo que ayuda a nivelar la postura de seguridad de toda la organización. 

Introducir la seguridad en todo el ciclo de vida del desarrollo de software garantizando que cada desarrollador individual haya alcanzado las habilidades de codificación segura necesarias para que se le conceda acceso al repositorio para confirmar el código. Esta integración garantizará que los desarrolladores conozcan las últimas prácticas de seguridad a través de la atractiva plataforma de SCW y que se reduzcan algunas de las cargas de las revisiones manuales del código, liberando horas de ingeniería para enviar más funcionalidad sin sacrificar la calidad.

Obtenga más información sobre Okta + SCW o vea la demostración aquí. 

Soporte "justo a tiempo" al confirmar el código

SCW para GitHub permite la formación contextual dentro de los flujos de trabajo de GitHub, ya sea en los archivos SARIF o directamente en las incidencias y pull requests en las que están trabajando. Esto permite a los desarrolladores acceder a los conocimientos cuando más los necesitan para ayudarles a enviar código de calidad más rápidamente. Esta integración no se limita a permitir un parche que a menudo se aplica sin comprender. Refuerza continuamente los patrones de codificación buenos y seguros para permitir un rápido reconocimiento del código vulnerable. 

Más información sobre SCW+GitHub o ver la demostración

La guía de codificación segura procesable integrada dentro de GitLab incorpora enlaces de formación altamente relevantes de Secure Code Warrior a la sección de detalles de vulnerabilidad de los informes de vulnerabilidad. En última instancia, esto ayuda a reducir la brecha de tiempo entre el aprendizaje y la aplicación de los conocimientos para garantizar el uso futuro al permitir esta integración. Por ejemplo, si los escáneres de vulnerabilidad detectan una falsificación de solicitud de sitio cruzado (CSRF) en el código de la aplicación, el detalle de la vulnerabilidad se actualizará con el enlace de formación pertinente.

"Al ofrecer Secure Code Warrior's amplio aprendizaje contextual a través de la codificación segura en nuestra plataforma, vamos a permitir a los desarrolladores a adoptar la seguridad primero desde el principio y no sólo ahorrar tiempo, sino también ayudarles a desarrollar nuevas habilidades." - Nima Badiey, vicepresidente de GitLab

Más información sobre SCW + GitLab

Secure Code Warrior La integración de Synopsys Seeker incorpora recursos, vídeos y enlaces de formación a los hallazgos de vulnerabilidad en Seeker. Esto garantiza el cumplimiento de las normas y reglamentos del sector con un microaprendizaje que identifica y resuelve las vulnerabilidades con una guía de formación fácilmente accesible dentro de Seeker. 

Más información sobre Synopsys + SCW

Ayuda dentro de un billete cuando lo necesitas ahora 

Deje de limitarse a encontrar fallos de seguridad y obtenga ayuda para solucionarlos con Secure Code Warrior para Jira. Los desarrolladores obtienen formación contextual directamente en su gestor de incidencias de Jira, lo que les permite acceder a los conocimientos cuando más los necesitan para poder enviar código de calidad con mayor rapidez. Secure Code Warrior para Jira detecta estos detalles de las incidencias y ofrece a los desarrolladores la oportunidad de aprender a solucionarlas, accediendo a vídeos de formación específicos dentro del entorno con el que están familiarizados. A través del microaprendizaje contextual, los equipos de desarrollo pueden reducir las vulnerabilidades en todo el código base y mantenerse al día mediante el seguimiento y la generación de informes a través de Jira.

Más información sobre SCW + Jira

Escribir código seguro a toda velocidad

Secure Code Warriorpermiten el microaprendizaje y una corrección más rápida con orientación y soluciones fiables para las vulnerabilidades más comunes. 

• Los enlaces de formación se adjuntan como comentarios en las incidencias y pull requests para que la orientación sea fácilmente accesible cuando se necesite.

• El contenido es muy relevante y se obtiene a partir de las referencias de Common Weakness Enumeration (CWE) o del Open Web Application Security Project (OWASP). 

• La amplia cobertura significa que los recursos de aprendizaje provienen de la principal colección de formación en codificación segura del mundo. 

Las vulnerabilidades comunes, muchas de las cuales se conocen desde hace décadas, siguen persistiendo dentro del SDLC debido a las medidas reactivas. Las herramientas de escaneo y pentesting sólo encuentran el problema, y a menudo después de que la aplicación ya está en producción. Son notoriamente lentos -surgiendo múltiples falsos positivos y negativos que requieren una revisión manual- y rara vez abordan la causa del problema o su origen.

Capacitar y habilitar a sus desarrolladores con consejos de microaprendizaje y corrección dentro de sus flujos de trabajo les ayuda a detectar los puntos débiles de seguridad en una fase más temprana del proceso de desarrollo, antes de que resulten costosos o, lo que es peor, de que dejen vulnerabilidades que puedan explotarse más tarde. Las integraciones de Secure Code Warrior van al encuentro de sus desarrolladores allí donde trabajan y no sólo les ayudan a encontrar y corregir vulnerabilidades más rápidamente, sino que aprenden con la práctica a partir de recursos de confianza y orientaciones del tamaño de un bocado para mejorar sus habilidades y reforzar la seguridad como un componente crítico del ciclo de vida del desarrollo de software. 

¿Quiere saber más? 

• Vea nuestros seminarios web Product Talk para conocer todas nuestras interesantes integraciones en SCW
• Vea la demostración de Okta 
• Ver la demostración de GitHub
• Pruebe gratis Secure Code Warrior 

Hoy en día, casi todos los equipos de desarrollo emplean algún tipo de formación en materia de cumplimiento normativo, ya sea como parte de un proceso de certificación inicial utilizado para garantizar que una empresa se mantiene dentro de los límites de los marcos del sector o de la normativa gubernamental, o como parte de un requisito o revisión anual. Es un paso importante, porque si una organización no puede cumplir los requisitos básicos de cumplimiento, sus trabajadores no pueden desempeñar sus funciones de forma realista.

Las normas de cumplimiento existen por una razón, porque cualquier persona que trabaje en el campo que cubren esas normas debe tener al menos una comprensión fundamental de todos los procesos y procedimientos pertinentes, así como de cualquier ley aplicable.

Aunque la formación en materia de cumplimiento es importante, completar los requisitos mínimos obligatorios no garantiza la verdadera seguridad de las aplicaciones. Esto es especialmente cierto para los desarrolladores que intentan integrar las habilidades de codificación segura en su flujo de trabajo diario. Casi todos los desarrolladores reciben algún tipo de formación sobre el cumplimiento de la normativa y, sin embargo, cuando se les encuestó, el 67% admitió que a menudo dejaban vulnerabilidades en su código.

¿Por qué?

Por segundo año, Secure Code Warrior realizó la encuesta "The state of developer-driven security survey, 2022" en colaboración con Evans Data Corp en diciembre de 2021. Encuestamos a 1200 desarrolladores de todo el mundo para conocer las habilidades, percepciones y comportamientos en lo que respecta a las prácticas de codificación segura, así como su impacto y relevancia percibida en el ciclo de vida del desarrollo de software (SDLC).

En cuanto a las razones por las que la formación sobre el cumplimiento de la normativa no consigue mejorar la seguridad de los programas informáticos, es una cuestión de la que llevamos hablando mucho tiempo. La reciente encuesta simplemente pone de manifiesto este problema.

Por un lado, se pide a los desarrolladores que asuman nuevas funciones incluyendo la ciberseguridad en todo el proceso de desarrollo de software, incluso cuando escriben inicialmente el código de las aplicaciones y programas. Pero escribir código seguro, o incluso simplemente aprender todo sobre los problemas de ciberseguridad y las vulnerabilidades que podrían afectarlo, no es una tarea fácil.En la encuesta, el 63% de los desarrolladores dijo que escribir código seguro era una tarea difícil.

La dificultad de escribir código seguro no debería ser una sorpresa. Hay una razón por la que tantos puestos de trabajo de ciberseguridad bien pagados no se cubren, con más de 3,5 millones de vacantes en todo el mundo según el último recuento. Si fuera un trabajo fácil, todo el mundo se lanzaría a ese campo. Aprender a combatir las amenazas y eliminar las vulnerabilidades dentro del código es difícil, y el panorama de las amenazas cambia constantemente. La formación estática sobre el cumplimiento de la normativa o las clases únicas no pueden seguir el ritmo ni proporcionar el tipo de educación que necesitan los desarrolladores. Puede marcar una casilla en términos de cumplimiento, pero no puede proporcionar garantías reales de seguridad de las aplicaciones para su organización o permitir a los desarrolladores escribir código seguro, o las habilidades para encontrar y corregir las vulnerabilidades del código.

El cumplimiento y la formación en seguridad son importantes, pero diferentes

Las organizaciones deben empezar a darse cuenta y reconocer lo que la formación en materia de cumplimiento puede hacer, y lo que no. No abandone la formación en materia de cumplimiento, especialmente si es obligatoria por ley. Y sobre todo porque (incluso con los métodos de formación actuales) el 92% de los encuestados declaró que necesitaba al menos algo de formación en cuestiones relacionadas con el cumplimiento o los marcos de seguridad, y el 50% subrayó la necesidad de una formación importante en materia de cumplimiento.

Entre los marcos de cumplimiento que más les interesan para formarse están los específicos de varios sectores, aunque también figuran en la lista varios marcos generales de ciberseguridad. Entre ellos se encuentran el Marco de Seguridad CIS, PCI DSS, el OWASP Top 10, MISRA C, ISO/IEC, la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) y otros.

Así que sí, forme en esos marcos, pero entienda que marcar una casilla en la formación de cumplimiento no equivale a proporcionar una base para la creación continua de código seguro.

En su lugar, considere la formación en materia de cumplimiento como parte de una oportunidad continua para ampliar las habilidades de codificación segura de sus desarrolladores, que pueden repetirse fuera del ciclo de cumplimiento, de modo que puedan crear y publicar software seguro todos los días. Cambie la prioridad de lograr el cumplimiento a permitir que los equipos de desarrollo codifiquen de forma segura con un aprendizaje continuo. Si invierte tiempo y recursos en la capacitación de los desarrolladores, los ejercicios o exámenes anuales de cumplimiento se convertirán en un juego de niños para que su personal los apruebe y los complete, mientras se beneficia de una mayor productividad en general.

¿Cómo se puede dar el paso a la seguridad impulsada por los desarrolladores?

Los desarrolladores afirmaron mayoritariamente que la formación era valiosa, pero se mostraron disconformes con el tipo de formación que han recibido en materia de codificación segura a lo largo de los años. Los desarrolladores dijeron que querían que se hiciera más hincapié en la formación práctica con ejemplos del mundo real que fueran relevantes para sus trabajos (30%). El 26% de los encuestados también considera que es fundamental una mayor interactividad, especialmente si pueden practicar la escritura de código seguro como parte de esos ejercicios.

El 23% de los desarrolladores encuestados consideró importante recibir una formación más guiada, centrada en las vulnerabilidades específicas con las que era más probable que se encontraran en su industria o sector, mientras que el 22% quería ver más ejemplos de vulnerabilidades del mundo real en su formación courses.

Está claro que limitarse a impartir una formación estática y no interactiva (que suele ser la experiencia de la formación en materia de cumplimiento) tiene poco valor en términos de habilidades de seguridad repetibles para los desarrolladores. En su lugar, las organizaciones deberían centrarse en cosas como la formación "justo a tiempo", en la que se enseña a los desarrolladores sobre seguridad a medida que trabajan. Incluso se podría considerar la posibilidad de implementar un programa de aprendizaje por niveles.

Con un enfoque escalonado, los temas más amplios suelen dividirse en experiencias de aprendizaje o conceptos discretos. A medida que los desarrolladores progresan, los conceptos más avanzados se superponen a los que ya dominan, al igual que se construye un andamiaje físico a medida que un edificio crece. Se trata de un método probado para enseñar un tema difícil y en constante evolución como la ciberseguridad, dividiéndolo primero en trozos más pequeños y menos complejos y luego construyendo más complejidad sobre esa base.

Sea cual sea el enfoque que le dé a su programa de habilidades de seguridad para desarrolladores, será clave mantenerlo separado de los ejercicios de cumplimiento. Tanto el cumplimiento como la formación en seguridad son importantes, y ambos requieren enfoques diferentes para lograr el éxito.

Para más información

Libro blanco: Los retos (y oportunidades) para mejorar la seguridad del software.

Libro blanco: El enfoque preventivo de los desarrolladores sobre la seguridad del software.

Informe: El estado de la seguridad impulsada por los desarrolladores.

Una versión de este artículo apareció en Revista Infosecurity. Se ha actualizado y sindicado aquí.

‍

Hace unos años, hablábamos mucho de que la ciberseguridad es el Salvaje Oeste, y que había una necesidad desesperada de que más gente se preocupara por ella en general, por no mencionar el riesgo muy real para la vida que podían suponer muchos ciberataques. 

Si avanzamos hasta 2023, es agradable ver que se han hecho algunos progresos, especialmente a nivel gubernamental en muchos países influyentes. Para nosotros, sin embargo, el camino hacia un código realmente seguro y un software más seguro no tiene fin. La aparición del metaverso, el fenómeno digital del momento, añade una nueva y enorme superficie de ataque tanto para las vulnerabilidades a nivel de código como para la ingeniería social.

Y simplemente no estamos preparados para la batalla en este nuevo campo de juego que se nutre de humo y espejos.

La realidad mixta conlleva un mayor riesgo

A pesar de su actual condición de Sabor del Mes, el concepto de metaverso existe desde hace mucho tiempo. La plataforma en línea Second Life existe desde 2003 y da servicio a un nicho fiel con un universo en línea totalmente personalizable en el que los avatares de los usuarios interactúan mediante chat de voz y texto, se puede jugar y empresas como Adidas ofrecen tiendas virtuales oficiales. En el ámbito puramente lúdico, los juegos multijugador masivos en línea (MMO) como Fortnite y World of Warcraft ofrecen mundos extensos a sus jugadores y dependen cada vez más de las microtransacciones, es decir, de desembolsar dinero real por objetos virtuales. Solo Fortnite obtuvo 4.300 millones de dólares en ingresos por microtransacciones en sus dos primeros años en el mercado. 

Está muy claro que el concepto de metaverso no sólo ha llegado para quedarse, sino que también está a punto de recibir un empujón del tamaño de Mark Zuckerberg en la corriente principal. Se trata de una evolución apasionante de Internet -o al menos de las redes sociales y parte del comercio electrónico- tal y como la conocemos, pero la posibilidad de que se produzcan ciberataques y exploits dañinos es alucinante. 

La superficie de ataque del metaverso es de gran alcance y va mucho más allá del software basado en web, las API y las pasarelas de pago. Los elementos periféricos de los cascos y accesorios de realidad virtual también suponen una amenaza para los datos esenciales, ya que el software integrado en esos dispositivos es una alfombra roja muy cómoda para llegar a la cima si son vulnerables. 

Investigadores de seguridad de la Universidad de Rutgers revelaron a principios de este año "Face-Mic", el primer estudio de este tipo que examina cómo las funciones de comandos de voz de los cascos de realidad virtual podrían dar lugar a graves violaciones de la privacidad, conocidas como "ataques de escucha". El trabajo es fascinante, ya que muestra que los actores de amenazas podrían utilizar algunos cascos de realidad virtual (AR/VR) con sensores de movimiento incorporados para grabar gestos faciales asociados a la voz, lo que conduciría al posible robo de información sensible comunicada a través de controles activados por voz, incluidos datos de tarjetas de crédito y contraseñas. La raíz del problema parece ser la falta de autenticación del usuario. Dado que el acelerómetro y el giroscopio no requieren ningún permiso de acceso, los intrincados movimientos faciales, las vibraciones transmitidas por los huesos y las transmitidas por el aire podrían registrarse y utilizarse para deducir desde PIN bancarios hasta registros sanitarios muy restringidos, en función de los patrones del usuario. 

En el metaverso, cada movimiento que haces es un punto de datos, y si el acceso a ellos es posible a través de una seguridad de software laxa, el incentivo para que los atacantes prueben suerte es enorme. 

Los contratos inteligentes se enfrentan a adversarios (más) inteligentes

La metaeconomía exige descentralización, desmaterialización, flexibilidad y, por supuesto, seguridad sin concesiones. En este momento, hay microeconomías metaversas en crecimiento en varias comunidades de criptodivisas, como Shiba Inu. Para comprar bienes inmuebles virtuales y otros productos intangibles, se utilizan contratos inteligentes almacenados en la cadena de bloques.

Al mencionar "cadena de bloques", la mayoría de la gente normal (con un poco de conocimientos tecnológicos) lo entiende como un sistema seguro y anónimo para lo que se considera el futuro de la moneda digital. Sin embargo, hay un pequeño problema con eso: ninguna fortaleza en línea es impenetrable, y esos contratos inteligentes no son una excepción. Son esencialmente pequeños programas, y pueden ser pirateados.

Los contratos inteligentes son susceptibles de ser explotados gracias a unas cuantas vulnerabilidades bastante comunes, a saber, desbordamiento y subdesbordamiento de enteros, ataques de repetición y el (muy perjudicial) error centrado en la cadena de bloques que conduce a ataques de reentrada, el último de los cuales puede llevar a que un usuario se quede sin su saldo de criptomonedas almacenado. Todos estos ataques son posibles gracias a patrones de codificación deficientes que conducen a vulnerabilidades explotables y a fundamentos de diseño inseguros.

Esta tecnología se utilizará cada vez más, pero tal y como están las cosas hoy en día, nos va a costar encontrar suficientes desarrolladores conscientes de la seguridad para garantizar un metaverso seguro y a prueba de fallos. Las organizaciones deben comprender la magnitud de su participación en el metaverso, sobre todo si están en juego datos y divisas... y es difícil imaginar un escenario en el que no sea así.

Es un entorno no regulado, y tú eres (todavía) el producto

Como hemos visto en el cine, la televisión, Second Life y los videojuegos, un entorno metaverso nos permite ser quienes queramos. En un mundo virtual, las posibilidades sólo están limitadas por tu imaginación, y esa flexibilidad es un gran atractivo para los usuarios. Sin embargo, el inconveniente es que, a la escala planeada para algo como Meta, es demasiado vasto y descentralizado como para controlarlo de forma que sea hermético desde el punto de vista de la seguridad. Las estafas serán inevitables y los delincuentes cualificados tendrán aún más trabajo desde el punto de vista de la ingeniería social. 

Los datos confidenciales de los usuarios son el nuevo oro, y el metaverso tiene el potencial de ser la fuente de datos más rica y completa que hemos visto hasta la fecha, siempre que la adopción prevista vaya según lo previsto. Aunque cabe suponer que los programas informáticos relacionados con el metaverso cumplirán las normas reglamentarias y las medidas de conformidad vigentes, será necesario actualizarlos para que sean compatibles con un universo digital en rápida expansión y su economía. Para ello será fundamental que las organizaciones asuman la responsabilidad de la seguridad de sus contribuciones al metaverso, con un nivel de madurez de seguridad interna que garantice que todas las personas que trabajan en el software piensen en la seguridad y la apliquen en cada paso de su proceso, especialmente en la cohorte de desarrollo. 

Por qué la codificación segura será crucial para el éxito del metaverso

Por muy divertido que sea galopar por una dimensión digital sin ley, representado por un avatar que es todo lo que desearías ser en el mundo real, nunca debemos olvidar que detrás de cada "personaje" hay un ser humano. Y cuando están en juego los datos y las finanzas de personas reales, la cosa está muy lejos de ser un juego. 

En ciberseguridad, somos muy conscientes de que los errores tienen consecuencias que pueden ser realmente devastadoras, y la integridad de cada componente del metaverso no puede ser una ocurrencia tardía si queremos que la adopción generalizada y la confianza de los consumidores lleguen a buen puerto. 

Las organizaciones pueden empezar a planificarlo ahora haciendo un análisis realista de su madurez en materia de seguridad en assessment , haciendo hincapié en la mejora de los conocimientos de seguridad de los desarrolladores que trabajan activamente en el software. Como se desprende del estudio de la Universidad de Rutgers, el control de acceso no es más que una potente vulnerabilidad que puede dar lugar a una fuga de datos generalizada, y los desarrolladores conscientes de la seguridad estarían mucho mejor situados para sortear estos problemas a medida que se escribe el código, y mucho antes de que entren en el código comprometido. 

Apoyarse en la excusa de la escasez de competencias en ciberseguridad no va a funcionar después de una importante violación de datos en el metaverso, y tenemos las herramientas a nuestro alcance no sólo para hacerlo lo mejor que podamos, sino para elevar activamente los estándares de seguridad del software para siempre. Ahora es el momento de invertir en la formación de los arquitectos del metaverso y cosechar los beneficios de una reimaginación virtual de los productos y servicios tal y como los conocemos.

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y sindicado aquí.

‍

Todo el mundo ha visto en algún momento de su carrera uno de esos organigramas que definen quién depende de quién en una organización. A veces se denominan simplemente organigramas y son una herramienta útil para que la gente sepa quién trabaja para ellos y quiénes son sus jefes. Por ejemplo, en un organigrama típico, el jefe de un grupo de codificación puede depender del director de desarrollo de productos, que a su vez depende del vicepresidente de innovación. Y luego las líneas de autoridad continúan hacia arriba y hacia abajo en la estructura de la empresa. ¿Quién no ha mirado uno de esos organigramas para intentar encontrar su pequeño bloque personal en algún lugar?

No es de extrañar que a los humanos nos fascinen tanto la jerarquía y la estructura. Es lo que históricamente nos ha mantenido vivos como especie durante tanto tiempo, incluso en la antigüedad, cuando nos enfrentábamos a un mundo muy peligroso. Nunca fuimos las criaturas más fuertes ni las más rápidas, pero trabajábamos bien en equipo y cada uno sabía cuál era su lugar y su responsabilidad a la hora de mantener unida, viva y próspera a nuestra familia, tribu o grupo. El organigrama moderno es en realidad una prolongación de aquellos tiempos y de aquel antiguo éxito.

Pero hay algo que casi todos los organigramas tienen en común, independientemente del tamaño de la empresa o de otros factores. En su mayor parte, todos los componentes de esos organigramas son humanos o grupos de humanos. Aún no hemos llegado al punto en que las máquinas puedan supervisar a los humanos, así que, por ahora, los organigramas son un asunto exclusivamente humano. Pero, ¿nuestro software también necesita una jerarquía organizativa?

Por supuesto, no estoy sugiriendo que añadamos software a los organigramas de nuestras empresas. Nadie quiere tener una aplicación como jefe. ¿Cómo le pedirías un aumento? Pero el panorama de amenazas al que se enfrentan nuestras aplicaciones y programas hoy en día no es muy distinto del peligroso entorno al que se enfrentaban nuestros antiguos parientes humanos hace mucho tiempo. Ayudando a definir las responsabilidades de nuestras aplicaciones y programas dentro de una jerarquía estricta, y aplicando esas políticas con el menor privilegio, podemos asegurarnos de que nuestras aplicaciones y programas también sobrevivan y prosperen a pesar del devastador y duro panorama de amenazas que se les presenta.

Los ataques a aplicaciones y programas informáticos alcanzan su máximo histórico

Para entender la necesidad de crear mejores jerarquías organizativas para el software, es importante comprender primero el panorama de las amenazas. Hoy en día, los atacantes, y los bots y el software automatizado que trabajan para ellos, buscan constantemente cualquier fallo en las defensas que puedan aprovechar. Y aunque se siguen lanzando ataques de phishing y de otro tipo contra humanos, los hackers más hábiles han trasladado la mayoría de sus esfuerzos a atacar software.

Y aunque todo el software está en el punto de mira, los ataques más exitosos se están realizando contra las interfaces de programación de aplicaciones, o API. Estas sencillas API son pequeñas piezas de software utilizadas por los desarrolladores para realizar una serie de pequeñas pero importantes tareas para sus aplicaciones y programas. A menudo son flexibles y únicas, y a veces incluso se crean sobre la marcha, según las necesidades del proceso de desarrollo.

Las API son ciertamente flexibles, pero también suelen tener demasiados permisos para sus funciones. Los desarrolladores tienden a darles muchos permisos para que puedan, por ejemplo, seguir funcionando aunque el programa que están ayudando a gestionar siga desarrollándose y cambiando. Pero eso significa que si un atacante los compromete, entonces obtienen mucho más que los derechos para acceder, por ejemplo, a una parte de una base de datos específica. Pueden incluso obtener derechos de casi administrador para toda una red.

No es de extrañar que varias empresas de investigación de seguridad afirmen que la inmensa mayoría de los ataques actuales de robo de credenciales se realizan contra software como las API. Akamai cifra esa cifra en el 75% del total, mientras que Gartner también afirma que las vulnerabilidades que afectan a las API se han convertido en el vector de ataque más frecuente. Y el informe más reciente de Salt Labs muestra que los ataques contra las API han aumentado casi un 700% en comparación con el año pasado.

Creación de un organigrama para software

Una de las formas en que las organizaciones están luchando contra las amenazas de robo de credenciales es aplicando el mínimo privilegio o incluso la confianza cero dentro de sus redes. Esto limita a los usuarios a recibir permisos apenas suficientes para realizar su trabajo o tareas. Ese acceso suele restringirse aún más por factores como la hora y la ubicación. De esta forma, incluso si un ataque de robo de credenciales tiene éxito, no servirá de mucho al atacante, ya que sólo tendrá permiso para realizar funciones limitadas durante un breve periodo de tiempo.

El mínimo privilegio es una buena defensa, pero normalmente sólo se aplica a los usuarios humanos. Tendemos a olvidar que las API también tienen privilegios elevados, y a menudo no están tan reguladas. Esta es una de las razones por las que un control de acceso defectuoso es ahora el enemigo público número uno según el Open Web Application Security Project (OWASP), que rastrea los patrones de los ciberataques. 

Es fácil decir que la solución a este problema crítico es simplemente aplicar el mínimo privilegio al software. Pero es mucho más difícil de aplicar. En primer lugar, hay que concienciar a los desarrolladores de los peligros. Y luego, de cara al futuro, las API y demás software deben situarse oficialmente, o al menos preverse, como parte de un organigrama dentro de la red informática en la que residirán. Por ejemplo, si una API debe obtener datos de vuelos en tiempo real como parte de una aplicación de reservas, no hay razón para que también pueda conectarse con los sistemas de nóminas o finanzas. En el organigrama del software, no habría líneas directas, ni siquiera discontinuas, que conectaran esos sistemas.

Probablemente sea poco realista para los desarrolladores crear un organigrama que muestre los miles o incluso millones de APIs que operan en su organización. Pero ser conscientes del peligro que suponen y restringir sus permisos a lo estrictamente necesario para realizar su trabajo contribuirá en gran medida a detener los ataques desenfrenados de robo de credenciales a los que todo el mundo se enfrenta estos días. Comienza con la concienciación y termina tratando las API y el software con el mismo escrutinio que a los usuarios humanos.
‍

¿Quiere elevar su equipo de desarrollo? Navegue por los problemas de seguridad de las API y mucho más con nuestro ágil learning platform herramientas de seguridad ágiles y orientadas al desarrollador.

Los desarrolladores que crean el software, las aplicaciones y los programas que impulsan los negocios digitales se han convertido en el alma de muchas organizaciones. La mayoría de las empresas modernas no podrían funcionar (de forma rentable), sin aplicaciones y programas competitivos, o sin acceso las 24 horas del día a sus sitios web y otras infraestructuras.

Sin embargo, estos mismos puntos de contacto suelen ser la puerta de entrada que los hackers y otros usuarios malintencionados emplean para robar información, lanzar ataques y dar paso a otras actividades delictivas como el fraude y el ransomware. El último informe de Verizon sobre investigaciones de fugas de datos destaca que las amenazas que se ciernen sobre las empresas y organizaciones son hoy más peligrosas y costosas que en cualquier otro momento de la historia.

Los ataques exitosos siguen siendo frecuentes, a pesar de que el gasto en ciberseguridad en la mayoría de las organizaciones ha aumentado, y a pesar de que movimientos como DevSecOps están desplazando la seguridad hacia los desarrolladores que son el alma de las empresas hoy en día.

Los desarrolladores comprenden la importancia de la seguridad y desean mayoritariamente desplegar un código seguro y de calidad, pero las vulnerabilidades del software siguen siendo explotadas.

¿Por qué?

Por segundo año, Secure Code Warrior realizó la encuesta The state of developer-driven security, 2022 en colaboración con Evans Data Corp en diciembre de 2021. Encuestamos a 1200 desarrolladores de todo el mundo para conocer las habilidades, percepciones y comportamientos en lo que respecta a las prácticas de codificación segura, así como su impacto y relevancia percibida en el ciclo de vida del desarrollo de software (SDLC).

La encuesta detectó la ausencia de una definición clara o una comprensión de lo que constituye un código seguro. Resulta que hay una gran discrepancia entre lo que los desarrolladores piensan que es un código seguro y lo que es realmente.

No es de extrañar que la escritura de código de calidad sea una de las principales prioridades de la comunidad de desarrolladores, pero cuando se les preguntó específicamente por el código seguro, sólo el 29% dijo que se priorizaba la práctica activa de escribir código libre de vulnerabilidades. En cambio, los desarrolladores asociaron prácticas menos seguras y mucho menos fiables a la creación de código seguro. Por ejemplo, el escrutinio del código existente (37%) y la confianza en bibliotecas de origen externo para obtener código seguro (37%) fueron las principales prácticas que los desarrolladores asociaron con la codificación segura. Reutilizar el código que ya se ha considerado seguro (32%) fue otra de las opciones más populares. La práctica activa de escribir código libre de vulnerabilidades ocupó el sexto lugar, con un 29% que declaró que era una práctica principal en la creación de código seguro. Cuando se les preguntó más a fondo, la falta de tiempo y la falta de un enfoque cohesivo por parte de la dirección se declararon como los principales obstáculos para crear código seguro.

La confianza en el código existente es uno de los factores que aumenta el riesgo de que el software se distribuya con vulnerabilidades explotables. Es necesario abordar esta desconexión de lo que constituye un código seguro para que los desarrolladores creen un código de calidad que también sea seguro.

Resulta que hay una gran discrepancia entre lo que los desarrolladores piensan que es un código seguro, y lo que es realmente un código seguro.

¿Qué pueden hacer las organizaciones para arreglar la situación?

Uno de los mensajes predominantes de la encuesta fue que la comunidad de desarrolladores en su conjunto está formada por personas profesionales que se preocupan por lo que hacen. Escribir un código de máxima calidad era abrumadoramente importante para ellos como grupo. El problema es que, en muchos casos, las organizaciones para las que trabajan no han identificado las mejores prácticas necesarias para producir código seguro, y no han dedicado suficientes recursos a la formación o han capacitado a sus desarrolladores para alcanzar esos objetivos.

De hecho, la mayoría de los desarrolladores afirmaron que sus organizaciones ni siquiera tenían una definición clara de lo que constituye un código seguro. Uno de los ejemplos más preocupantes es que el 28% de los encuestados afirmó que su organización consideraba que el código era seguro si no se denunciaba ninguna infracción una vez que la aplicación o el programa se desplegaba en un entorno de producción o se ponía a disposición del público.

Probablemente no hace falta decirlo, pero en el complejo panorama actual de las amenazas, limitarse a esperar buenos resultados sin trabajar realmente para conseguirlos probablemente producirá resultados predecibles: aún más violaciones de la seguridad.

Afortunadamente, se trata de una situación en la que es relativamente fácil, al menos, empezar a solucionar el problema y comenzar a trabajar para conseguir el objetivo de un código seguro. El primer paso, y posiblemente el más importante, es que las organizaciones definan lo que consideran código seguro. Y todo lo que esté fuera de esa definición debe ser considerado como no seguro.

La codificación segura debería definirse como la práctica de los desarrolladores cualificados de escribir código libre de vulnerabilidades, desde el inicio del SDLC. Solo una vez definida esta práctica, la comunidad de desarrolladores puede trabajar en pos de ese objetivo.

Hacer realidad el objetivo de un código seguro

Una vez establecida la definición de código seguro, las organizaciones deben estar preparadas para apoyar esos esfuerzos y a sus desarrolladores que llevarán a cabo el objetivo de implementar prácticas de código totalmente seguro. Ese apoyo es fundamental. Sin él, la definición de código seguro dentro de su organización, aunque importante, será poco más que un tigre de papel. Las prácticas de código seguro deben ser respaldadas por la dirección y recibir la consideración, la autoridad y el presupuesto adecuados para que tengan éxito.

Esto puede requerir nuevos objetivos de evaluación comparativa para los desarrolladores, que tradicionalmente se han medido por la velocidad de su codificación. De hecho, el 37% de los desarrolladores que participaron en la encuesta declararon haber dejado vulnerabilidades conocidas dentro de su código porque los plazos ajustados no les permitían disponer del tiempo necesario para solucionarlas, o para codificar correctamente desde el principio.Al principio, esto puede significar aumentar los plazos para dar a los desarrolladores más tiempo para codificar correctamente, aunque ese gasto de tiempo al principio del proceso de codificación probablemente se recuperará más tarde debido a la menor necesidad de revisiones del programa, parches y trabajo posterior a la implantación. Y eliminar la posibilidad de una brecha una vez desplegada puede acabar ahorrando cientos de horas y la posibilidad de millones en pérdidas de ingresos, multas y costes de limpieza.

Los desarrolladores también necesitarán una formación pertinente y práctica, especialmente en lo que respecta a las vulnerabilidades específicas con las que probablemente se encuentren, y ayuda para aprender a identificar y corregir las vulnerabilidades del código. Esto es especialmente cierto a la luz del 36% de los encuestados que dijeron que querían eliminar las vulnerabilidades de su código, pero no tenían las habilidades o el conocimiento para hacerlo.

El 37% de los desarrolladores que participaron en la encuesta declararon haber dejado vulnerabilidades conocidas dentro de su código porque los plazos ajustados no les permitían disponer del tiempo necesario para solucionarlas, o para codificar correctamente desde el principio.

¿Le interesa saber más sobre este tema?

Libro blanco: Los retos (y las oportunidades) para mejorar la seguridad del software.
Informe: Encuesta sobre el estado de la seguridad impulsada por los desarrolladores, 2022.

Recientemente, un equipo de investigadores de seguridad ha anunciado el hallazgo de un fallo de hace quince años en la funcionalidad de extracción de archivos tar de Python. La vulnerabilidad fue revelada por primera vez en 2007 y rastreada como CVE-2007-4559. Se añadió una nota a la documentación oficial de Python, pero el fallo en sí quedó sin parchear.

Esta vulnerabilidad podría afectar a miles de proyectos de software y, sin embargo, mucha gente no está familiarizada con la situación o con cómo manejarla. Por eso, aquí en Secure Code Warriorte damos la oportunidad de simular la explotación de esta vulnerabilidad para que veas el impacto de primera mano y adquieras experiencia práctica en la mecánica de este error persistente, ¡para que puedas proteger mejor tu aplicación!

Pruebe ahora la Misión simulada.

La vulnerabilidad: el cruce de rutas durante la extracción de archivos tar

El cruce de rutas o directorios se produce cuando se utiliza una entrada de usuario no saneada para construir una ruta de archivo, lo que permite a un atacante acceder y sobrescribir archivos, e incluso ejecutar código arbitrario. 

La vulnerabilidad existe en el módulo tarfile de Python. Un archivo tar (archivo de cinta) es un archivo único, llamado archivo. Agrupa múltiples archivos junto con sus metadatos, y normalmente se reconoce por tener la extensión .tar.gz o .tgz. Cada miembro del archivo puede ser representado por un objeto TarInfo, que contiene metadatos, como el nombre del archivo, la hora de modificación, la propiedad, etc.

El riesgo surge de la capacidad de los archivos para ser extraídos de nuevo.

Al ser extraído, cada miembro necesita una ruta para ser escrito. Esta ubicación se crea uniendo la ruta base con el nombre del archivo: 

Una vez creada esta ruta, se pasa a la función tarfile.extract o tarfile.extractall para realizar la extracción: 

El problema aquí es la falta de sanitización del nombre del archivo. Un atacante podría cambiar el nombre de los archivos para incluir caracteres de cruce de ruta, como la barra de puntos (../), lo que haría que el archivo saliera del directorio en el que debía estar y sobrescribiera archivos arbitrarios. Esto podría llevar eventualmente a la ejecución remota de código, lo cual es propicio para su explotación. 

La vulnerabilidad aparece en otros escenarios, si se sabe identificar. Además del manejo de archivos tar por parte de Python, la vulnerabilidad existe en la extracción de archivos zip. Puede que estés familiarizado con esto bajo otro nombre, como la vulnerabilidad zip slip, ¡que se ha manifestado en otros lenguajes además de Python!

ENLACE A LA MISIÓN 

¿Cómo se puede mitigar el riesgo?

A pesar de que la vulnerabilidad se conoce desde hace años, los mantenedores de Python consideran que la funcionalidad de extracción hace lo que se supone que debe hacer. En este caso, algunos pueden decir que "es una característica, no un error". Por desgracia, los desarrolladores no siempre pueden evitar extraer archivos tar o zip de una fuente desconocida. Depende de ellos sanear la entrada no confiable para prevenir las vulnerabilidades de cruce de rutas como parte de las prácticas de desarrollo seguro.

¿Quiere saber más sobre cómo escribir código seguro y mitigar los riesgos con Python?

Pruebe gratis nuestro reto de Python.

Si está interesado en obtener más directrices de codificación gratuitas, consulte Secure Code Coach, que le ayudará a mantenerse al tanto de las prácticas de codificación seguras.

‍

‍

Secure Code Warrior está profundamente comprometida a ayudar a educar a la comunidad de desarrolladores y de seguridad sobre cómo escribir código de forma segura, así como a mitigar el riesgo de vulnerabilidades introducidas a través de código inseguro. Como parte de este objetivo, utilizaremos la historia en desarrollo del reciente incidente de seguridad de Uber como una oportunidad para discutir la importancia de la seguridad impulsada por los desarrolladores y el cambio de la izquierda.

Incidente de seguridad en Uber

Uber publicó un comunicado sobre el incidente de ciberseguridad el 16 de septiembre y siguen actualizándolo. Los lectores deben tener en cuenta que esta es una historia en curso. Recapitulemos lo que hemos aprendido a través del anuncio de Uber hasta el momento y de otras publicaciones reputadas en la comunidad de seguridad. 

El hacker comenzó con la ingeniería social de un empleado de Uber, después de haber encontrado su número de What'sApp. El atacante se puso en contacto con ellos y comenzó a suplantar sus credenciales haciendo que el empleado desprevenido iniciara sesión en un sitio falso de Uber y luego capturando su nombre de usuario y contraseña. 

Las cuentas de Uber están protegidas a través de la autenticación multifactor (MFA), lo que significa que, además de enviar una contraseña, el usuario debe presentar una segunda prueba que confirme su identidad. En la mayoría de los casos, se trata de un aviso enviado a un dispositivo móvil. 

Tras obtener las credenciales, el atacante inició un ataque de fatiga MFA intentando continuamente iniciar sesión en el sitio genuino de Uber, y abrumando al empleado con numerosas notificaciones push en su dispositivo. De nuevo, el atacante se puso en contacto con la víctima a través de WhatsApp. Esta vez, supuestamente, se hizo pasar por el servicio de asistencia informática y logró convencerles de que aceptaran.

Credenciales codificadas

La base de la brecha de seguridad de Uber fue un exitoso ataque de phishing. Una vez dentro, el intruso encontró recursos compartidos de red que contenían scripts de PowerShell. Uno de estos scripts contenía las credenciales codificadas de un usuario administrador, lo que llevó a comprometer los servicios internos de Uber, como AWS, G-Suite y los repositorios de código. El hacker también obtuvo acceso a la cuenta HackerOne de Uber. Según Uber, sin embargo, "todos los informes de errores a los que el atacante pudo acceder han sido remediados".

¿Tiene curiosidad por ver cómo se vería esta vulnerabilidad en el código? Pruebe nuestro desafío PowerShell de forma gratuita.

¿Qué tan comunes son estos tipos de ataques?

La ingeniería social como vector de ataque es difícil de defender, ya que el factor humano siempre se ha considerado la parte más débil de la ciberseguridad. El hackeo de Uber ha ilustrado claramente que las implementaciones de MFA pueden ser fácilmente burladas. La clave para evitarlo es crear más conciencia entre los empleados sobre el funcionamiento de los ataques de phishing. 

Lo que causó la exposición de los servicios internos de Uber, sin embargo, son el nombre de usuario y la contraseña del administrador que se encontraron en un script de PowerShell. La codificación de credenciales nunca es buena, ya que son legibles para cualquier desarrollador y, básicamente, para cualquiera que tenga acceso al código. 

Pero, de nuevo, ¡la concienciación es la clave! Los desarrolladores con una mentalidad centrada en la seguridad son más propensos a detectar vulnerabilidades, y menos a escribirlas.

Un enfoque doble de educación general sobre ingeniería social y, más concretamente, de formación proactiva en codificación segura, reducirá el número de vulnerabilidades en una base de código y, por tanto, resultará fundamental en la lucha contra las amenazas a la seguridad.

¿Quiere saber más sobre cómo mantenerse al día con las mejores prácticas de codificación segura? Consulte Secure Code Coach. Aquí puede aprender las directrices de codificación segura y probar ejercicios de formación de forma gratuita.  

El mundo está cambiando rápidamente, no importa la empresa o el producto, las cosas son cada vez más digitales y dependientes del software. Los desarrolladores envían el código más rápido que nunca, pero el 75% del código sigue siendo revisado y marcado por los equipos de AppSec en busca de vulnerabilidades comunes y fácilmente prevenibles. 

No dar prioridad al código seguro y a la seguridad como parte fundamental del proceso de desarrollo de software entraña enormes riesgos. De hecho, el coste medio global de la violación de datos ha aumentado este último año hasta los 4,35 millones de dólares(IBM Cost of a Data Breach Report 2022). Los desarrolladores necesitan una formación atractiva e innovadora para estar al día con las nuevas amenazas y un cambio de cultura para cambiar la mentalidad orientada a la seguridad que se deja en colaboración con el equipo de seguridad.

En Secure Code Warrior innovamos constantemente para ayudar a equipar a los desarrolladores y a las organizaciones con las habilidades adecuadas para hacer frente a los cambiantes desafíos de seguridad de hoy en día. Lo hacemos a través de programas de formación muy atractivos, flexibles y fáciles de gestionar. 

Este último trimestre nos hemos centrado en la creación de nuevas formas de aprender con Coding Labs (recientemente disponible en la vista previa), hemos habilitado una integración LMS SCORM y hemos creado experiencias de usuario más accesibles e inclusivas, todo ello mientras simplificamos la experiencia de administración para ayudar a ahorrar tiempo. 

Vamos a sumergirnos para saber más.

Anunciamos Coding Labs - Aprendizaje de alto nivel

En una reciente encuesta del sector(The State of Developer-Driven Security Report 2022), el 40% de los desarrolladores afirmaron que su formación no era lo suficientemente práctica. Coding Labs ayuda a los desarrolladores a mejorar sus habilidades de codificación segura mediante una formación práctica con codificación real y comentarios intuitivos, todo ello dentro de un IDE familiar y potente en el navegador, lo que facilita más que nunca el paso del aprendizaje a la práctica.

En lugar de encontrarse con una guía poco clara y frustrante de "correcto o incorrecto", los desarrolladores también pueden estar seguros de que están aprendiendo de la manera correcta y mejorar su comprensión con comentarios en tiempo real y en contexto. Coding Labs apoya los objetivos de los desarrolladores de prevenir las vulnerabilidades de seguridad y mejorar la postura de seguridad de su organización.

Como parte de la plataforma SCW, esta nueva experiencia aporta una nueva perspectiva a la capacitación de los desarrolladores. Los líderes pueden crear un programa de formación que prepare a los desarrolladores para el éxito, con un aprendizaje accesible y de tamaño reducido que se adapte al desarrollador donde se encuentre. Entrene a las personas a través de una nueva vulnerabilidad con una formación guiada accesible para llegar a experiencias más desafiantes y prácticas como los Coding Labs. Los líderes pueden estar seguros de que los desarrolladores encontrarán la formación más atractiva, más fácil de retener, y en última instancia, aplicar a la base de código para reducir las vulnerabilidades y retrabajo. 

Coding Labs ya está disponible en la versión preliminar. Si es cliente de SCW, póngase en contacto con su gestor de cuentas para obtener más información sobre el acceso.

¿No es cliente de SCW pero quiere estar al tanto de la disponibilidad de Coding Labs? Rellene el formulario aquí.

Únase a SCW para conocer las innovaciones de nuestros productos y ver una demostración de Coding Labs. Regístrese en el seminario web aquí.

Integre la formación en código seguro con su SCORM LMS preferido 

Próximamente, los administradores de SCW podrán gestionar más fácilmente su programa de formación en código seguro junto con sus otras plataformas de formación, sin necesidad de un esfuerzo de desarrollo manual. Esto ahorrará tiempo y ayudará a los administradores a centrarse en formas más impactantes de mejorar sus programas de formación. 

Si no está familiarizado, SCORM significa Sharable Content Object Reference Model y es un estándar internacional para e-courses. Si su curso está publicado en el formato SCORM, puede estar seguro de que casi cualquier sistema de gestión del aprendizaje (LMS) lo reconocerá.

Con la nueva integración de SCORM LMS, puede:

• Incorpore la formación con código seguro directamente en su LMS preferido para gestionar los participantes y las tareas en un solo lugar
• Seguimiento del progreso y la finalización de su organización

‍

Asegúrese de que su programa SCW está integrado directamente en el flujo de trabajo de sus desarrolladores preferidos para mejorar las experiencias de los usuarios. Los paquetes SCORM pueden descargarse para Courses y Assessments, proporcionando una perfecta integración LMS con plataformas populares como SAP SuccessFactors, Workday, Cornerstone, y más.

La integración de LMS SCORM estará disponible para los clientes en la vista previa en octubre, póngase en contacto con su gerente de cuenta para obtener más información. 

Ampliación de la amplitud y profundidad de la plataforma SCW 

Secure Code WarriorLa continua expansión de nuestros contenidos ayuda a mantener nuestros módulos relevantes, oportunos y adaptados a lo que usted necesita saber en el panorama actual de la ciberseguridad. Con una amplitud y profundidad líderes en la industria de más de 55 lenguajes, es fácil construir y escalar un programa para capacitar a los desarrolladores en un gran número de lenguajes y marcos. 

Asegure las aplicaciones ABAP con los nuevos contenidos de formación

Sobre la base de nuestro lanzamiento en la primavera, estamos encantados de lanzar nuevas formas de formación para los desarrolladores que codifican en ABAP con 6 nuevos recorridos y 14 missions.

Acceda a una educación flexible y diversa con nuevos retos y contenidos 

Secure Code Warrior se esfuerza por publicar continuamente contenidos que se ajusten a diversos niveles de habilidad, manteniendo nuestros módulos de formación relevantes y desafiantes. Este trimestre, SCW ha publicado más contenido para lenguajes de codificación populares como:

• 33 retos extra de RPG, una de las principales peticiones de los clientes
• La posibilidad de crear un tournaments en RPG  
• 10 retos adicionales de Python Django

Todos los nuevos contenidos ya están disponibles en los grupos de desafíos para jugar en la plataforma.

Simplificación de la experiencia del administrador y del usuario

Configurar un programa de formación en código seguro, escalable y atractivo, es ahora más fácil que nunca gracias a las mejoras de usabilidad de la plataforma.

Editar fácilmente un curso publicado 

Manténgase al día con las necesidades siempre cambiantes de su organización y programa de formación con nuevas formas de editar los programas existentes. El versionado de cursos permite a los administradores editar sus courses existentes sin tener que crear un nuevo curso. Esta fue una de las características más solicitadas por los clientes.

Las actualizaciones incluyen:

• Añadir nuevos idiomas a un curso publicado
• Añadir/actualizar/eliminar módulos y contenidos de actividades en el curso 
• Añadir/actualizar/borrar actividades de fin de curso 
• La plataforma guardará una versión mayor de un curso para crear un versionado básico 

Acceda a Courses desde la pantalla de inicio

La adición de un botón "Continuar" en la nueva página de inicio muestra una lista de tarjetas de actividad para ayudar a los usuarios a reanudar rápidamente los módulos que han comenzado previamente. Los usuarios también podrán ver una ventana en la pantalla de inicio para ver los módulos no completados

Esto permite a los usuarios retomar efectivamente el curso donde lo dejaron si tienen que pausar un curso o assessment, sin perder nada de su progreso.

‍

Ambas funciones están disponibles para las cuentas que han habilitado el acceso temprano en la plataforma. Póngase en contacto con su gestor de cuenta para cualquier pregunta sobre el acceso.

Diseño inclusivo y accesible 

En Secure Code Warrior creemos que el lenguaje y el diseño tienen el poder de construir puentes y aumentar la comprensión, conectando a diversos grupos de usuarios bajo nuestra misión de defender la codificación segura. Nuestro objetivo es crear y ofrecer una experiencia inclusiva y accesible, y estamos muy contentos de seguir avanzando en el diseño accesible.

Ya está disponible el chino tradicional 

Con la incorporación del chino tradicional a los idiomas de la plataforma, seguimos construyendo una comunidad verdaderamente global de desarrolladores que pueden acceder a las herramientas que necesitan para convertirse en campeones de la seguridad. 

Puedes acceder a los idiomas desde el menú desplegable de los ajustes. El chino tradicional también está disponible con subtítulos de vídeo en nuestra sección de recursos.

Únase al seminario web ProductTalk el 5 de octubre de 2022. 

¿Quiere saber más? Únase a nuestro seminario web ProductTalk el 5 de octubre de 2022 para que los miembros de nuestros equipos de productos le informen de las interesantes actualizaciones y nuevas funciones, y conozca el cambiante panorama de la seguridad impulsada por los desarrolladores. 

Inscríbase en el seminario web aquí.

¿Está interesado en probar Secure Code Warrior pero aún no tiene una cuenta? Regístrese en una cuenta de prueba gratuita hoy mismo para empezar.

Con estoterminamos las novedades de este trimestre. Siga Secure Code Warrior en Twitter para obtener información actualizada sobre los últimos lanzamientos y mejoras.

En el clima económico actual y el panorama de las amenazas, ciertamente no envidio al CISO medio. Tienen la tarea de ofrecer seguridad, cumplimiento, innovación y valor empresarial, al tiempo que se enfrentan a una ardua batalla con presupuestos cada vez más reducidos y un mayor escrutinio. Tal vez sea más apremiante el hecho de que cada organización (y su respectivo equipo de desarrollo) se encuentra en diferentes etapas de madurez de seguridad, y no todos están equipados para dar lo mejor de sí en términos de ciberdefensa. 

La escalada de incidentes de ciberseguridad de los últimos años ha dificultado mucho que los responsables de seguridad vayan un paso por delante. Basta con echar un vistazo a algunos de los datos sobre nuestra creciente situación para ver que se trata de un polvorín: solo en 2023, los ciberdelincuentes robarán más de 33.000 millones de registros, lo que supone un aumento del 175% respecto a 2018. Se prevé que el coste de la ciberdelincuencia alcanzará los 10,5 billones de dólares en 2025, y el coste medio de una filtración de datos se ha disparado hasta los 4,24 millones de dólares (aunque solo tenemos que echar un vistazo a incidentes como los de Equifax o Solar Winds para ver que puede ser mucho peor). 

Como industria, llevamos mucho tiempo esperando que aparezca un héroe que nos rescate de los malos de la ciberseguridad que parecen tener más poder del que creíamos posible, incluso hace diez años. Estamos esperando a que más profesionales de la ciberseguridad se suban al carro y nos eleven a un nivel superior de programa de seguridad, pero es una brecha que no podemos cerrar. Estamos esperando la solución de herramientas de bala de plata que promete automatizarnos para alejarnos del riesgo creciente, pero no existe y es muy poco probable que exista. Estamos esperando que nuestro Luke Skywalker nos ayude a luchar contra el Lado Oscuro.

Resulta que la ayuda (y la esperanza) está en camino, en forma de Plan de movilización de la seguridad del software de código abierto. Sin embargo, todos debemos hacer un balance y evaluar honestamente si somos lo suficientemente maduros en nuestra organización -y si nuestros equipos de desarrollo tienen el nivel adecuado de conciencia y habilidades de seguridad- para implementar las últimas y mejores estrategias defensivas, especialmente cuando requieren el apoyo y la ejecución del equipo de desarrollo.

¿Qué es el plan de movilización de la seguridad del software de código abierto?

Este plan de diez puntos fue encabezado por la Open Source Software Foundation (OpenSSF) y la Linux Foundation, junto con funcionarios de la Casa Blanca, los principales CISO y otros altos dirigentes de 37 empresas tecnológicas privadas. Con este apoyo combinado, tanto en acciones como en financiación, el estándar de seguridad del software de código abierto va a ser mucho más fuerte. 

Lo que es especialmente interesante es su enfoque en la educación y certificación de base a nivel de desarrolladores, y las medidas diseñadas para racionalizar las actividades internas de la lista de materiales de software (SBOM). Ambas son notoriamente difíciles de implementar de una manera que tenga un impacto duradero, lo que puede atribuirse en parte a los dolores de crecimiento dentro de los programas de seguridad de la organización, y una falta general de madurez de seguridad entre la cohorte de desarrollo, sin culpa alguna. Se encuentran en un entorno de olla a presión en el que reina el volumen de código a gran velocidad, frente a plazos cada vez más irrazonables. Añadir aún más tareas en forma de peticiones de seguridad y mantenimiento de SBOM sin aumentar el tiempo disponible para ellas es una receta que ha fracasado antes de empezar, y tristemente, es más común de lo que podríamos esperar.

Así que, echemos un vistazo bajo el capó.

Certificación de seguridad para desarrolladores: ¿Hemos llegado ya a ese punto?

Si hay algo que sabemos con certeza es que los desarrolladores con conocimientos de seguridad siguen siendo un bien escaso. Esta es la realidad por una serie de razones, a saber, que hasta hace poco, los desarrolladores no formaban parte de la ecuación cuando se trataba de estrategias de seguridad de software dentro de las organizaciones. Si a esto le sumamos que los desarrolladores no tienen muchos motivos para dar prioridad a la seguridad (su formación es inadecuada o inexistente, lleva más tiempo, no forma parte de sus KPI y su principal preocupación es hacer lo que mejor saben hacer: crear funcionalidades), tenemos equipos de desarrollo que no están preparados para ocuparse realmente de la seguridad a nivel de código, ni para desempeñar su papel en un ciclo de vida de desarrollo de software (SDLC) modernizado y centrado en DevSecOps. 

Si nos fijamos en el Plan de Movilización de la Seguridad del Software de Código Abierto, la primera línea del plan de diez puntos se ocupa de las habilidades de seguridad de los desarrolladores, para "Ofrecer educación y certificación de desarrollo de software seguro de base para todos", que es esencial para construir la madurez de la seguridad en los equipos de desarrollo. Destacan los problemas que hemos discutido durante algún tiempo, incluyendo el hecho de que la codificación segura es MIA de la mayoría de la ingeniería de software courses en el nivel terciario. Es increíblemente alentador ver que esto es apoyado por individuos y departamentos que pueden cambiar el statu quo de la industria, y con el 99% del software del mundo que contiene al menos algo de código abierto, este ámbito de desarrollo es un gran lugar para empezar a centrarse en la formación de los desarrolladores en materia de seguridad.

El plan cita recursos venerables como los fundamentos del software seguro de la OpenSSF courses, y los amplios y antiguos recursos de la Fundación OWASP. Estos centros de información son inestimables. El despliegue propuesto para difundir estos materiales con el fin de capacitar a los desarrolladores implica reunir una amplia red de socios, tanto en el sector público como en el privado, además de asociarse con instituciones educativas para que el desarrollo seguro de código abierto sea una característica clave del plan de estudios. 

En cuanto a la forma de ganarse los corazones y las mentes de los ingenieros de software de todo el mundo, muchos de los cuales han visto reforzada la seguridad como algo que no es su trabajo ni su prioridad, el plan detalla una estrategia de recompensa y reconocimiento para dirigirse tanto a los desarrolladores que mantienen las bibliotecas de código abierto como a los ingenieros en activo que necesitan ver el valor de las certificaciones de seguridad. 

Sabemos por experiencia que los desarrolladores responden bien a los incentivos, y que los sistemas de distintivos por niveles que muestran el progreso y la habilidad funcionan tan bien en un entorno de aprendizaje como en algo como Steam o Xbox.

Sin embargo, lo que preocupa es que no estamos abordando uno de los problemas principales, y es la entrega de módulos de aprendizaje dentro del programa de seguridad de una organización. Al haber trabajado estrechamente con desarrolladores durante gran parte de mi carrera, sé lo escépticos que son cuando se trata de herramientas y formación, por no hablar de cualquier cosa que parezca que pueda interrumpir el trabajo que es la prioridad número uno. La capacitación de los desarrolladores requiere que se comprometan continuamente con el material del curso, y para que esto tenga éxito, tiene que tener sentido en el contexto de su trabajo diario.

Si consideramos un modelo de madurez establecido como el Modelo de Madurez de Aseguramiento del Software (SAMM), la "Educación y Orientación" es un componente central de la capa de Gobernanza, y hay un enfoque clave en la educación del desarrollador. El modelo en su totalidad es amplio, y hay pasos progresivos para alcanzar niveles más altos de madurez. Sin embargo, las etapas iniciales recomiendan sólo 1 ó 2 días de formación formal para los desarrolladores, lo que apenas es suficiente para arañar la superficie de la conciencia de seguridad. Incluso así, un informe reciente del Enterprise Strategy Group (ESG) reveló que menos de la mitad de las organizaciones exigen a los desarrolladores que participen en una formación formal sobre seguridad más de una vez al año. Nuestra propia investigación en conjunto con Evans Data reveló que sólo el 29% de los desarrolladores cree que se debe priorizar la práctica activa de escribir código libre de vulnerabilidades. Existe una clara desconexión entre la forma en que se imparte y se recibe la formación, y su utilidad real para lograr la madurez en materia de seguridad, especialmente si los desarrolladores no ven su valor.

Lista de materiales de software: ¿Este plan rompe las barreras de adopción?

Otra área que el plan pretende abordar es la calamidad que a menudo existe en torno a la creación y el mantenimiento de la lista de materiales de software (SBOM), con la corriente "SBOM Everywhere - Improve SBOM Tooling and Training to Drive Adoption" (SBOM en todas partes: mejorar las herramientas y la formación de SBOM para impulsar la adopción), que investiga formas de facilitar a los desarrolladores y a sus organizaciones la creación, actualización y uso de SBOM para impulsar mejores resultados de seguridad.

En la actualidad, los SBOM no están ampliamente adoptados en la mayoría de los sectores verticales, lo que dificulta el aprovechamiento de su potencial para reducir los riesgos de seguridad. El plan cuenta con una brillante estrategia para definir los estándares clave para la formulación de los SBOM, así como herramientas para facilitar su creación que se ajusten a la forma de trabajar de los desarrolladores. Sólo con esto se conseguiría disminuir la carga de otra tarea del SDLC para los desarrolladores, que ya están dando muchas vueltas para crear software a la velocidad de la demanda. 

Lo que me temo, sin embargo, es que en la organización media, las responsabilidades de seguridad pueden ser una verdadera zona gris para los desarrolladores. ¿Quién es el responsable de la seguridad? En última instancia, es el equipo de seguridad, pero los desarrolladores deben participar en el viaje si queremos su ayuda. Hay que definir claramente las tareas y las expectativas, y necesitan tiempo para asumir estas medidas adicionales de su éxito. 

Del OSS al resto del mundo del software

El Plan de Movilización de la Seguridad del Software de Código Abierto es ambicioso, audaz y exactamente lo que se necesita para impulsar la responsabilidad de los desarrolladores en materia de seguridad. Ha sido necesaria una "Alianza Rebelde" de algunos actores poderosos que se han unido, pero esto sirve como prueba de que estamos avanzando en la dirección correcta y dejando atrás la idea de que la brecha de habilidades de ciberseguridad se arreglará mágicamente. 

Es nuestra nueva esperanza, y nos va a hacer falta a todos para impulsar esta estructura más allá del OSS. Sin embargo, los profesionales de la seguridad deben mirar dentro de sí mismos, y analizar los equipos de desarrollo que trabajan en el código que tienen la tarea de proteger. Deben hacer un assessment honesto de sus capacidades actuales, donde están las lagunas, y trabajar para crear un estado maduro de última etapa que sea hermético, proactivo, e incluya un programa que imparta verdaderas habilidades de seguridad a la cohorte de desarrollo. Hasta que no estén significativamente habilitadas, es posible que todavía estemos un poco inmaduros en nuestro enfoque de las vulnerabilidades a nivel de código.

‍

>> Ponga a prueba la madurez de su equipo en materia de seguridad con nuestro desafío XSS práctico e interactivo.