En un panorama de amenazas en constante evolución, las operaciones de seguridad están llegando a un punto de inflexión. A medida que aumentan la velocidad y complejidad de las amenazas, los equipos se expanden y los entornos gestionados se multiplican. Comúnmente, los enfoques manuales para la gestión de normas se convierten en un cuello de botella. Aquí es donde entra Detections as Code (DaC), no solo como herramienta, sino como metodología.

El DaC como metodología aplica prácticas de desarrollo de software a la creación, gestión y despliegue de reglas de detección de seguridad. Al tratar las reglas de detección como código, permite el control de versiones, las pruebas automatizadas y los procesos de despliegue, mejorando la colaboración, la coherencia y la agilidad ante amenazas. El DaC agiliza el ciclo de vida de las reglas de detección, cerciorando detecciones de alta calidad mediante revisiones por pares y pruebas automatizadas. Esta metodología también apoya el cumplimiento de los requisitos de gestión del cambio y fomenta una postura de seguridad madura.

Por eso estamos entusiasmados de compartir las últimas actualizaciones de las reglas de detección de Elastic, nuestro repositorio abierto para escribir, probar y gestionar reglas de detección de seguridad en Elastic, que también te permite crear tu propio framework de Detecciones como Código (DaC). Sigue leyendo para ver ejemplos destacados de implementaciones que usan funcionalidad extendida, y el anuncio del taller gratis Detections as Code de Elastic.

Elastic Security DaC: El viaje desde la alfa hasta la disponibilidad general

Con la funcionalidad que ahora ofrece el repositorio de reglas de detección , los usuarios pueden gestionar todas sus reglas de detección como código, revisar ajustes de reglas, probar y validar automáticamente las reglas, y automatizar el despliegue de reglas en sus entornos.

Pre-2024: El uso interno de DaC por parte de Elastic

El equipo de investigación y detección de amenazas de Elastic creó y empleó el repositorio de reglas de detección para desarrollar, probar, gestionar y liberar reglas predefinidas, siguiendo los principios de DaC: revisando las reglas en equipo, automatizando sus pruebas y liberaciones. El repositorio también tiene una CLI interactiva para crear reglas, así que los ingenieros podrían empezar a trabajar en las reglas justo allí.

A medida que crecía el interés de la comunidad de seguridad por los principios de código y las APIs de Elastic Security disponibles ya permitían a los usuarios implementar sus soluciones personalizadas de Detections como código, Elastic decidió ampliar la funcionalidad del repositorio de reglas de detección para que nuestros usuarios se beneficiaran de nuestras herramientas y los ayudaran a crear sus procesos DaC.

Aquí están los hitos clave del desarrollo de DaC centrado en el usuario de Elastic, desde la alfa hasta la disponibilidad general.

Mayo 2024: Lanzamiento en Alpha de las nuevas funciones de "crear tu propio proyecto"

Nuestro repositorio de reglas de detección se ajusta para el uso del cliente, permitiendo gestionar reglas personalizadas, adaptar el conjunto de pruebas a las necesidades del usuario y gestionar acciones y excepciones junto con las reglas.

Incorporaciones clave:

• Soporte de directorios de reglas personalizadas
• Selecciona qué prueba realizar según tus necesidades
• Excepciones y soporte de acciones

También publicamos una guía extensa para Detections as Code con ejemplos de implementación con Elastic Security usando repositorio de reglas de detección .

Agosto 2024: "Crea tu propio proyecto" ahora cuenta con la beta

La funcionalidad se amplía para permitir la importación y exportación de reglas personalizadas entre Elastic Security y el repositorio, además de más opciones de configuración y funcionalidad de versionado a las reglas personalizadas.

Se agregaron nuevas características:

• Importación/exportación masiva de reglas personalizadas (basadas en APIs de Elastic Security)
• Pruebas unitarias totalmente configurables, validación y esquemas
• Bloqueo de versión para reglas personalizadas

Marzo - agosto de 2025: están disponibles y soportados en general

Usando DaC con Elastic Security 8.18 en adelante:

• Soporta la gestión de reglas predefinidas. Puedes exportar todas las reglas preconstruidas desde Elastic Security y almacenarlas junto a tus reglas personalizadas.
• Se agregó soporte para filtrado de reglas para exportación.

Además de los esfuerzos de DaC, también lanzamos nuevos recursos de Terraform (V0.12.0 y V0.13.0) en octubre-diciembre de 2025, permitiendo a los usuarios de Terraform gestionar reglas de detección y excepciones.

Con esta base expuesta, exploremos las poderosas funciones disponibles para agilizar tu proceso de ingeniería de detección.

Aspectos destacados de la funcionalidad DaC de las reglas de detección

Hay algunas incorporaciones interesantes desde nuestra última publicación en DaC, que ampliaremos a continuación.

Filtros adicionales

La funcionalidad de filtro disponible al exportar reglas desde Kibana se amplió para permitir definir con precisión qué reglas sincronizar en DaC. Aquí están las nuevas banderas:

Tomemos un ejemplo de cuando quieres organizar reglas por fuente de datos y quieres exportar las reglas de AWS a una carpeta específica. En este caso, usemos filtrado en etiquetas para fuentes de datos y exportemos todas las reglas con la etiqueta Data Source AWS :

python -m detection_rules kibana export-rules -d dac_test/rules #add rules to the dac_test/rules folder
-sv #strip the version fields from all rules
-cro #export only custom rules
-eq "alert.attributes.tags: "Data Source: AWS"" # export only rules with "Data Source: AWS" tag

Consulta la documentación de Kibana para el filtrado de cadenas de consulta para la llamada API subyacente empleada aquí y la lista de todas las reglas de detección, por ejemplo, los campos disponibles para construir el filtro de consultas.

Estructura de carpetas personalizada

En el repositorio de reglas de detección, empleamos una estructura de carpetas basada en la plataforma, la integración y la información de MITRE ATT&CK. Esto nos ayuda en la organización y el desarrollo de las normas. Este no es en absoluto el único método de organización. Quizá quieras organizar tus normas por cliente, fecha o fuente, por ejemplo. Esto variará mucho según tu caso de uso.

Ya sea que uses este proceso de exportación o la organización manual, una vez que tengas tus reglas en una ubicación o estructura de carpetas que te guste, ahora puedes mantener esta estructura local incluso al reexportar reglas. Es importante señalar que las nuevas reglas deben colocar manualmente en la ubicación deseada. El mecanismo local de carga de reglas detecta dónde se colocan las reglas para saber dónde colocarlas. Si la regla no está ahí, entonces usará el directorio de salida especificado para colocar la(s) nueva(s) regla(s). Para usar la carga local de reglas para actualizar las reglas existentes, emplea la bandera --load-rule-loading / -lr para los comandos kibana export-rules y import-rules-to-repo . Estas banderas te permiten emplear las carpetas locales especificadas en tu config.yaml.

Veamos el ejemplo con las reglas organizadas en carpetas de la siguiente manera:

rule_dirs:
- rules
my_test_rule.toml
- another_rules_dir
high_number_of_process_and_or_service_terminations.toml

Especificaremos lo siguiente en el archivo config.yaml :

rule_dirs:
- rules
- another_rules_dir

Con la nueva opción -lr , las actualizaciones de reglas de Kibana ahora usarán estas rutas adicionales en lugar de exportarlas directamente al directorio especificado.

Ejecutar python -m detection_rules kibana --space test_local export-rules -d dac_test/rules/ -sv -ac -e -lr,exportará reglas desde test_local espacio, my_test_rule.toml se escribirá en dac_test/rules/ ya que ya estaba en el disco allí y high_number_of_process_and_or_service_terminations.toml se escribirá en dac_test/another_rules_dir/.

