SC-200完全ガイド（前編）：Microsoft Security Operations Analyst試験対策2026 - 試験概要からセキュリティ運用環境・保護設定まで

はじめに

SC-200（Microsoft Security Operations Analyst）は、Microsoftのセキュリティ分野において中核となる認定資格です。クラウドおよびオンプレミス環境でのアクティブな攻撃への迅速な対応、脅威保護の改善提案、組織ポリシー違反の特定など、セキュリティ運用アナリストに求められる実践的なスキルを証明します。

本記事（前編）では、2026年1月22日更新版に対応した試験範囲のうち、**セクション1-2（セキュリティ運用環境の管理、保護と検出の構成）**を詳しく解説します。

後編はこちら: SC-200完全ガイド（後編）：インシデント対応・脅威管理編

1. SC-200試験とは - 資格の全体像

1.1 SC-200認定資格の位置づけ

SC-200は、Microsoftセキュリティ認定資格体系においてAssociate（中級）レベルに位置し、実務経験を持つセキュリティ運用アナリストを対象としています。

【Microsoftセキュリティ認定資格の階層】
Fundamentals: SC-900（セキュリティ基礎）
    ↓
Associate:    SC-200（セキュリティ運用アナリスト）← 本記事の対象
              SC-300（アイデンティティおよびアクセス管理者）
              SC-400（情報保護管理者）
    ↓
Expert:       SC-100（サイバーセキュリティアーキテクト）

1.2 取得するメリット

キャリア面でのメリット

• セキュリティ運用アナリストとしての専門スキルの証明
• SOC（Security Operations Center）業務への従事機会の拡大
• 給与・待遇面での優位性

実務面でのメリット

• Microsoft 365 Defender、Sentinel、Defender for Cloudの体系的理解
• KQL（Kusto Query Language）スキルの習得
• インシデント対応能力の向上
• 脅威ハンティング能力の強化

組織面でのメリット

• Microsoftパートナー企業の認定要件を満たす
• セキュリティチームの能力向上

1.3 前提知識と推奨される前提資格

推奨される前提資格

• SC-900: Microsoft Security, Compliance, and Identity Fundamentals
• AZ-900: Microsoft Azure Fundamentals

必要な実務経験

• セキュリティ運用業務の実務経験（6ヶ月以上推奨）
• Microsoft 365、Azure環境の基本的な理解
• ネットワーク、OS、クラウドの基礎知識

2. 試験の基本情報

2.1 試験形式

2.2 試験範囲と配点比率（2026年1月22日更新版）

最重要セクション: **セクション3（インシデント対応の管理）**が最も配点が高く、実践的なスキルが問われます。

2.3 2026年1月22日更新版の変更点

主な変更点

• Microsoft Security Copilotの追加（インシデント対応セクションに統合）
• Exposure Managementの追加（アセット管理に統合）
• 「管理」および「構成」セクションに軽微な更新

新機能への対応

• GA（一般提供）機能が中心
• 広く使用されているPreview機能も含まれる可能性

3. 試験範囲の詳細解説

3-1. セキュリティ運用環境の管理（20-25%）

このセクションでは、セキュリティ運用の基盤となる環境の構築・管理スキルが問われます。

3-1-1. Microsoft Defender XDR設定の構成

アラートと脆弱性通知ルールの構成

アラート通知の重要性

• SOCチームへの迅速な通知
• 優先度に応じたエスカレーション
• 通知チャネルの適切な設定

構成可能な通知チャネル

• メール通知
• Microsoft Teams統合
• SIEM（Sentinelなど）への転送
• Webhook経由での外部システム連携

実践的な設定例

【高優先度アラートの通知設定】
- 重大度: High以上
- 通知先: セキュリティチームのTeamsチャネル
- 頻度: リアルタイム
- エスカレーション: 30分以内に未対応の場合、マネージャーに通知

Microsoft Defender for Endpoint高度な機能の構成

エンドポイントルール設定

1. Attack Surface Reduction（ASR）ルール

• 実行可能コンテンツのブロック
• Office アプリケーションからの子プロセス作成のブロック
• スクリプトの難読化コードの実行ブロック
• PSExec/WMI経由のプロセス作成の制限

ASRルール展開のベストプラクティス

段階1: 監査モード（Audit Mode）で影響を評価
    ↓
段階2: パイロットグループで有効化
    ↓
段階3: 除外設定の最適化
    ↓
段階4: 全社展開

2. エンドポイント検出および応答（EDR）設定

• ブロックモード（EDR in block mode）の有効化
• 自動調査レベルの設定
• ファイル隔離の自動化

自動調査および対応（AIR）機能の管理

