Los errores de software más peligrosos de 2019: más pruebas de que la historia se repite

Publicado el 12 de febrero de 2020
por Pieter Danhieux
ESTUDIO DE CASO

Los errores de software más peligrosos de 2019: más pruebas de que la historia se repite

Publicado el 12 de febrero de 2020
por Pieter Danhieux
Ver recurso
Ver recurso

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.

Ver recurso
Ver recurso

Autor

Pieter Danhieux

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.

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

Los errores de software más peligrosos de 2019: más pruebas de que la historia se repite

Publicado el 12 de febrero de 2020
Por Pieter Danhieux

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.

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.