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 Buzz, y fue retomado por varios otros medios. Se ha actualizado aquí para su distribución.

Hacia finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos (CWE Top 25) que afectaron al mundo en 2019. Esta lista no se basa en opiniones, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como NIST, así como datos públicos de Vulnerabilidades y Exposiciones Comunes (CVE). Para determinar los fallos "principales", se asigna una puntuación basada en su gravedad, explotabilidad y prevalencia en el software actual. No es el tipo de lista que vaya a ganar premios positivos, eso es seguro.

Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes en esta lista ya habían aparecido antes... una y otra vez. Si esto fuera la lista Billboard Hot 100, sería como si Baby One More Time de Britney Spears y I Want It That Way de los Backstreet Boys aparecieran cada año desde su lanzamiento inicial. ¿Y por qué elegí esas canciones? Bueno, tienen aproximadamente veinte años (¿ya te sientes viejo?), al igual que algunos de estos peligrosos errores de software que siguen acechándonos en 2020 a pesar de haber sido descubiertos hace décadas.

¿Por qué siguen siendo tan peligrosos los errores antiguos? ¿Acaso no sabemos cómo solucionarlos?

El número seis en la lista actual de MITRE es 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 le hacíamos preguntas a Ask 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 hackeo más utilizadas en 2019. El informe State of the Internet de Akamai reveló que la inyección SQL fue la responsable de dos tercios de todos los ataques a aplicaciones web.

En cuanto a complejidad, la inyección SQL está lejos de ser una vulnerabilidad 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. Esto pudo haber sido más fácil hace veinte años, pero con el enorme volumen de software que se crea hoy y que se creará 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 a culpar a los desarrolladores por entregar código "malo". La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. A un equipo de desarrollo promedio se le pide que cree software hermoso y funcional lo más rápido posible. La insaciable necesidad de software de la sociedad garantiza que los equipos de desarrollo ya estén saturados, y la seguridad no es una consideración primordial; después de todo, ¿no es para eso que existen los especialistas en AppSec? Los ingenieros de software están acostumbrados a una relación algo fría con la seguridad: solo tienen noticias de ellos cuando surgen problemas, y esos problemas pueden retrasar la producción de su arduo trabajo.

Por otro lado, los especialistas en AppSec están hartos de corregir errores de hace décadas que siguen apareciendo en cada escaneo y revisión manual de código. Estos especialistas son costosos y escasos, y su tiempo se aprovecha mucho mejor en fallos de seguridad complejos que en corregir errores bien conocidos una y otra vez.

Existe una cultura tácita de señalar con el dedo entre estos equipos, pero tienen (o deberían tener) el mismo objetivo: software seguro. Los desarrolladores operan en un entorno que rara vez les brinda las mejores oportunidades 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 superior, y la capacitación en el trabajo suele ser demasiado infrecuente o completamente ineficaz. Existe una clara falta de énfasis en la concienciación sobre seguridad y en una educación profunda y relevante, y el resultado es el costo astronómico de corregir errores antiguos en el código ya comprometido, además de la amenaza inminente de una brecha de datos que destruya la reputación.

El factor humano, también conocido como "¿Por qué todas estas herramientas no hacen que nuestros datos sean más seguros?"

Otro problema que aparece con frecuencia es que, en lugar de capacitación, se pone a disposición un vasto arsenal de herramientas de seguridad para encontrar problemas antes de que el software se lance al mercado. La variedad de herramientas de escaneo y protección de aplicaciones (SAST/DAST/RASP/IAST) sin duda puede ayudar en la producción de software seguro, pero conllevan sus propios problemas. Depender totalmente de ellas no garantiza la seguridad, porque:

• Ninguna herramienta "única" puede escanear todas las vulnerabilidades, en todos los marcos de trabajo, en todos los casos de uso
• Pueden ser lentas, especialmente cuando se ejecutan en conjunto para proporcionar análisis de código tanto estáticos como dinámicos
• 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, al despriorizar la codificación segura con la expectativa de que estas herramientas detectarán cualquier problema.

Las herramientas sin duda descubrirán fallos de seguridad que se pueden parchear, pero ¿encontrarán todo? Es imposible garantizar una tasa de éxito del 100%, y un atacante solo necesita una puerta abierta para entrar y arruinarte el día.

Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que interviene en las vulnerabilidades de software. La mayoría de los desarrolladores no están adecuadamente capacitados para la codificación segura y su conciencia general sobre la 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 ataques cibernéticos devastadores que nos cuestan miles de millones cada año.

Los desarrolladores necesitan tener la oportunidad de prosperar, con una capacitación que hable su idioma, sea relevante para su trabajo y los entusiasme activamente con la seguridad. El código libre de errores debería ser un motivo de orgullo, al igual que construir algo funcionalmente increíble te ganará el respeto de tus compañeros.

Un programa de seguridad moderno debería ser una prioridad empresarial.

Los equipos de desarrollo no pueden mejorar por sí solos ni implementar una cultura de concienciación sobre seguridad en toda la empresa. Necesitan las herramientas, el conocimiento y el apoyo adecuados para integrar la seguridad en el proceso de desarrollo de software desde el primer momento.

Los métodos de formación tradicionales claramente no funcionan si la lista de MITRE sigue mostrando tantos errores de seguridad antiguos, así que pruebe algo nuevo. Busque soluciones de formación que sean:

• Prácticas; a los desarrolladores les encanta "aprender haciendo", no ver vídeos de personas hablando.
• Relevantes; no les haga formarse en C# si utilizan Java a diario.
• Atractivas; el aprendizaje en pequeñas dosis es fácil de asimilar y permite a los desarrolladores seguir construyendo sobre conocimientos previos.
• Medibles; no se limite a marcar una casilla y seguir adelante. Asegúrese de que la formación sea eficaz y cree vías de mejora.
• Divertidas; busque formas de fomentar la concienciación sobre seguridad, apoyar una cultura de seguridad positiva y crear un entorno de equipo cohesionado.

La seguridad debe ser una prioridad absoluta para todos en la organización, con un CISO visible y transparente en sus esfuerzos a todos los niveles para mantener nuestros datos más seguros. Al fin y al cabo, ¿quién quiere escuchar siempre lo mismo? Es hora de tomarse en serio la eliminación definitiva de los errores antiguos.