Secure Code insights

Imagina crear algo desde cero, ejerciendo tus habilidades y experiencia con maestría para dejar una pequeña, pero especial, marca en el mundo. Ya sea solo o formando parte de un equipo, dedicas tu corazón y tu alma a construir algo de la nada. Dedicas cientos, tal vez incluso miles, de horas a ello, asegurándote de que tu bebé esté lo mejor posible. Al completarla, esa oleada de logros puede parecer una recompensa por sí sola.

Ahora, imagina que aparece un spoilsport y te dice que no es tan bueno. Quizás vayan un paso más allá y te digan que no, a pesar de la energía, el tiempo y el amor que has sacrificado, en realidad ni siquiera se puede usar: está roto. En esencia, te han dicho que tu bebé es feo.

El escenario anterior seguramente causará cierta tensión; después de todo, ¿quién quiere que su arduo trabajo sea desmentido y condenado por inadecuado? Lamentablemente, para muchos desarrolladores, esta puede ser la realidad de su relación con el equipo de AppSec. Un desarrollador tiene la responsabilidad principal de crear un software que sea funcional, rico en funciones y que se entregue dentro de los estrictos plazos del proyecto. La seguridad rara vez es la prioridad, e incluso puede considerarse un obstáculo para la entrega rápida y la innovación. AppSec tiene la poco envidiable tarea de comprobar meticulosamente el código, realizar pruebas con bolígrafos y, a continuación, informar de la mala noticia: la presencia de vulnerabilidades de seguridad en un código que, a menudo, ya está comprometido. Se trata de un proceso caro en un entorno en el que a menudo se agotan los recursos y el tiempo necesarios, ya que la configuración puede provocar desacuerdos entre dos equipos que tienen el mismo objetivo, pero que hablan idiomas tan diferentes que parecen estar en desacuerdo.

¿No crees que es hora de renovar la seguridad? Es tan simple como cambiar la conversación y hacer que todo sea un poco más positivo (¡sin mencionar que es divertido!) para ambas partes, especialmente para el equipo de desarrollo.

Fuera del aula, al campo de juego

Dado que muchos desarrolladores completan su formación profesional sin aprender mucho sobre programación de forma segura, suele ocurrir que su primer punto de contacto con la educación en seguridad es al entrar en el mundo laboral. La formación presencial es una solución que se utiliza con frecuencia, pero quita un tiempo precioso a la entrega de funciones (y, seamos sinceros: si el profesor y el contenido son poco estimulantes, puede ser una pérdida de tiempo fácil de olvidar para todos). También hay cursos en vídeo, exámenes en papel y cursos genéricos sobre políticas de seguridad empresariales... todo lo cual puede resultar tan poco específico que resulta inútil en la vida laboral diaria del desarrollador medio.

Con demasiada frecuencia, se trata como un ejercicio de cumplimiento de «marcar la casilla y seguir adelante» y, con demasiada frecuencia, tiene el efecto contrario: solo genera una brecha más amplia entre AppSec y el equipo de desarrollo. Al fin y al cabo, no parece que la formación convencional esté teniendo el efecto positivo en la cultura de seguridad y el cumplimiento que nosotros, como industria, buscamos con tanta urgencia. Seguimos cometiendo los mismos errores.

Según la enumeración de debilidades comunes (CWE) comunidad, hay más de 700 común debilidades de seguridad del software contra las que luchar. Algunas, como la inyección de SQL, son como cucarachas que no han sido aplastadas a pesar de su existencia desde hace más de veinte años. ¡Nosotros conocer cómo solucionarlo; la formación está ahí para que los desarrolladores puedan detenerlo y muchos otros, pero los procesos de revisión manual del código y pruebas con lápiz identifican continuamente estas infracciones.

Quizás lo hemos analizado todo mal y, como industria, necesitamos abordar la educación viable desde un ángulo diferente, uno que aproveche las increíbles habilidades que tanto valoran nuestros desarrolladores. Son solucionadores de problemas creativos e inquisitivos a los que les encantan los desafíos. Gamificar la formación en seguridad es hablar su idioma, permitirles practicar con la práctica y, quién sabe, es posible que al final se enamoren de la seguridad.

Un poco de competencia sana

La confianza en herramientas (bastante imprecisas), las costosas pruebas con lápiz y la escasez de especialistas en AppSec nos hundirán aún más en el agujero negro de la seguridad. Gran parte de nuestras vidas y de nuestra privacidad están en línea como para que las empresas sigan siendo cautelosas con las fortalezas virtuales que protegen nuestros datos. A medida que la transformación digital de nuestro mundo aumenta nuestra dependencia del software, necesitamos recurrir a los superhéroes que siempre hemos tenido en la oficina: el equipo de desarrollo.

La formación gamificada, en los lenguajes y marcos pertinentes, es una herramienta potente para que los administradores de AppSec comiencen a transformar la cultura de seguridad dentro de la empresa. A partir de la formación, los desarrolladores pueden poner a prueba sus habilidades de seguridad recién adquiridas en un entorno de torneo divertido, que puede resultar tan emocionante como lo imagine: basta con echar un vistazo a cómo El «Juego de códigos» de IAG tengo todos hablando sobre la seguridad dentro de su organización.

Código seguro: Warrior's módulo de torneo proporciona algo más que un pequeño límite a un compromiso de formación mesurado: es una plataforma desde la que cada desarrollador puede validar sus habilidades, ver cuánto ha avanzado desde que comenzó la formación e identificar las áreas que pueden necesitar mejoras. El aspecto competitivo realmente actúa como un motivador para comprometerse de manera positiva con la seguridad, utilizando la recompensa y el reconocimiento para apoyar el desarrollo de una cultura de seguridad sólida en el equipo y en la empresa en general.

Inyectar un poco de diversión en lo que puede considerarse una tarea laboriosa, si no abrumadora, puede contribuir en gran medida a cambiar las mentalidades negativas e inspirar una participación continua. Después de todo, ¿a quién no le gusta la gloria de conseguir más puntos que sus compañeros en un entorno competitivo (saludable)?

Los campeones caminan entre vosotros

La formación gamificada y los torneos posteriores ayudan enormemente a impulsar una cultura de seguridad positiva, ya que los equipos de AppSec y de desarrollo obtienen mucha más información sobre el trabajo diario de los demás. Un desarrollador seguro es un activo, ya que corrige las vulnerabilidades más comunes y deja que los problemas complejos se encarguen de los escasos especialistas en AppSec sobre el terreno. Las mejores relaciones crecen y prosperan, y el valioso presupuesto de seguridad no se agota solucionando el escenario del «Día de la Marmota» en el que se repiten los mismos errores una y otra vez.

Sin embargo, hay otro poderoso subproducto: la revelación de los campeones de seguridad que no sabías que tenías. Los torneos pueden descubrir a aquellos que no solo tienen aptitudes para la seguridad, sino que muestran una pasión por ella de forma activa. Estos campeones son fundamentales para mantener el impulso y actuar como punto de contacto entre los equipos, supervisar a los compañeros y defender las políticas de mejores prácticas. La implementación de un programa de promoción sólido, que incluya el reconocimiento y el apoyo de los ejecutivos, es un tanto a favor de la organización, además de un poderoso aporte para el currículum y la futura carrera profesional de la persona.

¿El resultado final? Debemos exigir mejores resultados en las pruebas de seguridad. Errores menos comunes, más apoyo para quienes están en primera línea. ¿Por qué no te das cuenta de cómo un torneo de desarrolladores puede ayudarte a conseguirlo antes de lo que crees?

Si un desarrollador escribe un error de secuencia de comandos entre sitios mientras está codificando en JavaScript y es capaz de detectarlo a los pocos minutos de haber creado ese error, es probable que solo necesite unos minutos o segundos para solucionarlo.

Mientras que si un comprobador manual descubre ese defecto dos semanas después, se introducirá en un sistema de seguimiento de defectos. Se va a clasificar. Se va a poner en la lista de errores de alguien.

Con el retraso en la identificación, habrá que investigarlo en su contexto original y ralentizará su desarrollo. Ahora, es posible que estés hablando de horas para corregir el mismo defecto. Tal vez se necesite una escala de 10 o 100 veces más tiempo

