Detectar cambios en Security posture

Estas reglas de ejemplo generan alertas sobre cambios en Security posture de tu organización, usando las actividades que registra el Activity Feed de la Compliance API. Suponen que tu sistema de “security information and event management” (gestión de información y eventos de seguridad), o SIEM, almacena estas actividades, como se describe en Enviar eventos a tu SIEM.

Antes de escribir una regla

Cada regla consta de una descripción sencilla y de una consulta que no usa ningún lenguaje de consulta en particular.

• Las consultas usan los nombres de campo del Activity Feed, más stored_at, el nombre que esta página usa para el momento en que almacenaste una actividad. Cualquier otro nombre es una lista o un alias propio.
• Antes de que una regla cuente actividades, deduplícalas por id.
• Salvo que una regla indique otra cosa, ejecútala sobre el tiempo transcurrido desde su última ejecución completada, según stored_at, no created_at, porque una actividad puede llegar tarde; las consultas omiten ese intervalo.
• Escribe reglas que se activen con una actividad que almacenaste, nunca con una que no: puede llegar tarde, o ser un cambio que el Activity Feed no registra. Para comparar las actividades almacenadas con los resultados actuales, consulta Comparar eventos con resultados.

Reglas de atestación

Estas cinco reglas leen actividades org_security_control_attestation_updated.

Se aceptó un riesgo

Genera una alerta cuando alguien acepta el riesgo (accepted_risk) de no cumplir un control de seguridad, para que una segunda persona pueda revisar la decisión.

type == "org_security_control_attestation_updated"
AND status == "accepted_risk"
AND actor.type != "system_actor"

La regla excluye a un system_actor, porque un cambio automático, como una atestación que dejó de estar vigente (lapsed), conserva el status pero no es una aceptación.

Un control se atestó como Fallido

Genera una alerta cuando alguien atesta un control como Fallido (control_failed), para que alguien haga seguimiento del control.

type == "org_security_control_attestation_updated"
AND status == "control_failed"
AND actor.type != "system_actor"

La regla excluye a un system_actor por el mismo motivo que en Se aceptó un riesgo.

Alguien fuera de una lista de permitidos cambió una atestación

Genera una alerta cuando alguien que no está en tu lista de personas que administran atestaciones registra, cambia, vuelve a guardar o borra una atestación. Guarda sus valores de user_id (allowed_user_ids) en tu SIEM.

type == "org_security_control_attestation_updated"
AND actor.type != "system_actor"
AND NOT (actor.type == "user_actor" AND actor.user_id IN allowed_user_ids)

• Cualquier actor que no sea ni un user_actor de la lista ni un system_actor activa la regla.
• Identifica la lista por actor.user_id: actor.email_address es la dirección que tenía la persona cuando se registró la actividad (Correlaciona con tu SIEM).

Una persona hizo muchos cambios de atestación

Genera una alerta cuando una persona hace más cambios de atestación en poco tiempo de lo habitual en tu organización. El umbral de 10 y la ventana de 1 hora son ejemplos; elige ambos a partir de tu propia actividad.

type == "org_security_control_attestation_updated"
AND actor.type == "user_actor"
| group by organization_uuid, actor.user_id over a sliding 1 hour of created_at
| where count(distinct id) >= 10

• Alerta solo para un grupo que contenga una actividad almacenada desde la última ejecución de la regla, y cuenta sobre todas las actividades que almacenaste, para que una actividad que llega tarde se sume a una ráfaga cuyas otras actividades almacenaste antes.
• Contar por created_at mide el ritmo de la persona, no el de tu ingesta.

Una atestación dejó de estar vigente automáticamente

Trata una actividad lapsed como un aviso para revisar el control que nombra.

type == "org_security_control_attestation_updated"
AND action == "lapsed"

Una actividad lapsed significa que el resultado de la verificación del control o su valor actual difiere del que había cuando se guardó la atestación, no que haya pasado una fecha de finalización (review_date). Puede llegar tarde.

Mantener las reglas funcionando cuando cambian los valores

Pueden aparecer valores nuevos en cualquiera de estos campos.

• Identifica los cambios automáticos por actor.type, no por el valor de actor.service.
• No descartes actividades cuyo valor de control, action o status no figure en una regla; un nuevo valor de action puede registrar una aceptación. Consulta la referencia de eventos.

Probar una regla

Para ver cómo se activa la regla de la lista de permitidos, elige a alguien que pueda atestar y que no esté en tu lista. Pide a esa persona que ateste un control que no tenga atestación y de cuyo resultado nadie dependa, y que luego borre la atestación. Hasta que se borre, la atestación puede cambiar el resultado de ese control. Ambas actividades pueden tardar un poco en llegar al Activity Feed.

Si almacenas estas actividades como eventos de Open Cybersecurity Schema Framework (OCSF), Mapear eventos de Security posture a OCSF mapea sus campos.