Esto puede ser especialmente útil si tienes las mismas reglas en diferentes configuraciones de subcarpetas para distintos clientes. Por ejemplo, supongamos que tienes tus reglas desglosadas por plataforma e integración similar a la estructura de carpetas preconstruida de Elastic. Para tus clientes, SOCs o equipos de caza de amenazas, tener las reglas organizadas bajo estas carpetas de plataforma/integración puede ser el mecanismo más útil para que gestionen las reglas. Sin embargo, tu equipo de seguridad de la información o el equipo principal de ingeniería de detección pueden querer gestionar las reglas por iniciativa o autor de reglas para que todas las normas de las que es responsable una persona o equipo en individuo estén organizadas en un solo lugar. Ahora, con las banderas locales de carga de reglas, puedes simplemente tener dos archivos de configuración y las reglas duplicadas en cada estructura. Cuando exportas actualizaciones de las reglas, entonces usas la variable de entorno para seleccionar el archivo de configuración adecuado y exportar las actualizaciones de las reglas. Estas actualizaciones se aplicarán entonces a las reglas vigentes, manteniendo la estructura de directorios.

Actualizaciones locales diversas de carga

Además de lo anterior, agregamos dos funciones nuevas más pequeñas diseñadas para ayudar a los usuarios que están agregando información local en las reglas de detección: archivos TOML y esquema. Estos son los siguientes:

1. Soporte de fecha local desde los archivos locales donde la fecha local se mantendrá desde el archivo original
2. Mejoras a la función de generación automática para heredar tipos conocidos del esquema existente.

El componente de fecha local puede ser útil cuando se quiere un control más manual sobre el campo de fecha en el archivo. Sin usar la anulación, la fecha se basará en cuándo se exportaron los contenidos de la regla Kibana. Usando la bandera de --local-creation-date , la fecha no se actualizará cuando el contenido del archivo se reexporte.

La generación automática de esquemas se actualizó para heredar los tipos de otros índices/integraciones si están presentes. Esto proporciona un esquema potencialmente más preciso, además de reducir la necesidad de actualizaciones manuales a posteriori. Por ejemplo, tienes una regla que emplea el índice "new-integration*" con los siguientes campos:

• host.os.type.new_field
• dll.Ext.relative_file_creation_time
• process.name.okta.thread

En lugar de que cada uno de estos campos se añada al esquema con un tipo por defecto, sus tipos se heredan de esquemas existentes. En este caso, los tipos para dll.Ext.relative_file_creation_time y process.name.okta.thread se heredan.

{
  "new-integration*": {
    "dll.Ext.relative_file_creation_time": "double",
    "host.os.type.new_field": "keyword",
    "process.name.okta.thread": "keyword"
  }
}

Para ver cómo usar esto con tus tipos de datos personalizados, consulta la sección Uso de esquemas personalizados dentro de la sección de Ejemplos de Implementación de este blog.

Ampliando ejemplos de uso

A continuación encontrarás más ejemplos de implementaciones de DaC, que no se centran en nuevas incorporaciones de funcionalidad, sino que profundizan en los temas que vemos tratados en la comunidad.

Cabe destacar que las características de Detecciones como Código se proporcionan como componentes que pueden usar para construir una implementación personalizada para el proceso y la arquitectura que elijas. Al implementar DaC en tu entorno de producción, trátalo como un proceso de ingeniería y sigue las mejores prácticas.

Implementación de DaC con Gitlab

Cuando analizamos las implementaciones de DaC, normalmente esto voltea en torno a usar algún tipo de producto CI/CD para realizar automáticamente la gestión de reglas basada en un disparador dado. Estos disparadores varían considerablemente según la configuración deseada, específicamente la fuente autorizada de las reglas y el estado deseado de tu sistema de control de versiones (VCS). Para una exploración mucho más profunda de algunas de estas consideraciones, consulta nuestro Material de Referencia de DaC. A continuación se muestra un ejemplo sencillo usando Gitlab como proveedor de VCS y su CI/CD integrado a través de Gitlab Actions.

stages:                # Define the pipeline stages
  - sync               # Add a 'sync' stage

