午前3時47分:オープンソースSOCスタックが実際に検知したインシデントの内側

SOCに関する記事の多くはアーキテクチャの説明に終始します。この記事では、中堅企業向けに稼働している本番スタックで実際に発生したインシデントを、アラート単位で追っていきます。検知はWazuh、ケース管理はDFIR-IRIS、両者をつなぐのは自社開発のFastAPIインテグレーター。SaaSライセンスなし、クラウドSIEMの費用なし。すべてがオープンソースか自社開発です。

顧客を特定できる情報は一般化していますが、検知ロジック、タイムスタンプ、システムの挙動は実際のものです。

アーキテクチャの全体像を先に知りたい方は、コミット単位で構築過程をまとめた記事と、simpliSOCが監視する範囲全体をご覧ください。本記事は、そのスタックが実際に何を捉えたかの記録です。

午前3時47分 — 最初のアラート

経理部門のアカウントでVPNコンセントレーターへのログインが成功します。それ自体は珍しいことではありません。リモートワークが前提の環境では、業務時間外のログインが即座に不審とは限らないためです。Wazuhのアイデンティティルールセットがこれを記録し、リスクスコアを低く評価して処理を続けます。

午前3時52分 — 2回目のログイン、大陸をまたいで

5分後、同じアカウントが再び認証を通過します。今度は最初のログイン地点から約9,000km離れた住宅系IPブロックからです。単独のログインであれば、多くのSOCでも見過ごされるでしょう。しかし両方を合わせると、物理的に不可能な移動になります。

ここでステートレスなルールエンジンは限界に達します。Wazuhは「新しい場所からのログイン」を単一イベントとしてフラグ付けできますが、5分前のログインを記憶しておらず、両者の距離と経過時間を計算する手段も持ちません。この相関ロジックはインテグレーター層にあります。PostgreSQLを基盤としたワーカーがユーザーごとの直近の認証イベントを追跡し、haversine距離計算を経過時間と照合します。商用旅客機の速度を超える移動が必要な2回のログインは自動的にフラグ付けされます。アナリストが目視でパターンに気づく必要はありません。

相関エンジンがDFIR-IRISでケースをオープンします。重大度:クリティカル。SLAタイマー開始:初動対応まで1時間。

午前3時53分 — 人間が見る前のエンリッチメント

ケースがアナリストのキューに現れる時点で、すでにコンテキストが付与されています。インテグレーターのエンリッチメントワーカーが、2回目のログイン元IPをバックグラウンドでVirusTotalとAbuseIPDBに照会していました。このIPはコミュニティのブロックリスト3件に登録されており、過去のクレデンシャルスタッフィング攻撃との関連が確認されています。この信頼度スコアは構造化されたフィールドとしてケースノートに記録されており、アナリストが探し出さなければならない文章の中に埋もれてはいません。

これは見た目以上に重要です。多くのSOC構成では、エンリッチメントはトリアージの後に行われるか、アナリストが別ツールに切り替える必要があります。このスタックでは、IOCエンリッチメントが非同期で動作し、アラート作成と並行して実行されるため、ケースが人間に届く前に完了しています。

午前3時58分 — キューを溢れさせなかったアラート

同じ送信元IPが、その後4分間で2つのアカウントへのログインを試みます。いずれも失敗。通常であれば、それぞれが個別のアラートを生成します。重複排除がなければ、これはまさにアナリストがキューを無視するようになる典型的なパターンです。1つの根本原因に対して3つの関連アラートが、それぞれ個別の対応を要求してくるのです。

インテグレーターの重複排除ワーカーは、ルールごとに設定されたクールダウンウィンドウを使ってこれらを元のケースにまとめます。クレデンシャル悪用パターンには、本番環境のアラート量から調整された、ユーザー/ホストごとのウィンドウが設定されています。推測ではありません。結果は1つのケース、1つのSLAタイマー、3つのデータポイント — 3つの別々のアラートではなく。

午前4時04分 — アナリストが対応開始

オンコールのアナリストがPagerDuty経由で呼び出されます。クリティカル重大度は自動的にそこにルーティングされます。IRISのケースを開くと、そこには両方のログインイベント、地理的位置の計算結果、IOCエンリッチメント、MITRE ATT&CKマッピング(T1078 – Valid Accounts)、そしてこのルール専用のトリアージチェックリストがYAMLから読み込まれた状態で、すべて1か所にまとまっています。午前4時に記憶を頼りに書き出す必要はありません。

アカウントは無効化され、経理部門に通知が送られ、セッショントークンは失効させられます。2回目のログインから封じ込めまでの合計時間は23分 — クリティカルSLAの1時間以内で、プログレスバーは緑のままでした。

午前4時31分 — ループを閉じる

ここは多くのスタックが省略しがちなステップです。アナリストはIRISでケースを確定させます。しかし、ケース管理ツールの中だけで完結する相関確認は、検知の半分にすぎません。インテグレーターはWazuhにsyslogメッセージを送り返し、確定したインシデントをSIEM自体に登録します。これで両方のインターフェースが一致します。相関は調査されただけでなく、今後同じアカウントから同じパターンを監視し続ける検知層に記憶されたのです。

インテグレーターがなければどうなっていたか

相関エンジンを取り除くと、これは無関係に見える低重要度のアラート2件が、別々のキューに並ぶだけになります。「ユーザーの入力ミス、VPNクライアントが古い位置情報をキャッシュしていた」として個別にクローズされ、誰も両者を結びつけません。

重複排除を取り除くと、2件ではなく5件のアラートになり、そのうち3件は同一イベントに対する重複です。これがアラート疲れを助長し、本当の兆候を見えにくくします。

エンリッチメントワーカーを取り除くと、アナリストは手動でVirusTotalを確認するために別タブを開くことになります。人間がコンテキストスイッチするたびに、23分という封じ込め時間は延びていきます。

個々の要素はどれも特別なものではありません。違いを生むのは、それらが連携し、人間が関与する前に動作していることです。

このスタックを支える数値

指標	値
カスタム検知ルール	8カテゴリにわたる95ルール
アラート同期サイクル(Wazuh→IRIS)	5秒ごと
IOCリスト更新	4時間ごと
相関の状態管理	PostgreSQLによる永続化
クリティカルインシデントのSLA	初動対応まで1時間
本件:検知から封じ込めまで	23分
デプロイ形態	オンプレミス100%、クラウド依存なし

なぜこの設計なのか

このスタックの検知ルールはすべて2バージョンで出荷されます。合成テストデータで発火するシミュレーションルールと、実際のイベントフィールドに合わせて調整された本番ルールです。このペアリングにより、上記の相関ロジックは実際のログインを監視する前にテストハーネスで検証済みでした。午前3時52分のアラートは、そのルールが初めて発火した瞬間ではなく、初めて重要な意味を持った瞬間だったのです。

これはまた、このスタックがWazuh組み込みのactive-responseスクリプトに依存せず、独立したFastAPIサービスとして稼働している理由でもあります。相関にはイベント間で持続する状態が必要であり、エンリッチメントはアラート作成をブロックせずに非同期で行う必要があり、今回のようなインシデント後にしきい値を調整する際には、あらゆる判断がREST endpoint経由で再現可能でなければなりません。

APPI(個人情報保護法)やJ-SOX、そして経済安全保障推進法の対象となる企業にとって、ログとインシデント対応の証跡が海外のクラウドSIEMではなく国内オンプレミス基盤に残ることは、監督官庁への報告や監査対応を大きく単純化します。NISCのガイドラインに沿った運用体制を求められる場合も同様です。

よくある質問

これは実際のインシデントですか、それともデモ用のシナリオですか
検知ロジック、タイムスタンプ、システムの挙動は実際の本番環境から取得したものです。顧客を特定できる情報は機密保持のため一般化しています。

このセットアップはクレデンシャル悪用以外も検知できますか
はい。同じ相関エンジンが、同じ永続的な状態管理のアプローチでラテラルムーブメントや権限昇格のパターンも処理します。クレデンシャル悪用は、全体の流れを最も明確に説明できる例として取り上げています。

自社環境でこのようなスタックを稼働させるには何が必要ですか
既存のログソースとコンプライアンス要件によって異なります。最も早い方法は、自社に近いシナリオで実際の動作を確認することです。

既存のファイアウォールやエンドポイントツールを置き換えるものですか
いいえ。このスタックは既存のペリメーターおよびエンドポイントのログソース(ファイアウォールsyslog、Windows AD、Sysmon、ハイパーバイザーログ)を取り込みます。その上に載る検知・相関・ケース管理レイヤーであり、既存のログ収集を置き換えるものではありません。

このスタックが実際のシナリオを捉える様子をご覧ください

23分の封じ込め時間を読むことと、相関エンジンがリアルタイムでフラグを立て、IRISのケースが自動生成され、Wazuhへループが閉じる様子を見ることは別の体験です。デモをご依頼ください。 御社の実際の環境に近いシナリオを — 御社のログソース、コンプライアンス要件、アラート量に基づいて — 実演いたします。

hello@simplico.net

関連サービス