La prevención en la era de la superficie de ataque interminable
Una versión de este artículo apareció en el SD Times. Se ha actualizado y sindicado aquí.
Cuando hablamos de progreso, normalmente el avance digital está en primera línea de la conversación. Queremos que todo sea mejor, más rápido, más cómodo, más potente, y queremos hacerlo por menos dinero, tiempo y riesgo. En la mayoría de los casos, estos objetivos "imposibles" se acaban cumpliendo; puede que se necesiten varios años y múltiples versiones (y un equipo de desarrolladores que podría dar un golpe de estado si se les pide que cambien de marcha en el diseño de características una maldita vez más), pero cada día, el código está ahí fuera cambiando el mundo.
Sin embargo, una gran expansión del software conlleva una gran responsabilidad, y la realidad es que, sencillamente, no estamos preparados para afrontarla desde el punto de vista de la seguridad. El desarrollo de software ya no es una isla, y cuando tenemos en cuenta todos los aspectos del riesgo impulsado por el software -todo, desde la nube, los sistemas integrados en aparatos y vehículos, nuestra infraestructura crítica, por no mencionar las API que lo conectan todo- la superficie de ataque no tiene fronteras y está fuera de control.
No podemos esperar una época mágica en la que cada línea de código sea revisada meticulosamente por expertos en seguridad -esa brecha de habilidades no se va a cerrar pronto-, pero sí podemos, como industria, adoptar un enfoque más holístico de la seguridad a nivel de código.
Exploremos cómo podemos acorralar esa infinita superficie de ataque con las herramientas que tenemos a mano:
Sea realista sobre el nivel de riesgo empresarial (y lo que está dispuesto a aceptar)
La seguridad perfecta no es sostenible, pero tampoco lo es ponerse una venda en los ojos y pretender que todo es un cielo azul. Ya sabemos que las organizaciones distribuyen a sabiendas código vulnerable, y es evidente que se trata de un riesgo calculado en función del tiempo de comercialización de nuevas funciones y productos.
La seguridad a gran velocidad es un reto, especialmente en lugares donde DevSecOps no es la metodología de desarrollo estándar. Sin embargo, solo tenemos que mirar el reciente exploit Log4Shell para descubrir cómo problemas de seguridad relativamente pequeños en el código han abierto oportunidades para un ataque exitoso, y ver que las consecuencias de esos riesgos calculados para enviar código de menor calidad podrían ser mucho mayores de lo proyectado.
Acomodarse a ser un fanático del control (de acceso)
Un número alarmante de costosas filtraciones de datos son causadas por entornos de almacenamiento en la nube mal configurados, y el potencial de exposición de datos sensibles resultante de errores de control de acceso sigue atormentando a los equipos de seguridad de la mayoría de las organizaciones.
En 2019, la empresa de la lista Fortune 500 First American Financial Corp. lo descubrió por las malas. Un error de autenticación -que era relativamente sencillo de remediar- llevó a la exposición de más de 800 millones de registros, incluyendo extractos bancarios, contratos hipotecarios y documentos de identidad con fotografía. Los enlaces a los documentos no requerían ninguna identificación de usuario o inicio de sesión, por lo que eran accesibles a cualquier persona con un navegador web. Y lo que es peor, estaban registrados con números secuenciales, lo que significaba que un simple cambio de número en el enlace exponía un nuevo registro de datos.
Este problema de seguridad se identificó internamente antes de salir a la luz en los medios de comunicación, sin embargo, los fallos a la hora de categorizarlo adecuadamente como un problema de seguridad de alto riesgo, y el hecho de no informarlo a la alta dirección para que lo solucionara urgentemente, provocaron unas consecuencias que aún hoy se están sorteando.
Hay una razón por la que el control de acceso roto ahora se encuentra en la parte superior de la OWASP Top 10: es tan común como la suciedad, y los desarrolladores necesitan conciencia de seguridad verificada y habilidades prácticas para navegar por las mejores prácticas en torno a la autenticación y los privilegios en sus propias construcciones, asegurando que los controles y las medidas están en su lugar para proteger la exposición de datos sensibles.
La naturaleza de las APIs las hace especialmente relevantes y delicadas; por su diseño son muy conversadoras con otras aplicaciones, y los equipos de desarrollo deben tener visibilidad de todos los posibles puntos de acceso. Al fin y al cabo, no pueden tener en cuenta variables y casos de uso desconocidos en su afán por ofrecer un software más seguro.
Analice su programa de seguridad: ¿cuánto énfasis se pone en la prevención?
Es lógico que un gran componente de un programa de seguridad se dedique a la respuesta y reacción ante incidentes, pero muchas organizaciones están perdiendo una valiosa minimización de riesgos al no utilizar todos los recursos disponibles para prevenir un incidente de seguridad en primer lugar.
Es cierto que existen amplias herramientas de seguridad que ayudan a descubrir fallos problemáticos, pero casi el 50% de las empresas admitieron haber enviado código que sabían que era vulnerable. Las limitaciones de tiempo, la complejidad de los conjuntos de herramientas y la falta de expertos capacitados para responder a los informes contribuyen a lo que ha sido esencialmente un riesgo calculado, pero el hecho de que el código necesita ser asegurado en la nube, en las aplicaciones, en la funcionalidad de la API, en los sistemas integrados, en las bibliotecas y en un panorama de tecnología cada vez más amplio, asegura que siempre estaremos un paso atrás con el enfoque actual.
Los errores de seguridad son un problema causado por el ser humano, y no podemos esperar que los robots hagan todo el trabajo por nosotros. Si su grupo de desarrolladores no recibe una formación eficaz -no sólo un seminario anual, sino bloques de construcción educativos adecuados-, siempre corre el riesgo de aceptar un código de baja calidad como estándar, con el riesgo de seguridad que ello conlleva.
¿Ha sobrestimado la preparación de sus desarrolladores?
Los desarrolladores rara vez son evaluados por sus habilidades de codificación segura, y no es su prioridad (ni es un KPI en muchos casos). No pueden ser los culpables de las malas prácticas de seguridad si no se les muestra un camino mejor o se les dice que es una medida de su éxito.
Sin embargo, con demasiada frecuencia se asume dentro de las organizaciones que la orientación proporcionada ha sido eficaz en la preparación del equipo de ingeniería para mitigar los riesgos de seguridad comunes. Dependiendo de la formación y de su concienciación para aplicar las mejores prácticas de seguridad, puede que no estén preparados para ser esa deseable primera línea de defensa (y evitar que un sinfín de fallos de inyección obstruyan los informes de pentest).
El estado ideal es que se completen itinerarios de aprendizaje de complejidad creciente, con las habilidades resultantes verificadas para asegurar que realmente funciona para el desarrollador en el mundo real. Sin embargo, esto requiere una norma cultural en la que se tenga en cuenta a los desarrolladores desde el principio, y se les habilite correctamente. Si nosotros, como industria, vamos a salir al desierto para defender este vasto paisaje de código que hemos creado nosotros mismos, necesitaremos toda la ayuda que podamos conseguir... y hay más delante de nosotros de lo que creemos.


