Los errores de software más peligrosos de 2019: más pruebas de que la historia se repite
Este artículo apareció originalmente en Information Security Buzzy fue recogido por otros medios. Se ha actualizado para su distribución aquí.
A finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos de la CWE que afectaron al mundo en 2019. Esta lista no se basa en una opinión, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como el NIST, así como los datos publicados de Common Vulnerabilities and Exposures (CVE). Para determinar los "principales" defectos, se atribuye una puntuación basada en su gravedad, capacidad de explotación y prevalencia en el software actual. No es el tipo de lista que va a ganar ningún elogio positivo, eso es seguro.
Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes en esta lista han aparecido antes... una y otra vez. Si ésta fuera la lista de los Billboard Hot 100, sería como si Britney Spears'Baby One More Time y los Backstreet Boys'I Want It That Way aparecieran cada año desde su lanzamiento inicial. ¿Y por qué he elegido esas canciones? Pues porque tienen unos veinte años de antigüedad (¿te sientes ya antiguo?), al igual que algunos de esos peligrosos errores de software que siguen asolándonos en 2020 a pesar de haber sido descubiertos hace décadas.
¿Por qué siguen siendo tan peligrosos los viejos bichos? ¿No sabemos cómo solucionarlos?
El número seis de la lista actual del MITRE es el CWE-89, más conocido como inyección SQL (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando muchos de nosotros todavía hacíamos nuestras preguntas más candentes a Jeeves en lugar de a Google. Poco después se dio a conocer una solución y, sin embargo, sigue siendo una de las técnicas de hacking más utilizadas en 2019. El informe de Akamai Estado de Internet reveló que SQLi fue el culpable de dos tercios de todos los ataques a aplicaciones web.
En cuanto a la complejidad, la inyección SQL está lejos de ser un exploit de nivel genio. Es una solución sencilla para un desarrollador web, y sabemos sin ninguna duda cómo evitar que esta vulnerabilidad exponga datos valiosos a un atacante... el problema es que para muchos desarrolladores, incluso hoy en día, la seguridad no es una prioridad. Puede que esto fuera más fácil hace veinte años, pero con el enorme volumen de software que se está creando hoy y en el futuro, esto ya no puede seguir siendo la norma.
Los desarrolladores operan en un sistema roto (la mayor parte del tiempo).
Es demasiado fácil sentarse y culpar a los desarrolladores por entregar un código "malo". La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. Al equipo de desarrollo medio se le pide que haga un software bonito y funcional lo más rápido posible. La insaciable necesidad de software de la sociedad asegura que los equipos de desarrollo ya están sobrecargados, y la seguridad no es una consideración primordial; después de todo, ¿no es por eso que existen los especialistas en seguridad de aplicaciones? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad: sólo tienen noticias de ellos cuando surgen problemas, y esos problemas pueden retrasar la producción de su duro trabajo.
En el otro lado de la valla, los especialistas en seguridad de aplicaciones están hartos de arreglar errores de hace décadas que siguen apareciendo en cada análisis y revisión manual del código. Estos especialistas son caros y escasos, y su tiempo está mucho mejor invertido en fallos de seguridad complejos en lugar de aplastar errores conocidos una y otra vez.
Existe una cultura tácita de señalamiento entre estos equipos, pero tienen (o deberían tener) el mismo objetivo: un software seguro. Los desarrolladores operan en un entorno que rara vez les da la mejor oportunidad de éxito en términos de codificación segura; las mejores prácticas de seguridad rara vez se enseñan como parte de su educación terciaria, y la formación en el trabajo es a menudo demasiado infrecuente, o completamente ineficaz. Hay una clara falta de énfasis en la concienciación sobre la seguridad y en la educación en profundidad y relevante, y el resultado es el coste astronómico de arreglar viejos fallos en el código comprometido, además de la amenaza inminente de una violación de datos que acabe con la reputación.
El factor humano, también conocido como "¿Por qué todas estas herramientas no hacen más seguros nuestros datos?"
Otro problema que aparece con frecuencia es que, en lugar de la formación, se pone un vasto arsenal de herramientas de seguridad a la tarea de encontrar problemas antes de que el software sea liberado en la naturaleza. El conjunto de herramientas de escaneo y protección de aplicaciones(SAST/DAST/RASP/IAST) puede ciertamente ayudar a la producción de software seguro, pero vienen con sus propios problemas. Depender completamente de ellas no garantiza la seguridad, porque:
- Ninguna herramienta puede buscar todas las vulnerabilidades, en todas las estructuras y en todos los casos de uso.
- Pueden ser lentos, especialmente cuando se ejecutan en tándem para proporcionar un análisis de código estático y dinámico
- Los falsos positivos siguen siendo un problema; a menudo detienen la producción y requieren una revisión manual innecesaria del código para dar sentido a las alertas
- Crean una falsa sensación de seguridad, ya que la codificación segura no tiene prioridad con la expectativa de que estas herramientas detecten cualquier problema.
Las herramientas ciertamente descubrirán fallos de seguridad que pueden ser parcheados, pero ¿encontrarán todo? Es imposible garantizar una tasa de aciertos del 100%, y un atacante sólo necesita una puerta abierta para entrar y arruinarle el día.
Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que entra en juego en las vulnerabilidades del software. La mayoría de los desarrolladores no están adecuadamente formados para la codificación segura, y su conciencia general de seguridad es baja. Sin embargo, se encuentran al principio del ciclo de vida del desarrollo de software y están en una posición privilegiada para evitar que las vulnerabilidades lleguen al código comprometido. Si codificaran de forma segura desde el principio, serían la primera línea de defensa contra los devastadores ciberataques que nos cuestan miles de millones cada año.
Los desarrolladores deben tener la oportunidad de prosperar, con una formación que hable su idioma, que sea relevante para su trabajo y que los entusiasme activamente con la seguridad. Un código sin errores debería ser un motivo de orgullo, al igual que construir algo funcionalmente genial te hará ganar el respeto de tus compañeros.
Un programa de seguridad moderno debe ser una prioridad empresarial.
Los equipos de desarrollo no pueden ponerse de pie por sí mismos y promulgar una conciencia de seguridad positiva en toda la empresa. Necesitarán las herramientas, los conocimientos y el apoyo adecuados para incorporar la seguridad al proceso de desarrollo de software desde el principio.
Está claro que los viejos métodos de formación no funcionan si la lista de MITRE sigue mostrando tantos fallos de seguridad antiguos, así que pruebe algo nuevo. Busque soluciones de formación que sean:
- Práctica; a los desarrolladores les gusta "aprender haciendo", no viendo cabezas parlantes en vídeos
- Relevante; no les hagas entrenar en C# si están usando Java todos los días
- Atractivo; el aprendizaje por bocados es fácil de digerir y permite a los desarrolladores seguir ampliando sus conocimientos previos
- Medible; no se limita a marcar una casilla y seguir adelante. Garantizar la eficacia de la formación y crear vías de mejora
- Diversión; mira cómo puedes crear conciencia de seguridad además de apoyar una cultura de seguridad positiva, y cómo esto puede crear un ambiente de equipo cohesivo.
La seguridad debería ser una prioridad para todos los miembros de la organización, y el CISO debería ser visible y transparente en los esfuerzos realizados en todos los niveles para mantener nuestros datos más seguros. ¿Quién quiere escuchar la misma canción de siempre? Es hora de tomarse en serio lo de aplastar los viejos fallos para siempre.
Hacia finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos del CWE que afectaron al mundo en 2019. Y la mayoría no fue una sorpresa.
Director General, Presidente y Cofundador
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ónDirector General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Este artículo apareció originalmente en Information Security Buzzy fue recogido por otros medios. Se ha actualizado para su distribución aquí.
A finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos de la CWE que afectaron al mundo en 2019. Esta lista no se basa en una opinión, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como el NIST, así como los datos publicados de Common Vulnerabilities and Exposures (CVE). Para determinar los "principales" defectos, se atribuye una puntuación basada en su gravedad, capacidad de explotación y prevalencia en el software actual. No es el tipo de lista que va a ganar ningún elogio positivo, eso es seguro.
Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes en esta lista han aparecido antes... una y otra vez. Si ésta fuera la lista de los Billboard Hot 100, sería como si Britney Spears'Baby One More Time y los Backstreet Boys'I Want It That Way aparecieran cada año desde su lanzamiento inicial. ¿Y por qué he elegido esas canciones? Pues porque tienen unos veinte años de antigüedad (¿te sientes ya antiguo?), al igual que algunos de esos peligrosos errores de software que siguen asolándonos en 2020 a pesar de haber sido descubiertos hace décadas.
¿Por qué siguen siendo tan peligrosos los viejos bichos? ¿No sabemos cómo solucionarlos?
El número seis de la lista actual del MITRE es el CWE-89, más conocido como inyección SQL (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando muchos de nosotros todavía hacíamos nuestras preguntas más candentes a Jeeves en lugar de a Google. Poco después se dio a conocer una solución y, sin embargo, sigue siendo una de las técnicas de hacking más utilizadas en 2019. El informe de Akamai Estado de Internet reveló que SQLi fue el culpable de dos tercios de todos los ataques a aplicaciones web.
En cuanto a la complejidad, la inyección SQL está lejos de ser un exploit de nivel genio. Es una solución sencilla para un desarrollador web, y sabemos sin ninguna duda cómo evitar que esta vulnerabilidad exponga datos valiosos a un atacante... el problema es que para muchos desarrolladores, incluso hoy en día, la seguridad no es una prioridad. Puede que esto fuera más fácil hace veinte años, pero con el enorme volumen de software que se está creando hoy y en el futuro, esto ya no puede seguir siendo la norma.
Los desarrolladores operan en un sistema roto (la mayor parte del tiempo).
Es demasiado fácil sentarse y culpar a los desarrolladores por entregar un código "malo". La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. Al equipo de desarrollo medio se le pide que haga un software bonito y funcional lo más rápido posible. La insaciable necesidad de software de la sociedad asegura que los equipos de desarrollo ya están sobrecargados, y la seguridad no es una consideración primordial; después de todo, ¿no es por eso que existen los especialistas en seguridad de aplicaciones? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad: sólo tienen noticias de ellos cuando surgen problemas, y esos problemas pueden retrasar la producción de su duro trabajo.
En el otro lado de la valla, los especialistas en seguridad de aplicaciones están hartos de arreglar errores de hace décadas que siguen apareciendo en cada análisis y revisión manual del código. Estos especialistas son caros y escasos, y su tiempo está mucho mejor invertido en fallos de seguridad complejos en lugar de aplastar errores conocidos una y otra vez.
Existe una cultura tácita de señalamiento entre estos equipos, pero tienen (o deberían tener) el mismo objetivo: un software seguro. Los desarrolladores operan en un entorno que rara vez les da la mejor oportunidad de éxito en términos de codificación segura; las mejores prácticas de seguridad rara vez se enseñan como parte de su educación terciaria, y la formación en el trabajo es a menudo demasiado infrecuente, o completamente ineficaz. Hay una clara falta de énfasis en la concienciación sobre la seguridad y en la educación en profundidad y relevante, y el resultado es el coste astronómico de arreglar viejos fallos en el código comprometido, además de la amenaza inminente de una violación de datos que acabe con la reputación.
El factor humano, también conocido como "¿Por qué todas estas herramientas no hacen más seguros nuestros datos?"
Otro problema que aparece con frecuencia es que, en lugar de la formación, se pone un vasto arsenal de herramientas de seguridad a la tarea de encontrar problemas antes de que el software sea liberado en la naturaleza. El conjunto de herramientas de escaneo y protección de aplicaciones(SAST/DAST/RASP/IAST) puede ciertamente ayudar a la producción de software seguro, pero vienen con sus propios problemas. Depender completamente de ellas no garantiza la seguridad, porque:
- Ninguna herramienta puede buscar todas las vulnerabilidades, en todas las estructuras y en todos los casos de uso.
- Pueden ser lentos, especialmente cuando se ejecutan en tándem para proporcionar un análisis de código estático y dinámico
- Los falsos positivos siguen siendo un problema; a menudo detienen la producción y requieren una revisión manual innecesaria del código para dar sentido a las alertas
- Crean una falsa sensación de seguridad, ya que la codificación segura no tiene prioridad con la expectativa de que estas herramientas detecten cualquier problema.
Las herramientas ciertamente descubrirán fallos de seguridad que pueden ser parcheados, pero ¿encontrarán todo? Es imposible garantizar una tasa de aciertos del 100%, y un atacante sólo necesita una puerta abierta para entrar y arruinarle el día.
Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que entra en juego en las vulnerabilidades del software. La mayoría de los desarrolladores no están adecuadamente formados para la codificación segura, y su conciencia general de seguridad es baja. Sin embargo, se encuentran al principio del ciclo de vida del desarrollo de software y están en una posición privilegiada para evitar que las vulnerabilidades lleguen al código comprometido. Si codificaran de forma segura desde el principio, serían la primera línea de defensa contra los devastadores ciberataques que nos cuestan miles de millones cada año.
Los desarrolladores deben tener la oportunidad de prosperar, con una formación que hable su idioma, que sea relevante para su trabajo y que los entusiasme activamente con la seguridad. Un código sin errores debería ser un motivo de orgullo, al igual que construir algo funcionalmente genial te hará ganar el respeto de tus compañeros.
Un programa de seguridad moderno debe ser una prioridad empresarial.
Los equipos de desarrollo no pueden ponerse de pie por sí mismos y promulgar una conciencia de seguridad positiva en toda la empresa. Necesitarán las herramientas, los conocimientos y el apoyo adecuados para incorporar la seguridad al proceso de desarrollo de software desde el principio.
Está claro que los viejos métodos de formación no funcionan si la lista de MITRE sigue mostrando tantos fallos de seguridad antiguos, así que pruebe algo nuevo. Busque soluciones de formación que sean:
- Práctica; a los desarrolladores les gusta "aprender haciendo", no viendo cabezas parlantes en vídeos
- Relevante; no les hagas entrenar en C# si están usando Java todos los días
- Atractivo; el aprendizaje por bocados es fácil de digerir y permite a los desarrolladores seguir ampliando sus conocimientos previos
- Medible; no se limita a marcar una casilla y seguir adelante. Garantizar la eficacia de la formación y crear vías de mejora
- Diversión; mira cómo puedes crear conciencia de seguridad además de apoyar una cultura de seguridad positiva, y cómo esto puede crear un ambiente de equipo cohesivo.
La seguridad debería ser una prioridad para todos los miembros de la organización, y el CISO debería ser visible y transparente en los esfuerzos realizados en todos los niveles para mantener nuestros datos más seguros. ¿Quién quiere escuchar la misma canción de siempre? Es hora de tomarse en serio lo de aplastar los viejos fallos para siempre.
Este artículo apareció originalmente en Information Security Buzzy fue recogido por otros medios. Se ha actualizado para su distribución aquí.
A finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos de la CWE que afectaron al mundo en 2019. Esta lista no se basa en una opinión, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como el NIST, así como los datos publicados de Common Vulnerabilities and Exposures (CVE). Para determinar los "principales" defectos, se atribuye una puntuación basada en su gravedad, capacidad de explotación y prevalencia en el software actual. No es el tipo de lista que va a ganar ningún elogio positivo, eso es seguro.
Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes en esta lista han aparecido antes... una y otra vez. Si ésta fuera la lista de los Billboard Hot 100, sería como si Britney Spears'Baby One More Time y los Backstreet Boys'I Want It That Way aparecieran cada año desde su lanzamiento inicial. ¿Y por qué he elegido esas canciones? Pues porque tienen unos veinte años de antigüedad (¿te sientes ya antiguo?), al igual que algunos de esos peligrosos errores de software que siguen asolándonos en 2020 a pesar de haber sido descubiertos hace décadas.
¿Por qué siguen siendo tan peligrosos los viejos bichos? ¿No sabemos cómo solucionarlos?
El número seis de la lista actual del MITRE es el CWE-89, más conocido como inyección SQL (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando muchos de nosotros todavía hacíamos nuestras preguntas más candentes a Jeeves en lugar de a Google. Poco después se dio a conocer una solución y, sin embargo, sigue siendo una de las técnicas de hacking más utilizadas en 2019. El informe de Akamai Estado de Internet reveló que SQLi fue el culpable de dos tercios de todos los ataques a aplicaciones web.
En cuanto a la complejidad, la inyección SQL está lejos de ser un exploit de nivel genio. Es una solución sencilla para un desarrollador web, y sabemos sin ninguna duda cómo evitar que esta vulnerabilidad exponga datos valiosos a un atacante... el problema es que para muchos desarrolladores, incluso hoy en día, la seguridad no es una prioridad. Puede que esto fuera más fácil hace veinte años, pero con el enorme volumen de software que se está creando hoy y en el futuro, esto ya no puede seguir siendo la norma.
Los desarrolladores operan en un sistema roto (la mayor parte del tiempo).
Es demasiado fácil sentarse y culpar a los desarrolladores por entregar un código "malo". La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. Al equipo de desarrollo medio se le pide que haga un software bonito y funcional lo más rápido posible. La insaciable necesidad de software de la sociedad asegura que los equipos de desarrollo ya están sobrecargados, y la seguridad no es una consideración primordial; después de todo, ¿no es por eso que existen los especialistas en seguridad de aplicaciones? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad: sólo tienen noticias de ellos cuando surgen problemas, y esos problemas pueden retrasar la producción de su duro trabajo.
En el otro lado de la valla, los especialistas en seguridad de aplicaciones están hartos de arreglar errores de hace décadas que siguen apareciendo en cada análisis y revisión manual del código. Estos especialistas son caros y escasos, y su tiempo está mucho mejor invertido en fallos de seguridad complejos en lugar de aplastar errores conocidos una y otra vez.
Existe una cultura tácita de señalamiento entre estos equipos, pero tienen (o deberían tener) el mismo objetivo: un software seguro. Los desarrolladores operan en un entorno que rara vez les da la mejor oportunidad de éxito en términos de codificación segura; las mejores prácticas de seguridad rara vez se enseñan como parte de su educación terciaria, y la formación en el trabajo es a menudo demasiado infrecuente, o completamente ineficaz. Hay una clara falta de énfasis en la concienciación sobre la seguridad y en la educación en profundidad y relevante, y el resultado es el coste astronómico de arreglar viejos fallos en el código comprometido, además de la amenaza inminente de una violación de datos que acabe con la reputación.
El factor humano, también conocido como "¿Por qué todas estas herramientas no hacen más seguros nuestros datos?"
Otro problema que aparece con frecuencia es que, en lugar de la formación, se pone un vasto arsenal de herramientas de seguridad a la tarea de encontrar problemas antes de que el software sea liberado en la naturaleza. El conjunto de herramientas de escaneo y protección de aplicaciones(SAST/DAST/RASP/IAST) puede ciertamente ayudar a la producción de software seguro, pero vienen con sus propios problemas. Depender completamente de ellas no garantiza la seguridad, porque:
- Ninguna herramienta puede buscar todas las vulnerabilidades, en todas las estructuras y en todos los casos de uso.
- Pueden ser lentos, especialmente cuando se ejecutan en tándem para proporcionar un análisis de código estático y dinámico
- Los falsos positivos siguen siendo un problema; a menudo detienen la producción y requieren una revisión manual innecesaria del código para dar sentido a las alertas
- Crean una falsa sensación de seguridad, ya que la codificación segura no tiene prioridad con la expectativa de que estas herramientas detecten cualquier problema.
Las herramientas ciertamente descubrirán fallos de seguridad que pueden ser parcheados, pero ¿encontrarán todo? Es imposible garantizar una tasa de aciertos del 100%, y un atacante sólo necesita una puerta abierta para entrar y arruinarle el día.
Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que entra en juego en las vulnerabilidades del software. La mayoría de los desarrolladores no están adecuadamente formados para la codificación segura, y su conciencia general de seguridad es baja. Sin embargo, se encuentran al principio del ciclo de vida del desarrollo de software y están en una posición privilegiada para evitar que las vulnerabilidades lleguen al código comprometido. Si codificaran de forma segura desde el principio, serían la primera línea de defensa contra los devastadores ciberataques que nos cuestan miles de millones cada año.
Los desarrolladores deben tener la oportunidad de prosperar, con una formación que hable su idioma, que sea relevante para su trabajo y que los entusiasme activamente con la seguridad. Un código sin errores debería ser un motivo de orgullo, al igual que construir algo funcionalmente genial te hará ganar el respeto de tus compañeros.
Un programa de seguridad moderno debe ser una prioridad empresarial.
Los equipos de desarrollo no pueden ponerse de pie por sí mismos y promulgar una conciencia de seguridad positiva en toda la empresa. Necesitarán las herramientas, los conocimientos y el apoyo adecuados para incorporar la seguridad al proceso de desarrollo de software desde el principio.
Está claro que los viejos métodos de formación no funcionan si la lista de MITRE sigue mostrando tantos fallos de seguridad antiguos, así que pruebe algo nuevo. Busque soluciones de formación que sean:
- Práctica; a los desarrolladores les gusta "aprender haciendo", no viendo cabezas parlantes en vídeos
- Relevante; no les hagas entrenar en C# si están usando Java todos los días
- Atractivo; el aprendizaje por bocados es fácil de digerir y permite a los desarrolladores seguir ampliando sus conocimientos previos
- Medible; no se limita a marcar una casilla y seguir adelante. Garantizar la eficacia de la formación y crear vías de mejora
- Diversión; mira cómo puedes crear conciencia de seguridad además de apoyar una cultura de seguridad positiva, y cómo esto puede crear un ambiente de equipo cohesivo.
La seguridad debería ser una prioridad para todos los miembros de la organización, y el CISO debería ser visible y transparente en los esfuerzos realizados en todos los niveles para mantener nuestros datos más seguros. ¿Quién quiere escuchar la misma canción de siempre? Es hora de tomarse en serio lo de aplastar los viejos fallos para siempre.
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ónDirector General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Este artículo apareció originalmente en Information Security Buzzy fue recogido por otros medios. Se ha actualizado para su distribución aquí.
A finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos de la CWE que afectaron al mundo en 2019. Esta lista no se basa en una opinión, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como el NIST, así como los datos publicados de Common Vulnerabilities and Exposures (CVE). Para determinar los "principales" defectos, se atribuye una puntuación basada en su gravedad, capacidad de explotación y prevalencia en el software actual. No es el tipo de lista que va a ganar ningún elogio positivo, eso es seguro.
Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes en esta lista han aparecido antes... una y otra vez. Si ésta fuera la lista de los Billboard Hot 100, sería como si Britney Spears'Baby One More Time y los Backstreet Boys'I Want It That Way aparecieran cada año desde su lanzamiento inicial. ¿Y por qué he elegido esas canciones? Pues porque tienen unos veinte años de antigüedad (¿te sientes ya antiguo?), al igual que algunos de esos peligrosos errores de software que siguen asolándonos en 2020 a pesar de haber sido descubiertos hace décadas.
¿Por qué siguen siendo tan peligrosos los viejos bichos? ¿No sabemos cómo solucionarlos?
El número seis de la lista actual del MITRE es el CWE-89, más conocido como inyección SQL (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando muchos de nosotros todavía hacíamos nuestras preguntas más candentes a Jeeves en lugar de a Google. Poco después se dio a conocer una solución y, sin embargo, sigue siendo una de las técnicas de hacking más utilizadas en 2019. El informe de Akamai Estado de Internet reveló que SQLi fue el culpable de dos tercios de todos los ataques a aplicaciones web.
En cuanto a la complejidad, la inyección SQL está lejos de ser un exploit de nivel genio. Es una solución sencilla para un desarrollador web, y sabemos sin ninguna duda cómo evitar que esta vulnerabilidad exponga datos valiosos a un atacante... el problema es que para muchos desarrolladores, incluso hoy en día, la seguridad no es una prioridad. Puede que esto fuera más fácil hace veinte años, pero con el enorme volumen de software que se está creando hoy y en el futuro, esto ya no puede seguir siendo la norma.
Los desarrolladores operan en un sistema roto (la mayor parte del tiempo).
Es demasiado fácil sentarse y culpar a los desarrolladores por entregar un código "malo". La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. Al equipo de desarrollo medio se le pide que haga un software bonito y funcional lo más rápido posible. La insaciable necesidad de software de la sociedad asegura que los equipos de desarrollo ya están sobrecargados, y la seguridad no es una consideración primordial; después de todo, ¿no es por eso que existen los especialistas en seguridad de aplicaciones? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad: sólo tienen noticias de ellos cuando surgen problemas, y esos problemas pueden retrasar la producción de su duro trabajo.
En el otro lado de la valla, los especialistas en seguridad de aplicaciones están hartos de arreglar errores de hace décadas que siguen apareciendo en cada análisis y revisión manual del código. Estos especialistas son caros y escasos, y su tiempo está mucho mejor invertido en fallos de seguridad complejos en lugar de aplastar errores conocidos una y otra vez.
Existe una cultura tácita de señalamiento entre estos equipos, pero tienen (o deberían tener) el mismo objetivo: un software seguro. Los desarrolladores operan en un entorno que rara vez les da la mejor oportunidad de éxito en términos de codificación segura; las mejores prácticas de seguridad rara vez se enseñan como parte de su educación terciaria, y la formación en el trabajo es a menudo demasiado infrecuente, o completamente ineficaz. Hay una clara falta de énfasis en la concienciación sobre la seguridad y en la educación en profundidad y relevante, y el resultado es el coste astronómico de arreglar viejos fallos en el código comprometido, además de la amenaza inminente de una violación de datos que acabe con la reputación.
El factor humano, también conocido como "¿Por qué todas estas herramientas no hacen más seguros nuestros datos?"
Otro problema que aparece con frecuencia es que, en lugar de la formación, se pone un vasto arsenal de herramientas de seguridad a la tarea de encontrar problemas antes de que el software sea liberado en la naturaleza. El conjunto de herramientas de escaneo y protección de aplicaciones(SAST/DAST/RASP/IAST) puede ciertamente ayudar a la producción de software seguro, pero vienen con sus propios problemas. Depender completamente de ellas no garantiza la seguridad, porque:
- Ninguna herramienta puede buscar todas las vulnerabilidades, en todas las estructuras y en todos los casos de uso.
- Pueden ser lentos, especialmente cuando se ejecutan en tándem para proporcionar un análisis de código estático y dinámico
- Los falsos positivos siguen siendo un problema; a menudo detienen la producción y requieren una revisión manual innecesaria del código para dar sentido a las alertas
- Crean una falsa sensación de seguridad, ya que la codificación segura no tiene prioridad con la expectativa de que estas herramientas detecten cualquier problema.
Las herramientas ciertamente descubrirán fallos de seguridad que pueden ser parcheados, pero ¿encontrarán todo? Es imposible garantizar una tasa de aciertos del 100%, y un atacante sólo necesita una puerta abierta para entrar y arruinarle el día.
Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que entra en juego en las vulnerabilidades del software. La mayoría de los desarrolladores no están adecuadamente formados para la codificación segura, y su conciencia general de seguridad es baja. Sin embargo, se encuentran al principio del ciclo de vida del desarrollo de software y están en una posición privilegiada para evitar que las vulnerabilidades lleguen al código comprometido. Si codificaran de forma segura desde el principio, serían la primera línea de defensa contra los devastadores ciberataques que nos cuestan miles de millones cada año.
Los desarrolladores deben tener la oportunidad de prosperar, con una formación que hable su idioma, que sea relevante para su trabajo y que los entusiasme activamente con la seguridad. Un código sin errores debería ser un motivo de orgullo, al igual que construir algo funcionalmente genial te hará ganar el respeto de tus compañeros.
Un programa de seguridad moderno debe ser una prioridad empresarial.
Los equipos de desarrollo no pueden ponerse de pie por sí mismos y promulgar una conciencia de seguridad positiva en toda la empresa. Necesitarán las herramientas, los conocimientos y el apoyo adecuados para incorporar la seguridad al proceso de desarrollo de software desde el principio.
Está claro que los viejos métodos de formación no funcionan si la lista de MITRE sigue mostrando tantos fallos de seguridad antiguos, así que pruebe algo nuevo. Busque soluciones de formación que sean:
- Práctica; a los desarrolladores les gusta "aprender haciendo", no viendo cabezas parlantes en vídeos
- Relevante; no les hagas entrenar en C# si están usando Java todos los días
- Atractivo; el aprendizaje por bocados es fácil de digerir y permite a los desarrolladores seguir ampliando sus conocimientos previos
- Medible; no se limita a marcar una casilla y seguir adelante. Garantizar la eficacia de la formación y crear vías de mejora
- Diversión; mira cómo puedes crear conciencia de seguridad además de apoyar una cultura de seguridad positiva, y cómo esto puede crear un ambiente de equipo cohesivo.
La seguridad debería ser una prioridad para todos los miembros de la organización, y el CISO debería ser visible y transparente en los esfuerzos realizados en todos los niveles para mantener nuestros datos más seguros. ¿Quién quiere escuchar la misma canción de siempre? Es hora de tomarse en serio lo de aplastar los viejos fallos para siempre.
Índice
Director General, Presidente y Cofundador
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
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
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.