Cumplimiento Continuo como Código P1: Sigma

El cumplimiento siempre ha sido una especie de proceso reactivo, ya que los estándares son extensos, requieren mucho esfuerzo y tiempo para actualizarse, incluso más tiempo para implementarse y el proceso de auditoría ocurre una vez al año. Viniendo del mundo del SIEM, manejaba el cumplimiento a través de un prisma de informes predefinidos que usualmente devuelven resultados vacíos o algo que está muy lejos de ser explicable para un auditor externo. Por otro lado, la lógica subyacente de los informes y las consultas es oscura y requiere un gran esfuerzo para mantenerla, por decir lo mínimo. Para que funcione, uno necesita dominar el motor de reglas de correlación o el lenguaje de consulta de una tecnología SIEM específica y el motor de informes que lo acompaña, configurar numerosas listas y excepciones de manera estática, mientras que el entorno real es dinámico y solo reunir todos los datos en un solo lugar puede tomar muchos meses. Y para cuando hemos terminado con estas tareas, la tecnología SIEM se cambia o trabajo con otro cliente que utiliza un sistema de análisis de seguridad basado en búsqueda en lugar de uno de “correlación en tiempo real” al estilo antiguo. Se vuelve más fácil si tenemos herramientas de auditoría de seguridad como escáneres de VM que tienen características de auditoría de cumplimiento, por ejemplo, Qualys Policy Compliance, Tripwire y similares. Sin embargo, estas últimas herramientas no construyen una imagen holística ni en tiempo real, a menos que estén conectadas con una plataforma de SIEM o Analytics de Seguridad de algún tipo. Luego llega el tren de GRC con productos masivos y años/hombre de esfuerzo de consultoría. Aburrido. Costoso e ineficiente. Garantiza brechas en la visibilidad. Demasiado lento para la era digital en la que vivimos. ¿Y qué tan bueno es todo lo anterior para abordar NIST CSF o GDPR? En mi humilde opinión, el cumplimiento es un reflejo de la seguridad, así que si estás haciendo ciberseguridad correctamente, el cumplimiento seguirá. Sin embargo, esto no funciona al revés. ¿Es hora de un cambio? Sí. Y hoy comenzaremos con la serie de artículos para hacer de tu cumplimiento un proceso ágil, transparente y rentable, adecuado para el negocio digital moderno.

Evolución de reglas Sigma y su vínculo con el Cumplimiento

Considero la adopción acelerada de las reglas Sigma para tareas de SIEM, SOC y Threat Hunting uno de los cambios más positivos en la industria de la seguridad. Y aunque Sigma ya es un estándar de facto para consultas de búsqueda de amenazas, tuvimos esta loca idea de aplicarlo para establecer prácticas de Cumplimiento Continuo. En caso de que no hayas oído hablar de Sigma antes, es un lenguaje fácil de entender, con curva de aprendizaje rápida, agnóstico a la plataforma y de código abierto. Ejemplos de las reglas y código fuente https://github.com/Neo23x0/sigma y tutorial para comenzar https://www.nextron-systems.com/2018/02/10/write-sigma-rules/Si tienes Elastic stack, Splunk, ArcSight, QRadar, Qualys, Microsoft Windows Defender ATP, Logpoint, Greylog: ya puedes obtener valor de las reglas Sigma para seguridad y búsqueda. Es probable que estas plataformas sean parte de tu infraestructura de seguridad / SOC y tengan toneladas de datos utilizables para el cumplimiento. Y es aún más probable que tengas un Elastic stack, versión premium o comunitaria, usado en varias unidades de negocio de tu organización, que puede tener datos para controles de cumplimiento automatizados. Una de las razones importantes para la evolución de Sigma y su adopción global es su soporte nativo de MITRE ATT&CK https://attack.mitre.org. En caso de que estés leyendo este artículo y no provengas del ámbito de la seguridad de la información: MITRE ATT&CK es como la blockchain de la ciberseguridad o la tabla periódica de elementos de la química. Así que tenemos un estándar de código abierto, ampliamente adoptado, más fácil de aprender que cualquier lenguaje de consulta de cualquier SIEM y que admite etiquetado con la metodología de ATT&CK para realizar atribución de TTP sobre la marcha. ¿Qué pasaría si agregáramos etiquetas relevantes para estándares de Cumplimiento? ¿Tener una consulta para control automatizado según CSC 8.2 o encontrar sistemas que procesan datos personales para GDPR? Para Sigma, esto es solo otra etiqueta, por lo tanto, técnicamente, es un siguiente paso lógico de la evolución.

Cómo escribir reglas Sigma para Cumplimiento

No es un secreto que, aunque personalmente soy un gran defensor de Sigma, no escribo tantas reglas yo mismo en este momento. Para una guía detallada de CÓMO, capturé a Alex Yamposlkyi para una charla rápida. Alex, siendo uno de los desarrolladores de reglas Sigma más activos, en términos de cantidad de reglas desarrolladas, solo superado por Florian Roth, ha proporcionado algunas ideas muy prácticas.