AIRの仕組み

Microsoft Defender XDRは、アラートをトリガーとして自動的に調査を開始し、影響範囲を特定、脅威を修復します。

自動化レベルの設定

AIR管理のポイント

• デバイスグループごとに自動化レベルを設定可能
• 誤検知の傾向を分析し、除外設定を最適化
• 定期的なレビューと調整

自動攻撃中断（Automatic Attack Disruption）の構成

自動攻撃中断とは

ランサムウェアやBEC（Business Email Compromise）などの進行中の攻撃を、AIが自動的に検出し、攻撃チェーンを中断する機能です。

動作の流れ

設定のベストプラクティス

• 本番環境への適用前にパイロット運用
• 誤検知時の迅速な復旧手順の整備
• 自動中断アクションのログ監視

3-1-2. アセットと環境の管理

デバイスグループ、権限、オートメーションレベルの構成

デバイスグループの設計戦略

デバイスグループは、組織の構造、セキュリティ要件、自動化ニーズに応じて設計します。

設計パターン例

【部門別パターン】
- Finance_Devices（自動化レベル: Semi）
- Engineering_Devices（自動化レベル: Full）
- Executive_Devices（自動化レベル: No automation）

【リスクレベル別パターン】
- High_Risk_Devices（インターネット公開サーバー等）
- Standard_Devices（一般ユーザーPC）
- Isolated_Devices（機密環境）

権限（RBAC）の設定

非管理デバイスの特定と対処

非管理デバイスのリスク

• セキュリティポリシーが適用されていない
• 脆弱性パッチが未適用
• 可視性の欠如

特定方法

1. Microsoft Defender for Endpointの検出機能
   • ネットワーク上の未登録デバイスを自動検出
2. Microsoft Entra ID（旧Azure AD）連携
   • 登録済みデバイスと照合
3. ネットワークスキャン
   • 定期的なネットワークスキャンで未管理デバイスを発見

対処方法

発見 → 棚卸し → 正当性確認 → オンボーディングまたは隔離

Defender for Cloudによる非保護リソースの検出

非保護リソースとは

• Defender for Cloudエージェントが未インストールのVM
• セキュリティポリシーが適用されていないリソース
• 脆弱性評価が未実施のリソース

検出方法

1. Defender for Cloudダッシュボード
   • 「Inventory」タブで保護状態を確認
2. セキュアスコア
   • 推奨事項から非保護リソースを特定
3. Azure Resource Graph クエリ
   • KQLで非保護リソースを抽出

実践的なKQLクエリ例

// Defender for Cloudエージェント未インストールのVMを検出
SecurityResources
| where type == "microsoft.security/assessments"
| where properties.displayName == "Log Analytics agent should be installed on virtual machines"
| where properties.status.code == "Unhealthy"
| project VMName = properties.resourceDetails.Id, Status = properties.status.code

Microsoft Defender Vulnerability Managementでのリスク端末の特定と修復

Defender Vulnerability Management（DVM）の役割

• 脆弱性の継続的な検出
• リスクベースの優先順位付け
• 修復推奨事項の提供

リスク端末の特定方法

1. エクスポージャースコア

• デバイスごとのリスクを数値化（0-1000）
• 未パッチの脆弱性、不適切な設定、アクティブな脅威を総合評価

2. セキュリティ推奨事項

• CVSSスコア、悪用の有無、影響範囲に基づいた優先順位

3. 脆弱性タイムライン

• CVE（Common Vulnerabilities and Exposures）の発見から修復までの追跡

修復プロセス

【4段階修復アプローチ】
段階1: 重大な脆弱性（CVSSスコア9.0以上、Exploit公開済み）
    ↓
段階2: 高リスクデバイス（インターネット公開、重要業務システム）
    ↓
段階3: 中程度の脆弱性
    ↓
段階4: 低優先度の脆弱性

修復オプション

• 自動パッチ適用: Windows Update、Intuneポリシー経由
• 構成変更: セキュリティベースラインの適用
• 緩和策: パッチ適用が困難な場合、ASRルールやファイアウォールで対処
• 例外承認: ビジネス上の理由で修復できない場合

Microsoft Defender XDRのExposure Managementによるリスク軽減

Exposure Managementとは

組織全体の攻撃対象領域（Attack Surface）を可視化し、リスクを優先順位付けして軽減する機能です（2026年1月更新版で追加）。

主要機能

1. 攻撃パスの可視化

• 攻撃者が侵入した場合の影響範囲をシミュレーション
• クリティカルアセットへの経路を特定

2. セキュリティイニシアチブ

• リスク軽減のためのアクションプランを自動生成
• 効果の高い対策を優先的に提示