No podría estar más de acuerdo con Chris Wysopal (CTO de Veracode) en su reciente podcast con O'Reilly Security Podcast, donde explica por qué desplazar la seguridad hacia la izquierda (para los desarrolladores al principio del ciclo de vida del desarrollo) es clave en un entorno ágil para mantener el ritmo y la velocidad.

La seguridad debería facilitarse a los desarrolladores mediante el uso de complementos IDE y escáneres y educándolos para que adquieran las habilidades básicas de seguridad (higiene). Las organizaciones no deben confiar únicamente en expertos en seguridad o en un equipo de seguridad centralizado que valide todos los cambios.

Nuestro modus operandi de seguridad típico no funciona (¡llame a un experto!) y necesitamos integrar la seguridad en los equipos de desarrollo para garantizar que se mantenga la calidad sin dejar de ser ágiles.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

A medida que las ciberamenazas se vuelven cada vez más sofisticadas, las empresas de todos los tamaños deben evaluar y abordar de manera proactiva sus riesgos de ciberseguridad para proteger los datos confidenciales, mantener la confianza de los clientes y cumplir con los requisitos legales. Una comprensión integral de las posibles vulnerabilidades permite a las organizaciones tomar medidas específicas y asignar los recursos de manera eficaz, lo que minimiza las posibilidades de que se produzca un incidente perjudicial.

Evaluar los riesgos de ciberseguridad es una tarea compleja, dada la variedad de amenazas a las que puede enfrentarse su empresa, desde el malware hasta las prácticas de codificación inseguras y las filtraciones de datos. Al realizar evaluaciones periódicas de los riesgos de ciberseguridad, su empresa puede anticiparse a la evolución de las amenazas y asegurarse de que cuenta con las medidas necesarias para proteger sus activos. Veamos cómo su empresa puede llevar a cabo una evaluación de riesgos eficaz para identificar las debilidades y crear un marco de seguridad resiliente.

¿Qué es una evaluación de riesgos de ciberseguridad?

Una evaluación de riesgos de ciberseguridad es el proceso de identificar, evaluar y priorizar los riesgos para los sistemas de tecnología de la información de su organización. El objetivo de una evaluación de los riesgos de ciberseguridad es detectar las vulnerabilidades actuales y predecir las amenazas futuras, como los ataques por inyección o el uso de scripts entre sitios (XSS), para que su empresa pueda comprender el impacto potencial de esas vulnerabilidades y la mejor manera de mitigarlas. Muchos de estos problemas pueden abordarse antes de que causen daños graves mediante la implementación de prácticas de codificación seguras desde el principio del ciclo de vida de desarrollo de software (SDLC).

El panorama de la ciberseguridad cambia constantemente, con nuevas amenazas emergentes y la evolución de las existentes. Es por eso que las organizaciones deben realizar evaluaciones de riesgos con regularidad, en lugar de tratarlas como un ejercicio único.

El uso de un marco estructurado, como los estándares NIST (Instituto Nacional de Estándares y Tecnología) o ISO/IEC 27001, puede mejorar y agilizar las evaluaciones de riesgos de ciberseguridad al proporcionar un enfoque probado y bien definido. Estos marcos ofrecen directrices sobre las mejores prácticas para la identificación, la evaluación y la mitigación de los riesgos. Si bien su organización puede utilizar estos marcos como base, en muchos casos es mejor desarrollar una metodología personalizada que se adapte a sus necesidades específicas. Esto garantiza que la evaluación aborde los riesgos específicos de su industria o entorno operativo.

La importancia y los beneficios de las evaluaciones de riesgos de ciberseguridad

Los ciberataques plantean importantes riesgos organizativos en términos de pérdidas financieras y daños a la reputación. Por ejemplo, un ataque de ransomware puede costar millones a las empresas en tiempo de inactividad y costos de recuperación, mientras que una violación de datos puede provocar la pérdida de la confianza de los clientes y provocar multas reglamentarias. Cuanto más tiempo permanezca sin abordarse una vulnerabilidad, mayor será la probabilidad de que se produzca un ataque y mayores serán los costos asociados.

La realización de evaluaciones periódicas de los riesgos de ciberseguridad también permite a su empresa obtener una comprensión profunda y precisa de sus vulnerabilidades de seguridad de forma continua. De este modo, su empresa puede tomar decisiones más informadas sobre cómo invertir sus limitados recursos de ciberseguridad priorizando las vulnerabilidades en función de la gravedad y la probabilidad de un ataque.

Cómo realizar una evaluación de riesgos de ciberseguridad en 7 pasos

Realizar una evaluación de riesgos de ciberseguridad implica identificar, analizar y abordar los riesgos a los que se enfrenta su organización. Si bien hay pasos que se aplican a la mayoría de las evaluaciones de riesgos, es importante adaptar el proceso a las necesidades, el tamaño, el sector y los requisitos de seguridad específicos de la empresa. Este es un desglose de los pasos fundamentales que debe seguir su empresa.

1. Defina los objetivos y el alcance

En primer lugar, es necesario definir claramente los objetivos y el alcance de la evaluación de riesgos. Esto significa comprender lo que se pretende lograr con la evaluación y las áreas de su negocio que cubrirá. Este paso es fundamental porque sienta las bases de toda la evaluación. Un alcance bien definido evita que la evaluación sea abrumadora, lo que garantiza que se dediquen tiempo y recursos a evaluar lo que más importa.

Involucrar a los miembros del equipo de los departamentos pertinentes durante esta fase ayuda a garantizar que no se pase por alto ningún área esencial. Involucre a las partes interesadas clave de todos los departamentos, como el de TI, el legal, el de operaciones y el de cumplimiento, para delinear las áreas de mayor preocupación y establecer de manera colaborativa objetivos claros para la evaluación. A continuación, establezca un cronograma y un presupuesto para el proyecto a fin de evitar que se amplíe el alcance y mantener la concentración. Y asegúrate de no descuidar la formación sobre prácticas de codificación seguras para abordar el riesgo de vulnerabilidades introducidas al principio del proceso de desarrollo.

2. Priorice los activos de TI

Tras definir el alcance, es el momento de identificar y priorizar los activos de TI de su organización. Al determinar qué activos son los más críticos para las operaciones de su negocio, puede asignar los recursos de manera más eficaz durante el proceso de mitigación de riesgos. Esto es especialmente importante para las organizaciones más pequeñas que pueden no tener la capacidad de abordar todos los riesgos potenciales de manera oportuna. La priorización de los activos de TI garantiza que se concentre en las áreas que, de verse comprometidas, tendrían un impacto más significativo en la funcionalidad o la reputación de su organización.

Comience por colaborar con las unidades empresariales y de TI para identificar y clasificar los activos en función de su importancia para la organización. Planifique los sistemas clave, las bases de datos, la propiedad intelectual y cualquier otro recurso que sea esencial para el funcionamiento de su organización. Esto debe incluir la determinación de las necesidades de confidencialidad, integridad y disponibilidad de cada activo. Una vez que se hayan priorizado los activos, puede comenzar a evaluar los riesgos y las vulnerabilidades asociados a ellos, asegurándose de que los activos de alto valor reciban la atención que merecen.

3. Identifique amenazas y vulnerabilidades

El siguiente paso es identificar las posibles amenazas y vulnerabilidades que podrían afectar a sus activos de TI priorizados. Las amenazas se refieren a cualquier factor externo o interno que pueda aprovechar las debilidades de su sistema, como los ciberdelincuentes, el malware o los desastres naturales. Las vulnerabilidades son puntos débiles del sistema que podrían aprovechar estas amenazas, como un cifrado insuficiente, sistemas mal configurados o prácticas de desarrollo de software inseguras.

Aquí es donde su empresa comienza a comprender los riesgos específicos a los que se enfrenta y las brechas en su postura de seguridad actual. Por ejemplo, si su organización utiliza software desactualizado o políticas de contraseñas poco seguras, estas podrían convertirse en puntos de entrada para los ciberdelincuentes. Un conocimiento profundo de las vulnerabilidades y la superficie de ataque de su sistema le proporciona una hoja de ruta para implementar las soluciones. También sienta las bases para los próximos pasos del proceso de evaluación de riesgos, que implica evaluar el impacto y la probabilidad de estas amenazas.

