Security postureの変更を検出する

これらのサンプルルールは、Compliance APIのアクティビティフィードが記録するアクティビティを使用して、組織のSecurity postureの変更についてアラートを出します。これらのルールは、イベントをSIEMに送信するで説明しているとおり、セキュリティ情報イベント管理（SIEM）システムがこれらのアクティビティを保存していることを前提としています。

ルールを作成する前に

各ルールは、平易な説明と、特定のクエリ言語に依存しないクエリで構成されています。

• クエリでは、アクティビティフィードのフィールド名に加えて、stored_atを使用します。stored_atは、アクティビティを保存した日時を表す、このページ独自の名前です。それ以外の名前は、独自のリストまたはエイリアスです。
• ルールでアクティビティを数える前に、idでそれらを重複排除してください。
• アクティビティは遅れて届く可能性があるため、ルールに別途指定がない限り、各ルールはcreated_atではなくstored_atを基準として、前回完了した実行以降の期間に対して実行してください。クエリではその期間を省略しています。
• ルールは、保存したアクティビティに対して発火するように作成し、保存していないアクティビティに対して発火するようには決して作成しないでください。保存していないアクティビティは、遅れているか、フィードが記録しない変更である可能性があります。保存したアクティビティを現在の結果と比較するには、イベントを結果と照合するを参照してください。

表明のルール

これら5つのルールは、org_security_control_attestation_updatedアクティビティを読み取ります。

リスクが受容された

誰かがセキュリティコントロールを満たさないリスクを受容した（accepted_risk）ときにアラートを出し、別の人がその判断を確認できるようにします。

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

このルールはsystem_actorを除外します。終了した表明（lapsed）などの自動的な変更は、statusを保持しますが、受容ではないためです。

コントロールが不合格として表明された

誰かがコントロールを不合格として表明した（control_failed）ときにアラートを出し、誰かがそのコントロールに対応できるようにします。

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

このルールは、リスクが受容されたと同じ理由でsystem_actorを除外します。

許可リスト外の人が表明を変更した

表明を管理する担当者のリストに含まれていない人が、表明を記録、変更、再保存、または取り消したときにアラートを出します。担当者のuser_idの値（allowed_user_ids）は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)

• リストに含まれるuser_actorまたはsystem_actor以外のアクターであれば、いずれもルールを発火させます。
• リストはactor.user_idの値で作成し、その値で照合してください。actor.email_addressは、アクティビティが記録された時点でその人が使用していたアドレスです（SIEMと相関させる）。

1人が多数の表明の変更を行った

1人が短時間に、組織で通常見られるよりも多くの表明の変更を行ったときにアラートを出します。しきい値の10と1時間の時間枠は例です。どちらも自組織のアクティビティに基づいて選んでください。

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

• ルールの前回の実行以降に保存したアクティビティを含むグループについてのみアラートを出し、保存したすべてのアクティビティを対象に数えてください。そうすることで、遅れて届いたアクティビティが、他のアクティビティを先に保存していた一連の集中した変更に加わります。
• created_atで数えると、取り込みのペースではなく、その人のペースを測定できます。

表明が自動的に終了した

lapsedアクティビティは、そこで示されているコントロールを確認するきっかけとして扱ってください。

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

lapsedアクティビティは、コントロールのチェック結果または現在の値が、表明が保存された時点のものと異なることを意味し、終了日（review_date）が過ぎたことを意味するものではありません。このアクティビティは遅れて届く可能性があります。

値が変わってもルールが機能し続けるようにする

これらのフィールドのいずれにも、新しい値が現れる可能性があります。

• 自動的な変更は、actor.serviceの値ではなくactor.typeで識別してください。
• ルールに記載されていないcontrol、action、またはstatusの値を持つアクティビティを除外しないでください。新しいactionの値が受容を記録する可能性があります。イベントリファレンスを参照してください。

ルールをテストする

許可リストのルールが発火することを確認するには、表明を行う権限があり、リストに含まれていない人を選びます。その人に、表明がなく、その結果に誰も依存していないコントロールに対して表明してもらい、その後その表明を取り消してもらいます。取り消されるまでの間、その表明によってそのコントロールの結果が変わる可能性があります。どちらのアクティビティも、アクティビティフィードに届くまでに時間がかかる場合があります。

これらのアクティビティをOpen Cybersecurity Schema Framework（OCSF）のイベントとして保存する場合は、Security postureのイベントをOCSFにマッピングするでそれらのフィールドのマッピングを説明しています。