Eventos de seguridad (SIEM)

Status200 guarda los eventos de seguridad junto a tus registros, trazas y métricas, y da a cada uno la misma forma, OCSF (el Open Cybersecurity Schema Framework), sea cual sea el formato en que llegó. Envía eventos desde cualquier origen, búscalos y encuentra los importantes con reglas de detección Sigma, inteligencia de amenazas y monitores. Lo que encuentran se convierte en casos que gestionar, y los playbooks responden a ellos.

Cómo funciona#

Abre Productos → Eventos de seguridad, en Observabilidad. Su menú tiene una sección para cada parte de la seguridad, y una página propia para cada cosa que contiene:

Detecciones, IA y Conexiones, que se configuran una vez, quedan plegadas hasta que las abres. ¿Empieza con la seguridad? Primeros pasos con la seguridad la configura en dos clics.

Antes de empezar#

Los datos de seguridad solo los leen los roles Project Owner y Project Admin y los tres roles de seguridad; los demás roles no ven nada en Eventos de seguridad. Consulta Roles.

Enviar eventos de seguridad#

1. Crea una clave de ingesta#

   Abre Ajustes del proyecto → Telemetría y APM → Claves de ingesta y haz clic en Crear clave de ingesta. Los eventos de seguridad usan las mismas claves que el resto de tu telemetría.

2. Envía tus eventos#

   Envía JSON a /security-events/v1/ingest con la clave en x-status200-token:

   OCSFGoogle UDMGeneric JSON

   OCSF

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=ocsf" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -H "x-status200-service-name: my-security-source" \
     -d '{ "events": [ { "class_uid": 3002, "severity_id": 4, "status": "Failure", "message": "Failed logon for alice", "actor": { "user": { "name": "alice" } }, "src_endpoint": { "ip": "203.0.113.7", "hostname": "laptop-alice" } } ] }'

   Google UDM

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=udm" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "metadata": { "event_type": "USER_LOGIN" }, "principal": { "hostname": "laptop-alice", "user": { "userid": "alice" }, "ip": ["203.0.113.7"] }, "security_result": [{ "severity": "HIGH", "action": ["BLOCK"] }] } ] }'

   Generic JSON

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "severity": "high", "event_type": "ssh_brute_force", "message": "12 failed SSH logins in 60s", "username": "root", "hostname": "web-01", "src_ip": "203.0.113.7" } ] }'

   El endpoint responde 200 en cuanto los eventos están en cola. Un evento enviado sin hora, como estos, se sitúa en el momento en que llega.

3. Encuéntralos en Eventos#

   Abre Productos → Eventos de seguridad → Eventos. Los eventos aparecen en pocos segundos, con su gravedad, clase, usuario, host y direcciones IP rellenados.

Formatos#

Indica el formato con ?format=, con la cabecera x-oneuptime-security-event-format o con un campo "format" de primer nivel. Si lo omites, el formato de cada evento se deduce por separado, así que un mismo webhook puede mezclar detecciones con eventos en bruto.

• El cuerpo puede ser un evento, un array de eventos o { "events": [...] }.
• La cabecera x-status200-service-name nombra el servicio de telemetría al que pertenecen los eventos. Sin ella, pertenecen al servicio con el nombre del producto o del proveedor del primer evento, o a Security Events.
• No se descarta nada por no poder mapearlo: cada campo del origen llega a los atributos del evento.

Campos de JSON genérico#

Un evento genérico se lee por nombres de campo habituales:

Una palabra de gravedad se convierte en un nivel OCSF: info se lee como Informational, warning como Low, error como Medium, alert como Critical y emergency como Fatal.

Reenviar con Fluent Bit#

Para enviar registros de seguridad que ya recopilas, como los de auditd, syslog o Falco, añade a Fluent Bit una salida http:

[OUTPUT]
    Name             http
    Match            security.*
    Host             status200.ru
    Port             443
    tls              On
    URI              /security-events/v1/ingest
    Format           json
    Json_date_key    timestamp
    Json_date_format iso8601
    Header           x-status200-token YOUR_INGESTION_TOKEN
    Header           x-status200-service-name my-security-source
    Retry_Limit      5

La página Guía de configuración, en Conexiones, tiene estos fragmentos con tu propio host y tu clave ya rellenados.

Encontrar eventos de seguridad en sus registros#