sync-to-production:    # Define a job named 'sync-to-production'
  stage: sync          # Assign this job to the 'sync' stage
  image: python:3.12   # Use the Python 3.12 Docker image
  variables:
    CUSTOM_RULES_DIR: $CUSTOM_RULES_DIR    # Set custom rules env var
  script:                                  # List of commands to run 
    - python -m pip install --upgrade pip  # Upgrade pip
    - pip cache purge                      # Clear pip cache
    - pip install .[dev]                   # Install package w/ dev deps
    - |  # Multi-line command to import rules                                        
      FLAGS="-d ${CUSTOM_RULES_DIR}/rules/ --overwrite -e -ac"
      python -m detection_rules kibana --space production import-rules $FLAGS
  environment:
    name: production   # Specify deployment environment as 'production'
  only:
    refs:
      - main           # Run this job only on the 'main' branch
    changes:
      - '**/*.toml'    # Run this job only if .toml files have changed

Esto es muy similar a otros CI/CD integrados de otros VCS basados en Git como Gitlab y Gitea. La principal diferencia está en la sintaxis que determina el evento desencadenante. Los comandos de DaC como kibana import-rules serían los mismos independientemente de VCS. En este ejemplo, estamos sincronizando las reglas desde nuestro fork del repositorio de reglas de detección con nuestro Espacio de Producción Kibana. Esto se basa en varias decisiones previas tomadas, por ejemplo, exigiendo que las pruebas unitarias pasen antes de fusionar las actualizaciones de reglas y que las reglas principales estén listas para producción. Para una guía basada en Github sobre estas consideraciones para este enfoque en individuo, por favor echa un vistazo a nuestro video de demostración.

Consejos y ejemplos de pruebas unitarias personalizadas

Al considerar el DaC como una capacidad para agregar a tu kit de detección, la configuración del CI/CD y la infraestructura base debe considerar como el primer paso en un proceso continuo para mejorar la calidad y utilidad de tus reglas. Uno de los propósitos clave de tener herramientas "como código" es agregar la capacidad de personalizar aún más las herramientas según tus necesidades y entorno.

Un ejemplo de esto son las pruebas unitarias para reglas. Más allá de las pruebas de funcionalidad base, algunas otras pruebas unitarias clave existentes aplican consideraciones específicas de Elastic sobre el rendimiento y la optimización de reglas, así como la organización de metadatos y etiquetados. Esto ayuda a que los ingenieros de detección y los investigadores de amenazas se mantengan coherentes en el desarrollo de sus reglas. A partir de este ejemplo, se puede considerar agregar pruebas unitarias personalizadas según tus necesidades específicas.

Para ilustrar esto, tomemos un entorno de Centro de Operaciones de Seguridad (SOC) donde hay varios analistas responsables de distintos dominios y tareas. Cuando se genera una alerta en el SIEM, puede que no sea inmediatamente evidente quién debe encargar de la remediación o qué equipo(s) deben ser informados del incidente. Etiquetar las reglas con una etiqueta de equipo: por ejemplo, Team: Windows Servers de forma similar a cómo Elastic emplea etiquetas para fuentes de datos, puede proporcionar al SOC un punto de contacto directo en la alerta para saber quién puede ayudar con la remediación.

En nuestro entorno DaC, podemos crear rápidamente un nuevo módulo de pruebas para hacer cumplir esto en todas las reglas personalizadas (o también pre-compiladas). Para esta prueba, vamos a imponer una etiqueta de Team: <some name> en todas las reglas de producción que no sean escritas por Elastic. En el repositorio de reglas de detección, nuestras pruebas se gestionan a través de la suite de pruebas de Python llamada pytest y, por tanto, las pruebas unitarias se organizan en módulos de Python (archivos) y las clases y funciones subsecuentes en estos archivos bajo la carpeta tests/ . Para agregar pruebas, simplemente hay que agregar clases o funciones a los archivos existentes o crear uno nuevo. En general, recomendamos crear nuevos archivos de prueba para que puedas recibir actualizaciones de las pruebas existentes desde Elastic sin tener que fusionar las diferencias.

Comenzaremos creando un nuevo archivo en python llamado test_custom_rules.py en el directorio tests/ con el siguiente contenido:

# test_custom_rules.py

"""Unit Tests for Custom Rules."""

from .base import BaseRuleTest


