Détecter les changements dans Security posture

Ces exemples de règles déclenchent une alerte lors de changements dans la Security posture de votre organisation, à l’aide des activités que le flux d’activité de la Compliance API enregistre. Ils supposent que votre système de « security information and event management » (gestion des informations et des événements de sécurité), ou SIEM, stocke ces activités, comme le décrit Envoyer les événements vers votre SIEM.

Avant d’écrire une règle

Chaque règle se compose d’une description simple et d’une requête écrite dans aucun langage de requête particulier.

• Les requêtes utilisent les noms de champs du flux d’activité, ainsi que stored_at, le nom que cette page donne au moment où vous avez stocké une activité. Tout autre nom est votre propre liste ou alias.
• Avant qu’une règle compte des activités, dédoublonnez-les par id.
• Sauf si une règle indique le contraire, exécutez-la sur la période écoulée depuis sa dernière exécution terminée, selon stored_at, et non created_at, car une activité peut arriver en retard ; les requêtes n’incluent pas cette plage.
• Écrivez des règles qui se déclenchent sur une activité que vous avez stockée, jamais sur une activité que vous n’avez pas stockée : elle peut être en retard, ou correspondre à un changement que le flux n’enregistre pas. Pour comparer les activités stockées aux résultats actuels, consultez Comparer les événements aux résultats.

Règles d’attestation

Ces cinq règles lisent les activités org_security_control_attestation_updated.

Un risque a été accepté

Déclenchez une alerte lorsque quelqu’un accepte le risque (accepted_risk) de ne pas respecter un contrôle de sécurité, afin qu’une deuxième personne puisse examiner la décision.

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

La règle exclut un system_actor, car un changement automatique, comme une attestation qui a pris fin (lapsed), conserve le status mais ne constitue pas une acceptation.

Un contrôle a été attesté comme Échoué

Déclenchez une alerte lorsque quelqu’un atteste d’un contrôle comme Échoué (control_failed), afin que quelqu’un assure le suivi du contrôle.

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

La règle exclut un system_actor pour la même raison que Un risque a été accepté.

Quelqu’un hors d’une liste d’autorisation a modifié une attestation

Déclenchez une alerte lorsqu’une attestation est enregistrée, modifiée, enregistrée à nouveau ou retirée par une personne qui ne figure pas sur votre liste des personnes qui gèrent les attestations. Conservez leurs valeurs user_id (allowed_user_ids) dans votre 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)

• N’importe quel acteur autre qu’un user_actor listé ou qu’un system_actor déclenche la règle.
• Faites en sorte que la liste soit identifiée par actor.user_id : actor.email_address est l’adresse que la personne avait lorsque l’activité a été enregistrée (Corréler avec votre SIEM).

Une personne a effectué de nombreux changements d’attestation

Déclenchez une alerte lorsqu’une personne effectue en peu de temps plus de changements d’attestation qu’il n’est habituel pour votre organisation. Le seuil de 10 et la fenêtre d’une heure sont des exemples ; choisissez-les tous deux en fonction de votre propre activité.

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

• Ne déclenchez une alerte que pour un groupe qui contient une activité stockée depuis la dernière exécution de la règle, et comptez sur toutes les activités que vous avez stockées, afin qu’une activité en retard rejoigne une rafale dont vous avez stocké les autres activités plus tôt.
• Compter par created_at mesure le rythme de la personne, et non celui de votre ingestion.

Une attestation a pris fin automatiquement

Considérez une activité lapsed comme une invitation à examiner le contrôle qu’elle nomme.

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

Une activité lapsed signifie que le résultat de la vérification du contrôle ou sa valeur actuelle diffère de celui sur lequel l’attestation a été enregistrée, et non qu’une date de fin (review_date) est passée. Elle peut arriver en retard.

Maintenir le fonctionnement des règles lorsque les valeurs changent

De nouvelles valeurs peuvent apparaître dans n’importe lequel de ces champs.

• Identifiez les changements automatiques par actor.type, et non par la valeur de actor.service.
• Ne supprimez pas les activités dont la valeur de control, action ou status ne figure pas dans une règle ; une nouvelle valeur d’action peut enregistrer une acceptation. Consultez la référence des événements.

Tester une règle

Pour voir la règle de la liste d’autorisation se déclencher, choisissez une personne autorisée à attester et qui ne figure pas sur votre liste. Demandez à cette personne d’attester d’un contrôle qui n’a aucune attestation et dont personne n’utilise le résultat, puis de retirer l’attestation. Tant que l’attestation n’est pas retirée, elle peut modifier le résultat de ce contrôle. Les deux activités peuvent mettre un certain temps à atteindre le flux d’activité.

Si vous stockez ces activités sous forme d’événements Open Cybersecurity Schema Framework (OCSF), Mapper les événements de Security posture vers OCSF mappe leurs champs.