SCW-Symbole
Held-Hintergrund ohne Trennlinie
Blog

¿Los proveedores de software se preocupan tanto por la seguridad como usted?

Matias Madou, Ph.D.
Veröffentlicht am 11. September 2023
Zuletzt aktualisiert am 06. März 2026

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.

Siehe Ressource
Siehe Ressource

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.

Interessiert an mehr?

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

mehr erfahren

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Eine Vorführung buchen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Autor
Matias Madou, Ph.D.
Veröffentlicht am 11. September 2023

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.

Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.

Teilen auf:
LinkedIn-MarkenSozialx Logo

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.

Siehe Ressource
Siehe Ressource

Füllen Sie das folgende Formular aus, um den Bericht herunterzuladen.

Wir möchten Ihre Erlaubnis einholen, Ihnen Informationen über unsere Produkte oder Themen im Zusammenhang mit sicherer Verschlüsselung zuzusenden. Wir werden Ihre personenbezogenen Daten stets mit größter Sorgfalt behandeln und niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
scw Erfolgssymbol
scw-Fehlersymbol
Um das Formular zu senden, aktivieren Sie bitte die „Analyse“-Cookies. Sie können diese nach Abschluss des Vorgangs wieder deaktivieren.

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.

Webinar ansehen
Beginnen
mehr erfahren

Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Bericht anzeigenEine Vorführung buchen
Siehe Ressource
Teilen auf:
LinkedIn-MarkenSozialx Logo
Interessiert an mehr?

Teilen auf:
LinkedIn-MarkenSozialx Logo
Autor
Matias Madou, Ph.D.
Veröffentlicht am 11. September 2023

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.

Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.

Teilen auf:
LinkedIn-MarkenSozialx Logo

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.

Inhaltsverzeichnis

PDF herunterladen
Siehe Ressource
Interessiert an mehr?

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

mehr erfahren

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Eine Vorführung buchenHerunterladen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Ressourcenzentrum

Ressourcen für den Einstieg

Weitere Veröffentlichungen
Ressourcenzentrum

Ressourcen für den Einstieg

Weitere Veröffentlichungen