ゼロトラストセキュリティでは、ネットワーク全体の可視化と継続的な監視が不可欠です。しかし、現代の組織では多種多様なシステムやアプリケーションから膨大なセキュリティイベントが生成され、人手だけで対処することは現実的ではありません。SIEM(Security Information and Event Management)とSOAR(Security Orchestration, Automation and Response)は、このような課題に対応するための中核技術として位置づけられています。
本記事では、SIEM/SOARについて以下の内容を解説します。
- SIEMの基本概念とログ統合・相関分析の仕組み
- SOARの役割と自動対応の実現方法
- SIEMとSOARの連携によるセキュリティ運用の最適化
- Microsoft SentinelとSplunkでの実装アプローチ
- 効果的なプレイブック設計とユースケース
この記事を読むことで、セキュリティイベントの統合監視と自動対応の仕組みを理解し、ゼロトラスト環境における効率的なセキュリティ運用を設計できるようになります。
前提知識
本記事を理解するために、以下の知識があることを前提としています。
- ゼロトラストの基本原則を把握している
- 継続的検証の考え方を理解している
- セキュリティログの基本概念を知っている
ゼロトラストの基本原則についてはゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを、継続的検証についてはゼロトラストにおける継続的検証 - リスクベース認証と行動分析を先に読むことをお勧めします。
期待される学習成果
本記事を読み終えると、以下のことができるようになります。
- SIEMの役割とログ収集・相関分析の仕組みを説明できる
- SOARの自動化機能とオーケストレーションの原理を理解できる
- SIEMとSOARの連携による効果的なセキュリティ運用を設計できる
- Microsoft Sentinelの自動化ルールとプレイブックの基本構成を把握できる
- 代表的なユースケースに基づいた自動対応シナリオを設計できる
SIEMとは
SIEM(Security Information and Event Management)は、組織全体のセキュリティ関連データを一元的に収集・分析し、脅威の検出とインシデント対応を支援するプラットフォームです。
SIEMの主要機能
SIEMは以下の機能を統合的に提供します。
flowchart TB
subgraph sources["データソース"]
fw["ファイアウォール"]
ids["IDS/IPS"]
endpoint["エンドポイント"]
cloud["クラウドサービス"]
app["アプリケーション"]
identity["ID管理システム"]
end
subgraph siem["SIEMプラットフォーム"]
collect["ログ収集・正規化"]
store["データ保存・インデックス化"]
correlate["相関分析"]
detect["脅威検出"]
alert["アラート生成"]
visualize["可視化・ダッシュボード"]
end
subgraph output["出力"]
incident["インシデント"]
report["レポート"]
notify["通知"]
end
sources --> collect
collect --> store
store --> correlate
correlate --> detect
detect --> alert
alert --> output
store --> visualize| 機能 | 説明 | ゼロトラストにおける役割 |
|---|---|---|
| ログ収集 | 複数のソースからログデータを一元的に収集 | 全体の可視化と監査証跡の確保 |
| 正規化 | 異なるフォーマットのログを統一形式に変換 | データソース間の相関分析を可能に |
| 相関分析 | 複数のイベントを関連付けて攻撃パターンを特定 | 複合的な脅威の検出 |
| 脅威検出 | ルールベースおよび機械学習による異常検知 | 継続的検証の実現 |
| アラート | 重要度に応じた通知とエスカレーション | 迅速な対応の起点 |
| 可視化 | ダッシュボードとレポートによる状況把握 | セキュリティ態勢の継続的な評価 |
ログ収集と正規化
SIEMの基盤となるのは、多様なソースからのログ収集と正規化です。
flowchart LR
subgraph raw["生ログ"]
syslog["Syslog形式<br/>プライオリティ、ファシリティ"]
cef["CEF形式<br/>Common Event Format"]
json["JSON形式<br/>構造化データ"]
custom["カスタム形式<br/>独自フォーマット"]
end
subgraph process["処理"]
parse["パース処理"]
normalize["正規化"]
enrich["エンリッチメント"]
end
subgraph unified["統一スキーマ"]
asim["ASIM<br/>Advanced Security<br/>Information Model"]
end
raw --> parse
parse --> normalize
normalize --> enrich
enrich --> unifiedMicrosoft Sentinelでは、ASIM(Advanced Security Information Model)を使用してログデータを正規化します。これにより、異なるベンダーのファイアウォールやエンドポイント製品からのログを統一的に分析できます。
主要なデータコネクタの種類は以下のとおりです。
| コネクタ種類 | 対象 | 特徴 |
|---|---|---|
| ネイティブコネクタ | Microsoft 365、Azure AD、Defender製品 | リアルタイム統合、追加設定不要 |
| Syslogコネクタ | ネットワーク機器、Linuxサーバー | 標準プロトコル、広範なサポート |
| CEFコネクタ | セキュリティ製品全般 | 構造化フォーマット、相互運用性 |
| REST APIコネクタ | SaaSアプリケーション | カスタム統合、柔軟性 |
| カスタムコネクタ | 独自システム | Azure Functionsで実装 |
相関分析と脅威検出
SIEMの真価は、個別のログイベントを相関分析によって意味のある脅威情報に変換する能力にあります。
flowchart TB
subgraph events["個別イベント"]
e1["認証失敗<br/>User: admin<br/>IP: 192.168.1.100"]
e2["認証失敗<br/>User: admin<br/>IP: 192.168.1.100"]
e3["認証成功<br/>User: admin<br/>IP: 192.168.1.100"]
e4["特権操作<br/>User: admin<br/>Action: Add user"]
end
subgraph correlation["相関分析"]
rule["分析ルール<br/>5分以内に3回以上の<br/>認証失敗後の成功"]
end
subgraph result["検出結果"]
incident["インシデント<br/>ブルートフォース攻撃<br/>の可能性"]
end
events --> correlation
correlation --> result分析ルールには以下の種類があります。
| ルール種類 | 説明 | 使用例 |
|---|---|---|
| スケジュールルール | 定期的にクエリを実行し、条件に一致するイベントを検出 | 異常なログイン試行の検出 |
| NRT(Near Real-Time)ルール | ほぼリアルタイムでイベントを検出 | 重大な脅威の即時検出 |
| Microsoft Security ルール | Microsoft製品からのアラートを自動的にインシデント化 | Defender for Endpointアラートの統合 |
| 異常検出ルール | 機械学習によるベースラインからの逸脱検出 | 通常と異なるユーザー行動の検出 |
| Fusion ルール | AIによる複数アラートの自動相関 | 高度な攻撃キャンペーンの検出 |
SOARとは
SOAR(Security Orchestration, Automation and Response)は、セキュリティ運用の自動化とオーケストレーションを実現するプラットフォームです。SIEMが「検出」に重点を置くのに対し、SOARは「対応」の自動化に焦点を当てています。
SOARの3つの柱
SOARは以下の3つの要素で構成されています。
flowchart TB
subgraph soar["SOAR"]
direction TB
subgraph orchestration["オーケストレーション<br/>Orchestration"]
o1["ツール間連携"]
o2["ワークフロー統合"]
o3["データ共有"]
end
subgraph automation["自動化<br/>Automation"]
a1["定型タスクの自動実行"]
a2["プレイブック実行"]
a3["エンリッチメント"]
end
subgraph response["対応<br/>Response"]
r1["インシデント対応"]
r2["封じ込め"]
r3["復旧"]
end
end
orchestration --> automation
automation --> response| 要素 | 説明 | 具体例 |
|---|---|---|
| オーケストレーション | 異なるセキュリティツールやシステムを連携させ、統合的なワークフローを実現 | SIEM、EDR、ファイアウォール、チケットシステムの連携 |
| 自動化 | 定型的なセキュリティタスクを人手を介さずに実行 | IOCのブロック、ユーザーアカウントの無効化、脅威情報の照会 |
| 対応 | インシデント発生時の調査、封じ込め、復旧プロセスの実行 | マルウェア感染端末の隔離、不正アクセスの遮断 |
SOARによる自動化のメリット
SOARを導入することで、セキュリティ運用に以下のメリットがもたらされます。
| メリット | 説明 | 定量的効果(業界平均) |
|---|---|---|
| 対応時間の短縮 | 人手による対応を自動化し、MTTR(平均対応時間)を削減 | 対応時間を最大90%削減 |
| アナリストの負担軽減 | 定型作業から解放し、高度な分析に集中可能に | アラート対応工数を60%削減 |
| 対応の一貫性 | 標準化されたプレイブックにより、対応品質を均一化 | ヒューマンエラーを80%削減 |
| スケーラビリティ | アラート量の増加にも自動化で対応 | 処理能力を10倍以上に拡張可能 |
| 24時間365日対応 | 自動化により、時間帯に関係なく即座に対応 | 夜間・休日の対応遅延を解消 |
SIEMとSOARの連携
SIEMとSOARを連携させることで、検出から対応までの一連のプロセスを自動化できます。
統合アーキテクチャ
flowchart TB
subgraph datasources["データソース"]
direction LR
ds1["クラウド"]
ds2["オンプレミス"]
ds3["エンドポイント"]
ds4["ネットワーク"]
end
subgraph siem["SIEM"]
collect["ログ収集"]
analyze["分析・検出"]
incident["インシデント生成"]
end
subgraph soar["SOAR"]
rule["自動化ルール"]
playbook["プレイブック"]
action["アクション実行"]
end
subgraph targets["対応先"]
direction LR
t1["エンドポイント"]
t2["ファイアウォール"]
t3["ID管理"]
t4["チケット"]
end
datasources --> siem
siem --> soar
soar --> targets
incident -->|"トリガー"| rule
rule -->|"条件一致"| playbook
playbook -->|"実行"| actionMicrosoft Sentinelにおける自動化
Microsoft Sentinelは、SIEMとSOARの機能を統合したクラウドネイティブなセキュリティプラットフォームです。自動化は「自動化ルール」と「プレイブック」の2つの仕組みで実現されます。
自動化ルールの役割
自動化ルールは、インシデントやアラートに対する自動処理を定義します。
flowchart LR
subgraph trigger["トリガー"]
t1["インシデント作成時"]
t2["インシデント更新時"]
t3["アラート作成時"]
end
subgraph conditions["条件"]
c1["分析ルール名"]
c2["重大度"]
c3["エンティティ"]
c4["タグ"]
end
subgraph actions["アクション"]
a1["担当者割り当て"]
a2["重大度変更"]
a3["タグ追加"]
a4["ステータス変更"]
a5["プレイブック実行"]
end
trigger --> conditions
conditions --> actions自動化ルールで実行できる主なアクションは以下のとおりです。
| アクション | 説明 | ユースケース |
|---|---|---|
| 担当者割り当て | インシデントを特定のアナリストまたはグループに割り当て | スキルベースのルーティング |
| 重大度変更 | インシデントの重大度を動的に調整 | ビジネスコンテキストに基づく優先度付け |
| タグ追加 | 分類やフィルタリング用のタグを付与 | インシデントのカテゴリ分け |
| ステータス変更 | インシデントをクローズまたは進行中に設定 | 誤検知の自動クローズ |
| タスク追加 | 調査・対応のためのタスクリストを作成 | 標準的な調査手順の適用 |
| プレイブック実行 | Azure Logic Appsベースの自動化ワークフローを起動 | 高度な自動対応 |
プレイブックの構成
プレイブックは、Azure Logic Appsをベースとした自動化ワークフローです。
flowchart TB
subgraph playbook["プレイブック構成"]
trigger["トリガー<br/>Microsoft Sentinelコネクタ"]
subgraph logic["ロジック"]
condition["条件分岐"]
loop["繰り返し処理"]
parallel["並列処理"]
end
subgraph connectors["コネクタ"]
c1["Microsoft Defender"]
c2["Microsoft Entra ID"]
c3["ServiceNow"]
c4["Slack/Teams"]
c5["カスタムAPI"]
end
action["アクション実行"]
end
trigger --> logic
logic --> connectors
connectors --> actionプレイブックで利用できる主要なコネクタは以下のとおりです。
| カテゴリ | コネクタ例 | 実行可能なアクション |
|---|---|---|
| エンドポイント | Microsoft Defender for Endpoint | デバイス隔離、フルスキャン実行、ファイル取得 |
| ID管理 | Microsoft Entra ID | ユーザー無効化、パスワードリセット強制、MFA要求 |
| ネットワーク | Azure Firewall、Palo Alto | IPアドレスブロック、ルール追加 |
| ITSM | ServiceNow、Jira | チケット作成、更新、エスカレーション |
| コミュニケーション | Teams、Slack、メール | 通知送信、承認要求 |
| 脅威インテリジェンス | VirusTotal、AbuseIPDB | IOCの評価、脅威情報照会 |
Splunk SOARの特徴
Splunk SOARは、300以上のサードパーティツールと連携し、2,800以上の自動化アクションをサポートする業界標準のSOARプラットフォームです。
Splunk SOARのアーキテクチャ
flowchart TB
subgraph splunk["Splunk統合プラットフォーム"]
subgraph es["Enterprise Security(SIEM)"]
correlation["相関ルール"]
notable["Notable Events"]
end
subgraph soar["SOAR"]
playbooks["プレイブック"]
apps["アプリ統合"]
cases["ケース管理"]
end
subgraph ueba["UEBA"]
behavior["行動分析"]
anomaly["異常検知"]
end
end
es --> soar
ueba --> es
soar --> appsSplunk SOARの主要機能は以下のとおりです。
| 機能 | 説明 | 特徴 |
|---|---|---|
| Visual Playbook Editor | GUIベースのプレイブック作成ツール | コーディング不要で複雑なワークフローを構築可能 |
| アプリ統合 | 300以上のセキュリティツールとの連携 | プラグアンドプレイ方式で即座に統合 |
| ケース管理 | インシデント調査のためのコラボレーション基盤 | タスク管理、エビデンス収集、レポート生成 |
| MITRE ATT&CK連携 | 攻撃手法に基づいたプレイブック | 標準化された対応手順 |
| カスタムアプリ開発 | Python SDKによるカスタム統合 | 独自システムとの連携 |
実践的なユースケース
SIEM/SOARの効果を最大化するための代表的なユースケースを紹介します。
ユースケース1: フィッシングメール対応の自動化
flowchart TB
subgraph trigger["検出"]
report["ユーザーからの報告<br/>または<br/>メールセキュリティアラート"]
end
subgraph analysis["分析"]
extract["URL/添付ファイル抽出"]
sandbox["サンドボックス分析"]
ti["脅威インテリジェンス照会"]
end
subgraph decision["判定"]
check{{"悪意あり?"}}
end
subgraph response_malicious["悪意ありの場合"]
block["URLブロック"]
quarantine["メール隔離"]
search["同一メール検索"]
notify["ユーザー通知"]
ticket["インシデントチケット作成"]
end
subgraph response_clean["正常の場合"]
close["自動クローズ"]
feedback["ユーザーへ結果通知"]
end
trigger --> analysis
analysis --> decision
check -->|"Yes"| response_malicious
check -->|"No"| response_cleanこのプレイブックの効果は以下のとおりです。
| 指標 | 手動対応 | 自動化後 | 改善率 |
|---|---|---|---|
| 平均対応時間 | 30分 | 3分 | 90%削減 |
| アナリスト作業時間 | 15分/件 | 2分/件 | 87%削減 |
| 対応漏れ | 発生する可能性あり | ほぼゼロ | 大幅改善 |
ユースケース2: ブルートフォース攻撃への対応
flowchart TB
subgraph detect["検出"]
alert["認証失敗アラート<br/>閾値: 5分以内に10回以上"]
end
subgraph enrich["エンリッチメント"]
geoip["GeoIP情報取得"]
history["過去の認証履歴確認"]
user_info["ユーザー情報取得"]
end
subgraph assess["リスク評価"]
check{{"リスクレベル"}}
end
subgraph high_risk["高リスク"]
block_ip["送信元IPブロック"]
disable["アカウント一時無効化"]
mfa["MFA強制"]
escalate["セキュリティチームに即時通知"]
end
subgraph medium_risk["中リスク"]
watch["監視強化"]
notify_user["ユーザーへ確認連絡"]
end
subgraph low_risk["低リスク"]
log["ログ記録のみ"]
end
detect --> enrich
enrich --> assess
check -->|"高"| high_risk
check -->|"中"| medium_risk
check -->|"低"| low_riskユースケース3: マルウェア感染端末の隔離
flowchart TB
subgraph detect["検出"]
edr_alert["EDRアラート<br/>マルウェア検出"]
end
subgraph validate["検証"]
hash_check["ファイルハッシュ確認"]
vt["VirusTotal照会"]
ti["脅威インテリジェンス照会"]
end
subgraph confirm["確認"]
malware{{"マルウェア確定?"}}
end
subgraph contain["封じ込め"]
isolate["デバイス隔離"]
collect["フォレンジックデータ収集"]
scan["フルスキャン実行"]
end
subgraph notify["通知"]
soc["SOCチーム通知"]
user["ユーザー通知"]
ticket["インシデントチケット作成"]
end
subgraph remediate["修復"]
clean["マルウェア駆除"]
restore["ネットワーク復帰"]
monitor["監視継続"]
end
detect --> validate
validate --> confirm
malware -->|"Yes"| contain
contain --> notify
notify --> remediate
malware -->|"No"| close["誤検知としてクローズ"]効果的なプレイブック設計のポイント
プレイブックを効果的に設計するためのベストプラクティスを紹介します。
設計原則
| 原則 | 説明 | 実践方法 |
|---|---|---|
| 段階的自動化 | 最初から完全自動化を目指さず、段階的に自動化範囲を拡大 | まず通知から始め、徐々に対応アクションを追加 |
| 人間による承認 | 重大な影響を与えるアクションは承認プロセスを組み込む | アカウント無効化前にTeamsで承認要求 |
| 冪等性の確保 | 同じプレイブックが複数回実行されても問題ないよう設計 | 実行済みチェックの実装 |
| エラーハンドリング | 外部システムの障害に備えたエラー処理 | タイムアウト設定、リトライロジック |
| ログ記録 | すべてのアクションを監査可能な形で記録 | 実行結果をインシデントにコメント追加 |
成熟度モデル
SOAR導入の成熟度は以下の段階で評価できます。
flowchart LR
subgraph levels["SOAR成熟度モデル"]
l1["レベル1<br/>通知自動化"]
l2["レベル2<br/>エンリッチメント"]
l3["レベル3<br/>部分的対応"]
l4["レベル4<br/>完全自動対応"]
l5["レベル5<br/>予防的対応"]
end
l1 --> l2
l2 --> l3
l3 --> l4
l4 --> l5| レベル | 内容 | 自動化率 | 人的介入 |
|---|---|---|---|
| 1: 通知自動化 | アラートの自動通知、チケット作成 | 10-20% | ほぼすべて |
| 2: エンリッチメント | 脅威情報の自動収集、コンテキスト付与 | 30-40% | 分析・判断 |
| 3: 部分的対応 | 低リスクの脅威に対する自動対応 | 50-60% | 承認・監視 |
| 4: 完全自動対応 | ほとんどのインシデントを自動処理 | 70-80% | 例外対応のみ |
| 5: 予防的対応 | 脅威の予測と事前対策の自動実行 | 80-90% | 戦略的意思決定 |
Microsoft Sentinelでの実装例
Microsoft Sentinelで自動化を実装する具体的な手順を紹介します。
自動化ルールの作成
自動化ルールは、Defender PortalまたはAzure Portalから作成できます。以下は、高重大度インシデントを自動的にセキュリティチームに割り当てる例です。
flowchart TB
subgraph rule["自動化ルール設定"]
name["名前: High-Severity-Auto-Assign"]
subgraph trigger["トリガー"]
incident_created["インシデント作成時"]
end
subgraph conditions["条件"]
severity["重大度 = High"]
end
subgraph actions["アクション"]
assign["担当者: SecurityTeam"]
tag["タグ: High-Priority"]
playbook["プレイブック: Notify-Security-Team"]
end
end
trigger --> conditions
conditions --> actionsプレイブックの実装
Azure Logic Appsでプレイブックを作成する基本的な構成は以下のとおりです。
flowchart TB
subgraph playbook["Notify-Security-Team プレイブック"]
trigger["トリガー<br/>Microsoft Sentinel<br/>インシデントトリガー"]
get_incident["インシデント詳細取得"]
subgraph entities["エンティティ処理"]
get_accounts["アカウント取得"]
get_hosts["ホスト取得"]
get_ips["IP取得"]
end
compose["通知メッセージ作成"]
teams["Teams通知送信<br/>アダプティブカード"]
email["メール送信<br/>詳細レポート"]
comment["インシデントに<br/>コメント追加"]
end
trigger --> get_incident
get_incident --> entities
entities --> compose
compose --> teams
compose --> email
teams --> comment
email --> comment承認フローの組み込み
重要なアクションには承認フローを組み込むことをお勧めします。
flowchart TB
subgraph approval["承認フロー"]
trigger["アカウント無効化要求"]
approval_request["Teams承認要求送信"]
wait["承認待ち<br/>タイムアウト: 30分"]
check{{"承認結果"}}
approved["アカウント無効化実行"]
rejected["操作キャンセル<br/>理由記録"]
timeout["エスカレーション<br/>上位者に通知"]
end
trigger --> approval_request
approval_request --> wait
wait --> check
check -->|"承認"| approved
check -->|"却下"| rejected
check -->|"タイムアウト"| timeout運用上の考慮事項
SIEM/SOARを効果的に運用するための考慮事項を紹介します。
アラート疲れへの対策
| 問題 | 原因 | 対策 |
|---|---|---|
| 大量の誤検知 | 検出ルールの閾値が適切でない | ベースラインの調整、ホワイトリストの活用 |
| 重複アラート | 同一インシデントが複数のルールで検出 | 相関ルールの整理、インシデントのマージ |
| 低優先度アラートの氾濫 | 重大度設定が適切でない | リスクベースの重大度自動調整 |
| コンテキスト不足 | エンリッチメントが不十分 | 自動エンリッチメントの追加 |
KPIとメトリクス
SIEM/SOARの効果を測定するための主要なKPIは以下のとおりです。
| KPI | 定義 | 目標値(参考) |
|---|---|---|
| MTTD(Mean Time to Detect) | 脅威発生から検出までの平均時間 | 1時間以内 |
| MTTR(Mean Time to Respond) | 検出から対応完了までの平均時間 | 4時間以内 |
| 自動化率 | 自動処理されたインシデントの割合 | 70%以上 |
| 誤検知率 | 誤検知として閉じられたアラートの割合 | 10%以下 |
| エスカレーション率 | 上位チームにエスカレーションされた割合 | 5%以下 |
まとめ
本記事では、SIEM/SOARによるセキュリティ監視と自動対応について解説しました。
主要なポイントを振り返ります。
- SIEMの役割: ログの一元収集、正規化、相関分析により、組織全体の脅威を可視化し検出する
- SOARの価値: オーケストレーション、自動化、対応の3つの柱により、セキュリティ運用を効率化する
- 連携の効果: SIEMとSOARを連携させることで、検出から対応までのプロセスを自動化できる
- 段階的導入: 通知自動化から始め、徐々に対応アクションを追加する段階的アプローチが効果的
- 継続的改善: KPIを定義し、定期的に測定・改善するサイクルを確立する
ゼロトラストセキュリティにおいて、SIEM/SOARは「可視化と分析」「自動化とオーケストレーション」という2つの柱を支える基盤技術です。適切に導入・運用することで、セキュリティチームの負担を軽減しながら、より迅速かつ一貫性のある脅威対応を実現できます。
次のステップとして、ゼロトラストにおけるデータ保護 - 分類・暗号化・アクセス制御で、データ中心のセキュリティアプローチについて学ぶことをお勧めします。