X
BLOG

Por qué las vulnerabilidades de Appsec se descartan como "teóricas" o "falsas"

Por qué las vulnerabilidades de Appsec se descartan como "teóricas" o "falsas" Tiempo de leer: 6 minutos

Este contenido se publicó originalmente el El blog del código cascarrabias.

By Arthur Hicken, Evangelista jefe en Parasoft

En una Publicación anterior sobre las vulnerabilidades teóricas de Appsec, cubrí cómo "es teórico" es mal utilizado por aquellos que intentan evitar reparar una vulnerabilidad de seguridad o asumir la responsabilidad de ella, por ejemplo, el Brecha de Lenovo Superfishheartbleedataques wifi de aerolíneas.

La idea de que una vulnerabilidad es meramente teórica no solo es ignorante sino peligrosa. Las vulnerabilidades de software se producen porque los delincuentes operan encontrando lagunas inesperadas en un sistema de software. Piénselo de esta manera: si dejó la puerta abierta, ¿es un problema de seguridad? O tal vez "Si nunca se ingresa una puerta sin llave, ¿está realmente abierta" si es un filósofo? Se podría sostener que el riesgo es teórico, pero la mayoría de nosotros diría que tal afirmación es ridícula. (Accesorios para quienes viven en un área donde no se requiere seguridad en la puerta).

Las vulnerabilidades del software son exactamente como puertas abiertas. No son teóricos, son todo o aperturas reales en su software que pueden y probablemente serán explotadas. Si queremos tener aplicaciones seguras, debemos crecer y dejar de fingir que las vulnerabilidades a las que nos enfrentamos no son reales. Tenemos que adoptar un enfoque proactivo basado en la ingeniería preventiva que trate las vulnerabilidades como riesgos reales, solo así podremos estar seguros.

Sin embargo, la gente sigue justificando ignorar los resultados de sus escáneres de seguridad. ¿Cómo racionalizan esto? Sin ningún orden en particular ...

ruido

¡Ruido, ruido, ruido! No importa cómo lo llames, ya sean falsos positivos, falsas alarmas, problemas teóricos, demasiados mensajes o cualquier otra cosa, el ruido es un gran dolor. Jeff dice que la precisión importa y, de hecho, lo es. Pero en mi experiencia, los desarrolladores son tremendamente rápidos en apretar el gatillo del "ruido". Sería divertido hacer una encuesta / cuestionario con un par de ejemplos de código real y ver qué piensan los desarrolladores. El cuestionario básico de seguridad de aplicaciones en el Blog de AppSec Notes pero no expone los problemas de conocimiento relacionados con el reconocimiento de vulnerabilidades de seguridad reales en el código real. En otras palabras, ¿reconocería por qué un fragmento de código es peligroso si lo viera? Me gustaría ver el cuestionario que tiene tanto código bueno como ejemplos de código incorrecto y la pregunta "problema de seguridad o bien". Esto es más complicado de lo que parece al principio porque no puede simplemente tener un código incorrecto y un código fijo, necesita un código incorrecto y luego un código sospechoso que probablemente generaría una falsa alarma. Ahora hay una prueba real. Si alguien sabe de una bestia así o quiere construir una, asegúrese de hacérmelo saber.

El ruido puede empeorar aún más si tiene objetivos y métricas falsas. Por ejemplo, si basa el éxito en la “cantidad de problemas encontrados”, es probable que encuentre la mayor cantidad de problemas sin importancia. Hay mejores definiciones de éxito discutidas en la presentación. Teoría de la ventana rota de AppSec que vale la pena leer. Un ejemplo rápido es rastrear el éxito por el número de "fallas no encontradas" en nuevas aplicaciones.

Otro punto sobre el ruido, particularmente en el área de lo que a la gente le gusta llamar falsos positivos. Tengo la “Ley cascarrabias de la utilidad de la herramienta de análisis estático”. Cuanto más inteligente sea una herramienta de análisis estático, más probable será que su resultado se perciba como un falso positivo. Esto se debe a que es fácil aceptar un resultado que comprende, pero si una herramienta intenta decirle algo que no sabe (es decir, el resultado más útil) es menos probable que lo acepte. Es por eso que sigo presionando en a) una mejor presentación de los resultados para explicar POR QUÉ es importante yb) una mejor capacitación.