3. セキュリティメトリクス

• エクスポージャーレベルの数値化
• 経時的な改善状況のトラッキング

活用シナリオ

例: ランサムウェア対策
1. Exposure Managementで「ランサムウェア攻撃パス」を分析
2. クリティカルな脆弱性（未パッチのSMB脆弱性など）を特定
3. セキュリティイニシアチブに従って修復
4. 攻撃対象領域の縮小を確認

3-1-3. Microsoft Sentinelワークスペースの設計と構成

Microsoft Sentinelワークスペースの計画

ワークスペース設計の選択肢

1. 単一ワークスペース設計

【メリット】
- 管理が簡素化
- クロステナント分析が容易
- コスト最適化

【適用シナリオ】
- 単一の組織
- 中小規模の環境

2. 複数ワークスペース設計

【メリット】
- データ主権の要件に対応（リージョン分離）
- 部門ごとのアクセス制御
- スケーラビリティ

【適用シナリオ】
- 多国籍企業
- 規制要件が厳しい業界（金融、医療など）
- MSSP（Managed Security Service Provider）

設計時の考慮事項

Microsoft Sentinelロールの構成

組み込みロール

カスタムロールの作成例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "Name": "Sentinel Analyst - Limited",
  "Description": "インシデント対応とハンティングのみ許可",
  "Actions": [
    "Microsoft.SecurityInsights/incidents/read",
    "Microsoft.SecurityInsights/incidents/write",
    "Microsoft.OperationalInsights/workspaces/query/read"
  ],
  "NotActions": [
    "Microsoft.SecurityInsights/alertRules/write"
  ]
}

Azure RBACロールの指定

Log Analytics Workspaceとの統合

Sentinelは、Log Analyticsワークスペース上���構築されるため、以下のAzure RBACロールも考慮が必要です。

リソースレベルとテーブルレベルのRBAC

• リソースレベル: ワークスペース全体へのアクセス制御
• テーブルレベル: 特定のログテーブル（例: SecurityEvent）のみアクセス許可

データストレージ、ログタイプ、ログ保持期間の設計と構成

データストレージ設計

1. ログ取り込み量の見積もり

【一般的な取り込み量の目安】
- ユーザー1人あたり: 1-2 GB/月（Microsoft 365ログ含む）
- サーバー1台あたり: 5-10 GB/月
- ネットワークデバイス1台あたり: 2-5 GB/月

2. ログタイプの選定

3. ログ保持期間の最適化

段階的保持戦略

【3層保持戦略】
Hot Tier（90日）: リアルタイム分析、高速クエリ
    ↓
Archive Tier（1-7年）: コンプライアンス対応、長期保存
    ↓
削除または外部ストレージへの移行

コスト最適化のポイント

• Basic Logs: 調査頻度の低いログを低コストで保存
• Archive: 長期保存が必要なログをアーカイブ化（取り込みコストの約15%）
• データ収集ルール（DCR）: 不要なログフィールドを除外

実践的な設定例

【中規模組織の保持期間設計】
- SecurityEvent: 90日（Hot） + 365日（Archive）
- Office365Activity: 180日（Hot） + 2年（Archive）
- AzureActivity: 90日（Hot） + 1年（Archive）
- CommonSecurityLog: 30日（Hot）

3-1-4. Microsoft Sentinelのデータソース取り込み

取り込むデータソースの特定

データソース選定の戦略

1. 必須データソース（優先度: 高）

• Microsoft 365 Defender（Endpoint、Office 365、Identity、Cloud Apps）
• Azure Active Directory（サインインログ、監査ログ）
• Azureアクティビティログ
• Windows Securityイベント（ドメインコントローラー、重要サーバー）

2. 推奨データソース（優先度: 中）

• ファイアウォール（Palo Alto、Cisco、Fortinet等）
• プロキシ/Webゲートウェイ
• VPNログ
• DNSログ

3. オプショナルデータソース（優先度: 低）

• アプリケーションログ
• データベース監査ログ
• IoTデバイスログ

データソース選定のチェックリスト

• MITRE ATT&CKカバレッジ（検出できる攻撃手法の範囲）
• コンプライアンス要件（GDPR、PCI-DSS等）
• コスト対効果（取り込み量vs検出価値）
• 運用負荷（ログの正規化、パーサー開発）

Content Hubソリューションの実装と使用

Content Hubとは

Content Hubは、Sentinelのマーケットプレイスであり、すぐに使えるソリューション（データコネクタ、分析ルール、ワークブック、プレイブック）をパッケージで提供します。

主要なContent Hubソリューション

実装手順