Como parte de este proceso, realice un análisis de vulnerabilidades con herramientas que puedan detectar puntos débiles en la red y los sistemas. Complemente este análisis técnico con una revisión de los incidentes anteriores, los vectores de ataque más comunes en su sector y las ciberamenazas emergentes. Involucre al personal clave de TI y seguridad para identificar las áreas de preocupación y actualizar la lista de vulnerabilidades conocidas. También debe evaluar cuidadosamente cualquier vulnerabilidades en sus prácticas de desarrollo de software, como parte de la creación de un marco de ciclo de vida de desarrollo seguro de software (SSDLC).

4. Determine los niveles de riesgo y priorice los riesgos

Una vez identificadas las amenazas y vulnerabilidades, la organización debe determinar los niveles de riesgo asociados a cada una de ellas. Este paso implica evaluar tanto la probabilidad de que un actor de amenazas aproveche una vulnerabilidad como el posible impacto en su organización. Los niveles de riesgo se pueden clasificar en bajos, medios o altos, en función de factores como la gravedad del impacto, la facilidad con la que un atacante puede aprovechar la vulnerabilidad y la exposición del activo.

La determinación de los niveles de riesgo permite a la organización comprender qué amenazas representan el mayor peligro para sus operaciones y reputación. Una vulnerabilidad en un sitio web público puede clasificarse como de alto riesgo porque un ataque podría comprometer los datos confidenciales de los clientes y provocar un daño importante a la marca. Por otro lado, un riesgo interno, como un servidor mal configurado con acceso limitado, podría clasificarse como de menor riesgo.

Su empresa puede usar una matriz de riesgos para calcular la probabilidad y el impacto potencial de cada riesgo identificado. Involucre a su equipo de ciberseguridad para definir los factores que deberían influir en la puntuación de los riesgos, como la importancia del activo, la facilidad de explotación y el impacto empresarial de un ataque exitoso. También debes involucrar a la alta dirección en la evaluación de los niveles de riesgo para garantizar que los objetivos empresariales de la organización estén alineados con sus prioridades de seguridad.

Una vez que haya determinado los niveles de riesgo, priorice esos riesgos en función de su gravedad e impacto. No todos los riesgos pueden o necesitan mitigarse de inmediato, y algunos pueden requerir soluciones a largo plazo o una planificación estratégica. Al abordar primero los riesgos de alta prioridad, su empresa puede reducir su exposición a eventos catastróficos, como las filtraciones de datos o las interrupciones del sistema.

5. Aborde los riesgos con medidas de seguridad

El siguiente paso es implementar las medidas de seguridad adecuadas para mitigar los riesgos que ha priorizado. El objetivo es reducir la probabilidad de que se produzca una violación de seguridad y minimizar los posibles daños en caso de que se produzca un ataque. Comience por aplicar medidas de seguridad de alta prioridad para sus activos más críticos. Involucre a sus equipos de TI y seguridad para determinar las soluciones más adecuadas e integrarlas en la estrategia general de ciberseguridad de su empresa.

Cada solución de seguridad debe adaptarse a la amenaza o vulnerabilidad específica a la que se dirige. Esto podría implicar la aplicación de soluciones técnicas como firewalls, sistemas de detección de intrusos, el cifrado y la autenticación multifactor (MFA), así como nuevas políticas y formación para desarrolladores en áreas como la codificación segura.

6. Implemente prácticas de codificación seguras

La gestión de riesgos de los desarrolladores desempeña un papel fundamental a la hora de abordar los riesgos de ciberseguridad. Los desarrolladores deben estar capacitados para reconocer y mitigar las amenazas de seguridad en cada etapa del SDLC, desde la recopilación de requisitos hasta las pruebas y la implementación. La integración temprana de la seguridad en el SDLC ayuda a identificar las vulnerabilidades antes de que se conviertan en problemas críticos en la producción. La codificación segura también permite a los desarrolladores evaluar mejor el código generado por la IA para detectar posibles fallos de seguridad antes de que entre en producción, de modo que puedan mantener la eficiencia y la seguridad.

Las organizaciones deben capacitar a los desarrolladores en prácticas de codificación seguras e implementar canalizaciones de integración continua/entrega continua (CI/CD) que detecten y aborden automáticamente las vulnerabilidades durante el desarrollo. Estas prácticas de codificación seguras, como la validación de entradas, el almacenamiento seguro de datos y la gestión segura de las sesiones, pueden reducir en gran medida el riesgo de vulnerabilidades comunes relacionadas con el desarrollo, como la inyección de SQL, la creación de scripts entre sitios (XSS) y el desbordamiento del búfer.

7. Realice un monitoreo continuo y documente los riesgos

La gestión de riesgos de ciberseguridad debe ser un proceso continuo para mantener la resiliencia de su empresa frente a las amenazas en evolución. Implemente prácticas como la realización de evaluaciones de riesgos con un ritmo determinado, la configuración de herramientas de supervisión en tiempo real, la realización de análisis de vulnerabilidades periódicos y la revisión de los registros de acceso para detectar cualquier actividad anormal. Revisa y actualiza tu proceso de evaluación de riesgos con regularidad, con las aportaciones de las partes interesadas pertinentes de toda la organización.

Por último, para garantizar que las evaluaciones futuras se basen en lo anterior, documente siempre los riesgos que identifique y las medidas adoptadas para mitigarlos. Disponer de una única fuente de información fiable y de fácil acceso que haga un seguimiento de cada riesgo, su estado y las medidas conexas adoptadas puede ser una ayuda inestimable para sus esfuerzos continuos de ciberseguridad.

Llevar a cabo evaluaciones de riesgos de ciberseguridad y actuar en consecuencia

Los riesgos de ciberseguridad, si no se abordan, pueden tener consecuencias devastadoras, como costosas filtraciones de datos, sanciones reglamentarias, honorarios legales y daños duraderos a la reputación de la empresa. Para garantizar que su empresa esté adecuadamente protegida, debe realizar evaluaciones de los riesgos de ciberseguridad y actuar en consecuencia. Una de las mejores maneras de lograrlo es incorporar prácticas de codificación seguras en todo el SDLC para reducir drásticamente las vulnerabilidades.

La plataforma de aprendizaje de Secure Code Warrior proporciona a sus desarrolladores las habilidades y los conocimientos necesarios para abordar las fallas de seguridad antes de que el software llegue a la producción. Los equipos de desarrollo más cualificados que aprovechan la plataforma de Secure Code Warrior pueden reducir las vulnerabilidades en un 53%, lo que supone un ahorro de costes de hasta 14 millones de dólares. Con una reducción del riesgo entre dos y tres veces mayor, no es de extrañar que los desarrolladores sigan acudiendo para seguir aprendiendo, y el 92% de ellos está ansioso por recibir más formación.

Si está preparado para reducir su perfil de riesgo de ciberseguridad y garantizar que su software se cree de forma segura desde cero, programar una demostración de la plataforma actual de Secure Code Warrior.

Hace poco tiempo, las comunidades de seguridad y desarrollo recibieron un aviso del Proyecto curlsu desarrollador principal, Daniel Stenberg, quien dejó caer la desafortunada misiva que se publicó una nueva versión de curl, distribuida el 11 de octubre, para abordar dos vulnerabilidades de seguridad de alto impacto, una de las cuales describe como «probablemente la peor falla de seguridad de Curl en mucho tiempo».

UN autopsia en el blog de Stenberg, señaló que las versiones afectadas de la biblioteca curl son susceptibles a una vulnerabilidad de desbordamiento de búfer basada en pilas, relacionada con un problema heredado con el protocolo de proxy SOCKS5, en uso desde 2002.

Con su uso como herramienta de línea de comandos que se remonta a 1998, curl es ampliamente considerado como un pilar fundamental de Internet. Con una historia tan larga y un uso tan generalizado, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones continuas para la seguridad cibernética general.

