Änderungen in Security posture erkennen

Diese Beispielregeln lösen einen Alarm aus, wenn sich in Security posture deiner Organisation etwas ändert, und nutzen dafür die Aktivitäten, die der Activity Feed der Compliance API erfasst. Sie setzen voraus, dass dein System für „security information and event management“ (SIEM) diese Aktivitäten speichert, wie unter Ereignisse an dein SIEM senden beschrieben.

Bevor du eine Regel schreibst

Jede Regel besteht aus einer schlichten Beschreibung und einer Abfrage in keiner bestimmten Abfragesprache.

• Abfragen verwenden die Feldnamen des Activity Feed sowie stored_at, den Namen, den diese Seite für den Zeitpunkt verwendet, zu dem du eine Aktivität gespeichert hast. Jeder andere Name ist deine eigene Liste oder ein eigener Alias.
• Bevor eine Regel Aktivitäten zählt, dedupliziere sie anhand von id.
• Sofern eine Regel nichts anderes angibt, führe sie über den Zeitraum seit ihrem letzten abgeschlossenen Durchlauf aus, bemessen nach stored_at, nicht nach created_at, da eine Aktivität verspätet eintreffen kann; die Abfragen lassen diesen Zeitraum weg.
• Schreibe Regeln, die bei einer Aktivität auslösen, die du gespeichert hast, niemals bei einer, die du nicht gespeichert hast: Sie kann verspätet sein oder eine Änderung sein, die der Feed nicht erfasst. Um gespeicherte Aktivitäten mit aktuellen Ergebnissen zu vergleichen, siehe Ereignisse mit Ergebnissen abgleichen.

Regeln für Bestätigungen

Diese fünf Regeln lesen Aktivitäten vom Typ org_security_control_attestation_updated.

Ein Risiko wurde akzeptiert

Löse einen Alarm aus, wenn jemand das Risiko (accepted_risk) akzeptiert, eine Sicherheitskontrolle nicht zu erfüllen, damit eine zweite Person die Entscheidung prüfen kann.

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

Die Regel schließt einen system_actor aus, weil eine automatische Änderung, etwa eine Bestätigung, die geendet hat (lapsed), den status beibehält, aber keine Akzeptanz ist.

Eine Kontrolle wurde als Nicht bestanden bestätigt

Löse einen Alarm aus, wenn jemand eine Kontrolle als Nicht bestanden (control_failed) bestätigt, damit sich jemand um die Kontrolle kümmert.

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

Die Regel schließt einen system_actor aus demselben Grund aus wie bei Ein Risiko wurde akzeptiert.

Jemand außerhalb einer Allowlist hat eine Bestätigung geändert

Löse einen Alarm aus, wenn eine Bestätigung von jemandem erfasst, geändert, erneut gespeichert oder entfernt wird, der nicht auf deiner Liste der Personen steht, die Bestätigungen verwalten. Bewahre deren user_id-Werte (allowed_user_ids) in deinem SIEM auf.

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)

• Jeder Akteur außer einem aufgeführten user_actor oder einem system_actor löst die Regel aus.
• Führe die Liste mit actor.user_id als Schlüssel: actor.email_address ist die Adresse, die die Person hatte, als die Aktivität erfasst wurde (Mit deinem SIEM korrelieren).

Eine Person hat viele Änderungen an Bestätigungen vorgenommen

Löse einen Alarm aus, wenn eine Person in kurzer Zeit mehr Änderungen an Bestätigungen vornimmt, als in deiner Organisation üblich ist. Der Schwellenwert von 10 und das Zeitfenster von 1 Stunde sind Beispiele; wähle beide anhand deiner eigenen Aktivität.

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

• Alarmiere nur für eine Gruppe, die eine seit dem letzten Durchlauf der Regel gespeicherte Aktivität enthält, und zähle über jede Aktivität, die du gespeichert hast, damit eine verspätete Aktivität zu einer Häufung hinzukommt, deren andere Aktivitäten du früher gespeichert hast.
• Wenn du nach created_at zählst, misst du das Tempo der Person, nicht das deiner Erfassung.

Eine Bestätigung endete automatisch

Betrachte eine lapsed-Aktivität als Anlass, die darin genannte Kontrolle zu überprüfen.

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

Eine lapsed-Aktivität bedeutet, dass sich das Prüfergebnis der Kontrolle oder ihr aktueller Wert von dem unterscheidet, mit dem die Bestätigung gespeichert wurde, und nicht, dass ein Enddatum (review_date) überschritten wurde. Sie kann verspätet eintreffen.

Regeln funktionsfähig halten, wenn sich Werte ändern

In jedem dieser Felder können neue Werte auftauchen.

• Erkenne automatische Änderungen anhand von actor.type, nicht anhand des Werts von actor.service.
• Verwirf keine Aktivitäten, deren Wert für control, action oder status eine Regel nicht aufführt; ein neuer action-Wert kann eine Akzeptanz erfassen. Siehe die Referenz zu Ereignissen.

Eine Regel testen

Um die Allowlist-Regel auslösen zu sehen, wähle jemanden aus, der Bestätigungen abgeben kann und nicht auf deiner Liste steht. Lass diese Person eine Kontrolle bestätigen, die keine Bestätigung hat und auf deren Ergebnis sich niemand verlässt, und die Bestätigung anschließend entfernen. Solange sie nicht entfernt ist, kann die Bestätigung das Ergebnis dieser Kontrolle ändern. Beide Aktivitäten können eine Weile brauchen, bis sie im Activity Feed ankommen.

Wenn du diese Aktivitäten als Ereignisse im Open Cybersecurity Schema Framework (OCSF) speicherst, bildet Ereignisse aus Security posture auf OCSF abbilden ihre Felder ab.