1. Sentinel > Content Hub を開く
2. ソリューションを検索（例: "Microsoft 365"）
3. 「Install」をクリック
4. データコネクタを有効化
5. 分析ルールを有効化（必要に応じてカスタマイズ）
6. ワークブックで可視化

ベストプラクティス

• 全てのルールを有効化せず、組織に適したものを選定
• カスタマイズ前にコピーを作成（アップデート時の上書き防止）
• 定期的にContent Hubの更新を確認

Azureリソース用Microsoftコネクタの構成

主要なMicrosoftコネクタ

1. Microsoft 365 Defender

接続先: Microsoft 365 Defender XDR
取り込むログ:
- インシデント
- アラート
- 高度なハンティングテーブル

構成手順

1. Sentinel > Data connectors > Microsoft 365 Defender
2. 「Connect incidents & alerts」を有効化
3. 高度なハンティングテーブルを選択
   - DeviceEvents
   - DeviceNetworkEvents
   - EmailEvents
   - CloudAppEvents
4. 「Apply Changes」

2. Azure Active Directory

取り込むログ:
- サインインログ（Sign-in logs）
- 監査ログ（Audit logs）
- リスク検出（Risk detections）
- プロビジョニングログ

3. Azure Activity

取り込むログ:
- サブスクリプションレベルのイベント
- リソースの作成/削除/変更
- ロールの割り当て

4. Microsoft Defender for Cloud

取り込むログ:
- セキュリティアラート
- セキュアスコア
- 推奨事項

Syslog およびCEF（Common Event Format）イベント収集の計画と構成

Syslog vs CEF

Syslog収集の構成

アーキテクチャ

Syslogデバイス → Log Analytics Agent（Linux VM） → Sentinel

構成手順

1
2
3
4
5
6
7
8
9

# 1. Linux VMにLog Analytics Agentをインストール
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh
sh onboard_agent.sh -w <WorkspaceID> -s <WorkspaceKey>

# 2. Syslog設定ファイルを編集
sudo vi /etc/rsyslog.d/95-omsagent.conf

# 3. Syslogデーモンを再起動
sudo systemctl restart rsyslog

Sentinel側の設定

1. Sentinel > Data connectors > Syslog
2. 「Open connector page」
3. 収集するFacility（auth, cron, daemonなど）を選択
4. ログレベルを選択（LOG_DEBUG, LOG_INFO等）

CEF収集の構成

CEF形式の例

CEF:0|Palo Alto Networks|PAN-OS|8.1.0|THREAT|url|3|
rt=Dec 18 2025 12:34:56 deviceExternalId=12345
src=192.168.1.100 dst=203.0.113.50 spt=54321 dpt=443

構成手順

1. Log Analytics AgentがインストールされたLinux VMを準備
2. CEFフォワーダースクリプトを実行
   python cef_installer.py <WorkspaceID> <WorkspaceKey>
3. ファイアウォール等からCEFログをForwarder（TCP 514）に送信
4. Sentinel > Data connectors > Common Event Format（CEF）で確認

CEFパーサーのカスタマイズ

// Palo Alto Networks用カスタムパーサー
CommonSecurityLog
| where DeviceVendor == "Palo Alto Networks"
| extend
    SourceIP = coalesce(SourceIP, DeviceCustomIPv6Address2),
    ThreatName = DeviceCustomString1,
    URLCategory = DeviceCustomString4
| project TimeGenerated, SourceIP, DestinationIP, ThreatName, URLCategory

Windows Event Forwarding（WEF）を使用したWindows Securityイベント収集の計画と構成

WEFとは

Windows Event Forwardingは、複数のWindowsデバイスからイベントログを中央のコレクターサーバーに転送する機能です。Sentinelへの取り込み前に、WEFで集約することでエージェント数を削減できます。

アーキテクチャ

Windowsデバイス（ソース） → WEFコレクター → Log Analytics Agent → Sentinel

WEF構成手順

1. コレクターサーバーの準備

1
2
3
4
5

# WinRMサービスの有効化
winrm quickconfig

# Event Collectorサービスの開始
wecutil qc

2. サブスクリプションの作成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<!-- subscription.xml -->
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Security Events</SubscriptionId>
  <Query>
    <QueryList>
      <Query Id="0">
        <Select Path="Security">
          *[System[(EventID=4624 or EventID=4625 or EventID=4672)]]
        </Select>
      </Query>
    </QueryList>
  </Query>
</Subscription>

1
2

# サブスクリプションの作成
wecutil cs subscription.xml

3. ソースデバイスの構成

1
2
3

# グループポリシーで設定
Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding
- Configure target Subscription Manager: Server=http://collector.domain.com:5985/wsman/SubscriptionManager/WEC