Este incidente comparte similitudes con el devastador ataque Log4Shell en Log4j, otra dependencia vulnerable que sigue siendo explotada casi dos años después.
‍
>>> ¡Pon a prueba tus conocimientos ahora mismo con nuestra misión curl!‍

La vulnerabilidad: desbordamiento de búfer

El exploit se detalla en CVE-2023-38545, y afecta a las versiones 7.69.0 de curl y 8.3.0, inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en pilas, y los informes iniciales indican que una explotación exitosa podría provocar un ataque de ejecución remota de código (RCE) más devastador. Si bien se trata de un posible flujo de trabajo para un actor de amenazas, se trata de un caso de uso poco frecuente y no algo dado por hecho.

Quizás la única gracia salvadora para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar por un proxy SOCKS5, lo cual es un despliegue relativamente poco común.

Al igual que el exploit curl, echemos un vistazo a esta explicación sobre Buffer Overflow:

Cuando se le diga a curl que use un proxy SOCKS5, pasará el nombre de host y hará que el proxy lo resuelva. Sin embargo, si el nombre de host supera el límite de 255 bytes, curl resolverá el nombre de host localmente (como se ve en el siguiente fragmento de código: fuente).

En caso de que el enlace entre el cliente y el proxy sea lento, es posible que el nombre de host largo se copie en el búfer de memoria en lugar de la dirección resuelta (más corta). La parte de memoria asignada solo admite un valor de 255 bytes, por lo que si recibe un valor que supera este límite, los datos desbordarán los límites del búfer de memoria.

>>> Pruébelo usted mismo en este misión jugable!

El desbordamiento de búfer es un poderoso vector de ataque que puede prevalecer en muchos lenguajes de programación antiguos. En este caso concreto, la explotación dio paso a un ataque más grave y perjudicial en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco frecuente e improbable.

¿Cómo se puede mitigar el riesgo de desbordamiento de búfer?

En este momento, la solución de máxima prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido que puede que no sea necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, es necesaria la auditoría y la posterior aplicación de parches.

En general, los defectos de desbordamiento del búfer se pueden mitigar mediante el uso de un lenguaje que proteja la memoria, como Óxido, sin embargo, como es el caso de un proyecto extenso como curl, no es práctico migrarlo a otro idioma o reescribirlo por capricho. Como Stenberg notas mientras discutíamos la posibilidad de usar y soportar más dependencias escritas en lenguajes seguros para la memoria, o la alternativa de reemplazar gradualmente partes de curl de forma gradual, «... el desarrollo está... actualmente ocurriendo a una velocidad casi glacial y muestra con una claridad dolorosa los desafíos involucrados. Curl permanecerá escrito en C en un futuro próximo». No es una empresa pequeña y las implicaciones de seguridad son inmensas.

Los errores de seguridad pueden ocurrir y ocurrirán, y no siempre es posible confiar en los escáneres y las pruebas para detectar todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos errores es el compromiso con la concienciación continua en materia de seguridad y el desarrollo de habilidades.
‍

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

Prueba nuestro Desafío Heap Overflow gratis.

Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.

Una versión de este artículo apareció en Seguridad de Help Net. Se ha actualizado y distribuido aquí.

‍

He dedicado mi carrera a buscar, arreglar, discutir y derrumbar vulnerabilidades de software, de una forma u otra. Sé que cuando se trata de algunos errores de seguridad comunes, a pesar de estar en nuestra órbita desde los años 90, siguen plagando nuestro software y causando problemas importantes, a pesar de que la solución (a menudo sencilla) se conoce desde hace casi el mismo tiempo. Realmente se siente como el Día de la Marmota, en el que nosotros, como industria, parecemos hacer lo mismo una y otra vez y esperar un resultado diferente.

Sin embargo, hay otro pequeño problema. No estamos recibiendo consejos realistas ni las soluciones más rápidas para combatir el ataque continuo que representa la ciberseguridad moderna. Por supuesto, cada violación es diferente a su manera, y existen numerosos vectores de ataque que pueden explotarse en el software vulnerable. Los consejos genéricos factibles serán limitados, pero el enfoque basado en las mejores prácticas parece tener más defectos cada hora.

Con este fin, me pregunto por qué gran parte de los comentarios y análisis sobre la ciberseguridad han omitido soluciones que realmente abordan la causa fundamental de tantas vulnerabilidades: los seres humanos. La más reciente de Gartner Hype Cycle para la seguridad de las aplicaciones, y Forrester's El estado de la seguridad de las aplicaciones en 2021, ambas biblias para expertos en seguridad que, sin duda, ayudan a dar forma a su programa y a la posible adopción de productos, se centran casi por completo en las herramientas. Un informe de Aberdeen en 2017 demostró lo ingobernable que se había vuelto la tecnología de seguridad promedio, ya que los CISO administran cientos de productos como parte de sus estrategias de seguridad; cuatro años después, nos enfrentamos a más riesgos, más vulnerabilidades y a más incorporaciones a las crecientes bestias de la tecnología.

Las herramientas de seguridad son imprescindibles, pero necesitamos tener una visión más amplia y restablecer el equilibrio del componente humano de la defensa de la seguridad.

La automatización es el futuro. ¿Por qué debemos preocuparnos por el elemento humano de la ciberseguridad?

Prácticamente todo en nuestras vidas funciona con software, y es cierto que la automatización está reemplazando los elementos humanos que alguna vez estuvieron presentes en tantos sectores. Es una señal de progreso en un mundo que se digitaliza a una velocidad vertiginosa, ya que la inteligencia artificial y el aprendizaje automático son temas candentes que mantienen a muchas organizaciones centradas en el futuro.

Entonces, ¿por qué un enfoque de ciberseguridad centrado en las personas sería otra cosa que una solución anticuada para un problema que avanza tecnológicamente? El hecho de que se hayan robado miles de millones de registros de datos en el último año, incluida la violación más reciente de Facebook afectando a más de 500 millones de cuentas, debería indicar que no estamos haciendo lo suficiente (o no estamos adoptando el enfoque correcto) para dar un serio contragolpe a los actores de las amenazas.

Las herramientas de ciberseguridad son un componente muy necesario de la ciberdefensa, y las herramientas siempre tendrán un lugar. Los analistas han estado absolutamente en lo cierto al recomendar las herramientas más recientes en un enfoque de mitigación de riesgos para las empresas, y eso no cambiará. Sin embargo, dado que la calidad del código (y, por definición, la seguridad) es difícil de gestionar con el volumen de producción de código, las herramientas no pueden hacer el trabajo por sí solas. Hasta la fecha, no existe una herramienta única que pueda:

• Analice todas las vulnerabilidades, en todos los idiomas:framework
• Escanear a gran velocidad
• Minimice la doble manipulación provocada por los falsos positivos y negativos

Las herramientas pueden ser lentas, engorrosas y difíciles de manejar. Sin embargo, sobre todo, solo encuentran problemas, no los solucionan ni recomiendan soluciones. Esto último requiere expertos en seguridad, con pocos recursos y con exceso de trabajo, que buscan entre la basura en busca de tesoros entre interminables resultados de análisis y análisis.

El hecho es que, según el informe del índice de inteligencia de ciberseguridad de IBM, el error humano desempeña un papel en El 95% de todas las filtraciones de datos exitosas. Casi la mitad de esos se relacionan directamente con vulnerabilidades de software, muchos de los cuales podrían aliviarse si en las primeras etapas del SDLC hubiera una mayor adhesión a la codificación y el conocimiento seguros. Sin embargo, para que esto suceda, es fundamental que los desarrolladores se centren de manera más precisa y relevante en la educación, además de convertirla en algo intrínseco a su flujo de trabajo.

Nos guste o no, los seres humanos están profundamente arraigados en el proceso de desarrollo de software, y la ciberseguridad es, en gran medida, un problema humano. Las herramientas no servirán para corregir un defecto fundamental de nuestro enfoque, pero pueden desempeñar un papel de apoyo clave en la remodelación de las soluciones humanas.

¿Qué pasaría si solo construyéramos mejores herramientas (y muchas de ellas)?

