Ciberseguridad: Security Operations Center (SOC) Parte 2

ciberseguridad

Hace unos días comenzamos la serie artículos destinados a la ciberseguridad y en concreto al Security Operations Center o SOC.

Como muchos sabéis, ofrecemos este servicio a clientes de medianas y grandes organizaciones, ¡y también pequeñas! Por eso queremos contaros un poco como hacemos las cosas

El papel del Security Operations Center

En el anterior artículo se identificó claramente el papel del SOC tradicional, algo que lleva en las organizaciones mucho tiempo, o al menos en las grandes: la necesidad de monitorizar eventos de los distintos aparatos de manera centralizada.

Se trata de una cuestión de expertos y analistas realizando la labor de correlación de datos, o definiendo estas reglas, para que los equipos SIEM aporten más valor que un mero log. En este sentido siempre he sido franco con mi opinión: si tu SOC solo levanta alertas de un Antivirus, WAF, o producto X, prefiero que me llegue una alerta al correo y me ahorro el dinero.

La correlación típica se puede definir entre la obtención de información que proviene de relacionar una fuente de o más de eventos, generalmente en la dimensión tiempo, aunque puede ser por volumen, vayamos al detalle:

Los pormenores del SOC

Si tienes un portscan como evento, eso es un evento;, pero, ¿y si tienes 5 portscan en una hora, de la misma ip? estás relacionando varios eventos bajo la dimensión tiempo. Pero, ¿y si esos escaneos no son de la misma IP, pero sí del mismo ASN o país? Relacionas estos datos para aportar valor a los eventos.

Y ya sabes: dato, información, conocimiento o sabiduría son "niveles" de la pirámide que debes subir.

Para la correlación volumétrica, término que no tengo muy claro si existe o no, pongamos por ejemplo un evento 500 http, o un 404: error en el servidor o página no encontrada.

Este evento como tal no es un indicador de ataque. Puede ser un fallo puntual de un servidor, algún recurso externo que el desarrollador usa en la web y que está caído...vete tú a saber. Motivo para ir un domingo en bata a la oficina no, desde luego.

Problemática real de los ciberataques y la ciberseguridad

Bien, ya estamos metidos de lleno en el SOC, pero sigue faltando información sensible: nos damos cuenta que los cibercriminales trabajan con técnicas que los hacen indetectables, más bien se saltan reglas IPS, ejecutan 0 days o utilizan vectores de ataque basados en "humanos" que hacen muy difícil su detección.

Vamos a imaginar un caso de Phishing en el que el usuario realiza un click en un enlace, ejecuta un Javascript, abre un documento de la suite Office con una Macro... todo esto son escenarios conocidos de explotación usados por los cibercriminales para perpetrar sus ataques, pero vamos a ponernos en una situación más realista:

Imagina una cuenta de acceso VPN comprometida. No me refiero al proceso de fuerza bruta, ni nada de eso, que un cibercriminal tiene la clave: ¿qué aparato detecta que eso es normal? El cibercriminal entrará en la red campando a su anchas.

En tradicional, SOC 2 entra en acción con la detección de comportamientos basados no solo en los "aparatos defensivos" los firewalls, ids´s, waf´s, antivirus, etc.; sino que usa el propio endpoint para detectar comportamientos que nos den información de un posible ataque.

Vamos a poner un ejemplo, un atacante que emplea powershell para ejecutar una muestra de malware externa, el típico mimikatz, pero que usa la variante -version 2 que como todos sabéis tiene menos opción de LOGs en el sistema y deja menos huella.

Otra opción con Powershell, usar Powersploit, la suite de post-explotación Windows por excelencia para codificar el payload del comando en Base64 y así evadir el antivirus con -EncodedCommand

Las capacidades del analista de seguridad tienen que servir para investigar ataques, prepararse, crear reglas y casos de uso para entender que los incidentes de seguridad ocurren y ocurrirán, y que las capacidades de detección rápida y respuesta son vitales en la gestión del SOC. Lo dicho, si alguien tiene una clave para evitar cualquier error técnico o humano, que no pueda llegar hasta la cocina...

Retos de futuro en la ciberseguridad: SOC 3.0