4. Sentinel連携

1. コレクターサーバーにLog Analytics Agentをインストール
2. Sentinel > Data connectors > Security Events via Legacy Agent
3. イベントフィルタリング:
   - All Events（全イベント）
   - Common（推奨イベントのみ）
   - Minimal（最小限）
   - None（カスタム）

推奨イベントID

【認証関連】
- 4624: ログオン成功
- 4625: ログオン失敗
- 4672: 特権ログオン

【アカウント管理】
- 4720: ユーザーアカウント作成
- 4722: ユーザーアカウント有効化
- 4726: ユーザーアカウント削除

【グループ管理】
- 4728: ドメイングローバルグループにメンバー追加
- 4732: ローカルグループにメンバー追加
- 4756: ユニバーサルグループにメンバー追加

【ポリシー変更】
- 4719: システム監査ポリシー変更
- 4739: ドメインポリシー変更

カスタムログテーブルの作成

カスタムログが必要なシナリオ

• サードパーティアプリケーションのログ
• カスタム開発アプリケーション
• 既存コネクタでサポートされていないデータソース

作成方法

1. Data Collection Rule（DCR）を使用した方法（推奨）

1
2
3
4
5
6
7

# サンプルログファイル（JSON形式）
{
  "TimeGenerated": "2026-01-01T12:00:00Z",
  "Application": "CustomApp",
  "EventLevel": "Error",
  "Message": "Database connection failed"
}

構成手順

1. Sentinel > Configuration > Data collection rules
2. 「Create」をクリック
3. ログソース設定:
   - ソースタイプ: Custom Text Logs
   - ファイルパターン: C:\Logs\CustomApp\*.log
4. 変換（Transformation）の設定（KQL）:
   source
   | extend TimeGenerated = todatetime(TimeGenerated)
   | project TimeGenerated, Application, EventLevel, Message
5. 宛先: Log Analyticsワークスペース、テーブル名: CustomApp_CL

2. Log Analytics HTTP Data Collector APIを使用した方法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

import requests
import json
import hashlib
import hmac
import base64
from datetime import datetime

workspace_id = 'your-workspace-id'
shared_key = 'your-shared-key'
log_type = 'CustomAppLog'

def build_signature(date, content_length, method, content_type, resource):
    x_headers = f'x-ms-date:{date}'
    string_to_hash = f'{method}\n{content_length}\n{content_type}\n{x_headers}\n{resource}'
    bytes_to_hash = bytes(string_to_hash, encoding="utf-8")
    decoded_key = base64.b64decode(shared_key)
    encoded_hash = base64.b64encode(hmac.new(decoded_key, bytes_to_hash, digestmod=hashlib.sha256).digest()).decode()
    return f'SharedKey {workspace_id}:{encoded_hash}'

def post_data(body):
    method = 'POST'
    content_type = 'application/json'
    resource = '/api/logs'
    rfc1123date = datetime.utcnow().strftime('%a, %d %b %Y %H:%M:%S GMT')
    content_length = len(body)
    signature = build_signature(rfc1123date, content_length, method, content_type, resource)
    uri = f'https://{workspace_id}.ods.opinsights.azure.com{resource}?api-version=2016-04-01'

    headers = {
        'content-type': content_type,
        'Authorization': signature,
        'Log-Type': log_type,
        'x-ms-date': rfc1123date
    }

    response = requests.post(uri, data=body, headers=headers)
    return response.status_code

# ログデータの送信
log_data = [{
    "Application": "CustomApp",
    "EventLevel": "Error",
    "Message": "Database connection failed"
}]

body = json.dumps(log_data)
post_data(body)

データ取り込みの監視と最適化

監視のポイント

1. 取り込み量の監視

// 日次の取り込み量（GB単位）
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize IngestedGB = sum(Quantity) / 1000 by bin(TimeGenerated, 1d), DataType
| render timechart

2. 取り込み遅延の監視

// データソース別の取り込み遅延
Heartbeat
| extend IngestionDelay = ingestion_time() - TimeGenerated
| summarize avg(IngestionDelay), max(IngestionDelay) by Computer
| where max_IngestionDelay > 5m  // 5分以上の遅延

3. コネクタのヘルスチェック

// データコネクタの最終受信時間
union SecurityEvent, Syslog, CommonSecurityLog, AzureActivity
| summarize LastReceived = max(TimeGenerated) by $table
| extend TimeSinceLastEvent = now() - LastReceived
| where TimeSinceLastEvent > 1h  // 1時間以上データ受信なし

最適化テクニック

1. 不要なログフィールドの除外

