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

Este artículo apareció originalmente en Buzz sobre la seguridad de la información, y fue adquirido por varios otros puntos de venta. Se ha actualizado para su distribución aquí.

Hacia finales del año pasado, la increíble comunidad de MITRE publicó su lista de Los 25 errores de software más peligrosos de CWE que afectó 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 publicados sobre vulnerabilidades y exposiciones comunes (CVE). Para determinar cuáles son las «principales» fallas, se asigna una puntuación en función de su gravedad, explotabilidad y prevalencia en el software actual. No es el tipo de lista que va a ganar elogios positivos, eso es seguro.

Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes de esta lista han aparecido antes... una y otra vez. Si esta fuera la lista Billboard Hot 100, sería como la de Britney SpearsBebé una vez más y de los Backstreet BoysLo quiero de esa manera apareciendo todos los años desde su lanzamiento inicial. ¿Y por qué elegí esas canciones? Bueno, tienen aproximadamente veinte años (¿ya se sienten antiguas?) , al igual que algunos de estos peligrosos errores de software que seguirán plagándonos hasta 2020, a pesar de que se descubrieron hace décadas.

¿Por qué los bichos antiguos siguen siendo tan peligrosos? ¿No sabemos cómo solucionarlos?

El número seis de la lista actual de MITRE es CWE-89, más conocida como inyección SQL (SQLi). La vulnerabilidad de SQLi se descubrió por primera vez en 1998, cuando muchos de nosotros todavía hacíamos las preguntas más candentes a Jeeves en lugar de a Google. Poco después se dio a conocer una solución y, sin embargo, esta sigue siendo una de las técnicas de hackeo más utilizadas en 2019. De Akamai Estado de Internet el informe reveló que SQLi fue el culpable de dos tercios de todo ataques a aplicaciones web.

En lo que respecta a la complejidad, la inyección de SQL dista mucho de ser un exploit a nivel de genio. Es una solución sencilla para un desarrollador web, y nosotros hacer sepa sin dudarlo 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 hubiera sido 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 dañado (la mayoría de las veces).

Es muy fácil sentarse y culpar a los desarrolladores por entregar código «incorrecto». La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. A un equipo de desarrollo promedio se le dice que cree software atractivo y funcional lo más rápido posible. La insaciable necesidad de software por parte de la sociedad garantiza que los equipos de desarrollo ya estén agotados, y la seguridad no es una consideración primordial; al fin y al cabo, ¿no es por eso que existen los especialistas en AppSec? Los ingenieros de software están acostumbrados a mantener una relación un tanto fría con la seguridad: solo reciben noticias cuando surgen problemas, y esos problemas pueden retrasar la producción de su arduo trabajo.

Por otro lado, los especialistas de AppSec están hartos de corregir errores de hace décadas que siguen apareciendo en cada escaneo y revisión manual del código. Estos especialistas son caros y escasos, y es mucho mejor que dediquen su tiempo a solucionar fallos de seguridad complejos que a corregir errores 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: proteger el software. Los desarrolladores trabajan en un entorno que rara vez les ofrece las mejores posibilidades 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 formación en el puesto de trabajo suele ser demasiado poco frecuente o completamente ineficaz. Hay una clara falta de énfasis en la conciencia de seguridad y en la educación profunda y relevante, y el resultado es el coste astronómico de corregir errores antiguos 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 que nuestros datos estén más seguros?»

Otro problema que aparece con frecuencia es que, en lugar de formación, se dedica un vasto arsenal de herramientas de seguridad a la tarea de encontrar problemas antes de que el software salga a la venta. La matriz de herramientas de escaneo y protección de aplicaciones (SAST/RAST/RASP/IAST) ciertamente pueden ayudar a la producción segura de software, pero tienen sus propios problemas. Confiar completamente en ellos no garantiza la seguridad, porque:

• Ninguna herramienta «única» puede analizar todas las vulnerabilidades, en todos los marcos y en todos los casos de uso
• Pueden ser lentos, especialmente cuando se ejecutan en conjunto para proporcionar análisis de código estáticos y 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, con la codificación segura despriorizada con la expectativa de que estas herramientas detecten cualquier problema.

No cabe duda de que las herramientas descubrirán las fallas de seguridad que se pueden corregir, pero ¿lo encontrarán todo? Es imposible garantizar una tasa de aciertos del 100%, y un atacante solo necesita dejar una puerta abierta para entrar y arruinarle el día de verdad.

Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que interviene en vulnerabilidades de software. La mayoría de los desarrolladores no están adecuadamente capacitados para la codificación segura y, en general, su conocimiento de la seguridad es bajo. 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 a convertirse en código comprometido. Si codificaran de forma segura desde el principio, estarían en 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. El código libre de errores debería ser motivo de orgullo, del mismo modo que construir algo funcionalmente genial te granjeará el respeto de tus compañeros.

Un programa de seguridad moderno debe ser una prioridad empresarial.

Los equipos de desarrollo no pueden salir adelante por sí solos y crear conciencia positiva sobre la seguridad en toda la empresa. Necesitarán las herramientas, los conocimientos y el apoyo adecuados para incorporar la seguridad en el proceso de desarrollo de software desde el principio.

Es evidente que los métodos de entrenamiento antiguos 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áctico; a los desarrolladores les encanta «aprender haciendo», no viendo vídeos con cabezas parlantes
• Relevante; no los obligue a entrenar en C# si usan Java todos los días
• Un aprendizaje atractivo y breve es fácil de digerir y permite a los desarrolladores seguir desarrollando sus conocimientos previos
• Medible; 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
• Es divertido: descubre cómo puedes crear conciencia sobre la seguridad además de apoyar una cultura de seguridad positiva, y cómo esto puede crear un entorno de equipo cohesionado.

La seguridad debe ser una prioridad para todos los miembros de la organización, con el CISO visible y transparente con los esfuerzos en todos los niveles para mantener nuestros datos más seguros. Quiero decir, ¿quién quiere escuchar la misma vieja canción una y otra vez? Es hora de tomar en serio la idea de acabar con los viejos bichos para siempre.