Las herramientas de seguridad mejoran constantemente. Las herramientas SAST/DAST/IAST han avanzado mucho, mejorando en velocidad e inteligencia, y el RASP debería ser una consideración defensiva seria en muchos entornos de aplicaciones. Los firewalls, los gestores de secretos y las aplicaciones de seguridad en la nube y en la red: todo ello es una obviedad.

Los seres humanos siempre pueden esforzarse por crear mejores herramientas, pero la innovación no está a la altura de las necesidades de seguridad y protección de datos del mundo digital en el que vivimos. Las herramientas se crean, en su mayor parte, pensando en los robots. Pueden estar ahí para ayudar a los desarrolladores y al equipo de seguridad a escanear, supervisar o proteger el código, pero la interacción es muy limitada y muy pocas soluciones tienen como objetivo aumentar la conciencia sobre la seguridad o mejorar las habilidades básicas que pueden conducir a mejores resultados de seguridad.

De hecho, más de la mitad de las empresas ni siquiera saben si las herramientas funcionan para ellas, ni confían en poder evitar una violación de datos devastadora. Ese es un sentimiento muy negativo y, en una industria obsesionada con las herramientas, que no apoya un enfoque diferente, tiende a solidificar el status quo y los problemas internos.

¿Cómo puede una organización aprovechar un enfoque de seguridad dirigido por personas?

No cabe duda de que mantenerse a la vanguardia de las tendencias de la tecnología de seguridad de las aplicaciones es beneficioso e incluso puede ayudar a priorizar las actualizaciones o consolidaciones en un paquete tecnológico exagerado, pero dejar de atacar la causa principal del software vulnerable (nosotros, simples seres humanos) nos mantendrá en el bando perdedor de la batalla de la ciberseguridad.

Si queremos tomar en serio la reducción del número de vulnerabilidades de seguridad a nivel de código, es necesario que los desarrolladores cuenten con las bases para tener éxito en el reparto de la responsabilidad en materia de seguridad. Necesitan una formación práctica y relevante y una mejora de las habilidades en el puesto de trabajo, así como herramientas funcionales que no interrumpan su flujo de trabajo ni hagan que el desarrollo de la seguridad sea una tarea ardua. Lo ideal sería que algunas herramientas estuvieran centradas en los desarrolladores y se crearan teniendo en cuenta su experiencia de usuario.

Hasta el día de hoy, no existe un programa formal de certificación de seguridad para los desarrolladores, pero todas las empresas pueden beneficiarse de la evaluación comparativa y el desarrollo de sus habilidades de codificación segura, eliminando las vulnerabilidades comunes de forma temprana y frecuente, y antes de que esa gran cantidad de tecnología tenga que ponerse manos a la obra y ralentizar todo.

Un equipo de desarrolladores conscientes de la seguridad es un tesoro escondido para cualquier organización, pero como cualquier cosa que valga la pena tener, se necesitará tiempo y esfuerzo para implementar un equipo de ensueño eficaz. Lograr que los desarrolladores se preocupen por la seguridad y consideren que la programación segura es la base de la calidad del código requiere el compromiso de toda la organización de anteponer la seguridad. Y cuando equipos enteros se dan cuenta del impacto positivo que pueden tener al eliminar las vulnerabilidades más comunes a medida que se escribe el código, no hay ninguna herramienta en el mundo que pueda competir con ella.

Lo más probable es que si se ocupa del software de alguna manera, ya sea desarrollador, control de calidad, jefe de ingeniería o profesional de AppSec, la seguridad sea parte de su trabajo. La tarea del equipo de seguridad es señalar las vulnerabilidades del software, y la tarea del desarrollador es hacer todo lo posible para escribir código sin errores desde el principio. Sin embargo, para realizar esas tareas de la manera más eficiente y eficaz posible, es importante que todas las partes trabajen juntas contra las amenazas de seguridad, empezando por el código en el que se ejecutan las aplicaciones.

Sin embargo, aprender de manera efectiva sobre la codificación segura y retener ese conocimiento puede hacer que parezca que es intrínsecamente difícil. Con las herramientas adecuadas, no tiene por qué serlo. Sin embargo, no siempre es fácil convencer a las partes interesadas y a los superiores de que inviertan en el tipo de formación adecuado. La formación se elige con demasiada frecuencia con el único objetivo de cumplir con los requisitos y, en la mayoría de los casos, es irrelevante para el trabajo diario de un desarrollador. Pero, ¿qué pasaría si los desarrolladores pudieran aprender sobre la seguridad en tiempo real, en el lenguaje:framework en el que trabajan todos los días, y divertirse haciéndolo? ¿Y para colmo de males? Su organización cumple con los estándares de la industria al mismo tiempo.

Te respaldamos. Estas son algunas estrategias para ganarte el apoyo de tus colegas, líderes y responsables de la toma de decisiones más importantes de tu organización y así poder participar en un programa de formación sobre codificación de seguridad centrado en los desarrolladores.

Evitar las vulnerabilidades del software desde el principio ahorra una cantidad incalculable de tiempo y dinero

¿Dedica demasiado tiempo a buscar, denunciar o solucionar problemas de seguridad que se repiten? No estás solo.

Imagínese el siguiente escenario: tan pronto como AppSec encuentre una vulnerabilidad y la notifique al equipo de desarrollo, los desarrolladores comenzarán una lección de capacitación relevante y aprenderán no solo cómo corregir esa falla, sino también cómo evitar cometer el mismo error en el futuro. ¿Cuál cree que sería el resultado? Lo más probable es que ese desarrollador recuerde esa lección debido a su relevancia y sea menos probable que vuelva a cometer el mismo error. Esto significa que si trabajas en un equipo de seguridad, es menos probable que ese desarrollador vuelva a crear esa vulnerabilidad sin saberlo y es menos probable que ese mismo desarrollador tenga que volver a corregirla.

Vea este vídeo de nuestro cliente, Contrast Security, sobre la eficacia de la formación en tiempo real para su equipo de desarrollo.

Si todos los desarrolladores participaran en una formación regular sobre código seguro y tuvieran las herramientas al alcance de la mano para aprender sobre los problemas de seguridad en tiempo real, el tiempo que se recupera para crear software increíble y trabajar en programas de seguridad es inconmensurable. Parece un argumento bastante bueno para que su organización invierta en una herramienta como esa, ¿verdad?

Si has encontrado una gran herramienta que te encantaría usar para mejorar tus habilidades en seguridad, algo como (tos) Secure Code Warrior, este es un buen argumento para presentárselo al CISO o al CTO de su organización.

Los desarrolladores capacitados ofrecen mejores resultados y son más felices

El tiempo y el dinero son, por supuesto, muy importantes para su equipo de gestión, pero también lo es su satisfacción laboral. Los empleados satisfechos obtienen mejores resultados, permanecen más tiempo en sus puestos de trabajo y contribuyen a crear un entorno laboral positivo. Por eso, el desarrollo profesional y la formación son una inversión, no un coste. ¿Y si esa formación es realmente divertida y enseña algo relevante? Eso sí que es un billete dorado para el éxito.

La buena noticia es que los desarrolladores suelen estar muy motivados para aprender sobre seguridad porque saben lo importante que es para su trabajo. En un estudio realizado con Evans Data Corporation, encuestamos a desarrolladores de todo el mundo y descubrimos que los desarrolladores quieren aprender sobre seguridad porque:

1. Aumenta la productividad y la eficiencia
2. Sienten curiosidad y están personalmente interesados en conocerlo
3. Quieren evitar los problemas asociados con el código inseguro
4. Entienden que brinda la posibilidad de avanzar en la carrera
5. Es un uso más eficiente de los recursos humanos
   

(Descargue el documento técnico completo) aquí.)

El único problema es que la formación de codificación más segura los está decepcionando. No es relevante para su trabajo diario y, seamos sinceros, es francamente aburrido. Se trata de funciones que no suelen ofrecer buenos resultados en términos de retención de información y, de hecho, de aprendizaje. Sin embargo, cuando la plataforma de aprendizaje está centrada en el desarrollador, es divertida, atractiva y relevante para su trabajo, puede ofrecer resultados reales y crear personas empoderadas que quiero para escribir código seguro. ¿Y por qué su jefe, ya sea un jefe de desarrollo, un CISO o un CTO, no querría que los desarrolladores estuvieran interesados en programar de forma segura y tuvieran las habilidades necesarias para hacerlo?

