Las respuestas cortas son: muchos ataques / actividades no crearán un evento para que el SIEM lo procese.
Sin embargo, esto depende de 1) el tipo de ataque y 2) el estado de la infraestructura de registro . Pero incluso si el ataque en sí no se registra explícitamente (digamos con una alerta de firma IPS), hay 3) formas de detectar actividad anómala o lo que yo llamo las “huellas de un ataque”.
1. El tipo de ataque determina qué tan fácil es detectar con un SIEM. El mejor caso es cuando ve el evento real (es decir, “la pistola humeante”), como un IPS o AV durante la fase de entrega de la carga útil de un ataque, es decir, la fase de “explotación” en la Cadena de asesinatos cibernéticos. Estos ataques son eventos 1: 1 donde un solo evento puede asignarse a un solo incidente o boleto para investigación. Por supuesto, hay muchos falsos positivos con este enfoque y las mejores implementaciones de monitoreo de amenazas realizan el ajuste y la creación necesarios de políticas de correlación.
- Ciberguerra: ¿Debería considerarse el supuesto ciberataque de Corea del Norte contra Sony un acto de guerra?
- ¿Cuáles son los mayores defectos de seguridad en nuestras vidas digitales?
- ¿Qué tipo de código ayuda más con la seguridad cibernética?
- ¿Es cierto que la seguridad de CCIE es más difícil que otros CCIE?
- ¿Cuál es la mejor empresa de pruebas de penetración?
Otros tipos de ataque que generan un mensaje de registro directo pero que requieren correlación incluyen registros de hosts como eventos de autenticación, escalamiento privilegiado, registros de acceso a datos confidenciales, etc. Cada evento individual (como un inicio de sesión fallido) no es procesable, sino un grupo de mensajes con el tiempo puede ser accionable, por ejemplo, el ataque del diccionario da como resultado muchos inicios de sesión fallidos, inicios de sesión de cuentas administrativas en un patrón inusual.
Si un ataque es un ataque de día cero, incluso si tiene las tecnologías de seguridad adecuadas, es posible que no se detecte el ataque en sí, pero es posible que pueda ver el comportamiento resultante del atacante después del compromiso, como el comando y actividad de control (ver # 3).
2. El estado de la infraestructura de registro también es una variable clave a tener en cuenta. ¿Tiene monitoreo en los lugares correctos para detectar el ataque?
Cobertura incompleta con tecnología existente : en pocas palabras, esto es “alcance de monitoreo”. Por ejemplo, algunos entornos solo tienen IPS en los puntos de salida, o solo en entornos impulsados por el cumplimiento, tales como: entorno de tarjetahabiente para PCI, datos PII para HIPAA, o para NER CIP el entorno de producción (“Perímetro de seguridad electrónica”).
Cuando ocurre un ataque fuera de lo que se está monitoreando, no producirá un registro. ¿Están * todos * sus servidores Unix y Windows registrando o solo un subconjunto? ¿Son * todos * los registros de sus FW? . ¿Tiene suficientes dispositivos implementados? Muchos entornos no tienen suficiente segregación en las redes internas y utilizan el enrutamiento en lugar de colocar FW, IPS, NGFW, etc., de modo que un compromiso del sistema en un segmento de red se puede identificar y contener más rápidamente.
Falta de seguridad en profundidad : es posible que tenga un registro de IPS, FW y AV en su SIEM, pero ¿qué pasa con otras tecnologías de seguridad? ¿Tienes anti-malware / sandbox? ¿Qué pasa con algunos de los productos emergentes de detección de anomalías de aprendizaje automático como Darktrace, Exabeam y E8 (esta es una lista creciente con muchas nuevas empresas)? Es posible que tenga un registro de FW, pero ¿qué pasa con netflow? Netflow le brinda mucha más resolución en el tráfico que un registro FW puro, pero no todos habilitan Netflow en todas partes, y si su SIEM no es bueno para analizar Netflow en bruto, es posible que desee usar un dispositivo para StealthWatch que produzca alertas de Netflow para que su SIEM solo tiene que gestionar las alertas. ¿Necesita una captura completa de paquetes como Solera o NetWitness (ahora Security Analytics).
3. Las huellas de un ataque pueden ayudarte a detectar un ataque incluso si no viste el ataque original. Por ejemplo, un sistema comprometido puede iniciar una actividad de escaneo en su red, por lo que si su IPS no vio el ataque real (porque ocurrió fuera de su alcance de monitoreo, o estaba dentro de su alcance de monitoreo pero fue un ataque de día cero) , el IPS debería ver la actividad de escaneo que ocurre antes o después. Puede suscribirse a los servicios de inteligencia que le brindan listas de vigilancia, o tener productos de seguridad de puerta de enlace que vienen con las propias listas de vigilancia del proveedor, para que pueda detectar cosas como la comunicación a CnC. Es posible que detecte otros productos de seguridad que busquen anomalías en el comportamiento de inicio de sesión del usuario, consultas DNS (como bots que usan DNS de flujo rápido) u otras actividades anómalas (anomalías de acceso, anomalías de ancho de banda, anomalías de puertos / aplicaciones como el uso repentino de FTP o IRC )
Correlación : la clave para detectar ataques que no resultan en ese caso de uso de evento a incidente 1: 1 es a través de políticas de correlación. Lo bueno de la política de correlación es que no solo puede detectar ataques más avanzados, sino que también reduce en gran medida la cantidad de falsos positivos cuando se hace correctamente. Aquí es donde entra en juego el poder de un buen SIEM comercial, no solo por la flexibilidad en las diferentes políticas de correlación de red (variables, condiciones, árboles de decisión) sino también en el caso de la taxonomía o también llamado “soporte de dispositivos”. Un SIEM que tiene una taxonomía de eventos profunda puede permitirle profundizar en los metadatos del evento, tales como:
- if event.type = “autenticación” y result = “falló”
Aquí hay un ejemplo de una política de correlación que puede ayudar a encontrar un ataque:
- if event.type = “reconocimiento” a target.ip = “ip1”, seguido de dentro de 60 minutos
- event.type = “autenticación” de source.ip = “ip1” donde cuenta> 5 en 1 minuto, O
- event.type = “IRC | P2P | FTP | SFTP | SCP” de source.ip = “ip1” a network.zone = “externo”
En lo anterior, está viendo un patrón simple que comienza con el escaneo. Asume que no ve la explotación real (digamos día cero) pero luego, dentro de los 60 minutos de esa actividad de escaneo, puede ver otros eventos que se originan en el sistema escaneado. Esto podría ser intentos de autenticación de más de 5 en 1 minuto (que podría ser una actividad normal, pero aquí fue precedida por un escaneo) o puede ver tipos específicos de eventos como IRC, P2P o FTP a una red externa. En el caso de la última condición, normalmente puede ignorar la actividad IRC, P2P o FTP, pero aquí fue precedida por un escaneo.
Todo esto aún puede resultar en un falso positivo, pero también es por eso que se requiere un ajuste además de la política de correlación. Si tiene un host Unix con muchas cuentas compartidas, es probable que genere falsos positivos. Si tiene una base de datos de producción que tiene muy poca actividad del usuario, una alerta con estas huellas requiere una investigación inmediata.
En resumen, la correlación y el ajuste son necesarios para detectar lo que un SIEM puede pasar por alto normalmente, suponiendo que el alcance del monitoreo sea suficiente para detectar las “huellas de un ataque”. Una buena correlación y ajuste tiene el beneficio adicional de hacer que los incidentes SIEM sean más fáciles de analizar y reduce los falsos positivos. Pero, necesita expertos para definir las políticas de correlación y el conocimiento del entorno para ajustar. Tenga en cuenta que puede sintonizar de forma iterativa como parte de su proceso de respuesta a incidentes; este es un tema clave que la mayoría de las empresas y casi todos los MSSP omiten.