AB: “Alex, ¿ya has desarrollado alguna regla Sigma para Cumplimiento?”
AY: “Sí, han sido unos meses ocupados. Puedes encontrar algunos ejemplos en el repositorio oficial de Sigma en GitHub: https://github.com/Neo23x0/sigma/tree/master/rules/compliance y en SOC Prime Threat Detection Marketplace: https://tdm.socprime.com/?sigmaTypes[]=Compliance”

AB: “Genial. ¿Hay algún algoritmo particular que sigas al crear reglas Sigma para Cumplimiento?”
AY: “Creo que puedo describir esto como un proceso de 5 pasos:

1. Aprende el control CIS inicial en https://www.cisecurity.org/controls/cis-controls-list/
2. Comprende cuál de las fuentes de logs en tu organización se puede usar para cubrir los requisitos del control particular.
3. Busca los eventos necesarios en tu plataforma SIEM.
4. Una vez descubiertos los eventos adecuados, decide sobre la lógica de las reglas: tener una entrada de registro corresponde a un evento que es bueno o malo para el cumplimiento. Pregúntate: ¿pasa o falla este control de entrada de registro?
5. Codifica el evento resultante en una regla Sigma, eliminando cualquier parámetro de búsqueda específico de la plataforma para mantenerlo agnóstico al SIEM. Agrega etiquetas del elemento #1 y programa la búsqueda automatizada.”

AB: “Esto suena como una ganancia rápida. ¿Podemos intentar extender esto a una instrucción paso a paso?”
AY: “Sí. Aquí tienes una nota rápida.

1. Selecciona el dominio específico para el control que estás construyendo, por ejemplo, “Defensas contra Malware” que corresponde al dominio #8 de CSC.
2. Profundiza en la descripción de este control, en nuestro caso 8.2 se lee como “Asegúrate de que el software anti-malware de la organización actualice su motor de escaneo y base de datos de firmas regularmente.”
3. Piensa en lo que necesita suceder en el sistema para pasar o fallar este control. Para 8.2 significa que si el servicio AV se detiene o hay un error con su actualización, fallamos el control. Por lo tanto, necesitamos rastrear el registro de eventos de AV, específicamente para eventos de detención de servicio y error de actualización.
4. Es bastante fácil rastrear este control particular, tenemos que instalar un producto AV. En mi caso, este fue un producto Symantec integrado al Elastic stack usando Logstash. Después de clasificar los registros por un tiempo, encontré el evento que estaba buscando, responsable de la descarga e implementación de las actualizaciones, que contiene las siguientes cadenas “Descargado nuevo contenido”, “Una actualización para”.
5. Al verificar qué campos contienen estas palabras clave, puedo realizar una consulta sencilla de Elastic: (event.name:(«Descargado nuevo contenido»)) O (event.name:(«Una actualización para»))
6. Ahora tomamos una decisión sobre la lógica de la regla: si tener el evento es bueno o malo. En nuestro caso, tener la entrada de registro es positivo y significa que el control se ha pasado. Para automatizar el proceso, codificaremos la regla Sigma y la aplicaremos al mecanismo de búsqueda guardado específico de la plataforma. En mi caso, programo un Watcher para ejecutarse en Elastic stack con un intervalo de tiempo específico para mi entorno.
7. Escribamos una regla Sigma
8. En este ejemplo, puedo decidir programar una alerta cuando los eventos se pierdan durante un cierto período de tiempo. Con otros ejemplos, la situación puede ser la opuesta y puede que necesitemos una alerta cuando descubramos un evento.
9. Ahora nuestra regla necesita todas las etiquetas relevantes, así que voy a seguir adelante y agregarlas en este formatoEtiquetas:
   – CSC8.2
   – attack.impact
   – attack.t1489

Podemos mezclar etiquetas para ATT&CK y Cumplimiento. En el ejemplo anterior, “CSC8.2” es el número de control correspondiente por dominio CSC; “attack.persistence” es la táctica de MITRE ATT&CK y “attack.t1053” es una técnica específica en la que se enfoca el control.

Un código Sigma actualizado se verá asíUna vez que publico las reglas en Threat Detection Marketplace, también obtengo metadatos generados para las reglas al presionar el botón “Parse Sigma Content tags”.En la lista de “Etiquetas” puedo vincular las reglas con cualquier Estándar de Cumplimiento como ISO, PCI, NIST CSF, etc.

Nuestra conversación continuó por otra hora con suficiente material para una entrevista sobre el programa Prime Threat Bounty de SOC. Hasta entonces, se agradece cualquier comentario sobre Sigma para Cumplimiento.
Y si deseas un vistazo de cómo se ve el resultado final en el Elastic stack, consulta el video en https://my.socprime.com/en/continuous-compliance

/Mantente seguro