La comprensión de la seguridad hace que los ingenieros sean mejores en general

Cuando los ingenieros comprenden cómo el software puede ser vulnerable a los ataques, hacen su trabajo teniendo eso en cuenta. Cuanto más comprenda una persona lo que puede salir mal, más trabajará con un enfoque preventivo.

No solo eso, sino que el código de mala calidad tiene más probabilidades de contener vulnerabilidades de software y es más fácil para un desarrollador introducir una vulnerabilidad en ese código sin saberlo. ¿Por qué? Porque mucho de lo que hacen es leer y modificar el código. Cuando ese código está mal organizado y utiliza una lógica deficiente, lleva más tiempo realizar esas tareas y resulta más fácil cambiar algo e introducir accidentalmente un error de seguridad crítico.

Cuando se entiende la seguridad y cómo evitar problemas, también hay que pensar más en la calidad general de ese código y en cómo escribirlo de forma que no se pueda introducir un error fácilmente por accidente. La formación en seguridad es beneficiosa para todos. Los desarrolladores aprenden a programar de forma segura, pero mientras tanto también se convierten en mejores ingenieros.

Hay poder en los números

Otra gran táctica para conseguir la aceptación de sus líderes para adoptar una plataforma segura de aprendizaje de programación es hacer que sus colegas se unan. Cuantos más desarrolladores estén interesados en mejorar sus conocimientos de seguridad, más fácil será convencer a la dirección o a la alta dirección de que inviertan en ellos.

Entonces, ¿cómo se hace eso? Dado que la mayoría de los desarrolladores entienden la necesidad de mejorar en seguridad y quieren aprender, no debería ser demasiado difícil. También puedes hacer que echen un vistazo a esto presentación para desarrolladores de Secure Code Warrior y eche un vistazo a nuestro producto y comience a probar sus habilidades de codificación segura. Una vez que vean el impacto del código inseguro y aprendan que aprender sobre seguridad puede ser divertido, se sentirán capacitados para aprender más.

Una vez que hayas adoptado la herramienta adecuada, una excelente manera de hacer que tus desarrolladores se involucren es con una competencia sana. Intenta iniciar tu programa de entrenamiento con un torneo.

Descubra cómo Nelnet se volvió realmente creativa con los torneos para crear una cultura de seguridad en su empresa.

La formación continua en seguridad promueve una cultura empresarial deseable

El entrenamiento no tiene por qué ser aburrido, y realmente no debería serlo. Sabemos que las clases son caras y difíciles de organizar, especialmente con equipos distribuidos, y es poco probable que les quites mucho provecho. Sin embargo, las organizaciones siguen ofreciendo formación sobre programación segura a los desarrolladores, que no hacen más que marcar una casilla cada año para comprobar el cumplimiento. Ya no basta con mantener el status quo. Es hora de que los gerentes de desarrollo y AppSec den un paso adelante y trabajen juntos para implementar una herramienta de capacitación que promueva el aprendizaje continuo y atractivo. Y eso empieza por convencer a los responsables de la toma de decisiones.

La formación continua y práctica es necesaria por varias razones. Las amenazas de ciberseguridad están en constante evolución, por lo que es natural que la formación para combatir esas amenazas también se realice de forma continua. No solo eso, sino que, como ya se mencionó, cuando aprendemos en tiempo real, es mucho más probable que retengamos lo que hemos aprendido. La programación teniendo en cuenta la seguridad es difícil de implementar, porque esperar que un desarrollador recuerde algo que ha aprendido en una presentación de diapositivas fuera de contexto (quizás casi un año antes) no es realista. Pero si aprenden a evitar una vulnerabilidad de software concreta en el momento en que se les informa de ella y sienten que están jugando a un juego al mismo tiempo, es un juego completamente nuevo.

Tan pronto como se implementa una formación práctica y relevante, la seguridad pasa a formar parte de la cultura de la empresa y ya no se trata como una idea de último momento. Se incorpora al proceso de desarrollo desde el inicio del ciclo de vida del desarrollo del software.

Entonces, ¿qué estás esperando? Comience su camino hacia la mejora de la seguridad en su organización y la protección de los datos vitales de la empresa y los clientes. Haga que sus desarrolladores y jefes se unan para llevar la codificación segura al siguiente nivel en su organización. Deje de experimentar las mismas vulnerabilidades una y otra vez y piense en la seguridad desde el principio.

¿Necesitas más recursos?‍

Descargue el kit completo «Convenza a su CISO/CTO»

Una versión de este artículo apareció en DevOps.com; se le ha cambiado el título y se ha actualizado para incluir nueva información.

Si bien los CISO y los CIO tienen la posición poco envidiable de asumir la mayor parte de la responsabilidad por la seguridad del software, especialmente en el caso de una embarazosa violación de datos de la empresa, también se les brinda una oportunidad única de aumentar su relevancia: son los nuevos innovadores y pueden tener una gran influencia con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio de mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea perfecta tanto con los productos del pasado como con los del futuro, y cada vez es más obligatorio adoptar un enfoque empresarial que dé prioridad a lo digital. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que hay un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa eso para el CISO o CIO moderno? Naturalmente, significa que emplean equipos de desarrolladores, cada uno de los cuales crea línea tras línea del código que forma su producto o servicio digital. La ciberseguridad, si bien ha sido una de las principales consideraciones durante muchos años, es un factor de riesgo cada vez mayor, ya que cada vez más operaciones empresariales se llevan a cabo en línea y están en la mira de los atacantes. Las implicaciones de una violación son enormes, pero optar por no participar en la digitalización no es una opción.

Los CISO y CIO creativos se encuentran en una posición privilegiada para seguir forjando el camino de nuestro futuro digital, junto con sus equipos de desarrollo y AppSec. No cabe duda de que darán forma a la innovación a largo plazo de los servicios empresariales, gubernamentales y públicos en línea, pero tienen la gran responsabilidad de equilibrar los objetivos de rapidez de comercialización y una alta calidad del software y mitigar el riesgo de seguridad.

Este equilibrio ha sido, hasta la fecha, inmensamente difícil de lograr. Esto ha llevado a que los equipos de desarrollo estén a menudo fragmentados y se centren principalmente en ofrecer características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están creando tan rápidamente. Los especialistas de AppSec corrigen constantemente los mismos errores, mientras que la amenaza de que se produzca una violación si se deja abierta una puerta trasera relativamente sencilla es cada vez mayor.

Para que nuestros datos permanezcan seguros, los CISO y los CIO deben ser creativos con la forma en que sus equipos trabajan juntos y forjar una cultura de seguridad positiva y responsabilidad compartida desde arriba hacia abajo. Basta con observar las catastróficas consecuencias a las que se enfrentan Marriott como resultado de su infracción en 2018: una multa del RGPD de más de 123 millones de dólares, el robo de más de 500 millones de registros y una reputación de seguridad hecha jirones. Este desastre se produjo en gran parte como resultado directo de prácticas de codificación inseguras, con Las vulnerabilidades de inyección de SQL se descubrieron ya en 2014 en los servidores de Starwoods, una empresa adquirida por Marriott en 2016. Es evidente que su uso posterior del software no fue controlado desde el punto de vista de la seguridad de las aplicaciones. Esto permitió que los atacantes malintencionados tuvieran varios años para acceder a los datos y adquirirlos, mientras que otras vulnerabilidades, como las contraseñas débiles, dejaron más lagunas que aprovechar con el tiempo.

Los CIO y los CISO deben considerar con mucho cuidado el estado de sus propios climas de seguridad de software. ¿Hasta qué punto es consciente de la seguridad el desarrollador promedio? ¿Qué tan bien trabajan juntos los equipos de AppSec y de desarrollo? No existe una solución mágica, pero es posible mejorar la cultura, la formación y el soporte. Equipos de desarrollo poder pasen de ser la primera línea de riesgo de violación de datos de la organización a convertirse en superhéroes de la seguridad que detienen el código incorrecto antes de que entre en producción.

