¿Nos ha fallado la Defensa en profundidad?
La defensa en profundidad es una filosofía con la que todos estamos familiarizados, que distribuye los controles de seguridad en todos los sistemas y los sistemas de TI para que, si uno falla o, si se explota una vulnerabilidad, haya otro para prevenir un ataque. Habiéndose convertido en una práctica estándar para la gran mayoría, esto suena como un gran enfoque, ¿verdad? Bueno, quizás mal. Si hay que creer la gran cantidad de titulares sobre compromisos e infracciones, así como la velocidad a la que ocurren, parecería que no ha funcionado. Por lo tanto, a pesar de todas sus promesas, tal vez la defensa en profundidad nos haya fallado.
¿Pero por qué?
El problema principal surge del hecho de que cada capa de defensa ha sido un producto puntual: una tecnología dispar que tiene su propia inteligencia y funciona dentro de su propio silo, lo que resulta en tres desafíos clave. En primer lugar, los silos pueden dificultar el intercambio de inteligencia (entre herramientas o incluso entre equipos) de forma real. En segundo lugar, la complejidad de la administración crece exponencialmente a medida que agrega consolas de administración adicionales para un equipo de seguridad ya extendido. Y tercero, estos silos de tecnología actúan como una carrera de obstáculos para el atacante. Como dice el refrán, «cada obstáculo es una oportunidad», y los atacantes aprovechan eso, navegando con éxito esta carrera de obstáculos todos los días hasta que cumplen su misión, ya sea robar, interrumpir o dañar lo que no es suyo. Por supuesto, con el tiempo los adversarios han evolucionado, al igual que las tecnologías para atraparlos, sin embargo, la arquitectura no. Entonces, incluso si el curso puede ser más difícil, sigue siendo un curso de todos modos.
A medida que las empresas incorporan nuevos productos y tecnologías, se encuentran con numerosos productos y proveedores de seguridad en numerosos silos. Y, dado que estos productos no están integrados, cada capa de la arquitectura crea sus propios registros y eventos, lo que genera una gran cantidad de datos y un enorme desafío de gestión. Entonces, ¿a dónde van todos estos datos y cómo puede mantenerse al día? Investigación reciente de ESG encuentra que el 42 por ciento de los profesionales de seguridad dicen que su organización ignora una cantidad significativa de alertas de seguridad debido al volumen y más del 30 por ciento dice que ignoran más de la mitad. En la mayoría de los casos, son los operadores de seguridad dentro del Centro de Operaciones de Seguridad (SOC) los que se ahogan en estos datos mientras llevan a cabo la onerosa tarea de correlacionar manualmente registros y eventos para investigaciones y otras actividades.
¿Cual es la solución?
En un intento por superar el desafío de la sobrecarga de datos, los SIEM surgieron como una forma de almacenar todos estos datos y agregar y correlacionar registros y eventos. Si bien esto ha funcionado hasta cierto punto, incluso los SIEM tienen limitaciones. En el frente de la tecnología, los SIEM pueden ser complejos y pueden enfrentar desafíos de escala con los volúmenes de datos actuales. En el frente económico, puede ser costoso para una empresa almacenar todo en el SIEM, por lo que eligen y eligen qué incluir y qué No a.
La herramienta elegida para los SOC ha sido el SIEM y ciertamente ha ayudado, pero el volumen de datos es tan grande que los operadores de seguridad aún no pueden mantenerse al día. Ahora están buscando formas de extraer datos de SIEM para encontrar amenazas e infracciones. Un caso de uso es aplicar datos de amenazas de una fuente externa (comercial, industrial, gubernamental, de código abierto, etc.) directamente al SIEM. Utilizando datos sobre amenazas que se encuentran «en la naturaleza», el objetivo es ver qué indicadores de compromiso (IoC) pueden estar ocultos en la gran cantidad de datos. En teoría, la aplicación de fuentes de amenazas directamente al SIEM debería funcionar y proporcionar algo de alivio, pero en realidad este enfoque crea desafíos nuevos y adicionales por múltiples razones:
- Falta de contexto: los SIEM solo pueden aplicar un contexto limitado (si lo hay) a los registros y eventos. El contexto proviene de la correlación de eventos e indicadores asociados desde el interior de su entorno con datos externos sobre indicadores, adversarios y sus métodos.
- Falsos positivos: sin contexto, es imposible determinar el ‘quién, qué, dónde, cuándo, por qué y cómo’ de un ataque, con el fin de evaluar la relevancia para su entorno. Como resultado, los SIEM generan frecuentes falsos positivos. Los operadores de seguridad terminan desperdiciando recursos valiosos y tiempo persiguiendo problemas que no importan.
- Relevancia cuestionable: los feeds de inteligencia de amenazas solo ofrecen puntajes de riesgo global basados en la investigación y la visibilidad del proveedor, no dentro del contexto del entorno específico de su empresa. Los operadores de seguridad que utilizan estos puntajes globales se encuentran persiguiendo fantasmas.
- Sin priorización: la priorización basada en parámetros específicos de la empresa es imperativa para una toma de decisiones más rápida que mejore la postura de seguridad. La prioridad de inteligencia debe calcularse a través de muchas fuentes separadas (tanto externas como internas) y actualizarse a medida que ingresan más datos y contexto al sistema.
- Limitaciones de la arquitectura SIEM: como se mencionó anteriormente, los SIEM mismos ya están abrumados por los grandes volúmenes de registros y eventos que genera la defensa en profundidad. Agregar millones y millones de datos adicionales no se escala de manera asequible. Además, los SIEM se crearon como una tecnología reactiva para recopilar registros y eventos que ocurrieron anteriormente. Agregar datos e inteligencia sobre amenazas para correlacionar, contextualizar y priorizar de manera proactiva no es el diseño principal de un SIEM.
¿El resultado? Se pasan por alto los indicadores de compromiso, se malgastan los escasos recursos y los ataques aún tienen éxito.
¿Cómo se pueden convertir los obstáculos en oportunidades?
Los SOC deben tomar una página de los atacantes y navegar con éxito esta carrera de obstáculos. Al aplicar automáticamente el contexto, la relevancia y la priorización a los datos de amenazas antes de aplicarlos al SIEM, el SIEM se vuelve más eficiente y efectivo. Las puntuaciones de inteligencia de amenazas personalizadas basadas en los parámetros que establezca, junto con el contexto, permiten la priorización en función de lo que es relevante para un entorno específico. Ahora, al utilizar un subconjunto de datos de amenazas que se ha seleccionado en inteligencia de amenazas, la superposición adicional permite que SIEM genere menos falsos positivos y encuentre menos problemas de escalabilidad.
Además, las empresas pueden hacer que toda su infraestructura de seguridad sea más efectiva utilizando esta inteligencia de amenazas como el pegamento para integrar capas de productos puntuales dentro de una estrategia de defensa en profundidad. Al compensar la falta de intercambio de información y proporcionar conocimientos más completos, este enfoque ayuda a los SOC a acelerar la detección y respuesta de amenazas y a mejorar las tecnologías preventivas con protección contra amenazas futuras.
Con menos ruido y operaciones optimizadas, los SOC pueden convertir los obstáculos en oportunidades. En lugar de ahogarse en datos, pueden priorizar sus investigaciones en las amenazas de mayor riesgo primero, evitar que los atacantes naveguen con éxito por la pista de obstáculos y mejorar la postura de seguridad.
Por Anthony Perridge, Director Regional, ThreatQuotient