// Data Collection Ruleでの変換例
SecurityEvent
| where EventID in (4624, 4625, 4672)  // 必要なイベントIDのみ
| project TimeGenerated, Computer, Account, EventID, LogonType  // 必要なフィールドのみ

2. サンプリング

// 高頻度ログのサンプリング（10%のみ取り込み）
CommonSecurityLog
| where DeviceVendor == "Palo Alto Networks"
| where rand() < 0.1  // 10%サンプリング

3. Basic Logsの活用

用途: 調査頻度が低いログ（Syslog、Proxyログなど）
メリット: コスト削減（通常の約1/4）
制約: クエリ性能が低下、保持期間は8日まで

3-2. 保護と検出の構成（15-20%）

このセクションでは、脅威を未然に防ぎ、検出するための各種ポリシーとルールの構成方法が問われます。

3-2-1. Microsoft Defenderセキュリティテクノロジーでの保護の構成

Microsoft Defender for Cloud Appsポリシー

Defender for Cloud Appsの役割

• SaaS アプリケーションの可視化と制御
• シャドーIT検出
• データ漏洩防止
• 脅威保護

主要なポリシータイプ

1. アクセスポリシー

目的: リアルタイムでのアクセス制御
条件例:
- 特定の国からのアクセスをブロック
- 管理されていないデバイスからのアクセスを制限
- 高リスクなIPアドレスからのアクセスをブロック

実践的な設定例

ポリシー名: 管理外デバイスから��機密ファイルダウンロード防止
条件:
- アプリ: Office 365
- アクティビティタイプ: ファイルダウンロード
- デバイスタグ: Compliant ではない
- 機密ラベル: 機密、極秘
アクション: ブロック

2. アクティビティポリシー

目的: 異常なユーザーアクティビティの検出
条件例:
- 短時間での大量ファイルダウンロード
- 通常とは異なる場所からのアクセス
- 複数の失敗したログイン試行

3. ファイルポリシー

目的: 機密データの検出と保護
条件例:
- クレジットカード番号を含むファイルの共有検出
- 個人情報（PII）を含むファイルの外部共有検出

設定例

ポリシー名: クレジットカード情報の外部共有検出
条件:
- ファイルにクレジットカード番号が含まれる（DLP）
- 共有レベル: 外部
アクション:
- 管理者にアラート送信
- ファイル共有を取り消し
- ユーザーに通知

4. 異常検出ポリシー

組み込みポリシー（機械学習ベース）:
- 不可能な移動（Impossible travel）
- 通常とは異なる国からのアクティビティ
- ランサムウェアアクティビティ
- 複数回失敗したログイン

Microsoft Defender for Office 365ポリシー

Defender for Office 365の役割

• メール経由の脅威（フィッシング、マルウェア）からの保護
• 悪意のあるリンク・添付ファイルの検出
• 内部脅威の検出

主要なポリシー

1. Safe Attachments（安全な添付ファイル）

動作モード

実践的な設定例

ポリシー名: Executive Protection
適用対象: 役員グループ
設定:
- モード: Block
- 未知のマルウェア応答を有効化: オン
- リダイレクト: セキュリティチームのメールボックスへ

2. Safe Links（安全なリンク）

保護の仕組み

メール受信時 → URLの書き換え → クリック時にリアルタイムスキャン → 安全なら元URLへリダイレクト

設定項目

- メール内のURLを書き換える: オン
- Teams内のURLを書き換える: オン
- クリック追跡: オン（ユーザーがクリックしたURLを記録）
- ユーザーが元のURLをクリックできないようにする: オン（推奨）

3. Anti-phishing（フィッシング対策）

保護レイヤー

レイヤー1: スプーフィングインテリジェンス
    ↓
レイヤー2: 偽装保護（Impersonation protection）
    ↓
レイヤー3: 機械学習ベースの検出
    ↓
レイヤー4: 高度なフィッシング検出

偽装保護の設定

保護対象ユーザー:
- CEO: [email protected]
- CFO: [email protected]
- CTO: [email protected]

保護対象ドメイン:
- contoso.com
- contoso-partners.com

アクション:
- 偽装ユーザー検出時: 隔離
- 偽装ドメイン検出時: 隔離
- メールボックスインテリジェンス: オン

4. Anti-spam（スパム対策）

スパムフィルタリングレベル

アクション設定

検出タイプ別アクション:
- スパム: 迷惑メールフォルダーに移動
- 信頼度の高いスパム: 隔離
- フィッシング: 隔離
- 信頼度の高いフィッシング: 隔離
- マルウェア: 隔離

Microsoft Defender for Endpointセキュリティポリシー（ASRルール含む）

Attack Surface Reduction（ASR）ルール詳細

