SIEM設計とSOC運用
要旨
SIEMやSOCの設計では、「どのログを集めるか」が最初の論点になりやすい。しかし、ログを大量に集めるだけでは、攻撃の予兆検知、侵害の早期検知、封じ込め、復旧、事後調査にはつながらない。
重要なのは、ログを「見るため」ではなく「判断するため」に集めることである。SIEMはログ保管庫ではなく、攻撃仮説、証拠、判断、アクションをつなぐSOCの運用基盤として設計する必要がある。
NIST SP 800-92は、組織全体でログ管理を設計、実装、維持するための実務的なガイダンスを提供している。また、NIST SP 800-61 Rev.3は、インシデント対応を検知、対応、復旧を含むサイバーセキュリティリスク管理活動に統合する考え方を示している。12
本記事では、SIEM/SOC設計を次の観点で整理する。
- 攻撃の予兆検知
- 必要なログ
- 相関分析の具体例
- 閾値設計
- 検知時のアクション
- 侵害の早期検知
- 隔離、復旧に必要なログ
- 侵害後の調査、フォレンジックに必要なログ
SIEM/SOC設計の基本構造
SIEM設計では、次の順番で考える。
┌────────────────────────────────────────────
SIEM設計の基本順序
────────────────────────────────────────────
1. 何を検知したいのか
↓
2. そのためにどのログが必要か
↓
3. どのログ同士を相関させるか
↓
4. どの条件でアラートにするか
↓
5. 検知したら誰が何をするか
↓
6. どの証跡を保全するか
よくある失敗は、これを逆にしてしまうことである。
┌────────────────────────────────────────────
よくある失敗
────────────────────────────────────────────
× とりあえずログを集める
× SIEMに入れれば何か見えると考える
× 製品デフォルトの相関ルールに依存する
× アラートが多すぎてSOCが疲弊する
× 重大アラートがノイズに埋もれる
× アラート後のアクションが決まっていない
正しい設計は、攻撃シナリオから逆算することである。MITRE ATT&CKのData Sourcesは、攻撃技術ごとに、検知に必要となるデータソースを逆算するための参照として使える。ATT&CKは、Data Sourcesを「センサーやログから収集できる情報の対象」として整理しており、Data Componentsでは検知に関係する具体的な属性や値を示している。34
ログとアクションの関係
SOC運用では、ログを単体で見ても判断できないことが多い。
例えば、ログイン失敗が5回あっただけでは、単なる入力ミスかもしれない。しかし、同一IPアドレスから多数のユーザーにログイン失敗が発生していれば、パスワードスプレーの可能性が高まる。さらに、その後にログイン成功があり、直後にMFA設定変更や大量ファイルダウンロードがあれば、アカウント侵害の可能性が高い。
┌────────────────────────────────────────────
ログからアクションへの変換
────────────────────────────────────────────
単発ログ
例：ログイン失敗
↓
相関分析
例：同一IPから複数ユーザーに失敗
↓
攻撃仮説
例：パスワードスプレー
↓
追加確認
例：成功ログイン有無、MFA状況、送信元評価
↓
判断
例：侵害疑い、監視継続、誤検知
↓
アクション
例：IPブロック、セッション失効、ID停止、本人確認
CISA、ASD ACSC、NSA、FBI、NCSC-UK、CCCSなどが共同で示したイベントログと脅威検知のベストプラクティスでは、イベントログの方針、集中収集と相関、ログの完全性、関連脅威に対する検知戦略が重要な要素として整理されている。56
まず優先すべきログ
最初から全ログをSIEMに入れるのは現実的ではない。優先度を付ける必要がある。
┌────────────────────────────────────────────
SIEMに入れるログの優先順位
────────────────────────────────────────────
最優先：
・IdPログ
・AD / Entra ID等の認証ログ
・VPNログ
・EDRログ
・クラウド監査ログ
高優先：
・DNSログ
・Proxyログ
・FWログ
・WAFログ
・SaaS監査ログ
中優先：
・DLPログ
・CASBログ
・メールログ
・DB監査ログ
・ファイルサーバアクセスログ
補助情報：
・資産台帳
・脆弱性情報
・構成管理情報
・チケット情報
・人事イベント情報
最初に優先すべきなのは、次の5系統である。
┌────────────────────────────────────────────
最初にSIEMへ入れるべき5系統
────────────────────────────────────────────
1. 認証ログ
初期侵入、不正ログイン、横展開の検知に必要。
2. EDRログ
プロセス実行、ファイル作成、外部通信、横展開の検知に必要。
3. クラウド/IAM監査ログ
権限変更、鍵作成、API実行、監査設定変更の検知に必要。
4. DNS/Proxyログ
C2通信、不審サイト接続、外部送信の検知に必要。
5. 重要SaaSの監査ログ
ファイル共有、外部公開、管理者操作、データ持ち出しの検知に必要。
攻撃の予兆検知
攻撃の予兆検知とは、明確な侵害が確認される前に、攻撃準備や初期侵入の兆候を見つけることである。
予兆検知では、すべてを重大インシデントとして扱うのではなく、監視強化、追加確認、防御設定の見直しにつなげることが重要である。
予兆検知に必要なログ
| 検知対象 | 必要なログ |
|---|---|
| 外部スキャン | FW、WAF、IDS/IPS、CDN、Webサーバログ |
| 認証試行 | IdP、VPN、AD、SaaS、メール認証ログ |
| パスワード攻撃 | IdP、AD、VPN、MFAログ |
| フィッシング | メールログ、URLクリックログ、EDR、DNS |
| C2準備通信 | DNS、Proxy、FW、EDR通信ログ |
| クラウド探索 | クラウド監査ログ、IAMログ、API実行ログ |
| Web攻撃 | WAF、Webサーバ、アプリケーションログ |
相関分析例：パスワードスプレー
┌────────────────────────────────────────────
検知シナリオ：パスワードスプレー
────────────────────────────────────────────
攻撃仮説：
攻撃者が、少数のパスワードを多数ユーザーに対して試行している。
必要ログ：
・IdPログ
・VPNログ
・ADログ
・MFAログ
相関条件：
・同一送信元IPから複数ユーザーにログイン失敗
・失敗理由が「パスワード誤り」
・短時間に対象ユーザー数が増加
閾値例：
・10分間で20ユーザー以上に失敗
・1時間で50ユーザー以上に失敗
・失敗後に1件でも成功した場合は重大度を上げる
除外条件：
・社内Proxy
・既知の監視サービス
・認証連携基盤
・正規の脆弱性診断元
初期アクション：
・送信元IPの評価
・対象ユーザー一覧の確認
・成功ログイン有無の確認
・該当ユーザーの追加監視
強いアクション：
・送信元IPブロック
・条件付きアクセス強化
・該当ユーザーのセッション確認
・必要に応じてパスワードリセット
相関分析例：MFA疲労攻撃
┌────────────────────────────────────────────
検知シナリオ：MFA疲労攻撃
────────────────────────────────────────────
攻撃仮説：
攻撃者がユーザーにMFA通知を連続送信し、誤承認を誘っている。
必要ログ：
・IdPログ
・MFAログ
・セッションログ
相関条件：
・同一ユーザーに短時間でMFA要求が連続
・MFA拒否または未応答が連続
・拒否後または未応答後にMFA成功
閾値例：
・10分間でMFA要求5回以上
・30分間でMFA拒否3回以上
・MFA拒否後の成功はHigh以上
初期アクション：
・本人確認
・ログイン元IP確認
・成功セッション確認
強いアクション：
・セッション失効
・パスワードリセット
・MFA再登録確認
・該当アカウントの一時停止
相関分析例：Webスキャン
┌────────────────────────────────────────────
検知シナリオ：Web攻撃スキャン
────────────────────────────────────────────
攻撃仮説：
攻撃者が公開Webサイトに対して、管理画面、脆弱パス、既知脆弱性を探索している。
必要ログ：
・WAFログ
・Webサーバログ
・CDNログ
・アプリケーションログ
相関条件：
・存在しないパスへの連続アクセス
・管理画面、設定ファイル、バックアップファイル名へのアクセス
・複数の攻撃シグネチャへの一致
・404/403の後に200応答が発生
閾値例：
・5分間で404が50件以上
・管理系パスへのアクセスが10件以上
・攻撃シグネチャ一致が短時間に複数発生
・スキャン後の200応答は重大度を上げる
初期アクション：
・送信元IP確認
・User-Agent確認
・アクセスされたパスの確認
・200応答になったURLの確認
強いアクション：
・一時ブロック
・WAFルール強化
・レート制限
・対象アプリケーションの脆弱性確認
相関分析例：C2ビーコン疑い
┌────────────────────────────────────────────
検知シナリオ：C2ビーコン通信
────────────────────────────────────────────
攻撃仮説：
端末がマルウェア感染し、外部C2サーバへ周期的に通信している。
必要ログ：
・DNSログ
・Proxyログ
・FWログ
・EDR通信ログ
相関条件：
・同一端末から同一外部先へ周期的通信
・新規登録ドメインまたは低評価ドメインへの通信
・業務で通常使わないTLDへの通信
・不審プロセスからの通信
閾値例：
・同一外部先へ5分間隔で6回以上
・深夜帯の周期通信
・通信量は少ないが一定間隔で継続
・EDRで不審プロセスと紐付いた場合はHigh
初期アクション：
・端末所有者確認
・通信先ドメイン/IPの評価
・プロセス確認
・同一通信先への他端末検索
強いアクション：
・端末隔離
・通信先ブロック
・メモリ/ディスク調査
・同一IoCの全社横断検索
侵害の早期検知
侵害の早期検知では、すでに攻撃者が内部に入っている前提で考える。
見るべき行動は、次のようなものである。
┌────────────────────────────────────────────
侵害後に見るべき攻撃行動
────────────────────────────────────────────
・不審な認証成功
・権限昇格
・内部探索
・横展開
・永続化
・機密情報アクセス
・外部送信
・監査ログや防御設定の変更
侵害早期検知に必要なログ
| 攻撃行動 | 必要なログ |
|---|---|
| 不審ログイン | IdP、VPN、AD、SaaSログ |
| 権限昇格 | AD、IAM、クラウド監査ログ、PAMログ |
| 横展開 | AD、EDR、SMB、RDP、WinRM、Windowsイベント |
| 内部探索 | EDR、DNS、認証ログ、ネットワークログ |
| 永続化 | EDR、OSイベント、レジストリ、サービス作成ログ |
| 情報収集 | ファイルサーバ、SaaS、DB監査ログ |
| 外部送信 | Proxy、FW、DLP、CASB、SaaS監査ログ |
| 設定改変 | クラウド監査、IAM、SaaS管理者ログ |
相関分析例：アカウント侵害後の不審操作
┌────────────────────────────────────────────
検知シナリオ：アカウント侵害後の不審操作
────────────────────────────────────────────
攻撃仮説：
攻撃者が正規ユーザーのアカウントでログインし、データを探索または持ち出している。
必要ログ：
・IdPログ
・SaaS監査ログ
・DLPログ
・CASBログ
・Proxyログ
相関条件：
・普段と異なる国、端末、時間帯からログイン成功
・ログイン直後に大量ファイルアクセス
・外部共有リンク作成
・MFA設定変更
・メール転送ルール作成
閾値例：
・通常と異なる国からログイン成功
・ログイン後30分以内に100ファイル以上ダウンロード
・ログイン後30分以内に外部共有リンクを10件以上作成
・MFA設定変更と大量アクセスが同一セッションで発生
初期アクション：
・本人確認
・セッション確認
・アクセス元IP確認
・対象ファイル一覧の保存
強いアクション：
・セッション失効
・アカウント一時停止
・パスワードリセット
・MFA再登録
・外部共有リンク無効化
相関分析例：特権IDの悪用
┌────────────────────────────────────────────
検知シナリオ：特権IDの悪用
────────────────────────────────────────────
攻撃仮説：
攻撃者が管理者権限を取得し、権限追加、鍵作成、監査回避を行っている。
必要ログ：
・ADログ
・IAMログ
・クラウド監査ログ
・PAMログ
・管理コンソール操作ログ
相関条件：
・管理者ロール付与
・アクセスキー作成
・監査ログ設定変更
・MFAなしの管理者ログイン
・通常運用時間外の管理操作
閾値例：
・深夜帯の管理者ロール付与
・新規アクセスキー作成
・監査ログの停止、削除、保存先変更
・変更申請なしの権限変更
初期アクション：
・操作主体確認
・変更申請との照合
・対象ロールと影響範囲の確認
強いアクション：
・不審な権限の剥奪
・アクセスキー無効化
・管理者セッション失効
・監査ログ保全
・CSIRTエスカレーション
相関分析例：横展開
┌────────────────────────────────────────────
検知シナリオ：横展開
────────────────────────────────────────────
攻撃仮説：
攻撃者が侵害端末から複数端末やサーバへ移動しようとしている。
必要ログ：
・ADログ
・Windowsイベントログ
・EDRログ
・RDPログ
・SMBアクセスログ
・WinRMログ
相関条件：
・1端末から複数端末への認証試行
・管理共有へのアクセス
・リモートサービス作成
・PsExec、WinRM、RDP等の利用
・認証成功後の不審プロセス実行
閾値例：
・10分間で10台以上へ認証試行
・通常端末から複数サーバへRDP接続
・リモートサービス作成イベント発生
・通常ユーザーが管理共有にアクセス
初期アクション：
・認証元端末の確認
・使用アカウントの確認
・接続先端末一覧の作成
強いアクション：
・認証元端末のEDR隔離
・該当アカウント停止
・同一ハッシュ、同一プロセスの横断検索
・接続先端末の調査
相関分析例：データ持ち出し
┌────────────────────────────────────────────
検知シナリオ：データ持ち出し
────────────────────────────────────────────
攻撃仮説：
攻撃者または内部不正者が、機密情報を外部に送信している。
必要ログ：
・DLPログ
・Proxyログ
・FWログ
・SaaS監査ログ
・ファイルサーバアクセスログ
・DB監査ログ
相関条件：
・大量ファイルアクセス
・大量ダウンロード
・大量アップロード
・圧縮ファイル作成
・外部共有リンク作成
・通常使わない外部サービスへの送信
閾値例：
・1時間で通常平均の5倍以上のファイルアクセス
・1時間で1GB以上の外部アップロード
・機密ラベル付きファイルを短時間に多数参照
・外部共有リンクを短時間に10件以上作成
初期アクション：
・送信先確認
・対象ファイル一覧保存
・ユーザー本人確認
・業務上の正当性確認
強いアクション：
・外部送信遮断
・外部共有リンク無効化
・端末隔離
・アカウント停止
・法務、コンプライアンス連携
検知時のアクション設計
SIEMのアラートは、対応アクションと紐付いていなければ意味がない。ルールごとに、最低限次を決める。
| 項目 | 決めること |
|---|---|
| 初動担当 | SOC、CSIRT、インフラ、業務部門の誰が見るか |
| 確認手順 | どのログを何分以内に確認するか |
| 判断基準 | どの条件ならインシデント化するか |
| 封じ込め | 端末隔離、ID停止、通信遮断の条件 |
| エスカレーション | 誰に、どの重大度で上げるか |
| 証跡保全 | どのログを保存し、誰が保全するか |
| 復旧条件 | 何を確認すれば復旧してよいか |
| 事後報告 | 誰に、何を、いつ報告するか |
アクションは段階化する。
| レベル | アクション例 |
|---|---|
| L1 監視 | アラート記録、追加監視 |
| L2 確認 | ログ確認、ユーザー確認、チケット照合 |
| L3 抑止 | 条件付きアクセス強化、一時ブロック |
| L4 封じ込め | 端末隔離、ID停止、通信遮断 |
| L5 危機対応 | CSIRT招集、経営報告、外部専門家連携 |
自動化してよいアクションと、人間判断を残すべきアクションは分ける。
┌────────────────────────────────────────────
自動化しやすいアクション
────────────────────────────────────────────
・チケット作成
・関連ログ収集
・脅威インテリジェンス照合
・既知悪性IPの一時ブロック
・EDR調査パッケージ取得
・同一IoCの横断検索
┌────────────────────────────────────────────
人間判断を残すべきアクション
────────────────────────────────────────────
・重要サーバのネットワーク遮断
・役員、管理者、業務責任者のID停止
・本番サービス停止
・外部報告
・顧客報告
・法務、広報、経営判断が絡む対応
隔離に必要なログ
侵害の早期検知後、封じ込めでは「何を止めるべきか」を判断する必要がある。
| 判断対象 | 必要なログ |
|---|---|
| どの端末を隔離するか | EDR、端末ログ、認証ログ、通信ログ |
| どのIDを止めるか | IdP、AD、SaaS、クラウドIAMログ |
| どの通信を遮断するか | FW、Proxy、DNS、EDR通信ログ |
| どの権限を剥奪するか | IAM、AD、PAM、SaaS管理者ログ |
| どの共有を止めるか | SaaS監査、ファイル共有、DLPログ |
隔離時に確認すべき問いは次のとおりである。
┌────────────────────────────────────────────
隔離判断で答えるべき問い
────────────────────────────────────────────
・侵害元端末はどれか
・侵害されたIDはどれか
・攻撃者はどの端末、サーバ、SaaSにアクセスしたか
・攻撃者が使った通信先はどこか
・悪用された権限は何か
・外部共有や外部送信は発生したか
・隔離すると業務影響がどの程度あるか
封じ込めは強いアクションであるため、誤ると業務影響が大きい。したがって、隔離判断には、EDR、認証ログ、通信ログ、資産重要度、業務影響を組み合わせる必要がある。
復旧に必要なログ
復旧では、「正常に戻した」だけでなく、「再侵入経路が閉じられている」ことを確認する必要がある。
| 判断対象 | 必要なログ |
|---|---|
| マルウェア除去確認 | EDR、AV、端末スキャン結果 |
| 不正設定の復旧 | クラウド監査、構成管理、IaC差分 |
| 権限復旧 | IAM、AD、PAM、承認ログ |
| データ復旧 | バックアップログ、DBログ、変更履歴 |
| 再侵入防止 | FW、WAF、IdP、脆弱性診断結果 |
| 業務再開判断 | 監視ログ、正常性確認、運用確認 |
復旧で確認すべき問いは次のとおりである。
┌────────────────────────────────────────────
復旧判断で答えるべき問い
────────────────────────────────────────────
・侵入経路は塞がれているか
・不正に作成されたID、鍵、トークンは無効化されたか
・不正に変更された設定は戻されたか
・侵害端末はクリーンな状態になったか
・バックアップは安全な時点のものか
・復旧後に同じIoCが再発していないか
・監視強化のルールは追加されたか
復旧に必要なログが不足していると、「安全に戻った」と説明できない。復旧は技術作業であると同時に、説明責任の問題でもある。
侵害後の調査、フォレンジックに必要なログ
侵害後の調査では、目的が変わる。予兆検知や早期検知では「今すぐ止める」ことが重要である。一方、事後調査では「何が起きたかを説明する」ことが重要になる。
| 調査観点 | 確認すること |
|---|---|
| 初期侵入 | どこから入られたか |
| 認証 | どのIDが使われたか |
| 権限 | どの権限が悪用されたか |
| 端末 | どの端末で何が実行されたか |
| 横展開 | どの範囲に広がったか |
| 永続化 | バックドア、サービス、タスクが残ったか |
| データアクセス | どのファイル、DB、SaaSに触れたか |
| 外部送信 | 何が外に出た可能性があるか |
| 改ざん | 設定、データ、ログが変えられたか |
| 復旧妥当性 | 再侵入経路が閉じられているか |
詳細フォレンジックに必要なログは次のとおりである。
| ログ・証跡 | 用途 |
|---|---|
| EDRタイムライン | プロセス、ファイル、通信、親子関係の追跡 |
| OSイベントログ | ログオン、サービス作成、タスク登録、権限変更 |
| 認証ログ | 誰が、いつ、どこからログインしたか |
| ADログ | Kerberos、LDAP、GPO、管理者操作の確認 |
| DNSログ | 不審ドメイン、C2、探索通信の確認 |
| Proxy/FWログ | 外部通信、アップロード、遮断状況の確認 |
| WAF/Webログ | 初期侵入、脆弱性攻撃、Webシェル痕跡の確認 |
| クラウド監査ログ | API実行、IAM変更、鍵作成、ログ設定変更の確認 |
| SaaS監査ログ | ファイル操作、外部共有、管理者操作の確認 |
| DB監査ログ | 大量参照、エクスポート、権限変更の確認 |
| メールログ | フィッシング起点、転送ルール、添付ファイル確認 |
| DLP/CASBログ | 持ち出し、外部共有、機密情報操作の確認 |
| バックアップログ | 復旧可能性、破壊・暗号化時点の確認 |
| 脆弱性情報 | 侵入経路として悪用可能だったかの確認 |
| 資産台帳 | 影響範囲、重要度、所有者の確認 |
フォレンジックで特に重要なのは、時系列の再現である。
┌────────────────────────────────────────────
事後調査で再現すべき時系列
────────────────────────────────────────────
1. 初期侵入
↓
2. 認証成功
↓
3. 権限昇格
↓
4. 内部探索
↓
5. 横展開
↓
6. 永続化
↓
7. 情報収集
↓
8. 外部送信
↓
9. 痕跡消去
↓
10. 検知、封じ込め、復旧
この時系列を再現するには、端末、認証、ネットワーク、クラウド、SaaS、メール、ファイル、DBのログが横断的に必要になる。
ログの完全性と時刻同期
事後調査では、ログが存在するだけでは不十分である。ログが改ざんされていないこと、時刻が揃っていること、調査可能な期間だけ保持されていることが必要である。
┌────────────────────────────────────────────
ログ完全性の設計ポイント
────────────────────────────────────────────
・重要ログは端末やサーバ内だけに残さない
・SIEMまたはログ基盤へ集中転送する
・ログ保存先の権限を限定する
・ログ削除、設定変更も監査対象にする
・改ざん検知、WORM、オブジェクトロック等を検討する
・時刻同期を徹底する
・ログ保持期間を調査要件に合わせる
イベントログと脅威検知のベストプラクティスでも、集中収集と相関、セキュアな保存、ログ完全性が重要な要素として示されている。56
検知ルール設計テンプレート
SIEMルールは、条件式だけで管理しない。次のようなテンプレートで、検知、判断、アクションを一体化して管理する。
┌────────────────────────────────────────────
SIEM検知ルール設計テンプレート
────────────────────────────────────────────
ルール名：
パスワードスプレー疑い
攻撃仮説：
攻撃者が複数ユーザーに対して低頻度のログイン試行を行っている。
対応する攻撃フェーズ：
初期アクセス、認証突破
必要ログ：
IdPログ、VPNログ、ADログ、MFAログ
相関条件：
同一送信元IPから短時間に複数ユーザーへログイン失敗
閾値：
10分間で20ユーザー以上
失敗後に成功がある場合は重大度をHighへ引き上げる
除外条件：
社内Proxy
監視サービス
既知の認証連携基盤
重大度：
Medium
成功ログインありの場合High
初動：
送信元IP確認
対象ユーザー一覧確認
成功ログイン有無確認
封じ込め：
送信元IPブロック
該当ユーザーのセッション失効
必要に応じてパスワードリセット
証跡保全：
対象ログインイベント
成功ログイン後の操作ログ
IP評価情報
チューニング観点：
誤検知率
業務影響
既知送信元の除外
このテンプレートのポイントは、検知条件だけでなく、初動、封じ込め、証跡保全、チューニング観点まで持たせることである。
閾値設計の考え方
SIEMの閾値に絶対解はない。重要なのは、固定値だけに頼らないことである。
| 閾値種類 | 内容 |
|---|---|
| 固定閾値 | 10分で20回失敗、1時間で1GB送信など |
| ベースライン閾値 | 通常平均の5倍、通常時間帯外など |
| 文脈閾値 | 重要資産、特権ID、退職予定者、脆弱端末など |
固定閾値だけでは誤検知が多い。ベースラインだけでは、新しい攻撃や低頻度攻撃を見逃す可能性がある。文脈閾値を加えることで、SOCが見るべきアラートを絞り込める。
┌────────────────────────────────────────────
文脈による重大度変更の例
────────────────────────────────────────────
通常ユーザーの深夜ログイン
→ Medium
特権IDの深夜ログイン
→ High
特権IDの深夜ログイン後にアクセスキー作成
→ Critical
特権IDの深夜ログイン後に監査ログ無効化
→ Critical、即時封じ込め候補
SOC運用で見るべき指標
SIEM/SOCの成熟度は、ログ量では測れない。見るべき指標は、検知、判断、対応、復旧に関するものである。
| 指標 | 意味 |
|---|---|
| MTTD | 検知までの時間 |
| MTTA | アラート確認開始までの時間 |
| MTTR | 復旧までの時間 |
| 誤検知率 | アラートのうち不要だった割合 |
| 見逃し率 | 後から判明した未検知インシデント |
| 自動化率 | 初動やログ収集の自動化割合 |
| 証跡充足率 | 調査に必要なログが揃っていた割合 |
| ルール鮮度 | 検知ルールが見直されているか |
| 対応完了率 | アラートが放置されていないか |
特に重要なのは、MTTDと証跡充足率である。早く検知しても、調査に必要なログがなければ対応できない。逆にログが揃っていても、検知が遅ければ被害は拡大する。
まとめ
SIEM設計では、ログを大量に集めることが目的ではない。目的は、攻撃仮説を検証し、必要なアクションにつなげることである。
┌────────────────────────────────────────────
本記事の要点
────────────────────────────────────────────
・ログは「保管」ではなく「判断」のために集める
・相関分析とは、複数ログから攻撃仮説を作ることである
・予兆検知では、認証、Web、DNS、Proxy、EDRが重要になる
・侵害の早期検知では、認証成功後の行動連鎖を見る
・隔離では、端末、ID、通信、権限、共有の判断ログが必要になる
・復旧では、安全に戻ったことを説明できるログが必要になる
・事後調査では、初期侵入から外部送信まで時系列で再現できる必要がある
・検知ルールには、閾値だけでなくアクションと証跡保全を紐付ける
・SIEMの価値はログ量ではなく、検知、判断、対応の速さで決まる
SOCにおけるSIEMの本質は、「何かが起きたかもしれない」を「何が起きた、だから何をする」に変換することである。
そのためには、ログ、相関分析、閾値、アクション、証跡保全を、ひとつの設計として扱う必要がある。