En el marco de la actividad profesional, los desarrolladores, pentesters y expertos en seguridad deben enfrentarse a procesos como la Gestión de Vulnerabilidades (VM) y el SDLC (Secure).
Bajo estas frases se esconden diversos conjuntos de prácticas y herramientas utilizadas, que están entrelazadas, aunque sus usuarios son diferentes.
El progreso técnico aún no ha llegado a un punto en el que una herramienta pueda reemplazar al ser humano en el análisis de la seguridad de la infraestructura y el software.
Es interesante entender por qué es así y qué problemas deben enfrentarse.
Procesos
El proceso de Gestión de Vulnerabilidades está diseñado para el monitoreo continuo de la seguridad de la infraestructura y la gestión de parches.
El proceso de SDLC Seguro está destinado a apoyar la seguridad de la aplicación durante el desarrollo y operación.
Una parte similar de estos procesos es el proceso de Evaluación de Vulnerabilidades, que implica escaneos para detectar vulnerabilidades.
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 externo o en la configuración. Por ejemplo, una versión desactualizada de Windows o una cadena de comunidad predeterminada para SNMP.
En el segundo caso, el objetivo es identificar vulnerabilidades no solo en componentes externos (dependencias), sino principalmente en el código del nuevo producto.
Esto genera diferencias en herramientas y enfoques. En mi opinión, la tarea de encontrar nuevas vulnerabilidades en la aplicación es considerablemente más interesante, ya que no se limita a la identificación de versiones, recolección de banners, fuerza bruta de contraseñas, etc.
Para un escaneo automatizado de vulnerabilidades de aplicaciones de calidad, se necesitan algoritmos que tengan en cuenta la semántica de la aplicación, su propósito y amenazas específicas.
Un escáner de infraestructura, por otro lado, a menudo puede ser reemplazado por un temporizador, como expresó La idea es que, de manera puramente estadística, puedes considerar que tu infraestructura es vulnerable si no la has actualizado, digamos, en un mes.
Herramientas
El escaneo, al igual que el análisis de seguridad, puede realizarse tanto como una caja negra como una caja blanca.
Caja Negra
En el escaneo de caja negra, la herramienta debe ser capaz de interactuar con el servicio a través de las mismas interfaces que utilizan los usuarios.
Los escáneres de infraestructura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) buscan puertos de red abiertos, recopilan "banners", determinan las versiones del software instalado y buscan en su base de conocimientos información sobre vulnerabilidades en esas versiones. También intentan detectar errores de configuración, como contraseñas predeterminadas o acceso no autorizado a datos, cifrados débiles SSL, etc.
Los escáneres de aplicaciones web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) también son capaces de identificar componentes conocidos y sus versiones (por ejemplo, CMS, frameworks, bibliotecas JS). Los pasos principales del escáner son el crawling y el fuzzing.
Durante el crawling, el escáner recopila información sobre las interfaces existentes de la aplicación y los parámetros HTTP. Durante el fuzzing, se insertan datos mutados o generados en todos los parámetros descubiertos con la finalidad de provocar un error y detectar una vulnerabilidad.
Estos escáneres de aplicaciones pertenecen a las clases DAST e IAST, es decir, Dynamic y Interactive Application Security Testing.
Caja Blanca
Con el escaneo de caja blanca, hay más diferencias.
En el marco del proceso de VM, a los escáneres (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) a menudo se les da acceso a los sistemas, realizando un escaneo autenticado. De esta forma, el escáner puede extraer las versiones de los paquetes instalados y los parámetros de configuración directamente del sistema, sin tener que adivinarlos a partir de los banners de los servicios de red.
El escaneo resulta ser más preciso y completo.
En cuanto al escaneo de caja blanca (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) de aplicaciones, generalmente se refiere al análisis estático del código y al uso de herramientas correspondientes de la clase SAST — Static Application Security Testing.
Problemas
¡Hay muchos problemas con el escaneo! Con la mayoría de ellos me enfrento personalmente en el marco de la prestación de servicios para establecer procesos de escaneo y desarrollo seguro, así como al llevar a cabo trabajos de análisis de seguridad.
Destacaré 3 grupos principales de problemas, que se confirman tanto por mis conversaciones con ingenieros como con directores de departamentos de ciberseguridad en diversas empresas.
Problemas en el escaneo de aplicaciones web
- Dificultad de implementación. Los escáneres deben ser desplegados, configurados y personalizados para cada aplicación, dedicando un entorno de prueba para los escaneos e integrándolos en el proceso de CI/CD para que sean efectivos. De lo contrario, será un procedimiento formal inútil que solo generará falsas alarmas.
- Duración del escaneo. Los escáneres, incluso en 2019, tienen dificultades con la deduplicación de interfaces y pueden tardar días en escanear mil páginas con 10 parámetros cada una, considerándolas diferentes, a pesar de que el mismo código se encarga de ellas. Además, la decisión de desplegar en producción dentro del ciclo de desarrollo debe tomarse rápidamente.
- Recomendaciones escasas. Los escáneres proporcionan recomendaciones bastante generales, y no siempre el desarrollador puede entender rápidamente cómo reducir el nivel de riesgo, y lo más importante, si debe hacerlo de inmediato o si puede esperar.
- Impacto destructivo en la aplicación. Los escáneres pueden llevar a cabo un ataque DoS contra la aplicación y pueden crear una gran cantidad de entidades o modificar las existentes (por ejemplo, generar decenas de miles de comentarios en un blog), por lo que no se debe ejecutar un escaneo sin pensar en producción.
- Baja calidad en la detección de vulnerabilidades. Los escáneres suelen utilizar un conjunto fijo de cargas útiles y pueden fácilmente pasar por alto una vulnerabilidad que no encaja en el escenario de comportamiento conocido.
- Incomprensión de las funciones de la aplicación por parte del escáner. Los escáneres en sí no saben qué es un 'banco en línea', 'pago' o 'comentario'. Para ellos solo existen enlaces y parámetros, por lo que una gran cantidad de posibles vulnerabilidades en la lógica de negocio queda completamente descubierta; no deducirán un cargo duplicado, no verán datos ajenos por ID o aumentarán el saldo a través del redondeo.
- Incomprensión de la semántica de las páginas por parte del escáner. Los escáneres no pueden leer FAQ, no pueden reconocer captchas, no deducirán cómo registrarse y que después hay que volver a iniciar sesión, que no se debe presionar 'logout', y cómo se deben firmar las solicitudes al cambiar los valores de los parámetros. Como resultado, gran parte de la aplicación puede quedar sin escanear.
Problemas de escaneo del código fuente.
- Falsas alarmas. El análisis estático es una tarea compleja que implica numerosos compromisos. A menudo, se sacrifica la precisión, incluso los escáneres empresariales costosos generan una gran cantidad de falsos positivos.
- Dificultad de implementación. Para aumentar la precisión y la exhaustividad del análisis estático, es necesario desarrollar las reglas de escaneo, y la redacción de estas reglas puede resultar demasiado laboriosa. A veces es más fácil encontrar todos los lugares en el código con algún error y corregirlos que escribir una regla para detectar tales casos.
- Falta de soporte para dependencias. Los grandes proyectos dependen de una gran cantidad de bibliotecas y frameworks que amplían las capacidades del lenguaje de programación. Si la base de conocimientos del escáner no contiene información sobre los puntos peligrosos ("sinks") en estos frameworks, esto se convertirá en un vacío, y el escáner no podrá entender el código.
- Duración del escaneo. La búsqueda de vulnerabilidades en el código es una tarea compleja también en términos de algoritmos. Por lo tanto, el proceso puede prolongarse y requerir recursos computacionales significativos.
- Bajo nivel de cobertura. A pesar del consumo de recursos y la duración del escaneo, los desarrolladores de herramientas SAST todavía deben recurrir a compromisos y no analizan todos los estados en los que puede encontrarse el programa.
- Reproducibilidad de los hallazgos. Indicar una línea específica y una pila de llamadas que conducen a una vulnerabilidad es genial, pero en realidad, a menudo el escáner no proporciona suficiente información para verificar la existencia de la vulnerabilidad externamente. El defecto puede estar en el código muerto que es inalcanzable para un atacante.
Problemas de escaneo de infraestructura.
- Inventario insuficiente. En grandes infraestructuras, especialmente las geográficamente distribuidas, a menudo es más difícil entender qué hosts deben ser escaneados. En otras palabras, la tarea de escaneo está estrechamente relacionada con la gestión de activos.
- Pobre priorización. Los escáneres de red a menudo producen muchos resultados con defectos que, en la práctica, no son explotables, pero formalmente se consideran de alto riesgo. El consumidor recibe un informe que es difícil de interpretar y no está claro qué debe corregirse primero.
- Recomendaciones escasas. En la base de conocimientos del escáner, a menudo solo hay información muy general sobre la vulnerabilidad y cómo corregirla, por lo que los administradores tendrán que equiparse con Google. La situación es un poco mejor con los escáneres whitebox, que pueden proporcionar un comando específico para la corrección.
- Trabajo manual. En las infraestructuras puede haber muchos nodos, lo que significa que potencialmente hay muchas vulnerabilidades, cuyos informes deben ser analizados manualmente en cada iteración.
- Cobertura deficiente. La calidad del escaneo de la infraestructura depende directamente del volumen de la base de conocimientos sobre vulnerabilidades y versiones de software. Sin embargo, , incluso los líderes del mercado tienen bases de conocimientos que no son exhaustivas, y en las bases de soluciones gratuitas hay mucha información que no poseen los líderes.
- Problemas con el parcheo. La mayoría de las veces, el parcheo de vulnerabilidades en la infraestructura implica actualizar un paquete o cambiar un archivo de configuración. El gran problema aquí es que el sistema, especialmente uno legado, puede comportarse de forma impredecible como resultado de la actualización. En esencia, será necesario realizar pruebas de integración en la infraestructura en vivo en producción.
Enfoques
¿Qué hacer entonces?
En las siguientes partes, hablaré más sobre ejemplos y sobre cómo abordar muchos de los problemas mencionados, mientras que ahora señalaré las principales direcciones en las que se puede trabajar:
- Agregación de diversas herramientas de escaneo. Con el uso adecuado de varios escáneres, es posible lograr un aumento significativo en la base de conocimientos y la calidad de la detección. Se pueden encontrar incluso más vulnerabilidades que sumando todas las que se detectan por separado, además de poder evaluar con mayor precisión el nivel de riesgo y dar más recomendaciones.
- Integración de SAST y DAST. Se puede aumentar la cobertura de DAST y la precisión de SAST mediante el intercambio de información entre ellos. Desde los fuentes, se puede obtener información sobre las rutas existentes, y con DAST se puede comprobar si la vulnerabilidad es visible externamente.
- Machine Learning™. En 2015, yo (y ) sobre la aplicación de la estadística para dar a los escáneres la intuición de un hacker y acelerarlos. Esto definitivamente es un terreno fértil para el desarrollo del análisis automático de la seguridad en el futuro.
- Integración de IAST con pruebas automáticas y OpenAPI. En el marco del pipeline CI/CD, es posible crear un proceso de escaneo basado en herramientas que funcionan como proxy HTTP, así como pruebas funcionales que operan sobre HTTP. Las pruebas y contratos de OpenAPI/Swagger proporcionarán al escáner la información faltante sobre los flujos de datos y permitirán escanear la aplicación en diferentes estados.
- Configuración correcta. Es necesario crear un perfil de escaneo adecuado para cada aplicación e infraestructura, que considere la cantidad y naturaleza de las interfaces y las tecnologías utilizadas.
- Personalización de escáneres. A menudo, no se puede escanear la aplicación sin modificar el escáner. Un ejemplo es la pasarela de pago, en la que cada solicitud debe estar firmada. Sin desarrollar un conector para el protocolo de la pasarela, los escáneres intentarán enviar solicitudes con firmas incorrectas sin pensar. También es necesario crear escáneres especializados para tipos específicos de vulnerabilidades, como
- Gestión de riesgos. El uso de diversos escáneres e integración con sistemas externos, como Gestión de Activos y Gestión de Amenazas, permitirá utilizar múltiples parámetros para evaluar el nivel de riesgo, de modo que la dirección pueda obtener una imagen adecuada sobre el estado actual de la seguridad en el desarrollo o infraestructura.
¡Mantente atento y revolucionemos el escaneo de vulnerabilidades!
Fuente: habr.com