ASRルールは、一般的な攻撃手法をブロックすることで、攻撃対象領域を縮小します。

主要なASRルール

ASRルール展開戦略

段階的展開の4ステップ

【フェーズ1: 監査モード（2週間）】
目的: 影響範囲の把握
設定: 全ASRルールを監査モードで有効化
監視: イベントログ、レポートで誤検知を確認

【フェーズ2: パイロット展開（2週間）】
目的: 実環境での検証
対象: ITチーム、セキュリティチーム
設定: 低リスクルールをブロックモードに変更
除外: 必要に応じて除外設定を追加

【フェーズ3: 段階的展開（1ヶ月）】
目的: 部門ごとの展開
対象: 一般ユーザー（部門単位）
設定: 全ASRルールをブロックモードに
サポート: ヘルプデスク体制の強化

【フェーズ4: 全社展開】
目的: 全ユーザーへの適用
設定: 全ASRルールをブロックモード
最適化: 除外設定の継続的な見直し

除外設定の例

1
2
3
4
5

# ファイルパス除外
Add-MpPreference -AttackSurfaceReductionOnlyExclusions "C:\TrustedApp\app.exe"

# ルール単位の除外（特定ルールを無効化）
Set-MpPreference -AttackSurfaceReductionRules_Ids <RuleID> -AttackSurfaceReductionRules_Actions Disabled

その他のEndpointセキュリティポリシー

1. Endpoint Detection and Response（EDR）

EDR in Block Mode:
- Defender以外のアンチウイルスを使用している場合でも、EDRによる検出・ブロックを有効化
- リアルタイム保護が無効でも機能

2. Next-generation protection（次世代保護）

- クラウド配信の保護: オン
- ブロックレベル: High（誤検知増加の可能性あり）
- PUA（望ましくない可能性のあるアプリケーション）保護: オン

3. Web保護

- Web脅威保護: オン
- カスタムインジケーター（IoC）: 悪意のあるURL/IPをブロック

Microsoft Defender for Cloudクラウドワークロード保護

Defender for Cloudの保護対象

主要な保護設定

1. Just-In-Time（JIT） VM Access

動作の仕組み

通常状態: 管理ポート（RDP 3389、SSH 22）は閉鎖
    ↓
アクセス要求: ユーザーがAzure Portalから一時アクセスを要求
    ↓
承認後: 指定時間（例: 3時間）だけNSGでポートを開放
    ↓
期限切れ: 自動的にポートを再度閉鎖

設定例

JITポリシー:
- ポート 22（SSH）: 最大3時間、特定のIPアドレスのみ許可
- ポート 3389（RDP）: 最大3時間、承認必須

2. ファイル整合性監視（FIM）

監視対象

• レジストリキーの変更
• システムファイルの変更
• 構成ファイルの変更

設定例

Windows監視パス:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- C:\Windows\System32\drivers\etc\hosts
- C:\inetpub\wwwroot\web.config

Linux監視パス:
- /etc/passwd
- /etc/ssh/sshd_config
- /var/www/html/

3. 適応型アプリケーション制御（AAC）

動作の仕組み

学習期間（2週間）: 正常なアプリケーション実行パターンを学習
    ↓
推奨事項: 許可すべきアプリケーションリストを生成
    ↓
強制モード: リスト外のアプリケーション実行をブロック

3-2-2. Microsoft Defender XDRでの検出の構成

カスタム検出ルールの構成と管理

カスタム検出ルールとは

組み込みの検出ルールでカバーされない、組織固有の脅威を検出するためのKQLベースのルールです。

ルール作成の基本構造

// 例: 夜間の機密ファイルアクセス検出
CloudAppEvents
| where Timestamp > ago(1h)
| where ActionType == "FileAccessed"
| where FileName has_any ("confidential", "secret", "restricted")
| extend Hour = hourofday(Timestamp)
| where Hour >= 22 or Hour <= 6  // 22時～6時
| where AccountObjectId != "exclude-service-account-id"
| summarize FileAccessCount = count() by AccountDisplayName, FileName, bin(Timestamp, 5m)
| where FileAccessCount > 10  // 5分間に10回以上

ルール設定項目

KQLクエリのベストプラクティス

// ❌ 悪い例: パフォーマンスが悪い
DeviceEvents
| where Timestamp > ago(1h)
| where FileName contains "powershell"  // contains は遅い
| where DeviceName contains "DESKTOP"   // 曖昧すぎる条件