Mal flujo de trabajo o proceso

Esto está estrechamente relacionado con el problema del ruido. Si tiene un flujo de trabajo, un proceso o una configuración deficientes, el análisis de seguridad le resultará doloroso. A veces, este dolor es ruido, a veces es un esfuerzo adicional, trabajo lento u otros síntomas. Por ejemplo, había visto a personas escanear análisis estáticos en código heredado donde la política corporativa era "sin cambios a menos que haya un error informado en el campo". Escanear el código que no tiene la intención de corregir o buscar elementos que no tiene la intención de reparar ciertamente contribuye al ruido, el esfuerzo requerido y los costos.

La conclusión es asegurarse de que sus herramientas estén configuradas de manera óptima y que la forma en que se integran en su proceso no le cause dolores de cabeza. Podría dedicarme mucho tiempo a este tema, pero lo guardaremos para otro día. ¿Cómo saber si está causando dolores de cabeza? Pregunte a los que están usando las herramientas y a los que deben abordar el resultado de las herramientas.

Otra gran lectura sobre este tema es ¿El progreso proviene de los productos o procesos de seguridad? donde Gunnar Peterson dice "La ingeniería de procesos es profundamente poco atractiva. Está tan lejos del glamour, el mundo de los desfiles de moda de las conferencias de seguridad como pueda imaginar, pero es donde ocurren los cambios reales."

Priorización

Nuevamente, esta es una categoría estrechamente relacionada con el ruido. El ruido es un síntoma de la falta de priorización en los hallazgos de su appsec. Idealmente, está almacenando toda la salida de todas sus herramientas de seguridad en su arsenal en un sistema inteligente basado en datos que lo ayudará a determinar qué elementos son más importantes. Nadie quiere pasar semanas arreglando algo que es poco probable que suceda e incluso si sucediera, las consecuencias son mínimas.

La priorización de AppSec debe tener en cuenta el riesgo. ¿Ocurrirá esto? ¿Sucede esto hoy? ¿Qué tan difícil es explotar? ¿Qué tan difícil es prevenirlo? Además de todas las demás preguntas habituales sobre gestión de riesgos. Sabes qué hacer, si tienes demasiado ruido de tus herramientas, necesitas poner algo de inteligencia detrás para llegar a lo que importa.

Tenga en cuenta que cuando digo priorización no me refiero necesariamente a la clasificación. La clasificación implica un proceso impulsado por el ser humano (ver cuello de botella) que hace concesiones dolorosas en un período corto de tiempo en lugar de un proceso ordenado y bien pensado. En el Ventanas rotas presentación que mencioné anteriormente Erik Peterson dice "Triage! = Programa de seguridad de aplicaciones" y estoy totalmente de acuerdo.

Es por eso que soy un fanático del intento de desarrollar marcos de aplicaciones de riesgo integrales. Algunos de estos son los Sistema de puntuación de debilidad común (CWSS) que se gestiona en Mitre. CWSS propone una forma de sopesar adecuadamente los hallazgos de seguridad en el contexto de su aplicación, lo que debería permitir una mejor priorización automatizada. Esto va de la mano con el Marco común de análisis de riesgo de debilidad (CWRAF).

Sé que están lejos de ser perfectos y, de hecho, con frecuencia son demasiado complicados y dolorosos de usar. La investigación en esta área garantizará una mejora continua y espero que, en última instancia, se convierta en el impulsor crítico en el espacio de escaneo de aplicaciones.

Prueba de seguridad en

Todos hemos escuchado el dicho de que "no se puede probar la calidad en una aplicación". Esto se basa en el tercer principio de Deming: "dejar de depender de la inspección para lograr la calidad". Al principio, muchos no estaban de acuerdo con Deming, pero hoy es una verdad aceptada que la inspección por sí sola no resolverá sus problemas. Sin embargo, de alguna manera en AppSec, muchos creen que podemos "probar la seguridad en una aplicación". Esta actitud es fácil de reconocer porque da como resultado procesos de seguridad que son completamente ortogonales al desarrollo, y se destacan porque todas las actividades de seguridad son actividades de tipo QA posteriores al desarrollo. Ese método no funcionó para la calidad y no funcionará para la seguridad.