Control de estado de codificación segura: ¿el suyo está en soporte vital?

¿Dónde encaja tu propio equipo de desarrollo? He creado esta lista de verificación de programación segura para ayudar a los directores de TI y a los CISO a identificar si sus equipos de desarrollo están realmente preparados para convertirse en campeones de la codificación segura y ayudar a innovar con un código más rápido, mejor y más seguro (o, de hecho, si necesitan una reforma del programa de seguridad):

1. ¿Qué tan solidario es el resto de su alta dirección? ¿Entienden que la seguridad de red tradicional ya no es suficiente?

En el futuro del software, proteger la capa de red con medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, de todos modos rara vez tiene éxito) ni siquiera contra piratas informáticos semiprofesionales. Entre los muchos informes consistentes, «Informe de investigaciones sobre violaciones de datos de 2017» de Verizon«cita que un asombroso 35 por ciento de las filtraciones de datos actuales son causadas por vulnerabilidades de aplicaciones web.

La seguridad de las aplicaciones web es tan importante como la seguridad de la red; ignorar esto y no presupuestar ni inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarlo realmente expuesto a una violación.

2. ¿Te mueves lo suficientemente a la izquierda y lo haces lo suficientemente pronto?

El enfoque actual de la seguridad de las aplicaciones requiere una gran cantidad de herramientas y se centra en moverse de derecha a izquierda en el ciclo de vida del desarrollo de software (SDLC). Esto, por definición y diseño, reconoce que el proceso es defectuoso y apoya el resultado de la detección y la reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para corregir el código comprometido en lugar de asegurarse de que esté libre de errores tal como está creado. Según el Instituto Nacional de Estándares y Tecnología (NIST), es Detectar y corregir vulnerabilidades en el código comprometido es 30 veces más caro que evitar que estén escritos en el IDE. Esto ni siquiera tiene en cuenta los retrasos en la producción, la doble gestión y el tiempo dedicado a solucionar los mismos problemas de seguridad conocidos una y otra vez.

Una cultura de seguridad verdaderamente sólida insiste en empezando a la izquierda, inspirando a los defensores de la seguridad de la cohorte de desarrolladores y, al mismo tiempo, proporcionando al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Se centran en el autodesarrollo continuo y en desarrollar sus habilidades para resolver problemas, de modo que puedan ser la primera línea de defensa de la organización y evitar que se produzcan las vulnerabilidades más comunes.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad o simplemente está alimentando conocimientos unidireccionales?

La gran mayoría de las soluciones de capacitación en seguridad (en línea y CBT) se centran en desarrollar conocimientos en lugar de habilidades prácticas que se relacionan directamente con sus trabajos. Para que los desarrolladores prosperen y se dediquen a escribir código seguro, necesitan tener acceso regular a un aprendizaje práctico y contextual que los aliente activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades identificadas recientemente, con ejemplos de código reales, y poder trabajar en sus lenguajes y marcos preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a entender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que están trabajando activamente durante el ejercicio de su trabajo.

Si bien hay muchos profesores expertos y mucha información sobre cómo corregir las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no logra captar la atención de muchos desarrolladores creativos que resuelven problemas y, si el flujo constante de violaciones de datos es un indicio, sigue siendo en gran medida ineficaz a la hora de evitar que las vulnerabilidades ingresen código.

4. ¿Estás midiendo tus habilidades de codificación segura con métricas en tiempo real?

Un paso vital para garantizar que un equipo de desarrollo esté creando una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debería ser una suposición o un juego de adivinanzas: los desarrolladores o se preocupan por la seguridad o no lo son.

Metrics busca demostrar al desarrollador y a su organización que su arduo trabajo está dando sus frutos y que sus habilidades individuales de codificación segura están mejorando. No se puede mejorar lo que no se puede medir. Deberían realizarse las evaluaciones pertinentes, que deberían ayudar a identificar el progreso de sus equipos de desarrollo en tiempo real, así como a comparar sus puntos fuertes y débiles en materia de codificación segura para lograr una mejora continua.

Con demasiada frecuencia, la capacitación en seguridad se convierte en un ejercicio que las organizaciones cumplen con los requisitos, sin hacer hincapié en garantizar que esta capacitación haya sido eficaz, participe o incluso se mantenga.

5. ¿Sus proveedores subcontratados utilizan técnicas de codificación sólidas y seguras?

Muchas organizaciones deciden subcontratar el trabajo de desarrollo a agencias de terceros. Ya sea que existan en el extranjero o en el extranjero, sus habilidades y prácticas generales de codificación segura son un misterio relativo para sus clientes. En el mejor de los casos, la única forma de garantía que recibirá una organización en relación con la seguridad es una declaración en el contrato en la que se exija que el producto entregado sea «seguro». Son muy pocas las empresas que toman medidas para verificar por adelantado las aptitudes de estas empresas de desarrollo, por lo que corren el riesgo de recibir un software que funcione según lo previsto, pero que se haya creado sin seguir prácticas de codificación sólidas y seguras. Y lo que es peor, si la empresa compradora no tiene conocimiento de ningún fallo de seguridad inherente en la aplicación, corre el riesgo de que el software vulnerable salga a la luz pública.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad especializados (personas que son difíciles de encontrar y tienen un coste elevado), y se enfrenta a un retraso en la fecha de puesta en marcha y a posibles discusiones contractuales sobre quién debe pagar para corregir estas debilidades de seguridad. Sin embargo, si eres inteligente desde el principio y evalúas las habilidades de seguridad de las aplicaciones de los desarrolladores que van a crear tu próxima aplicación, te ahorras muchos posibles retrasos, frustraciones y dinero.

6. ¿Conocen sus desarrolladores las debilidades de seguridad más comúnmente explotadas?

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a solo 10 vulnerabilidades conocidas"la Los 10 mejores de OWASP. Como mínimo, su formación en seguridad de aplicaciones debe cubrir estos, además de muchos más tipos de vulnerabilidades. Los desafíos de capacitación a los que se enfrentan sus desarrolladores deben revisarse y actualizarse de forma regular, con nuevos desafíos para los nuevos marcos de codificación o los nuevos tipos de vulnerabilidades.

El entrenamiento de precisión utilizando escenarios de codificación segura del mundo real debería ser el estándar; un conocimiento general vago simplemente no es efectivo. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Eche un vistazo a nuestro Los codificadores conquistan la seguridad serie de blogs; hay un desafío jugable en cada publicación).

7. ¿Tiene campeones de seguridad internos?

Todas las organizaciones con muchos desarrolladores deberían invertir en un campeón de la seguridad, alguien que asuma la responsabilidad de mantener un alto estándar de seguridad dentro del equipo de desarrollo. Su objetivo es ser un punto de contacto de soporte para cualquier persona que tenga preguntas sobre seguridad, así como convertirse en los principales defensores de las mejores prácticas de seguridad.

Son una pieza vital del rompecabezas de la cultura de la seguridad; un gran defensor de la seguridad puede mantener el impulso generado por una formación intensiva, garantizar que todos los miembros del equipo tengan lo que necesitan y seguir abogando por el apoyo.

8. ¿Has invertido en herramientas para que tus desarrolladores faciliten la codificación segura?

Si su organización es una organización en la que se practica el desarrollo ágil o, de hecho, se enfrenta a actualizaciones frecuentes de las aplicaciones creadas por la empresa, la automatización de partes de su seguridad es una de las únicas formas de mantenerse al día con el ritmo y el volumen de trabajo frenéticos.

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de calidad o herramientas de detección. Además, algunas herramientas realizan pruebas automatizadas sobre el código, simulando un intento de hackeo una vez que el software está en producción. Todas tienen su propio conjunto de ventajas y desafíos, y ninguna puede ofrecer una garantía general del 100 por ciento de que no existen amenazas de seguridad dentro de la aplicación. La medida preventiva número uno que puede emplear es que, cuanto antes pueda detectar la debilidad, más rápido y económico será subsanarla con el menor impacto en su empresa.

