
¿Los proveedores de software se preocupan tanto por la seguridad como usted?
Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.
Y todo ocurrió porque las personas confiaban 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 agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.
Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.
Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger 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 Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.
Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del 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 garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?
La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que 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 miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.
Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (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, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.
¿Próximos pasos?
Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.
Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.


Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno.
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。
预约演示Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。


Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.
Y todo ocurrió porque las personas confiaban 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 agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.
Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.
Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger 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 Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.
Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del 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 garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?
La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que 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 miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.
Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (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, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.
¿Próximos pasos?
Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.
Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.

Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.
Y todo ocurrió porque las personas confiaban 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 agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.
Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.
Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger 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 Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.
Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del 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 garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?
La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que 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 miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.
Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (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, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.
¿Próximos pasos?
Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.
Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.

点击下方链接,下载此资源的PDF文件。
Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。
查看报告预约演示Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
Una versión de este artículo apareció en Revista de seguridad. Se ha actualizado y distribuido aquí.
Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que finalmente erradicamos la inyección de SQL para siempre? Por supuesto que no. ¿Quizás sea el «Día Internacional de Apreciación a los Trabajadores de Seguridad»? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre algo previamente desconocido campaña de intrusión global que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía código malicioso en lo más profundo de las actualizaciones de software del popular software de administración Orion de SolarWind.
Más de 18.000 clientes de SolarWinds ya habían descargado la actualización dañada. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con otros cientos de actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos a la hora de decidir qué atacar una vez que se les permitió acceder a través de la brecha de seguridad de SolarWinds. A muchas grandes empresas, así como a agencias gubernamentales, se les robaron los datos y se comprometieron sus redes. Fue uno de los más grandes y probablemente el infracción más costosa de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total de los daños nunca se ha compartido públicamente.
Y todo ocurrió porque las personas confiaban 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 agencias gubernamentales respondieron rápidamente. La violación de SolarWinds se detuvo, por supuesto, pero el ataque también puso de manifiesto los peligros de una cadena de suministro de software no regulada ni supervisada. Si bien el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relacionadas con la forma en que se utilizó la cadena de suministro como vector de ataque siguen sin resolverse. Si el ataque no resultó nada bueno, por lo menos puso de relieve un aspecto crítico de la ciberseguridad, aunque pasado por alto.
Una de las respuestas más destacadas al ataque de SolarWinds fue la del presidente Biden Orden ejecutiva sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad para las agencias y para quienes hacen negocios con el gobierno, aboga por protecciones avanzadas, como las redes de confianza cero, y destaca la necesidad de garantizar la seguridad de la cadena de suministro del software.
Si bien la EO es específica para el gobierno, otros grupos también han empezado a hacer hincapié en la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de Solarwinds. Por ejemplo, Palo Alto lanzó recientemente su Unidad 42: Informe sobre amenazas en la nube titulada «Proteja la cadena de suministro de software para proteger 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 Fundación de Computación Nativa en la Nube está de acuerdo y publica un libro blanco detallando las mejores prácticas fundamentales de la cadena de suministro de software que deben seguirse tras la aparición de SolarWinds.
Se puede decir con seguridad que los últimos dos años han supuesto una transformación para los estándares de ciberseguridad y, si bien no son obligatorios, todas las organizaciones deberían tener el objetivo de seguir su ejemplo y analizar las prácticas de seguridad de los proveedores como si formaran parte de su propio programa de seguridad interno. Iniciativas como la nueva de la CISA Plan estratégico proporciona más pruebas de que abordar la seguridad como una responsabilidad compartida forma parte de un nuevo estándar para todos los creadores de software, especialmente aquellos que participan en la infraestructura crítica o la cadena de suministro del 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 garantizar que sus proveedores se preocupen tanto por la ciberseguridad como ellos?
La EO describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y la concienciación, que es un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.
Resulta evidente que cualquier enfoque integral de la ciberseguridad en la actualidad debe incluir sin lugar a dudas una evaluación detallada de los riesgos por parte de terceros, que abarque los controles técnicos de seguridad vigentes y una evaluación de la forma en que 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 miembros de su cadena de suministro de software planean publicar actualizaciones seguras del programa con firmas de certificados verificadas y cómo ayudarán a administrar las identidades de todo su software y dispositivos. También debe mostrar una ruta clara para las mejoras y actualizaciones criptográficas de sus productos.
Y ahora que por fin se considera a los desarrolladores como un componente fundamental de la seguridad de la cadena de suministro de software, cualquier evaluación también debería incluir un informe en el que se detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores e, idealmente, una evaluación comparativa de sus habilidades y su formación actual. Sabemos que cada vez se hace más hincapié en la mejora de las competencias de los desarrolladores, pero El 48% de los desarrolladores ha admitido haber enviado código vulnerable a sabiendas.
Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad principal (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, cada la organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.
¿Próximos pasos?
Las evaluaciones de riesgos son fundamentales porque, si utilizas software de un proveedor que tiene problemas de seguridad, los heredarás en tu ecosistema y asumirás las consecuencias. Sin embargo, las organizaciones también deben darse cuenta de que es posible que sus proveedores sean más seguros e incluso que presten un mejor apoyo a sus comunidades de desarrolladores.
Puede utilizar una evaluación de riesgos de terceros como una forma secundaria de evaluar su propia seguridad. Si un proveedor gestiona algunos aspectos de la seguridad mejor que tú internamente, puedes adoptar sus métodos para mejorar tu propia organización.
Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. El primer paso es contar con un buen plan, pero también es necesario comprobar que realmente se está siguiendo y ayudar a producir un código seguro.
Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para programar de forma segura sea la norma, siempre estaremos atrasados a la hora de cerrar las ventanas de oportunidad antes de que los actores de amenazas puedan echar un vistazo. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar las habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。
预约演示下载



%20(1).avif)
.avif)