El desarrollo de software ya no es una isla, y cuando tenemos en cuenta todos los aspectos del riesgo que conlleva el software -todo, desde la nube, los sistemas integrados en aparatos y vehículos, nuestra infraestructura crítica, por no mencionar las API que lo conectan todo- la superficie de ataque no tiene fronteras y está fuera de control.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.


Una versión de este artículo apareció en el SD Times. Se ha actualizado y sindicado aquí.
Cuando hablamos de progreso, normalmente el avance digital está en primera línea de la conversación. Queremos que todo sea mejor, más rápido, más cómodo, más potente, y queremos hacerlo por menos dinero, tiempo y riesgo. En la mayoría de los casos, estos objetivos "imposibles" se acaban cumpliendo; puede que se necesiten varios años y múltiples versiones (y un equipo de desarrolladores que podría dar un golpe de estado si se les pide que cambien de marcha en el diseño de características una maldita vez más), pero cada día, el código está ahí fuera cambiando el mundo.
Sin embargo, una gran expansión del software conlleva una gran responsabilidad, y la realidad es que, sencillamente, no estamos preparados para afrontarla desde el punto de vista de la seguridad. El desarrollo de software ya no es una isla, y cuando tenemos en cuenta todos los aspectos del riesgo impulsado por el software -todo, desde la nube, los sistemas integrados en aparatos y vehículos, nuestra infraestructura crítica, por no mencionar las API que lo conectan todo- la superficie de ataque no tiene fronteras y está fuera de control.
No podemos esperar una época mágica en la que cada línea de código sea revisada meticulosamente por expertos en seguridad -esa brecha de habilidades no se va a cerrar pronto-, pero sí podemos, como industria, adoptar un enfoque más holístico de la seguridad a nivel de código.
Exploremos cómo podemos acorralar esa infinita superficie de ataque con las herramientas que tenemos a mano:
Sea realista sobre el nivel de riesgo empresarial (y lo que está dispuesto a aceptar)
La seguridad perfecta no es sostenible, pero tampoco lo es ponerse una venda en los ojos y pretender que todo es un cielo azul. Ya sabemos que las organizaciones distribuyen a sabiendas código vulnerable, y es evidente que se trata de un riesgo calculado en función del tiempo de comercialización de nuevas funciones y productos.
La seguridad a gran velocidad es un reto, especialmente en lugares donde DevSecOps no es la metodología de desarrollo estándar. Sin embargo, solo tenemos que mirar el reciente exploit Log4Shell para descubrir cómo problemas de seguridad relativamente pequeños en el código han abierto oportunidades para un ataque exitoso, y ver que las consecuencias de esos riesgos calculados para enviar código de menor calidad podrían ser mucho mayores de lo proyectado.
Acomodarse a ser un fanático del control (de acceso)
Un número alarmante de costosas filtraciones de datos son causadas por entornos de almacenamiento en la nube mal configurados, y el potencial de exposición de datos sensibles resultante de errores de control de acceso sigue atormentando a los equipos de seguridad de la mayoría de las organizaciones.
En 2019, la empresa de la lista Fortune 500 First American Financial Corp. lo descubrió por las malas. Un error de autenticación -que era relativamente sencillo de remediar- llevó a la exposición de más de 800 millones de registros, incluyendo extractos bancarios, contratos hipotecarios y documentos de identidad con fotografía. Los enlaces a los documentos no requerían ninguna identificación de usuario o inicio de sesión, por lo que eran accesibles a cualquier persona con un navegador web. Y lo que es peor, estaban registrados con números secuenciales, lo que significaba que un simple cambio de número en el enlace exponía un nuevo registro de datos.
Este problema de seguridad se identificó internamente antes de salir a la luz en los medios de comunicación, sin embargo, los fallos a la hora de categorizarlo adecuadamente como un problema de seguridad de alto riesgo, y el hecho de no informarlo a la alta dirección para que lo solucionara urgentemente, provocaron unas consecuencias que aún hoy se están sorteando.
Hay una razón por la que el control de acceso roto ahora se encuentra en la parte superior de la OWASP Top 10: es tan común como la suciedad, y los desarrolladores necesitan conciencia de seguridad verificada y habilidades prácticas para navegar por las mejores prácticas en torno a la autenticación y los privilegios en sus propias construcciones, asegurando que los controles y las medidas están en su lugar para proteger la exposición de datos sensibles.
La naturaleza de las APIs las hace especialmente relevantes y delicadas; por su diseño son muy conversadoras con otras aplicaciones, y los equipos de desarrollo deben tener visibilidad de todos los posibles puntos de acceso. Al fin y al cabo, no pueden tener en cuenta variables y casos de uso desconocidos en su afán por ofrecer un software más seguro.
Analice su programa de seguridad: ¿cuánto énfasis se pone en la prevención?
Es lógico que un gran componente de un programa de seguridad se dedique a la respuesta y reacción ante incidentes, pero muchas organizaciones están perdiendo una valiosa minimización de riesgos al no utilizar todos los recursos disponibles para prevenir un incidente de seguridad en primer lugar.
Es cierto que existen amplias herramientas de seguridad que ayudan a descubrir fallos problemáticos, pero casi el 50% de las empresas admitieron haber enviado código que sabían que era vulnerable. Las limitaciones de tiempo, la complejidad de los conjuntos de herramientas y la falta de expertos capacitados para responder a los informes contribuyen a lo que ha sido esencialmente un riesgo calculado, pero el hecho de que el código necesita ser asegurado en la nube, en las aplicaciones, en la funcionalidad de la API, en los sistemas integrados, en las bibliotecas y en un panorama de tecnología cada vez más amplio, asegura que siempre estaremos un paso atrás con el enfoque actual.
Los errores de seguridad son un problema causado por el ser humano, y no podemos esperar que los robots hagan todo el trabajo por nosotros. Si su grupo de desarrolladores no recibe una formación eficaz -no sólo un seminario anual, sino bloques de construcción educativos adecuados-, siempre corre el riesgo de aceptar un código de baja calidad como estándar, con el riesgo de seguridad que ello conlleva.
¿Ha sobrestimado la preparación de sus desarrolladores?
Los desarrolladores rara vez son evaluados por sus habilidades de codificación segura, y no es su prioridad (ni es un KPI en muchos casos). No pueden ser los culpables de las malas prácticas de seguridad si no se les muestra un camino mejor o se les dice que es una medida de su éxito.
Sin embargo, con demasiada frecuencia se asume dentro de las organizaciones que la orientación proporcionada ha sido eficaz en la preparación del equipo de ingeniería para mitigar los riesgos de seguridad comunes. Dependiendo de la formación y de su concienciación para aplicar las mejores prácticas de seguridad, puede que no estén preparados para ser esa deseable primera línea de defensa (y evitar que un sinfín de fallos de inyección obstruyan los informes de pentest).
El estado ideal es que se completen itinerarios de aprendizaje de complejidad creciente, con las habilidades resultantes verificadas para asegurar que realmente funciona para el desarrollador en el mundo real. Sin embargo, esto requiere una norma cultural en la que se tenga en cuenta a los desarrolladores desde el principio, y se les habilite correctamente. Si nosotros, como industria, vamos a salir al desierto para defender este vasto paisaje de código que hemos creado nosotros mismos, necesitaremos toda la ayuda que podamos conseguir... y hay más delante de nosotros de lo que creemos.