Para adelantarnos a los problemas de seguridad del software, tenemos que empezar a crear software seguro en primer lugar. Hay un gran sitio patrocinado por el gobierno de EE. UU. Llamado Construya seguridad en y tiene mucha información excelente para comenzar. También eche un vistazo a Construcción de seguridad en el modelo de madurez. Me doy cuenta de que es más fácil de decir “Introdúzcalo” de lo que realmente debe hacer y eso para construirlo trae sus propios desafíos. Pero al igual que la fabricación y la calidad, es la única forma de obtener una mejora sostenible a largo plazo.

Capacitación

La Instituto SANS hizo un encuesta sobre programas y prácticas de seguridad de aplicaciones y se encontró

“Aunque los proveedores continúan mejorando la velocidad y precisión de las herramientas SAST y haciéndolas más fáciles de usar, los desarrolladores necesitan capacitación en seguridad o ayuda experta para comprender lo que les dicen las herramientas, qué vulnerabilidades son importantes, por qué necesitan ser reparadas y cómo arreglalos."

El informe señala que solo el 26% de las organizaciones tenían capacitación en codificación segura que funcionaba bien o era obligatoria. Además se lee

“La falta de conocimientos y habilidades está frenando los programas de Appsec en la actualidad y está impidiendo que las organizaciones logren un progreso real en Appsec en el futuro. El obstáculo número uno para el éxito informado en la encuesta de este año es la escasez de personas capacitadas, parte de un problema mayor que enfrenta la industria de la seguridad de TI en general, como muestran estudios recientes de Forrester Research13 e (ISC) 214.

Se necesita capacitación y educación para abordar esta escasez de habilidades, no solo capacitar a más especialistas en Infosec y Appsec, sino también capacitar a desarrolladores y gerentes. Menos de una cuarta parte de los encuestados tiene programas de capacitación en curso y que funcionan bien, y la capacitación en codificación segura ocupa un lugar bajo en la lista de prácticas de las que dependen las organizaciones en sus programas de Appsec en la actualidad. Esto necesita cambiar. "

OWASP habla sobre el importancia de la formación

"Desde la perspectiva de la seguridad de la información, el enfoque holístico hacia la seguridad de las aplicaciones debe incluir, por ejemplo, capacitación en seguridad para los desarrolladores de software, así como para los oficiales y gerentes de seguridad ..."

encuesta en 2010 mostró que no se estaba impartiendo capacitación en seguridad y sospecho que hoy en día poco ha cambiado.

"Casi el 80% del personal de las agencias gubernamentales y los contratistas dijo que su organización no brinda suficiente capacitación y orientación para el desarrollo y la entrega de aplicaciones de seguridad de software, según una nueva encuesta".

Resumen

Las herramientas por sí solas y la precisión de las herramientas no resolverán por completo los problemas de AppSec. Nuevamente, de la encuesta de Sans

“No hay herramientas de próxima generación u otras fórmulas mágicas en el horizonte que resuelvan el problema del software seguro. La redacción de software seguro se basa en los fundamentos: diseño reflexivo, codificación cuidadosa, pruebas disciplinadas y gestión informada y responsable. Cuanto antes las organizaciones comprendan esto y empiecen a hacerlo, antes resolverán sus problemas de seguridad. "

Las falsas alarmas y la precisión son un gran problema. También lo es la falta de formación. No quisiera argumentar que uno es más importante que el otro, porque fácilmente podría encontrarme discutiendo ambos lados. Ambos son importantes. Hasta que tengamos un herramienta de seguridad perfecta, lo que significa que no hay falsas alarmas e igualmente importante, no hay falsos negativos, la capacitación desempeñará un papel integral necesario en la seguridad de las aplicaciones (appsec) y la seguridad del software (swsec).

Escrito por

Parasoft

Las herramientas de prueba de software automatizadas líderes en la industria de Parasoft respaldan todo el proceso de desarrollo de software, desde que el desarrollador escribe la primera línea de código hasta las pruebas unitarias y funcionales, hasta las pruebas de rendimiento y seguridad, aprovechando los entornos de prueba simulados en el camino.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft