セキュリティケースとプレイブック (SOAR)

セキュリティイベントは、検出ルール、脅威インテリジェンス、接続したセキュリティ製品が見つけたものをケースに変えます。調べる価値のある事象ごとにケースがひとつでき、同じユーザー、ホスト、アドレスに関する検出はすべてそのケースにまとめられます。アナリストはキューでケースを処理し、プレイブックは自動で、またはクリックひとつでケースに対応します。

仕組み#

キューを見るには 製品 → セキュリティイベント → セキュリティケース → 未解決のケース を開きます。 自分に割り当て済み、 未担当、 クローズ済みのケース、 すべてのケース はその隣にある独立したページで、それぞれ名前のとおりのケースを一覧表示します。

始める前に#

ケースとプレイブックの権限は、3 つの Security ロールに従います。Project Owner と Project Admin は、すべての操作ができます。

ケースの作成からプレイブックのステップの承認まで、これらの権限はそれぞれ個別に付与することもできます。 権限リファレンス を参照してください。

ケースの発生源#

どのソースも既定でオンです。接続は、別のレベルを選ばない限り、 高以上 のアラートに対してケースを開きます。それより低いアラートも、イベントとしては取り込まれます。

検出のまとめ方#

検出はひとつのエンティティに関するものです。エンティティとは、ブルートフォースのルールにおける IP アドレスのようにルールがグループ化に使う値や、脅威インテリジェンスの一致が示すインジケーターです。エンティティのない検出は単独で扱われます。

• そのエンティティに関する開いているケースがすでにあれば、検出はそのケースに加わります。ケースのエンティティと ATT&CK のマッピングが増え、優先度は検出の優先度まで上がります。下がることはありません。
• そのようなケースがなければ、検出にちなんだ名前で、検出の優先度を持つ新しいケースが開きます。
• 再び発火した検出は、行を追加する代わりに、その行の回数を増やします。

ケースの優先度は、検出の重大度から決まります。

ケースに対応する#

ケースは 4 つのステータスを順に進みます。新規から直接クローズされる誤検知のようにステータスを飛ばすことも、クローズしたケースを再び開くこともできます。

ケースのページには、対応に必要なものがすべてそろっています。

• 上部: Assign to Me、 Run Playbook、 インシデントを宣言、 Close Case のボタン、ステータスのステップ、そしてその横のメニューにある優先度。
• Status200 AI: Status200 AI がケースをどう読んだか、提案する優先度とプレイブック、そしてその根拠。セキュリティの Status200 AI を参照してください。
• 検出: ケースを開いた、またはケースに加わった検出の内容、その発火回数、一致した最新のイベント。
• エンティティ: ケースが対象とするユーザー、ホスト、アドレスと、直近 7 日間のすべてのセキュリティイベントにおけるそれらのアクティビティ。どれも 相関分析 で開けます。
• MITRE ATT&CK: 検出が対応付けられた戦術と手法。それぞれ attack.mitre.org の該当ページにリンクしています。
• プレイブックの実行: 各プレイブックがケースに対して行ったことをステップごとに示し、承認待ちのステップも表示します。
• メモ と タイムライン: チームが書いた内容と、起きたことのすべてを、誰が行ったかとともに示します。

複数のケースをまとめて処理するには、キューでそれらを選択し、 Assign to Me、 Change Status、 Change Priority のいずれかを使います。

ケースをクローズする#

Close Case では、判定と、任意のクローズ時のメモを入力します。

判定は概要ページで集計されます。ケースが False Positive としてクローズされ続けるルールは、調整が必要なルールです。

Google SecOps のアラートから開いたケースは、接続で ケースがクローズされたらアラートもクローズする がオンなら、判定とクローズ時のメモを付けて Google SecOps でもそのアラートをクローズします。 Google SecOps を参照してください。

インシデントを宣言する#

インシデントを宣言 は、選んだ重大度で、そのケースについての Status200 のインシデントを開き、両者を相互にリンクします。インシデントの説明にはケースが記され、ケースのヘッダーにはインシデントへのリンクが表示されます。そこから先は、オンコール、ステータスページ、ポストモーテムが引き継ぎます。ケースを処理でき、かつインシデントを作成できるロールが必要です。

通知#

Status200 は、ケースについて 3 つのことを人に知らせます。誰も何かを設定する必要はありません。 おすすめをオンにする をクリックしただけのプロジェクトでも、高と重大のケースについて、メールとプッシュで知らせを受けます。

• 知らされるのは、そのケースを閲覧できる人だけです。Project Owner、Project Admin、そして Security Admin、Security Member、Security Viewer のロールです。一部のラベルに限定されたロールには、それらのラベルが付いたケースについてだけ知らされます。
• 自分が行ったことについては、誰も知らされません。手動でケースを開いた人、ケースを割り当てた人、実行を開始した人には、そのことは通知されません。
• 各自がひとつのケースについて知らされるのは一度だけです。優先度が中で開き、後で重大に上がったケースは、上がった時点で、高または重大を選んだ人に届きます。中を選んだ人には、ケースが開いたときにすでに知らされているため、再び届くことはありません。
• テスト攻撃を送信 によるテスト攻撃は、誰にも通知しないケースを開きます。
• 重大のケースと承認待ちのステップはすぐに送信され、 メールのまとめ で保留されることはありません。
• ケースの タイムライン には、誰にいつ知らされたかが表示されます。

知らされる内容を選ぶ#

各自が ユーザー設定 → 通知設定 → セキュリティ で、自分で選びます。通知ごとのチャネル (メール、SMS、通話、プッシュ、Telegram、Slack、Microsoft Teams、Webhook) と、 新しいセキュリティケース の下で、通知を受ける優先度です。

セキュリティケースについては、WhatsApp のメッセージは送信されません。プッシュ通知は Status200 アプリを開き、そのリンクはブラウザーでケースを開きます。

Slack と Microsoft Teams のチャンネルに投稿する#

チャンネルに投稿するには、 製品 → セキュリティイベント → ワークスペース → Slack (または Microsoft Teams) にルールを追加します。どちらも接続していない場合、このセクションの項目は Slack または Teams を接続 のひとつだけです。ルールには、投稿先のチャンネル (Microsoft Teams ではチャットも) と、必要であれば対象とするケースを指定します。

3 つの通知は、それぞれ、その時点でケースが一致するすべてのルールのチャンネルに投稿されます。 セキュリティケースの優先度 が 重大 と 高 のいずれかを含む、というルールは、高と重大のケースを開いた時点で投稿し、中のケースは高に上がった時点で投稿します。セキュリティケースに専用のチャンネルが作られることはありません。

プレイブック#

プレイブックは、ケースに対して実行されるステップの一覧です。 製品 → セキュリティイベント → Playbooks で、テンプレートから、または空の状態から作成し、そのページでステップを追加します。

プレイブックが実行されるタイミング#

有効なプレイブックはどれも、ケースの Run Playbook から手動で実行することもできます。自動で実行されるプレイブックは、対象を絞り込めます。

• For Cases At Least: この優先度以上のケースだけ。
• Only For Detections From: ケースの元になった検出がこのソースから来たときだけ。
• Only For These Detection Rules: 検出がこれらのルールのいずれかから来たときだけ。

無効にしたプレイブックは、自動でも手動でも実行されません。

ステップ#

プレイブックのステップは最大 25 個です。ステップは順番に、前のステップが終わるたびにひとつずつ実行されます。どのステップにも、次の設定ができます。

• Needs Approval: 誰かがケース上で承認するまで、そのステップの前で実行を止めます。誰かを締め出す 4 つのステップでは、Security Admin がオフにしない限り、常にオンです。
• Only If Threat Intel Matched: 同じ実行の前の Check entities against threat intel ステップが既知のインジケーターを見つけていない限り、そのステップをスキップします。
• Carry On If It Fails: このステップが失敗しても次のステップを実行します。オフの場合、失敗したステップで実行が止まります。

封じ込め#

封じ込めステップは、製品への セキュリティイベントの接続 を通じて動作します。その接続には、読み取り以上のアクセス権が必要です。

封じ込めステップが動作するのは、ケースが対象とする次のユーザーまたはホストだけで、ケースに名前が挙がったものすべてではありません。

• ケースの検出のグループ化に使われている値。たとえば、ありえない移動のルールがグループ化に使うアカウントや、接続した製品のアラートが示すホストです。
• ケースのユーザーまたはホストのうち、脅威インテリジェンスがインジケーターとして把握しているもの。

VPN へのブルートフォースのように、アドレスでグループ化されたケースは、どちらにも当たりません。そのケースの封じ込めステップはスキップされ、狙われたアカウントにも、攻撃を受けたゲートウェイにも手を付けません。ステップが対象にするのは最大 10 件のユーザーまたはホストです。それぞれを製品の中で名前によって探し、各対象に何をしたかを実行に記録します。完了、すでに完了、見つからなかった、拒否された、保護されている、のいずれかです。

保護対象のエンティティ#

メニューの Playbooks の下にある Protected Entities には、緊急アクセス用アカウント、ドメインコントローラー、VPN ゲートウェイなど、どのプレイブックも封じ込めないユーザーとホストが一覧表示されます。値は大文字と小文字を区別せずに一致し、 * は任意の文字の並びを表します。 svc-* はすべてのサービスアカウントを保護します。ステップは、保護されたユーザーやホストを保護されていると報告し、手を付けません。この一覧は Security Admin が管理します。

承認#

誰かを締め出す 4 つのステップは承認を待ちます。そのいずれかで Needs Approval をオフにできるのは Security Admin だけで、Status200 は誰がオフにしたかを記録します。承認では、ステップが動作する予定のユーザーやホストが Act On の下に、すべてチェックされた状態で並びます。ステップが手を付けるべきでないものは、チェックを外してください。保護されたものは選択肢に表示されません。実行を開始した人は、その実行のステップを承認できず、承認は別の人が行います。ただし、開始した人も拒否はできます。

元に戻す#

元に戻すステップは、元のステップと同じく、ケースが対象とするユーザーまたはホストに動作します。実行が止まった後は、封じ込められたユーザーやホストのステップに、それ専用のボタンも表示されます。 Unsuspend、 Lift Containment、 解放 のいずれかです。終了した Okta セッションは元に戻せません。元に戻した操作はすべて、ケースのタイムラインとプロジェクトの監査ログに残ります。

メッセージ#

メモ、メール、Slack への投稿、Teams への投稿では、ケースの値を使えます。

独自のメッセージがないメールや投稿では、ケースの概要が送られます。

実行と承認#

すべての実行は、そのケースと 製品 → セキュリティイベント → Playbooks → プレイブックの実行 に、ステップごとに一覧表示されます。

承認待ちのステップでは、実行に Approve と 拒否 が表示され、任意でコメントを添えられます。承認するとそのステップから実行が続き、拒否すると実行が終わります。判断の内容、判断した人、コメントは、ステップ、ケースのタイムライン、プロジェクトの監査ログに残ります。 メニューの Playbooks の下にある 承認待ち は、判断を待っている実行を一覧表示して件数を示し、 プレイブックの実行 はすべての実行を一覧表示します。

再起動などでワーカーからの応答が途絶えた実行は、再び拾い上げられます。キューに入った実行は 2 分後に再びキューに入れられ、30 分間何も報告しなかった実行は失敗になります。

概要ページ#

製品 → セキュリティイベント → 概要 は、この製品を開いたときに最初に表示されるページです。

• 自分に割り当てられた開いているケース、誰も引き受けていない開いているケース、承認待ちのプレイブックのステップ。それぞれの件数から、それを一覧表示するページが開きます。
• 直近 30 日間に開いたケースについての 平均確認時間、 平均封じ込め時間、 平均クローズ時間。それぞれ、ケースが開いてから、誰かが引き受けるまで (担当者を割り当てるか、新規から移すまで)、Contained になるまで、クローズ済みになるまでの時間です。まだ待っているケースは平均に含まれません。
• 過去 30 日間に日ごとに開いたケースの数 (優先度別) と、過去 14 日間に日ごとに発生した検出の数 (ソース別)。
• 開いているケースの優先度別とステータス別の数、直近 30 日間の判定、ケースの背後にある ATT&CK の戦術、最も多く発火した検出、最も多くの検出結果に名前が挙がったエンティティ。

それらの上の帯には、セキュリティの設定状況が表示されます。ソース、検出、ケース、プレイブックが、それぞれの数値とともに並びます。まだ設定していないプロジェクトでは、そこに おすすめをオンにする と テスト攻撃を送信 が表示されます。セキュリティをはじめる を参照してください。誰の対応も必要ないときはページに 異常なし と表示され、グラフは表示するものができた時点で現れます。

脅威を見つける#

• エンティティ は、直近の 1 日、1 週間、1 か月のあいだに検出結果で最も多く名前が挙がったユーザー、ホスト、アドレス、ハッシュをランク付けし、任意の値を 30 日分のイベントから検索します。
• Rule Library には、ID、エンドポイント、クラウド、ネットワーク、Web、Kubernetes の脅威に対応した既製の検出ルールがあります。どれも、接続したすべてのソースが正規化される項目に合わせて書かれた Sigma ルールです。 ルールを追加 すると、それがあなたの検出ルールとして、オンの状態で、アラートではなくケースを開く設定で作成されます。ほかのルールと同じく 検出ルール で変更できます。おすすめ の印が付いたルールは、Status200 がすでに持っているデータから脅威を見つけます。まだ追加していないものは、1 つのボタンでまとめて追加できます。
• ATT&CK Coverage は MITRE ATT&CK のマトリクスを描き、有効なルールがカバーする手法を強調表示し、ライブラリのルールでカバーできる手法を枠線で示します。

自動化する#

• ワークフロー: ケースやメモが作成、更新、削除されたときにワークフローを開始できます。 Run a workflow ステップは、トリガーが Webhook のワークフローを開始します。
• API: ケース、メモ、検出、プレイブック、実行、保護対象のエンティティには、Status200 のほかの部分と同じ REST API が /security-case、 /security-case-note、 /security-detection、 /security-playbook、 /security-playbook-run、 /security-protected-entity の下にあります。 API リファレンス を参照してください。
• AI エージェント: MCP サーバーには、ケース、メモ、検出、プレイブックのためのツールがあります。 MCP サーバー を参照してください。

トラブルシューティング#

次のステップ#