
¿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.
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
데모 예약하기마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.


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 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
보고서 보기데모 예약하기마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
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.
목차
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
데모 예약하기다운로드



%20(1).avif)
.avif)
