En el capítulo de hoy, vamos a comentar algunas opciones o trabajos sencillos con Azure Sentinel, el nuevo servicio SIEM de Microsoft para la nube. Aún en fase de pruebas, gratuito, pero muy consolidado.
Como le digo a mis amigos últimamente, y como dice el CEO de Microsoft en algunas declaraciones, MS ha pasado de ser una compañía a la que tenías que comprar sus productos( por ejemplo, para usar Word) a una compañía a la que quieres comprarle productos. Eso del viejo, estancado, abusivo, privativo modelo Microsoft que muchos han detestado, se ha ido, se ha esfumado.
Desde plataformas Github gratuitas, pasando por Hyper-v gratuito ( en modo consola) hasta mil y unas funciones de alto interés, como por ejemplo la revolución que ha sido O365 para el mundo empresa.
Bueno, vamos al lío, SIEM, Gestor de eventos de seguridad de la información. Recolector de logs, con capacidades de correlación, identificar comportamientos en base a relaciones entre distintas fuentes de datos. Esto es de primero de SIEM, y seguro que habéis leído algo por aquí o por allá al respecto.
Una de las cosas que me ha gustado mucho es la capacidad de respuesta y orquestación que promete la suite, el famoso SOAR.
Hay que dar dos pasitos para configurar Sentinel, tan sencillos que con 1 minuto de esta lectura ya puedes tenerlo en marcha.
Uno de los pasos que se suelen repetir en todo siem son los data source, conectar las fuentes de datos que van a nutrir a nuestro SIEM de información, de ricos y jugosos logs.
De momento nos vamos a ceñir en las opciones por defecto que tenemos, aunque ahora más adelante haremos cositas chulas. Estos son algunos de los Data Sources disponibles a click:
Uno de los aspectos que hace muy sencillo el despliegue en entornos complejos es la capacidad de instalar una pasarela local para un entorno sin acceso a internet. Imagina una delegación con 5 equipos sin conectividad a internet, sin proxy ni nada, una fabrica de trabajo !!! y una vlan hacía el entorno de red de la empresa, donde si hay salida a internet... Click click click y nos bajamos una pasarela que nos hará de intermediario entre los logs y Azure. Tan sencillo como esto: https://docs.microsoft.com/es-es/azure/azure-monitor/platform/gateway
Una de las cosas que me ha llamado la atención es que tiene un agente para equipos Linux on premise, y que este hace uso del paquete Auditd, lo que viene siendo el sysmon de Windows para linux... pero seguro que tu ya usas auditd verdad...
Para instalarlo nos bajamos el instalador. Realmente es el mismo paquete de OMS para logs analytics, ya que es la base del control de logs. Sentinel solo implementa por encima la capa de seguridad.
Bueno, seguimos haciendo unos clicks para configurar el datasource más simple, los logs de las máquinas Windows.
Tenemos varias opciones generales a la hora de conectar fuentes de datos, pero la más normal es usar el un agente que normalice los datos en formato CEF y transporte UDP syslog hacia azure. En caso de grandes ingestas de datos se usará TCP, por eso del control ...
Después de conectar alguna máquina, empiezo a tener eventos relacionados con seguridad.
Lo interesante del siem es que no viene con un dashboard y unas cuantas alertas o reglas configuradas, pero podemos crear la que queremos, al más puro estilo asistente. Eso sí, de momento, son pocos los campos que nos permiten controlar, apenas 3, pero con el tiempo se ampliarán.
Al igual que en otros SIEM como splunk, no solo tenemos alertas sino que podemos realizar consultas puntuales, asociarlas como ellos llaman Hunting xDD. Estas consultas son bastante interesantes y como muestra de ellas, la página en github con las querys disponible: https://github.com/Azure/Azure-Sentinel/tree/master/Detections/SecurityEvent
Tiene muchas posibilidades, pero vamos a aportar algo más de valor al post. Vamos a generar una alerta personalizada.
Imagino que todos conocéis las SIGMA RULES, un trabajo INCREIBLE del señor NEO23x0. Consiste en un lenguaje de definición de marcas, yaml, para definir reglas de detección en formato genérico, y luego poder convertirlas al formato concreto del SIEM que uses. UNA PASADA !!!
Pués vamos a usar la herramienta que usamos para otros propósitos, pero esta vez para crear nuestra primera alerta en SENTINEL. Voy a usar una regla sencilla para detectar el acceso a un admin share o lo que es lo mismo, a un c$. Esta es la regla en formato SIGMA.
https://github.com/Neo23x0/sigma/blob/master/rules/windows/builtin/win_admin_share_access.yml
Si usamos la herramienta del proyecto, podemos convertirla en muchos formatos, por ejemplo, de splunk:
(EventID="5140" ShareName="Admin$") NOT (SubjectUserName="*$")
o ELK:
[
{
"_id": "Access-to-ADMIN$-Share",
"_type": "search",
"_source": {
"title": "Sigma: Access to ADMIN$ Share",
"description": "Detects access to $ADMIN share",
"hits": 0,
"columns": [],
"sort": [
"@timestamp",
"desc"
],
"version": 1,
"kibanaSavedObjectMeta": {
"searchSourceJSON": "{\"index\": \"*\", \"filter\": [], \"highlight\": {\"pre_tags\": [\"@kibana-highlighted-field@\"], \"post_tags\": [\"@/kibana-highlighted-field@\"], \"fields\": {\"*\": {}}, \"require_field_match\": false, \"fragment_size\": 2147483647}, \"query\": {\"query_string\": {\"query\": \"(EventID:\\\"5140\\\" AND ShareName:\\\"Admin$\\\") AND NOT (SubjectUserName:\\\"*$\\\")\", \"analyze_wildcard\": true}}}"
}
}
}
]
Pero mejor hacerlo en formato SENTINEL.
Nos permite hacer el mapeo de campos a mano, y una cosa muy chula, establecer la táctica al estilo MITRE !!! bieeeennnnn
Recuerda que si quieres poder ver este evento en concreto, deberás auditar el acceso a objetos en una GPO...
Otra de las funciones que me parece muy interesantes es la creación de un caso, opción que se habilita cuando tenemos configurada una alerta a nivel de Analytics. Es importante haber mapeado alguno de los campos principales para poder investigar el caso.
De momento solo podemos asignarlo a un usuario y agrupar los registros, ver el estado, pero próximamente nos prometen más información que pinta muy bien.
Como decíamos, SENTINEL tiene capacidades SOAR, mediante LOGIC APP de Azure, lo que podríamos denominar una especie de Webhooks o automatismos, en los que elegimos desencadenadores y se realizan acciones. Lo básico de la orquestación.
Podemos usar plantillas por defecto o crear una. Las por defecto de enganchar con Teams no está nada mal, ver en tu chat del SOC la alerta...
Al final, pudiendo elegir extraer un dato y conectaros a una API, tenemos todo un mundo de integraciones, de playbooks a nuestro alcance.
Como puedes comprobar, Microsoft se suma a la tendencia global de la seguridad, con sistemas más o menos económicos, uso de github para compartir inteligencia, uso de Mitre para taxonomías, SOAR...
Sin dunda un SIEM a tener en cuenta, y más que nada, crear todo el "walkaround" de controlar los logs de nuestra organización, luego el SIEM que usemos es una decisión organizativa.
Gracias por leerme.