Hasta aquí y a pesar de mi murciano camuflado en texto, se entiende todo bien, pero ¿y eso del next-gen? ¿O del SOC 3.0? Para mí es una mezcla por supuesto del SOC 2 y de una serie de aspectos relacionados con "el big data", pero no como Big Data sino como "muchos datos", esta vez es al revés.

Vamos a intentar dar forma a esto: imagina la monitorización de las consultas DNS:

  • Un SOC 1.0 detectaría que te has conectado a maligno.com y bloquearía el tráfico.
  • Un SOC 2.0 detectaría por ejemplo que estás usando SQLMAP para explotar una sqlinjection y usar consultas DNS para exfiltrar los datos mediante el payload DNS, mediante el subdominio, campo txt etc. EJEMPLO.

Una correcta monitorización detectaría tráfico DNS con tamaño anormal y repetido contra un host legítimo. Esta regla de detección no la implementa un IDS, sino el equipo humano del SOC 2.0 mediante su gestión de alertas podría detectar el ataque por:

  • Número de host dentro del dominio.
  • Excesivo retorno de NXDOMAIN para la detección de DGA.
  • Antigüedad del registro A y NX.

Nada nuevo, lo que vienen siendo técnicas de detección habituales en el SOC 2.0

El SOC 3.0 o next gen detectaría anomalías como el repentino volumen de tráfico DNS, el uso de servidores no oficiales en la red, ¡o incluso el horario de las consultas!

Vamos a poner otro caso, el de la situación en la que la empresa tiene comprometidas claves de usuario.

¿A qué hora se suele conectar el usuario “admin”? ¿Desde qué equipos? ¿Desde que Ip externas o países levanta la VPN? ¿A qué servidores se suelen conectar? ¿A qué carpetas?

Todo lo relacionado con la predicción en base de patrones conocidos es lo que se denomina User Behavior Analytics. Podemos encontrar distintas abreviaturas y aproximaciones a este concepto, como las ya famosas machine learning, inteligencia artificial y todo esto, pero me gusta UBA.

En este artículo podemos ver una comparativa de los principales "players".

Dentro de la documentación de Splunk sobre la "tecnología" UBA aparecen algunas anomalías que pueden ayudarnos a conocer un poco cómo funcionan estas tecnologías y que ayudas nos presentan

  • Blacklisted Application
  • Multiple Logins
  • Blacklisted Domain
  • Multiple Outgoing Connections
  • Blacklisted IP Address
  • Multiple Sessions Denial
  • Domain Name Anomaly
  • Period with Unusual AD Activity Sequences
  • Excessive Data Transmission
  • Suspicious Data Movement
  • Exploit Chain
  • Unusual Activity Time of Day
  • External Alarm
  • Unusual Activity Time of Week
  • External Website Attack
  • Unusual AD Event
  • Land Speed Violation
  • Unusual Box Activity
  • Machine Generated Beacon (HTTP)
  • Unusual External Alarm
  • Machine Generated Beacon (IP)
  • Unusual File Access
  • Malicious AD Activity
  • Unusual Web Browser
  • Malicious Domain
  • Unusual Machine Access
  • Malicious IP
  • Unusual Network Activity
  • Multiple Box Login Errors
  • Unusual Geolocation
  • Multiple Box Logins
  • Unusual Process
  • Multiple Box Operations
  • Unusual USB Activity
  • Multiple DLP Alarms
  • Unusual VPN Login Geolocation
  • Multiple External Alarms
  • Unusual Web Browser
  • Multiple Login Errors

Una de las plataformas más populares son Microsoft ATA, Advanced Threat Analytics. El software realiza capturas de tráfico al modo IDS pero de datos de autenticación y sesión de Active directory. Con esta información realiza un baseline de "normalidad" y después de unos días empieza a detectar actividades sospechosas. El detalle de su proceso de instalación y la línea: The ATA Center requires a minimum of 21 days of data for user behavioral analytics

abnormal behavior

 

Como puedes comprobar, nos aproximamos a todo esto que huele tanto a humo como a Machine learning: predicciones, hombre-máquina, big data. No soy experto en nada de esto, pero sí que entiendo que este típico de análisis predictivo es vital para la correcta detección de incidentes de seguridad y que como buen SOC debes controlar.