Una versión de este artículo apareció en el SD Times. Se ha actualizado y sindicado aquí.
Cuando hablamos de progreso, normalmente el avance digital está en primera línea de la conversación. Queremos que todo sea mejor, más rápido, más cómodo, más potente, y queremos hacerlo por menos dinero, tiempo y riesgo. En la mayoría de los casos, estos objetivos "imposibles" se acaban cumpliendo; puede que se necesiten varios años y múltiples versiones (y un equipo de desarrolladores que podría dar un golpe de estado si se les pide que cambien de marcha en el diseño de características una maldita vez más), pero cada día, el código está ahí fuera cambiando el mundo.
Sin embargo, una gran expansión del software conlleva una gran responsabilidad, y la realidad es que, sencillamente, no estamos preparados para afrontarla desde el punto de vista de la seguridad. El desarrollo de software ya no es una isla, y cuando tenemos en cuenta todos los aspectos del riesgo impulsado por el software -todo, desde la nube, los sistemas integrados en aparatos y vehículos, nuestra infraestructura crítica, por no mencionar las API que lo conectan todo- la superficie de ataque no tiene fronteras y está fuera de control.
No podemos esperar una época mágica en la que cada línea de código sea revisada meticulosamente por expertos en seguridad -esa brecha de habilidades no se va a cerrar pronto-, pero sí podemos, como industria, adoptar un enfoque más holístico de la seguridad a nivel de código.
Exploremos cómo podemos acorralar esa infinita superficie de ataque con las herramientas que tenemos a mano:
Sea realista sobre el nivel de riesgo empresarial (y lo que está dispuesto a aceptar)
La seguridad perfecta no es sostenible, pero tampoco lo es ponerse una venda en los ojos y pretender que todo es un cielo azul. Ya sabemos que las organizaciones distribuyen a sabiendas código vulnerable, y es evidente que se trata de un riesgo calculado en función del tiempo de comercialización de nuevas funciones y productos.
La seguridad a gran velocidad es un reto, especialmente en lugares donde DevSecOps no es la metodología de desarrollo estándar. Sin embargo, solo tenemos que mirar el reciente exploit Log4Shell para descubrir cómo problemas de seguridad relativamente pequeños en el código han abierto oportunidades para un ataque exitoso, y ver que las consecuencias de esos riesgos calculados para enviar código de menor calidad podrían ser mucho mayores de lo proyectado.
Acomodarse a ser un fanático del control (de acceso)
Un número alarmante de costosas filtraciones de datos son causadas por entornos de almacenamiento en la nube mal configurados, y el potencial de exposición de datos sensibles resultante de errores de control de acceso sigue atormentando a los equipos de seguridad de la mayoría de las organizaciones.
En 2019, la empresa de la lista Fortune 500 First American Financial Corp. lo descubrió por las malas. Un error de autenticación -que era relativamente sencillo de remediar- llevó a la exposición de más de 800 millones de registros, incluyendo extractos bancarios, contratos hipotecarios y documentos de identidad con fotografía. Los enlaces a los documentos no requerían ninguna identificación de usuario o inicio de sesión, por lo que eran accesibles a cualquier persona con un navegador web. Y lo que es peor, estaban registrados con números secuenciales, lo que significaba que un simple cambio de número en el enlace exponía un nuevo registro de datos.
Este problema de seguridad se identificó internamente antes de salir a la luz en los medios de comunicación, sin embargo, los fallos a la hora de categorizarlo adecuadamente como un problema de seguridad de alto riesgo, y el hecho de no informarlo a la alta dirección para que lo solucionara urgentemente, provocaron unas consecuencias que aún hoy se están sorteando.
Hay una razón por la que el control de acceso roto ahora se encuentra en la parte superior de la OWASP Top 10: es tan común como la suciedad, y los desarrolladores necesitan conciencia de seguridad verificada y habilidades prácticas para navegar por las mejores prácticas en torno a la autenticación y los privilegios en sus propias construcciones, asegurando que los controles y las medidas están en su lugar para proteger la exposición de datos sensibles.
La naturaleza de las APIs las hace especialmente relevantes y delicadas; por su diseño son muy conversadoras con otras aplicaciones, y los equipos de desarrollo deben tener visibilidad de todos los posibles puntos de acceso. Al fin y al cabo, no pueden tener en cuenta variables y casos de uso desconocidos en su afán por ofrecer un software más seguro.
Analice su programa de seguridad: ¿cuánto énfasis se pone en la prevención?
Es lógico que un gran componente de un programa de seguridad se dedique a la respuesta y reacción ante incidentes, pero muchas organizaciones están perdiendo una valiosa minimización de riesgos al no utilizar todos los recursos disponibles para prevenir un incidente de seguridad en primer lugar.
Es cierto que existen amplias herramientas de seguridad que ayudan a descubrir fallos problemáticos, pero casi el 50% de las empresas admitieron haber enviado código que sabían que era vulnerable. Las limitaciones de tiempo, la complejidad de los conjuntos de herramientas y la falta de expertos capacitados para responder a los informes contribuyen a lo que ha sido esencialmente un riesgo calculado, pero el hecho de que el código necesita ser asegurado en la nube, en las aplicaciones, en la funcionalidad de la API, en los sistemas integrados, en las bibliotecas y en un panorama de tecnología cada vez más amplio, asegura que siempre estaremos un paso atrás con el enfoque actual.
Los errores de seguridad son un problema causado por el ser humano, y no podemos esperar que los robots hagan todo el trabajo por nosotros. Si su grupo de desarrolladores no recibe una formación eficaz -no sólo un seminario anual, sino bloques de construcción educativos adecuados-, siempre corre el riesgo de aceptar un código de baja calidad como estándar, con el riesgo de seguridad que ello conlleva.
¿Ha sobrestimado la preparación de sus desarrolladores?
Los desarrolladores rara vez son evaluados por sus habilidades de codificación segura, y no es su prioridad (ni es un KPI en muchos casos). No pueden ser los culpables de las malas prácticas de seguridad si no se les muestra un camino mejor o se les dice que es una medida de su éxito.
Sin embargo, con demasiada frecuencia se asume dentro de las organizaciones que la orientación proporcionada ha sido eficaz en la preparación del equipo de ingeniería para mitigar los riesgos de seguridad comunes. Dependiendo de la formación y de su concienciación para aplicar las mejores prácticas de seguridad, puede que no estén preparados para ser esa deseable primera línea de defensa (y evitar que un sinfín de fallos de inyección obstruyan los informes de pentest).
El estado ideal es que se completen itinerarios de aprendizaje de complejidad creciente, con las habilidades resultantes verificadas para asegurar que realmente funciona para el desarrollador en el mundo real. Sin embargo, esto requiere una norma cultural en la que se tenga en cuenta a los desarrolladores desde el principio, y se les habilite correctamente. Si nosotros, como industria, vamos a salir al desierto para defender este vasto paisaje de código que hemos creado nosotros mismos, necesitaremos toda la ayuda que podamos conseguir... y hay más delante de nosotros de lo que creemos.

Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Una versión de este artículo apareció en el SD Times. Se ha actualizado y sindicado aquí.
Cuando hablamos de progreso, normalmente el avance digital está en primera línea de la conversación. Queremos que todo sea mejor, más rápido, más cómodo, más potente, y queremos hacerlo por menos dinero, tiempo y riesgo. En la mayoría de los casos, estos objetivos "imposibles" se acaban cumpliendo; puede que se necesiten varios años y múltiples versiones (y un equipo de desarrolladores que podría dar un golpe de estado si se les pide que cambien de marcha en el diseño de características una maldita vez más), pero cada día, el código está ahí fuera cambiando el mundo.
Sin embargo, una gran expansión del software conlleva una gran responsabilidad, y la realidad es que, sencillamente, no estamos preparados para afrontarla desde el punto de vista de la seguridad. El desarrollo de software ya no es una isla, y cuando tenemos en cuenta todos los aspectos del riesgo impulsado por el software -todo, desde la nube, los sistemas integrados en aparatos y vehículos, nuestra infraestructura crítica, por no mencionar las API que lo conectan todo- la superficie de ataque no tiene fronteras y está fuera de control.
No podemos esperar una época mágica en la que cada línea de código sea revisada meticulosamente por expertos en seguridad -esa brecha de habilidades no se va a cerrar pronto-, pero sí podemos, como industria, adoptar un enfoque más holístico de la seguridad a nivel de código.
Exploremos cómo podemos acorralar esa infinita superficie de ataque con las herramientas que tenemos a mano:
Sea realista sobre el nivel de riesgo empresarial (y lo que está dispuesto a aceptar)
La seguridad perfecta no es sostenible, pero tampoco lo es ponerse una venda en los ojos y pretender que todo es un cielo azul. Ya sabemos que las organizaciones distribuyen a sabiendas código vulnerable, y es evidente que se trata de un riesgo calculado en función del tiempo de comercialización de nuevas funciones y productos.
La seguridad a gran velocidad es un reto, especialmente en lugares donde DevSecOps no es la metodología de desarrollo estándar. Sin embargo, solo tenemos que mirar el reciente exploit Log4Shell para descubrir cómo problemas de seguridad relativamente pequeños en el código han abierto oportunidades para un ataque exitoso, y ver que las consecuencias de esos riesgos calculados para enviar código de menor calidad podrían ser mucho mayores de lo proyectado.
Acomodarse a ser un fanático del control (de acceso)
Un número alarmante de costosas filtraciones de datos son causadas por entornos de almacenamiento en la nube mal configurados, y el potencial de exposición de datos sensibles resultante de errores de control de acceso sigue atormentando a los equipos de seguridad de la mayoría de las organizaciones.
En 2019, la empresa de la lista Fortune 500 First American Financial Corp. lo descubrió por las malas. Un error de autenticación -que era relativamente sencillo de remediar- llevó a la exposición de más de 800 millones de registros, incluyendo extractos bancarios, contratos hipotecarios y documentos de identidad con fotografía. Los enlaces a los documentos no requerían ninguna identificación de usuario o inicio de sesión, por lo que eran accesibles a cualquier persona con un navegador web. Y lo que es peor, estaban registrados con números secuenciales, lo que significaba que un simple cambio de número en el enlace exponía un nuevo registro de datos.
Este problema de seguridad se identificó internamente antes de salir a la luz en los medios de comunicación, sin embargo, los fallos a la hora de categorizarlo adecuadamente como un problema de seguridad de alto riesgo, y el hecho de no informarlo a la alta dirección para que lo solucionara urgentemente, provocaron unas consecuencias que aún hoy se están sorteando.
Hay una razón por la que el control de acceso roto ahora se encuentra en la parte superior de la OWASP Top 10: es tan común como la suciedad, y los desarrolladores necesitan conciencia de seguridad verificada y habilidades prácticas para navegar por las mejores prácticas en torno a la autenticación y los privilegios en sus propias construcciones, asegurando que los controles y las medidas están en su lugar para proteger la exposición de datos sensibles.
La naturaleza de las APIs las hace especialmente relevantes y delicadas; por su diseño son muy conversadoras con otras aplicaciones, y los equipos de desarrollo deben tener visibilidad de todos los posibles puntos de acceso. Al fin y al cabo, no pueden tener en cuenta variables y casos de uso desconocidos en su afán por ofrecer un software más seguro.
Analice su programa de seguridad: ¿cuánto énfasis se pone en la prevención?
Es lógico que un gran componente de un programa de seguridad se dedique a la respuesta y reacción ante incidentes, pero muchas organizaciones están perdiendo una valiosa minimización de riesgos al no utilizar todos los recursos disponibles para prevenir un incidente de seguridad en primer lugar.
Es cierto que existen amplias herramientas de seguridad que ayudan a descubrir fallos problemáticos, pero casi el 50% de las empresas admitieron haber enviado código que sabían que era vulnerable. Las limitaciones de tiempo, la complejidad de los conjuntos de herramientas y la falta de expertos capacitados para responder a los informes contribuyen a lo que ha sido esencialmente un riesgo calculado, pero el hecho de que el código necesita ser asegurado en la nube, en las aplicaciones, en la funcionalidad de la API, en los sistemas integrados, en las bibliotecas y en un panorama de tecnología cada vez más amplio, asegura que siempre estaremos un paso atrás con el enfoque actual.
Los errores de seguridad son un problema causado por el ser humano, y no podemos esperar que los robots hagan todo el trabajo por nosotros. Si su grupo de desarrolladores no recibe una formación eficaz -no sólo un seminario anual, sino bloques de construcción educativos adecuados-, siempre corre el riesgo de aceptar un código de baja calidad como estándar, con el riesgo de seguridad que ello conlleva.
¿Ha sobrestimado la preparación de sus desarrolladores?
Los desarrolladores rara vez son evaluados por sus habilidades de codificación segura, y no es su prioridad (ni es un KPI en muchos casos). No pueden ser los culpables de las malas prácticas de seguridad si no se les muestra un camino mejor o se les dice que es una medida de su éxito.
Sin embargo, con demasiada frecuencia se asume dentro de las organizaciones que la orientación proporcionada ha sido eficaz en la preparación del equipo de ingeniería para mitigar los riesgos de seguridad comunes. Dependiendo de la formación y de su concienciación para aplicar las mejores prácticas de seguridad, puede que no estén preparados para ser esa deseable primera línea de defensa (y evitar que un sinfín de fallos de inyección obstruyan los informes de pentest).
El estado ideal es que se completen itinerarios de aprendizaje de complejidad creciente, con las habilidades resultantes verificadas para asegurar que realmente funciona para el desarrollador en el mundo real. Sin embargo, esto requiere una norma cultural en la que se tenga en cuenta a los desarrolladores desde el principio, y se les habilite correctamente. Si nosotros, como industria, vamos a salir al desierto para defender este vasto paisaje de código que hemos creado nosotros mismos, necesitaremos toda la ayuda que podamos conseguir... y hay más delante de nosotros de lo que creemos.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.