Como parte de sus actividades profesionales, los desarrolladores, los pentesters y los profesionales de seguridad tienen que lidiar con procesos como Vulnerability Management (VM), (Secure) SDLC.
Debajo de estas frases hay diferentes conjuntos de prácticas y herramientas utilizadas que están entrelazadas, aunque sus consumidores difieren.
El progreso técnico aún no ha llegado al punto de reemplazar a una persona con una herramienta para analizar la seguridad de la infraestructura y el software.
Es interesante entender por qué esto es así y qué problemas tiene que enfrentar.
Los procesos
El proceso de gestión de vulnerabilidades está destinado a la supervisión continua de la seguridad de la infraestructura y la gestión de parches.
El proceso Secure SDLC ("ciclo de desarrollo seguro") está diseñado para admitir la seguridad de la aplicación durante el desarrollo y la operación.
Una parte similar de estos procesos es el proceso de Evaluación de Vulnerabilidad: evaluación de vulnerabilidad, escaneo de vulnerabilidad.
La principal diferencia en el escaneo dentro de VM y SDLC es que, en el primer caso, el objetivo es detectar vulnerabilidades conocidas en software de terceros o en una configuración. Por ejemplo, una versión desactualizada de Windows o la cadena de comunidad predeterminada para SNMP.
En el segundo caso, el objetivo es detectar vulnerabilidades no solo en componentes de terceros (dependencias), sino principalmente en el código del nuevo producto.
Esto da lugar a diferencias en las herramientas y enfoques. En mi opinión, la tarea de encontrar nuevas vulnerabilidades en la aplicación es mucho más interesante, ya que no se reduce a las versiones de huellas digitales, la recopilación de pancartas, la clasificación de contraseñas, etc.
El escaneo automatizado de alta calidad de las vulnerabilidades de la aplicación requiere algoritmos que tengan en cuenta la semántica de la aplicación, su propósito, las amenazas específicas.
El escáner de infraestructura a menudo se puede reemplazar por un temporizador, como
lo dijo
avleonov . El punto es que, puramente estadísticamente, puede considerar su infraestructura vulnerable si no la actualizó, por ejemplo, un mes.
Las herramientas
El escaneo, así como el análisis de seguridad, se pueden realizar como un cuadro negro o un cuadro blanco.
Caja negra
Cuando se escanea el blackbox, la herramienta debe poder trabajar con el servicio a través de las mismas interfaces a través de las cuales los usuarios trabajan con él.
Los escáneres de infraestructura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) buscan puertos de red abiertos, recopilan "pancartas", determinan las versiones de software instaladas y buscan en su base de conocimiento información sobre vulnerabilidades en estas versiones. También intentan detectar errores de configuración, como contraseñas predeterminadas o acceso abierto a datos, cifrados SSL débiles, etc.
Los escáneres de aplicaciones web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) también saben cómo determinar los componentes conocidos y sus versiones (por ejemplo, CMS, frameworks, bibliotecas JS). Los pasos principales del escáner son gatear y difuminarse.
Durante el rastreo, el escáner recopila información sobre las interfaces de aplicaciones existentes, los parámetros HTTP. Durante el fuzzing, todos los parámetros detectados se sustituyen con datos mutados o generados para provocar un error y detectar vulnerabilidad.
Dichos escáneres de aplicaciones pertenecen a las clases DAST e IAST: pruebas de seguridad de aplicaciones dinámicas e interactivas, respectivamente.
Caja blanca
Los escaneos de Whitebox tienen más diferencias.
A lo largo del proceso, los escáneres VM (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) a menudo tienen acceso a los sistemas mediante la realización de un análisis autenticado. Por lo tanto, el escáner puede descargar versiones instaladas de paquetes y parámetros de configuración directamente desde el sistema, sin adivinarlos en los banners de los servicios de red.
El escaneo es más preciso y completo.
Si hablamos de escaneo de caja blanca (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) de aplicaciones, generalmente hablamos sobre análisis de código estático y el uso de las herramientas correspondientes de la clase SAST - Pruebas de seguridad de aplicaciones estáticas.
Los problemas
¡Hay muchos problemas con el escaneo! Tengo que tratar con la mayoría de ellos personalmente en el marco de la prestación de un servicio para crear procesos de escaneo y desarrollo seguro, así como al realizar trabajos de análisis de seguridad.
Destacaré 3 grupos principales de problemas, que se confirman mediante conversaciones con ingenieros y gerentes de servicios de seguridad de la información en varias empresas.
Problemas de escaneo de aplicaciones web
- La complejidad de la implementación. Los escáneres deben implementarse, configurarse, personalizarse para cada aplicación, asignarse un entorno de prueba para los análisis e implementarse en el proceso de CI / CD para que sean efectivos. De lo contrario, será un procedimiento formal inútil, que dará solo falsos positivos.
- Duración del escaneo. Los escáneres, incluso en 2019, funcionan mal con la deduplicación de la interfaz y pueden escanear miles de páginas durante 10 días con 10 parámetros en cada uno, considerándolos diferentes, aunque el mismo código es responsable de ellos. Al mismo tiempo, la decisión de desplegarse en producción dentro del ciclo de desarrollo debe tomarse rápidamente
- Pocas recomendaciones. Los escáneres ofrecen recomendaciones bastante generales, y no siempre es posible que un desarrollador comprenda rápidamente cómo reducir el nivel de riesgo y, lo que es más importante, si debe hacerse en este momento o no.
- Efecto destructivo sobre la aplicación. Los escáneres pueden llevar a cabo un ataque DoS en la aplicación, y también pueden crear una gran cantidad de entidades o modificar las existentes (por ejemplo, crear decenas de miles de comentarios en un blog), así que no inicies un escaneo sin pensar en el producto.
- Detección de vulnerabilidades de baja calidad. Los escáneres generalmente usan una matriz de cargas fijas y pueden pasar por alto fácilmente una vulnerabilidad que no se ajusta a su escenario conocido de comportamiento de la aplicación.
- El escáner no comprende las funciones de la aplicación. Los escáneres mismos no saben qué son "banca por Internet", "pago" y "comentario". Para ellos, solo hay enlaces y parámetros, por lo que una enorme capa de posibles vulnerabilidades en la lógica empresarial permanece completamente descubierta, no adivinarán escribir dos veces, espiar los datos de otras personas por ID o liquidar el saldo a través del redondeo
- El escáner no comprende la semántica de la página. Los escáneres no saben cómo leer las preguntas frecuentes, no saben cómo reconocer captchas, por sí mismos no adivinarán cómo registrarse, y luego deben iniciar sesión, que no pueden hacer clic en "cerrar sesión" y cómo firmar solicitudes al cambiar los valores de los parámetros. Como resultado, la mayor parte de la aplicación puede no escanearse en absoluto.
Problemas de escaneo del código fuente
- Falsos positivos. El análisis estático es una tarea difícil, para resolver lo que es necesario recurrir a muchos compromisos. A menudo hay que sacrificar la precisión, e incluso los costosos escáneres empresariales producen una gran cantidad de falsos positivos.
- La complejidad de la implementación. Para aumentar la precisión y la integridad del análisis estático, es necesario refinar las reglas de escaneo, y escribir estas reglas puede llevar demasiado tiempo. A veces es más fácil encontrar todos los lugares en el código con algún tipo de error y corregirlos, que escribir una regla para detectar tales casos
- Falta de soporte de dependencia. Los grandes proyectos dependen de una gran cantidad de bibliotecas y marcos que amplían las capacidades del lenguaje de programación. Si la base de conocimiento del escáner no tiene información sobre "sumideros" en estos marcos, esto se convertirá en un punto ciego y el escáner simplemente ni siquiera entenderá el código
- Duración del escaneo. Encontrar vulnerabilidades en el código es una tarea difícil en términos de algoritmos. Por lo tanto, el proceso puede retrasarse y requerir importantes recursos informáticos.
- Baja cobertura A pesar del consumo de recursos y la duración de la exploración, los desarrolladores de herramientas SAST todavía tienen que recurrir a compromisos y analizar no todas las condiciones en las que el programa puede estar
- Reproducibilidad de hallazgos. Señalar una línea específica y una pila de llamadas que conducen a una vulnerabilidad está bien, pero en realidad el escáner a menudo no proporciona suficiente información para verificar una vulnerabilidad externa. Después de todo, una falla también puede estar en código muerto, lo cual es inalcanzable para un atacante
Problemas de escaneo de infraestructura
- Inventario inadecuado. En grandes infraestructuras, especialmente separadas geográficamente, a menudo es más difícil entender qué hosts necesitan ser escaneados. En otras palabras, la tarea de escaneo está estrechamente relacionada con la tarea de gestión de activos.
- Mala priorización. Los escáneres de red a menudo producen muchos resultados con inconvenientes que no son explotables en la práctica, pero formalmente su nivel de riesgo es alto. El consumidor recibe un informe que es difícil de interpretar, y no está claro qué debe arreglarse primero
- Pocas recomendaciones. La base de conocimiento del escáner a menudo tiene información muy general sobre la vulnerabilidad y cómo solucionarla, por lo que los administradores tendrán que armarse con Google. La situación es un poco mejor con los escáneres de caja blanca que pueden emitir un comando específico para solucionar
- Trabajo manual Las infraestructuras pueden tener muchos nodos, lo que significa que hay potencialmente muchas deficiencias, informes sobre los cuales deben desmontarse y analizarse manualmente en cada iteración
- Mala cobertura La calidad del escaneo de la infraestructura depende directamente del volumen de la base de conocimiento sobre vulnerabilidades y versiones de software. Al mismo tiempo, resulta que incluso los líderes del mercado no tienen una base de conocimiento integral, y hay una gran cantidad de información en las bases de datos de soluciones gratuitas que los líderes no tienen.
- Problemas con parches. El parche más común para vulnerabilidades en la infraestructura es actualizar el paquete o cambiar el archivo de configuración. El gran problema aquí es que el sistema, especialmente el heredado, puede comportarse de manera impredecible como resultado de una actualización. En esencia, deberá realizar pruebas de integración en la infraestructura viva en producción.
Los enfoques
Como ser
Te contaré más sobre ejemplos y cómo lidiar con muchos de estos problemas en las siguientes partes, pero por ahora te indicaré las principales áreas en las que puedes trabajar:
- Agregación de diversas herramientas de escaneo. Con el uso correcto de múltiples escáneres, se puede lograr un aumento significativo en la base de conocimiento y la calidad de la detección. Puede encontrar aún más vulnerabilidades que en total todos los escáneres lanzados por separado, mientras que es posible evaluar con mayor precisión el nivel de riesgo y dar más recomendaciones
- Integración de SAST y DAST. Puede aumentar la cobertura DAST y la precisión SAST compartiendo información entre ellos. Desde la fuente puede obtener información sobre las rutas existentes, y con DAST puede verificar si la vulnerabilidad es visible desde el exterior
- Machine Learning ™ . En 2015, hablé (y aún ) sobre el uso de estadísticas para dar a los hackers la intuición de los escáneres y acelerarlos. Esto definitivamente es alimento para el desarrollo de futuros análisis de seguridad automatizados.
- Integración de IAST con autotest y OpenAPI. En el marco de la canalización de CI / CD, es posible crear un proceso de escaneo basado en herramientas que funcionan como proxies HTTP y pruebas funcionales que funcionan en HTTP. Las pruebas y los contratos de OpenAPI / Swagger le darán al escáner la información que falta sobre los flujos de datos y permitirán escanear la aplicación en varios estados
- Configuración correcta Para cada aplicación e infraestructura, debe crear un perfil de escaneo adecuado que tenga en cuenta el número y la naturaleza de las interfaces, las tecnologías utilizadas
- Personalización de escáneres. A menudo, una aplicación no se puede escanear sin finalizar el escáner. Un ejemplo es una pasarela de pago en la que se debe firmar cada solicitud. Sin escribir un conector en el protocolo de la puerta de enlace, los escáneres superarán sin pensar las solicitudes con la firma incorrecta. También es necesario escribir escáneres especializados para un tipo específico de falla, como la Referencia directa insegura de objetos
- Gestión de riesgos. El uso de diversos escáneres y la integración con sistemas externos, como la Gestión de activos y la Gestión de amenazas, le permitirán utilizar muchos parámetros para evaluar el nivel de riesgo, de modo que la administración pueda obtener una imagen adecuada del estado de seguridad actual del desarrollo o la infraestructura.
¡Estén atentos e interrumpamos el escaneo de vulnerabilidades!