La tarjeta Tus registros, en la parte superior de Conexiones, convierte en un origen los registros que ya envía a Status200. Con Encontrar eventos de seguridad en tus registros activado, los registros nuevos del proyecto se leen cada minuto, y cada inicio de sesión SSH, comando sudo, entrada de auditoría de Kubernetes, cambio de AWS CloudTrail y ataque web que contengan se guarda como evento de seguridad. Consulte Primeros pasos con la seguridad para saber qué cubre cada tipo.

Conectar un producto de seguridad#

Conexiones consulta un producto de seguridad por ti e importa sus registros nuevos como eventos de seguridad. Una conexión guarda los ajustes del producto y una credencial cifrada; un worker la consulta con el intervalo que definas y omite los registros que ya importó.

• Las alertas propias del producto con un nivel igual o superior a Open Cases From (Alta y superior salvo que elijas otro nivel, o Nunca) abren casos, agrupadas por el usuario, host o dirección de los que tratan.
• Una conexión lee los registros según el momento en que el producto los creó, no según el momento de la actividad que describen. Una regla de SIEM que se ejecuta cada hora crea detecciones mucho después de los eventos que coincidieron, y aun así se importan.
• La primera consulta mira 24 horas atrás, así que una conexión nueva muestra registros recientes de inmediato.
• Probar conexión, en la fila de la conexión, comprueba el acceso al producto y que los workers propios de Status200 están funcionando, y no importa nada. Ejecutar ahora consulta en el acto.

Qué contiene un evento#

Cada evento se guarda con campos tipados y su payload de origen:

Explorar los eventos de seguridad#

Eventos es un explorador de telemetría como los de registros y trazas: un gráfico de los eventos de la ventana por gravedad, una barra lateral de facetas, la lista y un panel con cada campo y atributo del evento que abras. La ventana, los filtros y la búsqueda viven en la URL, así que una vista filtrada se puede compartir y sobrevive a una recarga.

Búsqueda#

La barra de búsqueda habla el mismo lenguaje que los demás exploradores de telemetría (consulta Sintaxis de búsqueda):

Un campo es un nombre corto (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique) o el nombre propio del campo, como severityName o principalHost. Cualquier otro nombre se lee como atributo de origen. observable:<value> encuentra cada evento que menciona un valor, estuviera en el lado de la actividad que estuviera.

Facetas#

La barra lateral cuenta los eventos de la ventana por Origen, Gravedad, Clase de evento, Categoría, Actividad, Estado, Proveedor, Producto, Regla de detección, Usuario de origen, Host de origen, Proceso y Proceso padre. Haz clic en un valor para quedarte solo con sus eventos, o en el signo menos de al lado para excluirlos. Haz clic de nuevo para deshacerlo. El gráfico y cada recuento describen exactamente los eventos de la lista.

Correlacionar#

Correlacionar dibuja los eventos alrededor de un host, un usuario o una dirección IP: sus clases de evento alrededor de lo que buscaste, marcadas con su peor gravedad, y los demás valores vistos en los mismos eventos en el anillo exterior. Haz clic en una clase para listar sus eventos, o en un valor para correlacionar a continuación sobre él. Cada observable del panel de un evento en Eventos abre Correlacionar sobre él.

Reglas de detección#

Una regla de detección es una regla Sigma, un formato YAML abierto para describir actividad sospechosa, que Status200 ejecuta según una programación sobre tus eventos. Cuando coincide, abre un caso o se suma a uno, abre una alerta, opcionalmente un incidente, y escribe un Detection Finding de vuelta en los eventos. La Rule Library tiene reglas listas para usar como punto de partida.

Crear una regla#

Una primera regla, que coincide con los inicios de sesión fallidos desde fuera de 10.x.x.x:

title: Failed logon burst
description: Repeated authentication failures from one source.
level: high
tags:
  - attack.t1110
  - attack.ta0006
detection:
  selection:
    className: Authentication
    statusName: Failure
  filter_internal:
    principalIp|startswith: '10.'
  condition: selection and not filter_internal

Lo que puede expresar una regla#

Status200 ejecuta el núcleo booleano de Sigma:

• Las selecciones son mapas de campos (cada campo debe coincidir; una lista de valores coincide con cualquiera de ellos) o listas de palabras clave, que coinciden en cualquier parte del mensaje.
• Las condiciones combinan selecciones con and, or, not y paréntesis, o con 1 of selection_*, all of selection_*, any of them y all of them.
• Modificadores de campo: contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists y windash. El texto se compara sin distinguir mayúsculas, salvo que añadas cased.
• Un campo es un campo tipado (principalUser), una grafía Sigma habitual de uno (CommandLine, src_ip, Hostname) o cualquier clave de atributo, escrita como en el evento (threat.matched).
• Image y CommandLine leen el proceso del que trata el evento, el que se inició en el inicio de un proceso (processPath, processCommandLine), y ParentImage y ParentCommandLine el proceso que lo inició (parentProcessPath, parentProcessCommandLine). principalProcess es el proceso que actuó, que en un inicio es el proceso padre.
• level fija la gravedad: informational, low, medium, high o critical, y medium si falta. Los IDs de ATT&CK en tags (attack.t1110, attack.ta0006) rellenan los campos MITRE del hallazgo.

Las agregaciones como | count() by principalIp > 5 se rechazan al guardar: usa en su lugar una regla de correlación, o Campo de agrupación y Umbral de número de coincidencias. logsource es solo informativo y no acota nada: pon ese filtro en una selección, como className: Authentication. Un timeframe se ignora, porque el intervalo de la regla fija su ventana.

Reglas de correlación#

Una correlación de Sigma se dispara con varios eventos juntos en lugar de con uno. Pégala en Regla Sigma (YAML) con las reglas que lee, como documentos YAML separados por ---, o nombra reglas que el proyecto ya tiene por su name o su id de Sigma. La Rule Library tiene algunas listas para usar, como inicios de sesión fallidos seguidos de uno correcto.

title: Failed sign-ins, then a success from the same address
level: high
correlation:
  type: temporal_ordered
  rules:
    - failed_sign_ins
    - successful_sign_in
  group-by:
    - principalIp
  timespan: 10m
---
title: Five failed sign-ins
name: failed_sign_ins
correlation:
  type: event_count
  rules:
    - failed_sign_in
  group-by:
    - principalIp
  timespan: 10m
  condition:
    gte: 5
---
title: Failed sign-in
name: failed_sign_in
detection:
  selection:
    className: Authentication
    statusName: Failure
  condition: selection
---
title: Successful sign-in
name: successful_sign_in
detection:
  selection:
    className: Authentication
    statusName: Success
  condition: selection

• Un grupo es el valor de los campos de group-by, como una dirección. Los recuentos son móviles: una ráfaga que dos ejecuciones se reparten se cuenta igualmente entera dentro de su timespan, que es como máximo de 24 horas.
• new_value es un tipo propio de Status200, porque Sigma no tiene una correlación de «visto por primera vez»: compara con hasta 30 días de historial. value_sum, value_avg, value_percentile y value_median se rechazan al guardar.
• La columna Tipo de Reglas de detección nombra la clase de cada regla, y el formulario dice en una frase qué busca la regla.

Ajustes de evaluación#

La agrupación y el recuento distinto aceptan los mismos nombres de campo que la regla. Con ellos, el umbral dice «tantos, de lo mismo, en una ejecución», sin un monitor encima:

Cuándo se ejecuta una regla#

Status200 comprueba cada minuto qué reglas habilitadas han cumplido su intervalo desde su última ejecución. Cada ejecución lee los eventos cuya hora de evento cae entre la ejecución anterior y hace dos minutos, y después avanza. Esos dos minutos dan margen a los eventos que aún están en camino, como una línea de registro leída un minuto después de escribirse:

• Las ventanas van una tras otra, no se deslizan. Con un intervalo de 10 minutos, unos fallos a las 09:58 y a las 10:01 pueden caer en ejecuciones distintas y se cuentan por separado, así que deja margen al elegir un umbral.
• Tras un hueco, como una caída del worker o una regla que se vuelve a activar, la siguiente ejecución cubre el hueco entero, hasta las últimas 24 horas.
• Un evento que llega con más de dos minutos de retraso, cuando una ejecución ya ha cubierto su hora, se guarda y se puede buscar, pero esa regla nunca lo lee.
• Cada grupo que alcanza el umbral se convierte en un Detection Finding, hasta 10.000 por ejecución. Se abren alertas, incidentes y casos para los 100 con los recuentos más altos; el resto comparte un caso sobre la regla, y el Último error de la regla dice cuántos grupos coincidieron.

