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
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
Inmersión profunda: Navegando por la vulnerabilidad crítica CUPS en sistemas GNU-Linux
Descubra los últimos retos de seguridad a los que se enfrentan los usuarios de Linux mientras exploramos las recientes vulnerabilidades de alta gravedad en el Sistema de Impresión UNIX Común (CUPS). Aprenda cómo estos problemas pueden conducir a una potencial ejecución remota de código (RCE) y lo que puede hacer para proteger sus sistemas.