// ✅ 良い例: 最適化済み
DeviceEvents
| where Timestamp > ago(1h)
| where FileName in~ ("powershell.exe", "pwsh.exe")  // in~ は高速
| where DeviceName startswith "DESKTOP-"
| where ProcessCommandLine has_any ("EncodedCommand", "bypass", "hidden")
| summarize count() by DeviceName, AccountName
| where count_ > 5  // 閾値設定

アラートの管理（チューニング、抑止、相関）

アラートチューニングの目的

• 誤検知（False Positive）の削減
• アラート疲労（Alert Fatigue）の防止
• SOCチームの効率化

1. アラート抑止（Suppression）

抑止ルールの例

シナリオ: バックアップソフトウェアによる大量ファイルアクセスが
         「ランサムウェアアクティビティ」として誤検知される

抑止ルール:
- 条件1: プロセス名が "BackupAgent.exe"
- 条件2: アラートタイトルが "Ransomware activity detected"
- アクション: アラートを自動的に解決（Resolved）にする

設定場所

Microsoft 365 Defender > Settings > Endpoints > Rules > Alert suppression rules

2. アラート相関

インシデントへの自動グルーピング

Microsoft 365 Defenderは、以下の基準で関連アラートを自動的に1つのインシデントにグループ化します。

相関基準:
- 同一ユーザーアカウント
- 同一デバイス
- 同一IPアドレス
- 時間的近接性（24時間以内）
- 攻撃キャンペーンの類似性（AIベース）

カスタム相関ルール

// 例: フィッシングメール受信後のマルウェア実行を1つのインシデントに
EmailEvents
| where ThreatTypes has "Phish"
| join kind=inner (
    DeviceEvents
    | where ActionType == "ProcessCreated"
    | where ProcessCommandLine has_any ("powershell", "cmd")
) on $left.RecipientEmailAddress == $right.AccountUpn
| where (DeviceEvents_Timestamp - EmailEvents_Timestamp) between (0min .. 60min)

3. アラートチューニングのプロセス

【週次チューニングサイクル】
月曜: 前週の誤検知アラートをレビュー
    ↓
火曜: 抑止ルールを作成・更新
    ↓
水曜: 検出ルールのクエリを最適化
    ↓
木曜: 新規脅威に対する検出ルール追加
    ↓
金曜: チューニング結果の測定（検出率、誤検知率）

KPI（重要業績評価指標）

• 検出率（Detection Rate）: 実際の攻撃を検出した割合
• 誤検知率（False Positive Rate）: 誤検知の割合（目標: 5%以下）
• MTTD（Mean Time To Detect）: 攻撃検出までの平均時間
• MTTR（Mean Time To Respond）: 対応完了までの平均時間

Microsoft Defender XDRでの詐欺ルールの構成

詐欺（Fraud）ルールとは

ビジネスメール詐欺（BEC）、請求書詐欺、CEO詐欺などの金銭的被害を狙った攻撃を検出するルールです。

主要な詐欺パターン

1. CEO詐欺（Whaling）

パターン:
- 経営層を装った送信者
- 緊急の送金依頼
- 外部メールアドレスだが表示名は内部の役員名

検出条件:
- 送信者表示名が "CEO" or "CFO" を含む
- 送信者ドメインが組織ドメインではない
- メール本文に "urgent", "wire transfer", "confidential" を含む

2. 請求書詐欺

パターン:
- 正規の取引先を装った偽の請求書
- 振込先口座の変更依頼

検出条件:
- 添付ファイル名が "invoice", "payment" を含む
- 送信者ドメインが類似ドメイン（typosquatting）
  例: micros0ft.com（oを0に置換）

カスタム詐欺検出ルールの例

// BEC検出: 役員を装った外部メール
EmailEvents
| where Timestamp > ago(1h)
| where EmailDirection == "Inbound"
| extend SenderDisplayNameLower = tolower(SenderDisplayName)
| where SenderDisplayNameLower has_any ("ceo", "cfo", "president", "director")
| where SenderFromDomain != "contoso.com"  // 組織ドメイン
| where Subject has_any ("urgent", "wire transfer", "payment", "invoice")
| project Timestamp, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject, DeliveryAction

Defender for Office 365での詐欺対策ポリシー

Anti-phishing policy:
- ユーザー偽装保護:
  保護対象: CEO, CFO, 財務部門マネージャー
  アクション: 隔離 + セキュリティチームに通知

- ドメイン偽装保護:
  保護対象: contoso.com, contoso.co.jp
  アクション: 隔離

- スプーフィングインテリジェンス:
  - 組織ドメインのなりすまし検出
  - 許可リスト: 信頼できる外部メール中継サーバー

これで前編（セクション1-2）が完成しました。後編では、最も配点の高い「インシデント対応の管理」と「セキュリティ脅威の管理」を解説します。