El siguiente paso para los CISO con visión de futuro

Entonces, ¿cómo le fue a su organización en relación con la lista de verificación anterior?

Si bien los CISO y los CIO se ven obligados esencialmente a desarrollar agresivamente sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la capacitación adecuadas en todos los equipos. Las habilidades de programación seguras serán un arma, no un obstáculo, para la innovación, y renunciar a ellas podría significar la destrucción absoluta de la reputación y los datos de la empresa. Estas habilidades representan capacidades críticas y una solución a largo plazo mucho más económica para reducir las vulnerabilidades y mitigar los riesgos.

Un CISO brillante e innovador tiene el poder de organizar una cultura de seguridad saludable desde arriba hacia abajo; asegúrese de que su personal tenga lo que necesita para ejecutar las mejores prácticas de seguridad de manera efectiva.

Pieter Danhieux es experto en seguridad y cofundador de Secure Code Warrior.

En la onomatopeya japonesa, la frase «doki-doki» («"») representa el sonido de un corazón que late con fuerza... que es exactamente lo que podrían experimentar los miembros del equipo de seguridad si su servidor Docker se infecta con Doki, una nueva vulnerabilidad que proporciona una puerta trasera para la inyección de código malicioso y mucho más. Un nombre apropiado, por decir lo menos.

A medida que adoptamos una dependencia cada vez mayor de la infraestructura de nube, la necesidad de precisión y eficacia escalable de las mejores prácticas de seguridad es vital, y debe extenderse mucho más allá de lo mínimo indispensable para una implementación segura de las aplicaciones, con medidas personalizadas para la seguridad de los contenedores que se den a conocer e implementar en todo el SDLC.

Los ciberataques son cada vez más frecuentes y las amenazas que afectan a la infraestructura basada en Linux son cada vez más comunes, con el objetivo final de tener la oportunidad de abrir un cofre de botín de datos confidenciales almacenados en la nube. Ese es precisamente el objetivo de Doki, y su uso de múltiples tecnologías para no ser detectado, potente y eficaz no se parece a nada que se haya visto anteriormente en el ámbito de los problemas de seguridad basados en Docker.

¿Qué es Doki y cómo funciona?

Como es un tema común en muchas aplicaciones comprometidas, mala configuración de seguridad desempeña un papel inaceptablemente importante en la forma en que se violó el software. En el caso específico de Docker, la API de Docker Engine mal configurada ha demostrado ser beneficiosa para los atacantes. El Botnet Ngrok El robot de criptominería ha estado rastreando servidores Docker inseguros desde 2018, creando sus propios contenedores y ejecutando malware en la infraestructura de la víctima.

Doki es una versión más astuta y maliciosa de este malware, que tuvo éxito a través de la misma red de bots y expuso el mismo vector de ataque: la mala configuración de la API, que debería haberse solucionado mucho antes de cualquier implementación de código o visibilidad pública del servidor. Doki utiliza la cadena de bloques de la criptomoneda satírica favorita de todos, Dogecoin, para actuar como una puerta trasera prácticamente indetectable. Tal como está, se ha deslizado sin dejar rastro desde enero.

Básicamente, el malware abusa de una billetera blockchain para generar nombres de dominio de comando y control (C2), lo que no es nuevo en sí mismo, pero Doki proporciona una capacidad continua para la ejecución remota de código en un servidor infectado, lo que da paso a una serie de ataques dañinos basados en malware, como el ransomware y los DDoS. Es implacable, como un «dux con un hueso», por así decirlo. La buena gente de Intezer tiene un reseña completa sobre toda la amenaza y su enorme carga útil.

Detectando una ruta de Doki en el código.

El hecho de que Doki sea una puerta trasera que opera en una red blockchain descentralizada, que emplea técnicas rápidas y elusivas de escape de contenedores para cubrir las pistas, acceder a más áreas del host y seguir propagando la infección, lo convierte en una pesadilla tanto para los desarrolladores como para los equipos de seguridad.

Aun así, Doki no puede infectar un servidor Docker que tenga puertos API seguros. Configurarlos mal durante el proceso de producción es un error que puede tener consecuencias de gran alcance, pero si se trata de un malware tan complejo y contundente, se puede decir que es una solución un tanto «sencilla» para que los desarrolladores de la nube adquieran conocimientos eficaces sobre seguridad y habilidades prácticas de codificación segura.

Veamos este ejemplo de una API de Docker insegura, una en la que Doki podría encontrar una forma de entrar y empezar a difundirse:

acoplado -H tcp: //0.0.0. 0:2375

¿Puedes detectar los errores de configuración? La versión segura tiene este aspecto:

dockerd -H tcp: //0.0.0. 0:2376 --tlsverify --tlscacert=/etc/ssl/certs/ca.pem --tlscert=/etc/ssl/certs/server-cert.pem --tlskey=/etc/ssl/private/server-key.pem

En el ejemplo inseguro, la API de Docker Engine escucha en el puerto TCP 2375 y aceptará ninguna solicitud de conexión, por lo que está disponible para cualquiera que acceda al servidor Docker.

En el ejemplo seguro, la API de Docker Engine se configuró para usar la validación de certificados TLS y solo aceptará conexiones de clientes que proporcionen un certificado en el que confíe su CA.

Tenemos un conjunto completamente nuevo de desafíos gamificados para ayudar a los desarrolladores a identificar y corregir la causa principal de una infección de Doki, y tú puedes jugar a uno. aquí:

La infraestructura de nube segura es un deporte de equipo.

Configuraciones incorrectas en la nube costaron a las organizaciones la asombrosa suma de 5 billones de dólares en 2018 y 2019, lo que representa miles de millones de registros expuestos y un daño irreversible a la reputación. Para un vector de ataque que es en gran medida evitable, esta es una estadística bastante alarmante. Y pensar que medidas como supervisar y corregir los puertos expuestos (idealmente antes de la implementación), comprobar si hay contenedores desconocidos y controlar cualquier carga excesiva de los servidores podrían detener los daños que provoca algo como Doki, es un precio módico a pagar por su tranquilidad.

La conciencia de seguridad en toda la empresa es fundamental y, para cada persona involucrada en el SDLC, operar con las mejores prácticas de seguridad no es negociable. Las mejores organizaciones están comprometidas con un proceso de DevSecOps sólido, en el que la responsabilidad por la seguridad sea compartida, y tanto los desarrolladores como los profesionales de AppSec tienen los conocimientos y las herramientas necesarios para evitar que las vulnerabilidades más comunes lleguen al software y a la infraestructura vital.
¿Quiere empezar como un ingeniero de nube superpotente y consciente de la seguridad? Empieza a poner a prueba tus habilidades ahora.

Me alegra ver que Secure Code Warrior no es el único que piensa en cómo lograr un cambio de comportamiento dentro de una empresa mediante el refuerzo positivo y los elementos basados en el juego.

Este artículo del WSJ destacó realmente que la concienciación sobre la ciberseguridad es más eficaz y tiene un mayor impacto en los empleados cuando la formación no es espantosa, aburrida, repetitiva o simplemente inútil. En el pasado, la formación en ciberseguridad solía ser impartida por expertos en seguridad que eran técnicos y proporcionaban material detallado, pero sin pensar demasiado en cómo transmitir los mensajes clave que llegaban a los empleados.

Sin embargo, cada vez más, especialmente con los clientes con los que trabajamos, veo cómo las organizaciones ahora involucran a los equipos de marketing y comunicación y a los gerentes de cambio, además de utilizar la animación digital en su contenido y organizar eventos y desafíos para que la capacitación en ciberseguridad sea más divertida y atractiva. Dado que las amenazas a la ciberseguridad aumentan año tras año, la concienciación en materia de seguridad y la formación de los empleados son la inversión más importante que puede hacer una organización.

Las campañas de refuerzo positivo suelen ser una de las mejores maneras de modificar las conductas de riesgo, pero son «definitivamente un caso atípico» en el mundo empresarial, afirma la Sra. Sedova

https://www.wsj.com/articles/a-better-way-to-teach-cybersecurity-to-workers-1505700120