¿Los proveedores de software se preocupan por la seguridad tanto como usted?
Una versión de este artículo apareció en Security Magazine. Se ha actualizado y sindicado aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que por fin erradicamos la inyección SQL, para siempre? Por supuesto que no. ¿Quizás es el "Día Internacional de Apreciación de los Trabajadores de Seguridad"? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre una campaña de intrusión global hasta entonces desconocida que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía un código malicioso en las actualizaciones del popular software de gestión Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización corrupta. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con cientos de otras actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos en lo que eligieron para atacar una vez que se les dio acceso a través de la brecha de SolarWinds. Muchas empresas importantes, así como agencias gubernamentales, vieron sus datos robados y sus redes comprometidas. Fue una de las mayores y probablemente más costosas violaciones de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total del daño nunca se ha compartido públicamente.
Y todo ocurrió porque la gente confió en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.
El cambio masivo hacia la seguridad de la cadena de suministro
Una vez que se dio la alarma, las empresas, organizaciones y organismos gubernamentales se apresuraron a responder. La brecha de SolarWinds se detuvo, por supuesto, pero el ataque también expuso los peligros de una cadena de suministro de software no regulada y no supervisada. Aunque el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relativas a cómo se utilizó la cadena de suministro como vector de ataque siguen vigentes. Si nada bueno salió del ataque, al menos puso el foco en un aspecto crítico pero ignorado de la ciberseguridad.
Una de las respuestas más destacadas al ataque de SolarWinds fue la Orden Ejecutiva del Presidente Biden para mejorar la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en Estados Unidos. Exige una mejor ciberseguridad en las agencias y para aquellos que hacen negocios con el gobierno, aboga por protecciones avanzadas como las redes de confianza cero, y subraya la necesidad de la seguridad de la cadena de suministro de software.
Si bien la OE es específica para el gobierno, otros grupos también han comenzado a enfatizar la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de SolarWinds. Por ejemplo, Palo Alto ha publicado recientemente su informe sobre la amenaza de la nube de la Unidad 42, titulado "Asegurar la cadena de suministro de software para asegurar la nube". El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Cloud Native Computing Foundation está de acuerdo, publicando un libro blanco en el que se detallan las mejores prácticas críticas de la cadena de suministro de software que deben seguirse a raíz de SolarWinds.
Es seguro decir que los dos últimos años han sido transformadores para las normas de ciberseguridad y, aunque no es obligatorio, debería ser un objetivo para todas las organizaciones seguir el ejemplo y examinar las prácticas de seguridad de los proveedores como si fueran parte de su propio programa de seguridad interna. Iniciativas como el nuevo Plan Estratégico de CISA proporcionan una prueba más de que enfocar la seguridad como una responsabilidad compartida está formando parte de un nuevo estándar para todos los creadores de software, especialmente aquellos implicados en infraestructuras críticas o en la cadena de suministro de software.
¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?
La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. Qué puede hacer una organización para asegurarse de que sus proveedores se preocupan por la ciberseguridad tanto como ellos?
La OE destaca específicamente el impacto de los desarrolladores de software, y la necesidad de que cuenten con habilidades y conciencia de seguridad verificadas, que es un área que tiende a ser olvidada en una industria que está obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Se ha hecho evidente que cualquier enfoque integral de la ciberseguridad en estos días debe incluir absolutamente un riesgo detallado de terceros assessment, que cubra los controles técnicos de seguridad en el lugar y un assessment de cómo los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.
Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los integrantes de su cadena de suministro de software planean lanzar actualizaciones seguras de programas con firmas de certificados verificados, y cómo ayudarán a gestionar las identidades de todo su software y dispositivos. También debe demostrar una ruta clara para las actualizaciones criptográficas y las actualizaciones para sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente crítico de la seguridad de la cadena de suministro de software, cualquier assessment debe incluir también un informe que detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores, e idealmente, la evaluación comparativa de sus habilidades y la formación actual. Sabemos que el énfasis en la capacitación de los desarrolladores está mejorando, pero el 48% de los desarrolladores ha admitido haber enviado a sabiendas código vulnerable.
Factores como la falta de tiempo y la realidad de que la seguridad simplemente no es una prioridad (ni una medida del éxito) en su mundo, contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, todas las organizaciones deben comprometerse con un programa de seguridad más favorable para los desarrolladores.
¿Siguientes pasos?
Las evaluaciones de riesgos son fundamentales porque, si utiliza software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y sufrirá las consecuencias. Sin embargo, las organizaciones también deberían darse cuenta de que es posible que sus proveedores sean en realidad más seguros, e incluso que sean mejores en el apoyo a sus comunidades de desarrolladores.
Puede utilizar el riesgo de un tercero assessment como una forma secundaria de evaluar su propia seguridad. Si un proveedor maneja algún aspecto de la seguridad mejor que usted internamente, puede adoptar sus métodos para mejorar su propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implantar certificaciones de codificación segura para los desarrolladores. Disponer de un buen plan es el primer paso, pero la verificación de que realmente se está siguiendo y ayudando a producir un código seguro es también una necesidad.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para la codificación segura sea la norma, siempre estaremos rezagados a la hora de cerrar ventanas de oportunidad antes de que los actores de amenazas puedan asomarse. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Vea ahora cómo sus desarrolladores pueden perfeccionar habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil.
Es seguro decir que los dos últimos años han sido transformadores para las normas de ciberseguridad, y aunque no es obligatorio, debería ser un objetivo para todas las organizaciones seguir el ejemplo, y escudriñar las prácticas de seguridad de los proveedores como si fueran parte de su propio programa de seguridad interna.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Una versión de este artículo apareció en Security Magazine. Se ha actualizado y sindicado aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que por fin erradicamos la inyección SQL, para siempre? Por supuesto que no. ¿Quizás es el "Día Internacional de Apreciación de los Trabajadores de Seguridad"? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre una campaña de intrusión global hasta entonces desconocida que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía un código malicioso en las actualizaciones del popular software de gestión Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización corrupta. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con cientos de otras actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos en lo que eligieron para atacar una vez que se les dio acceso a través de la brecha de SolarWinds. Muchas empresas importantes, así como agencias gubernamentales, vieron sus datos robados y sus redes comprometidas. Fue una de las mayores y probablemente más costosas violaciones de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total del daño nunca se ha compartido públicamente.
Y todo ocurrió porque la gente confió en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.
El cambio masivo hacia la seguridad de la cadena de suministro
Una vez que se dio la alarma, las empresas, organizaciones y organismos gubernamentales se apresuraron a responder. La brecha de SolarWinds se detuvo, por supuesto, pero el ataque también expuso los peligros de una cadena de suministro de software no regulada y no supervisada. Aunque el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relativas a cómo se utilizó la cadena de suministro como vector de ataque siguen vigentes. Si nada bueno salió del ataque, al menos puso el foco en un aspecto crítico pero ignorado de la ciberseguridad.
Una de las respuestas más destacadas al ataque de SolarWinds fue la Orden Ejecutiva del Presidente Biden para mejorar la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en Estados Unidos. Exige una mejor ciberseguridad en las agencias y para aquellos que hacen negocios con el gobierno, aboga por protecciones avanzadas como las redes de confianza cero, y subraya la necesidad de la seguridad de la cadena de suministro de software.
Si bien la OE es específica para el gobierno, otros grupos también han comenzado a enfatizar la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de SolarWinds. Por ejemplo, Palo Alto ha publicado recientemente su informe sobre la amenaza de la nube de la Unidad 42, titulado "Asegurar la cadena de suministro de software para asegurar la nube". El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Cloud Native Computing Foundation está de acuerdo, publicando un libro blanco en el que se detallan las mejores prácticas críticas de la cadena de suministro de software que deben seguirse a raíz de SolarWinds.
Es seguro decir que los dos últimos años han sido transformadores para las normas de ciberseguridad y, aunque no es obligatorio, debería ser un objetivo para todas las organizaciones seguir el ejemplo y examinar las prácticas de seguridad de los proveedores como si fueran parte de su propio programa de seguridad interna. Iniciativas como el nuevo Plan Estratégico de CISA proporcionan una prueba más de que enfocar la seguridad como una responsabilidad compartida está formando parte de un nuevo estándar para todos los creadores de software, especialmente aquellos implicados en infraestructuras críticas o en la cadena de suministro de software.
¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?
La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. Qué puede hacer una organización para asegurarse de que sus proveedores se preocupan por la ciberseguridad tanto como ellos?
La OE destaca específicamente el impacto de los desarrolladores de software, y la necesidad de que cuenten con habilidades y conciencia de seguridad verificadas, que es un área que tiende a ser olvidada en una industria que está obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Se ha hecho evidente que cualquier enfoque integral de la ciberseguridad en estos días debe incluir absolutamente un riesgo detallado de terceros assessment, que cubra los controles técnicos de seguridad en el lugar y un assessment de cómo los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.
Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los integrantes de su cadena de suministro de software planean lanzar actualizaciones seguras de programas con firmas de certificados verificados, y cómo ayudarán a gestionar las identidades de todo su software y dispositivos. También debe demostrar una ruta clara para las actualizaciones criptográficas y las actualizaciones para sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente crítico de la seguridad de la cadena de suministro de software, cualquier assessment debe incluir también un informe que detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores, e idealmente, la evaluación comparativa de sus habilidades y la formación actual. Sabemos que el énfasis en la capacitación de los desarrolladores está mejorando, pero el 48% de los desarrolladores ha admitido haber enviado a sabiendas código vulnerable.
Factores como la falta de tiempo y la realidad de que la seguridad simplemente no es una prioridad (ni una medida del éxito) en su mundo, contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, todas las organizaciones deben comprometerse con un programa de seguridad más favorable para los desarrolladores.
¿Siguientes pasos?
Las evaluaciones de riesgos son fundamentales porque, si utiliza software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y sufrirá las consecuencias. Sin embargo, las organizaciones también deberían darse cuenta de que es posible que sus proveedores sean en realidad más seguros, e incluso que sean mejores en el apoyo a sus comunidades de desarrolladores.
Puede utilizar el riesgo de un tercero assessment como una forma secundaria de evaluar su propia seguridad. Si un proveedor maneja algún aspecto de la seguridad mejor que usted internamente, puede adoptar sus métodos para mejorar su propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implantar certificaciones de codificación segura para los desarrolladores. Disponer de un buen plan es el primer paso, pero la verificación de que realmente se está siguiendo y ayudando a producir un código seguro es también una necesidad.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para la codificación segura sea la norma, siempre estaremos rezagados a la hora de cerrar ventanas de oportunidad antes de que los actores de amenazas puedan asomarse. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Vea ahora cómo sus desarrolladores pueden perfeccionar habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil.
Una versión de este artículo apareció en Security Magazine. Se ha actualizado y sindicado aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que por fin erradicamos la inyección SQL, para siempre? Por supuesto que no. ¿Quizás es el "Día Internacional de Apreciación de los Trabajadores de Seguridad"? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre una campaña de intrusión global hasta entonces desconocida que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía un código malicioso en las actualizaciones del popular software de gestión Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización corrupta. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con cientos de otras actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos en lo que eligieron para atacar una vez que se les dio acceso a través de la brecha de SolarWinds. Muchas empresas importantes, así como agencias gubernamentales, vieron sus datos robados y sus redes comprometidas. Fue una de las mayores y probablemente más costosas violaciones de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total del daño nunca se ha compartido públicamente.
Y todo ocurrió porque la gente confió en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.
El cambio masivo hacia la seguridad de la cadena de suministro
Una vez que se dio la alarma, las empresas, organizaciones y organismos gubernamentales se apresuraron a responder. La brecha de SolarWinds se detuvo, por supuesto, pero el ataque también expuso los peligros de una cadena de suministro de software no regulada y no supervisada. Aunque el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relativas a cómo se utilizó la cadena de suministro como vector de ataque siguen vigentes. Si nada bueno salió del ataque, al menos puso el foco en un aspecto crítico pero ignorado de la ciberseguridad.
Una de las respuestas más destacadas al ataque de SolarWinds fue la Orden Ejecutiva del Presidente Biden para mejorar la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en Estados Unidos. Exige una mejor ciberseguridad en las agencias y para aquellos que hacen negocios con el gobierno, aboga por protecciones avanzadas como las redes de confianza cero, y subraya la necesidad de la seguridad de la cadena de suministro de software.
Si bien la OE es específica para el gobierno, otros grupos también han comenzado a enfatizar la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de SolarWinds. Por ejemplo, Palo Alto ha publicado recientemente su informe sobre la amenaza de la nube de la Unidad 42, titulado "Asegurar la cadena de suministro de software para asegurar la nube". El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Cloud Native Computing Foundation está de acuerdo, publicando un libro blanco en el que se detallan las mejores prácticas críticas de la cadena de suministro de software que deben seguirse a raíz de SolarWinds.
Es seguro decir que los dos últimos años han sido transformadores para las normas de ciberseguridad y, aunque no es obligatorio, debería ser un objetivo para todas las organizaciones seguir el ejemplo y examinar las prácticas de seguridad de los proveedores como si fueran parte de su propio programa de seguridad interna. Iniciativas como el nuevo Plan Estratégico de CISA proporcionan una prueba más de que enfocar la seguridad como una responsabilidad compartida está formando parte de un nuevo estándar para todos los creadores de software, especialmente aquellos implicados en infraestructuras críticas o en la cadena de suministro de software.
¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?
La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. Qué puede hacer una organización para asegurarse de que sus proveedores se preocupan por la ciberseguridad tanto como ellos?
La OE destaca específicamente el impacto de los desarrolladores de software, y la necesidad de que cuenten con habilidades y conciencia de seguridad verificadas, que es un área que tiende a ser olvidada en una industria que está obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Se ha hecho evidente que cualquier enfoque integral de la ciberseguridad en estos días debe incluir absolutamente un riesgo detallado de terceros assessment, que cubra los controles técnicos de seguridad en el lugar y un assessment de cómo los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.
Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los integrantes de su cadena de suministro de software planean lanzar actualizaciones seguras de programas con firmas de certificados verificados, y cómo ayudarán a gestionar las identidades de todo su software y dispositivos. También debe demostrar una ruta clara para las actualizaciones criptográficas y las actualizaciones para sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente crítico de la seguridad de la cadena de suministro de software, cualquier assessment debe incluir también un informe que detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores, e idealmente, la evaluación comparativa de sus habilidades y la formación actual. Sabemos que el énfasis en la capacitación de los desarrolladores está mejorando, pero el 48% de los desarrolladores ha admitido haber enviado a sabiendas código vulnerable.
Factores como la falta de tiempo y la realidad de que la seguridad simplemente no es una prioridad (ni una medida del éxito) en su mundo, contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, todas las organizaciones deben comprometerse con un programa de seguridad más favorable para los desarrolladores.
¿Siguientes pasos?
Las evaluaciones de riesgos son fundamentales porque, si utiliza software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y sufrirá las consecuencias. Sin embargo, las organizaciones también deberían darse cuenta de que es posible que sus proveedores sean en realidad más seguros, e incluso que sean mejores en el apoyo a sus comunidades de desarrolladores.
Puede utilizar el riesgo de un tercero assessment como una forma secundaria de evaluar su propia seguridad. Si un proveedor maneja algún aspecto de la seguridad mejor que usted internamente, puede adoptar sus métodos para mejorar su propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implantar certificaciones de codificación segura para los desarrolladores. Disponer de un buen plan es el primer paso, pero la verificación de que realmente se está siguiendo y ayudando a producir un código seguro es también una necesidad.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para la codificación segura sea la norma, siempre estaremos rezagados a la hora de cerrar ventanas de oportunidad antes de que los actores de amenazas puedan asomarse. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Vea ahora cómo sus desarrolladores pueden perfeccionar habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Haga clic en el siguiente enlace y descargue el PDF de esta página.
DescargarSecure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Una versión de este artículo apareció en Security Magazine. Se ha actualizado y sindicado aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que por fin erradicamos la inyección SQL, para siempre? Por supuesto que no. ¿Quizás es el "Día Internacional de Apreciación de los Trabajadores de Seguridad"? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre una campaña de intrusión global hasta entonces desconocida que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía un código malicioso en las actualizaciones del popular software de gestión Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización corrupta. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con cientos de otras actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos en lo que eligieron para atacar una vez que se les dio acceso a través de la brecha de SolarWinds. Muchas empresas importantes, así como agencias gubernamentales, vieron sus datos robados y sus redes comprometidas. Fue una de las mayores y probablemente más costosas violaciones de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total del daño nunca se ha compartido públicamente.
Y todo ocurrió porque la gente confió en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.
El cambio masivo hacia la seguridad de la cadena de suministro
Una vez que se dio la alarma, las empresas, organizaciones y organismos gubernamentales se apresuraron a responder. La brecha de SolarWinds se detuvo, por supuesto, pero el ataque también expuso los peligros de una cadena de suministro de software no regulada y no supervisada. Aunque el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relativas a cómo se utilizó la cadena de suministro como vector de ataque siguen vigentes. Si nada bueno salió del ataque, al menos puso el foco en un aspecto crítico pero ignorado de la ciberseguridad.
Una de las respuestas más destacadas al ataque de SolarWinds fue la Orden Ejecutiva del Presidente Biden para mejorar la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en Estados Unidos. Exige una mejor ciberseguridad en las agencias y para aquellos que hacen negocios con el gobierno, aboga por protecciones avanzadas como las redes de confianza cero, y subraya la necesidad de la seguridad de la cadena de suministro de software.
Si bien la OE es específica para el gobierno, otros grupos también han comenzado a enfatizar la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de SolarWinds. Por ejemplo, Palo Alto ha publicado recientemente su informe sobre la amenaza de la nube de la Unidad 42, titulado "Asegurar la cadena de suministro de software para asegurar la nube". El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Cloud Native Computing Foundation está de acuerdo, publicando un libro blanco en el que se detallan las mejores prácticas críticas de la cadena de suministro de software que deben seguirse a raíz de SolarWinds.
Es seguro decir que los dos últimos años han sido transformadores para las normas de ciberseguridad y, aunque no es obligatorio, debería ser un objetivo para todas las organizaciones seguir el ejemplo y examinar las prácticas de seguridad de los proveedores como si fueran parte de su propio programa de seguridad interna. Iniciativas como el nuevo Plan Estratégico de CISA proporcionan una prueba más de que enfocar la seguridad como una responsabilidad compartida está formando parte de un nuevo estándar para todos los creadores de software, especialmente aquellos implicados en infraestructuras críticas o en la cadena de suministro de software.
¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?
La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. Qué puede hacer una organización para asegurarse de que sus proveedores se preocupan por la ciberseguridad tanto como ellos?
La OE destaca específicamente el impacto de los desarrolladores de software, y la necesidad de que cuenten con habilidades y conciencia de seguridad verificadas, que es un área que tiende a ser olvidada en una industria que está obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Se ha hecho evidente que cualquier enfoque integral de la ciberseguridad en estos días debe incluir absolutamente un riesgo detallado de terceros assessment, que cubra los controles técnicos de seguridad en el lugar y un assessment de cómo los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones.
Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los integrantes de su cadena de suministro de software planean lanzar actualizaciones seguras de programas con firmas de certificados verificados, y cómo ayudarán a gestionar las identidades de todo su software y dispositivos. También debe demostrar una ruta clara para las actualizaciones criptográficas y las actualizaciones para sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente crítico de la seguridad de la cadena de suministro de software, cualquier assessment debe incluir también un informe que detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores, e idealmente, la evaluación comparativa de sus habilidades y la formación actual. Sabemos que el énfasis en la capacitación de los desarrolladores está mejorando, pero el 48% de los desarrolladores ha admitido haber enviado a sabiendas código vulnerable.
Factores como la falta de tiempo y la realidad de que la seguridad simplemente no es una prioridad (ni una medida del éxito) en su mundo, contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, todas las organizaciones deben comprometerse con un programa de seguridad más favorable para los desarrolladores.
¿Siguientes pasos?
Las evaluaciones de riesgos son fundamentales porque, si utiliza software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y sufrirá las consecuencias. Sin embargo, las organizaciones también deberían darse cuenta de que es posible que sus proveedores sean en realidad más seguros, e incluso que sean mejores en el apoyo a sus comunidades de desarrolladores.
Puede utilizar el riesgo de un tercero assessment como una forma secundaria de evaluar su propia seguridad. Si un proveedor maneja algún aspecto de la seguridad mejor que usted internamente, puede adoptar sus métodos para mejorar su propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implantar certificaciones de codificación segura para los desarrolladores. Disponer de un buen plan es el primer paso, pero la verificación de que realmente se está siguiendo y ayudando a producir un código seguro es también una necesidad.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para la codificación segura sea la norma, siempre estaremos rezagados a la hora de cerrar ventanas de oportunidad antes de que los actores de amenazas puedan asomarse. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Vea ahora cómo sus desarrolladores pueden perfeccionar habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Impulse la seguridad impulsada por los desarrolladores a escala global Tournaments
Nuestra plataforma le permite fomentar una red de ciberseguridad centrada en la comunidad con atractivos concursos de codificación y tournaments, destacando vulnerabilidades del mundo real y prácticas de codificación seguras.
Trust Agent en acción
SCW Trust Agent le proporciona las herramientas que necesita para entregar código seguro más rápidamente, garantizando que los desarrolladores tengan los conocimientos y las habilidades para implementar las mejores prácticas de seguridad en el lenguaje de programación específico de sus commits de código.
Recursos para empezar
Inmersión profunda: Navegando por la vulnerabilidad crítica CUPS en sistemas GNU-Linux
Descubra los últimos retos de seguridad a los que se enfrentan los usuarios de Linux mientras exploramos las recientes vulnerabilidades de alta gravedad en el Sistema de Impresión UNIX Común (CUPS). Aprenda cómo estos problemas pueden conducir a una potencial ejecución remota de código (RCE) y lo que puede hacer para proteger sus sistemas.
Inmersión profunda: Navegando por la vulnerabilidad crítica CUPS en sistemas GNU-Linux
Descubra los últimos retos de seguridad a los que se enfrentan los usuarios de Linux mientras exploramos las recientes vulnerabilidades de alta gravedad en el Sistema de Impresión UNIX Común (CUPS). Aprenda cómo estos problemas pueden conducir a una potencial ejecución remota de código (RCE) y lo que puede hacer para proteger sus sistemas.
Los programadores conquistan la seguridad: Compartir y aprender - Cross-Site Scripting (XSS)
El cross-site scripting (XSS) utiliza la confianza de los navegadores y la ignorancia de los usuarios para robar datos, apoderarse de cuentas y desfigurar sitios web; es una vulnerabilidad que puede ponerse muy fea, muy rápidamente. Echemos un vistazo a cómo funciona el XSS, qué daño puede causar y cómo prevenirlo.