class TestCustomRules(BaseRuleTest):
    """Test custom rules for given criteria."""

    def test_custom_rule_team_tag(self):
        """Unit test that all custom rules have a Team: <team_name> tag."""
        tag_format = "Team: <team_name>"
        for rule in self.all_rules:
            if "Elastic" not in rule.contents.data.author:
                tags = rule.contents.data.tags
                if tags:
                    self.assertTrue(
                        any(tag.startswith("Team: ") for tag in tags),
                        f"Custom rule {rule.contents.data.rule_id} does not have a {tag_format} tag",
                    )
                else:
                    raise AssertionError(
                        f"Custom rule {rule.contents.data.rule_id} does not have any tags, include a {tag_format} tag"
                    )

Ahora, cada regla que no sea Elastic deberá tener una etiqueta en el patrón especificado para un equipo responsable de la remediación. Por ejemplo, Team: Team A.

Uso de esquemas personalizados

La capacidad de Elastic para traer tus propios tipos de datos también se extiende a nuestras capacidades de DaC. Por ejemplo, echemos un vistazo a algunos esquemas personalizados para protocolos de red. Por supuesto, los datos diversos que tengas en tu pila pueden ser consultados por tus reglas, y también querremos aprovechar la validación y prueba aplicable para cualquier regla personalizada en estos tipos de datos. Aquí es donde los esquemas personalizados resultan útiles.

Cuando validamos consultas, la consulta se analiza en los campos respectivos y los tipos de estos campos se comparan con lo que se proporciona en un esquema dado (por ejemplo, Esquema ECS, la integración de AWS para datos de AWS, etc.). Para tipos de datos personalizados, esto sigue la misma ruta de validación, con la capacidad de extraer de esquemas personalizados definidos localmente. Estos archivos de esquema pueden construir manualmente como uno o más archivos json; Sin embargo, si ya tienes algunos datos de muestra en tu pila, puedes aprovecharlo y usarlo como validación para generar tus esquemas automáticamente.

Suponiendo que ya tienes configurada una carpeta de reglas personalizada (si no, consulta las instrucciones), puedes activar la generación automática de esquemas agregando auto_gen_schema_file: <path_to_your_json_file> a tu archivo de configuración. Esto generará un archivo de esquema en la ubicación especificada que se empleará para agregar entradas para cada combinación de campo e índice. El archivo se actualizará durante cualquier comando en el que el contenido de las reglas se valide contra un esquema, incluyendo import-rules-to-repo, kibana export-rules, view-rule y otros. Esto también lo agregará automáticamente a tu archivo stack-schema-map.yaml cuando uses un directorio y configuración de reglas personalizados.

Con este poder viene una mayor responsabilidad para los revisores de reglas, ya que cualquier campo empleado en la consulta se asume inmediatamente como válido y se agrega al esquema. Una forma de mitigar el riesgo es emplear un espacio de desarrollo que tenga acceso a los datos. En el PR, se puede enlazar a una ejecución exitosa de la consulta mediante validación a nivel de pila sobre sus tipos de datos. Una vez aprobado, se puede eliminar la auto_gen_schema_file adición a la configuración y ahora tienes un esquema válido conocido basado en tus datos personalizados. Esto proporciona una base sobre la que otros autores de reglas pueden construir según sea necesario y mantiene la validación de comprobación de tipos.

Aprende más sobre DaC y pruébalo tú mismo

Puedes experimentar de primera mano la funcionalidad de Detections as Code (DaC) de Elastic Security con nuestra formación interactiva en Instruqt. Esta formación proporciona una forma sencilla de explorar las funciones principales del DaC en un entorno de prueba preconfigurado, eliminando la necesidad de la configuración manual. ¡Pruébalo!

Si estás implementando DaC, comparte tu experiencia, haz tus preguntas y ayuda a otros en el canal de DaC de la comunidad de Slack.

Seguridad elástica de prueba

Para disfrutar al máximo de lo que Elastic ofrece a los ingenieros de detección, comienza tu prueba gratis de Elastic Security. Visita elastic.co/security para saber más.

El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a discreción exclusiva de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.