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

Este artículo se publicó originalmente en. Información sobre seguridad, y lo hemos recogido de otras tiendas. Se ha actualizado aquí para su sindicación.

A finales del año pasado, la increíble comunidad MITRE publicó una lista con los 25 errores de software más peligrosos de CWE 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 Además del NIST, también se han publicado datos sobre vulnerabilidades y exposiciones comunes (CVE). Para identificar los defectos «principales», se puntúan en función de su gravedad, su potencial de explotación y su prevalencia en el software actual. No es el tipo de lista que pueda recibir elogios positivos. Eso está claro.

Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes que aparecen en esta lista ya habían aparecido anteriormente... Si esta lista fuera la lista Billboard Hot 100, sería como la lista de Britney Spears.Baby One More Time y BackstreetBoys. Quiero hacerlo así. Aparecen cada año desde su lanzamiento inicial.¿Y por qué elegí esas canciones? Bueno, tengo unos veinte años (¿todavía parece antiguo?) y, a pesar de haber sido descubiertas hace décadas, son muy similares a los peligrosos errores de software que nos siguen atormentando en 2020.

¿Por qué los errores antiguos siguen siendo peligrosos? ¿No sabes cómo solucionarlos?

El sexto elemento de la lista actual de MITRE es más conocido como CWE-89SQLInjection (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando mucha gente solía plantear sus preguntas más importantes a Zibs en lugar de a Google.Aunque poco después se dio a conocer la corrección, este método sigue siendo una de las técnicas de piratería más utilizadas en 2019. Informe sobre el estado de Internet , SQLi fue el culpable en dos tercios de los casos. Todos los ataques a aplicaciones web

En lo que respecta a la complejidad, la inyección SQL dista mucho de ser un abuso de nivel genial. Se trata de una solución sencilla para los desarrolladores web, y debemos conocer sin dudarlo cómo evitar que esta vulnerabilidad exponga datos valiosos a los atacantes... El problema es que, incluso hoy en día, la seguridad no es una prioridad para muchos desarrolladores. Puede que hace veinte años esto fuera más fácil, pero con la enorme cantidad de software que se crea actualmente y que se creará en el futuro, ya no puede ser algo habitual.

La mayoría de los desarrolladores trabajan en sistemas defectuosos.

Es muy fácil sentarse y culpar al desarrollador que proporcionó el código «incorrecto». De hecho, sus prioridades son muy diferentes a las del equipo de seguridad. Por lo general, al equipo de desarrollo se le pide que cree un software bonito y funcional lo más rápido posible. Debido a la demanda incesante de software por parte de la sociedad, el equipo de desarrollo ya está ampliado y la seguridad no es una consideración principal. Al fin y al cabo, ¿no es precisamente por eso por lo que existen los expertos en AppSec? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad. Solo se les pide su opinión cuando surge un problema, y ese problema puede retrasar el arduo trabajo.

Por otro lado, los expertos en AppSec están cansados de corregir errores que llevan décadas apareciendo en todos los escaneos y revisiones manuales de código. Estos expertos son caros y escasos, y es mucho mejor invertir su tiempo en fallos de seguridad complejos que en eliminar repetidamente errores bien conocidos.

Estos equipos tienen una cultura implícita de transferir responsabilidades, pero ambos comparten (o deberían compartir) el mismo objetivo: la seguridad del software. Los desarrolladores trabajan en un entorno en el que es casi imposible tener éxito en lo que respecta a la codificación segura. En los programas de educación superior rara vez se enseñan las mejores prácticas de seguridad, y la formación práctica es demasiado escasa o, en muchos casos, ineficaz. Hay una notable falta de énfasis en la concienciación sobre la seguridad y en la formación relacionada con ella. Como resultado, se avecina la amenaza de una violación de datos que dañaría la reputación y supondría un coste astronómico para corregir los antiguos errores del código confirmado.

El factor humano, también conocido como «¿Por qué todas estas herramientas no logran que los datos sean más seguros?».

Otro problema frecuente es que, en lugar de centrarse en la formación, se invierte una gran cantidad de recursos en herramientas de seguridad para detectar problemas antes del lanzamiento del software. Las herramientas de inspección y protección de aplicaciones en matriz (Fast/Dust/Raz/Toast) pueden ser de gran ayuda en la creación de software de seguridad, pero también tienen sus propios problemas. Depender completamente de estas soluciones no garantiza la seguridad. Las razones son las siguientes:

• No existe una herramienta «única» que permita examinar todas las vulnerabilidades en todos los casos de uso de todos los marcos.
• En particular, la velocidad puede disminuir cuando se ejecutan simultáneamente análisis de código estático y análisis de código dinámico.
• Los falsos positivos siguen siendo un problema. En estos casos, la producción se interrumpe con frecuencia y es necesario realizar revisiones manuales innecesarias del código para identificar las advertencias.
• Estas herramientas están creando una conciencia errónea sobre la seguridad, ya que se espera que resuelvan los problemas y se les da prioridad sobre la codificación segura.

Estas herramientas detectarán sin duda alguna las vulnerabilidades de seguridad que pueden ser parcheadas. Pero, ¿pueden detectarlo todo? No se puede garantizar una tasa de acierto del 100 %, y un atacante solo tiene que encontrar una puerta abierta para colarse y arruinarle el día.

Afortunadamente, muchas organizaciones se están dando cuenta de que el factor humano es importante. Vulnerabilidad del software. La mayoría de los desarrolladores no han recibido una formación adecuada en materia de codificación segura y su nivel de concienciación general sobre la seguridad es bajo. Sin embargo, se encuentran en las primeras fases del ciclo de vida del desarrollo de software y están en la mejor posición para evitar que las vulnerabilidades se introduzcan en el código comprometido. Si se codifica de forma segura desde el principio, se estará en primera línea de defensa contra los ciberataques destructivos que causan pérdidas de miles de millones de dólares cada año.

Los desarrolladores deben tener la oportunidad de triunfar mediante una formación que les permita hablar su propio idioma, que esté relacionada con su trabajo y que les permita interesarse activamente por la seguridad. El código sin errores debe ser motivo de orgullo. Al igual que crear algo funcionalmente impresionante puede ganarse el respeto de los compañeros.

Los programas de seguridad más recientes deben ser una prioridad empresarial.

El equipo de desarrollo no puede utilizar Bootstrap para mejorar la concienciación sobre la seguridad en toda la empresa. Para aplicar la seguridad al proceso de desarrollo de software desde el principio, se necesitan las herramientas, los conocimientos y el apoyo adecuados.

Si la lista de MITRE sigue conteniendo demasiados errores de seguridad antiguos, es evidente que los métodos de formación anteriores no están funcionando. Por lo tanto, pruebe algo nuevo. Busque soluciones de formación como las siguientes.

• Puede probarlo usted mismo. A los desarrolladores les gusta «aprender probando» en lugar de ver lo que se dice en los vídeos.
• Relevancia: Si utiliza Java a diario, no lo enseñe con C#.
• El aprendizaje interesante y sencillo es fácil de entender y permite a los desarrolladores seguir avanzando basándose en sus conocimientos previos.
• Medible. No se limite a marcar la casilla y seguir adelante. Compruebe si la formación es eficaz y establezca una ruta para mejorarla.
• Es interesante. Además de apoyar una cultura de seguridad positiva, explore cómo se puede fomentar la concienciación sobre la seguridad y cómo esto puede ayudar a crear un entorno de equipo coherente.

La seguridad debe ser la máxima prioridad para todos los miembros de la organización, y el CISO debe llevar a cabo de forma visible y transparente los esfuerzos necesarios para mantener los datos más seguros en todos los niveles. Quiero decir, ¿quién querría escuchar la misma vieja canción una y otra vez? Es hora de plantearse seriamente cómo eliminar para siempre los antiguos errores.