Gravedad#

El level de una regla es la gravedad de sus hallazgos: informational, low, medium, high y critical pasan a ser Informational, Low, Medium, High y Critical. Sus alertas e incidentes toman una de las gravedades de tu proyecto, en este orden:

1. La Gravedad de la alerta (o Gravedad del incidente) de la regla, si está definida.
2. Tu gravedad con el nombre del nivel, como High, sin importar mayúsculas.
3. Por rango: las reglas critical y high toman tu gravedad más alta, las demás la más baja.

Alertas y hallazgos#

Cada grupo que se dispara abre una alerta titulada [Detection] <rule name> — <group value>, o [Detection] <rule name> para una regla sin campo de agrupación. Mientras está abierta, más coincidencias de ese grupo no abren otra. Una regla solo ve coincidencias y no puede saber que un ataque ha terminado, así que sus alertas siguen abiertas hasta que alguien las resuelve.

Un Detection Finding es un evento de seguridad de clase Detection Finding (clase OCSF 2004) del producto Status200 Detections, con las etiquetas MITRE de la regla, el valor del grupo en primer lugar en observables y estos atributos:

Los hallazgos son eventos corrientes: búscalos en Eventos y pivota sobre ellos en Correlacionar. Para probar una regla nueva sin ruido, desactiva todas las acciones salvo el hallazgo hasta que confíes en ella.

Monitores de eventos de seguridad#

Un monitor de eventos de seguridad cuenta los eventos que coinciden con sus filtros sobre una ventana deslizante y aplica al recuento los criterios habituales de los monitores: cambia el estado del monitor, abre alertas o incidentes y avisa a la guardia. Crea uno en Monitores → Crear monitor, con Eventos de seguridad como tipo; aparece allí junto a sus demás monitores.

Su formulario muestra Monitorear eventos que incluyan este texto, Monitorear eventos de seguridad durante (tiempo), Gravedad del evento y Clase de evento. Filtrar por servicio de telemetría y Filtrar por atributos esperan en Más campos, cuya cabecera muestra los que usa un monitor. Sus criterios comprueban Security Event Count.

Escribe la detección en sí como una regla, con su umbral. Usa un monitor cuando quieras una ventana deslizante, un estado que se recupere solo, una página de estado o políticas de guardia distintas por criterio.

Vigila tus detecciones#

Los hallazgos son eventos, así que un monitor puede vigilar las propias reglas:

• Tormentas: un monitor sobre la clase Detection Finding que cuenta cada hallazgo. Veinte reglas distintas disparándose en una hora es una señal que ninguna regla por sí sola puede ver.
• Cambios de ritmo: filtra por el status200.detection.rule_id de una regla. Una regla que se dispara cada semana y de pronto lo hace cincuenta veces por hora necesita otra respuesta.
• Silencio: los hallazgos que caen a cero, cuando normalmente ves unos pocos, suelen significar que un origen dejó de enviar. Usa un criterio que compruebe un recuento por debajo de un número.

La acción Crear monitor de la fila de una regla abre un monitor nuevo ya configurado así: la clase Detection Finding, el ID de la regla (nunca su nombre, que un cambio de nombre alteraría) y la última hora. Un monitor así cuenta hallazgos, uno por grupo y ejecución, no los eventos que hay detrás. Para exigir un número de eventos antes de que se dispare nada, usa el Umbral de número de coincidencias de la regla.

Inteligencia de amenazas#

Inteligencia de amenazas se suscribe a feeds STIX/TAXII de direcciones IP, dominios, URLs, direcciones de email y hashes de archivos maliciosos conocidos. Los eventos que mencionan uno se marcan con atributos threat.* al llegar, por los que pueden filtrar las reglas y los monitores, y cada minuto los eventos recientes se cotejan con los feeds y abren alertas y hallazgos como una regla. Consulta Inteligencia de amenazas.

Retención y facturación#

Los eventos de seguridad se facturan por GB ingerido, como el resto de tu telemetría, y se conservan durante tu retención de telemetría: la Retención predeterminada (días) del proyecto, en Ajustes del proyecto → Telemetría y APM → Retención de datos, o una retención definida en el servicio de telemetría al que pertenecen. Cuando termina la retención de un evento, se elimina.

Solución de problemas#

Próximos pasos#