1.SOC概要
1.1 SOCとは
24時間365日でログやネットワーク通信を継続的に監視・分析し、脅威を検出・初動対応する
1.2 CSIRTとの違い
| 項目 | SOC (Security Operation Center) | CSIRT (Computer Security Incident Response Team) |
|---|---|---|
| 役割 | 「検知」と「分析」 | 「対応」と「調整」 |
| 主な活動 | 24時間365日のログ監視、アラート分析。 | インシデント発生時の指示、社内外への連絡、法的対応。 |
| 位置づけ | 技術的な実行部隊。監視カメラのモニター室に近い。 | 消防本部や指揮所に近い。現場から報告を受け判断を下す。 |
| イメージ |  |
 |
1.3 情シスが監視業務もすればいいのでは？
SOCを導入するということは、「監視モニターの前に、24時間座って画面を見続け、怪しいものが映った時だけ情シスに『ヤバいですよ！』と電話をしてくれる専属のチームを作ること。
1.4 SOCの必要性（背景）
(1)サイバー攻撃の高度化・巧妙化
(2)必要性
インシデント発生時のビジネスインパクト（業務停止、情報漏洩、信用失墜）
1.4 SOC導入の目的
・被害の「未然防止」と、侵入を前提とした「早期検知・対応」
・統合管理（一元管理）、一元窓口として機能すること
・専門チームを分けることで、監視に特化した業務に専念できる
| 比較項目 | SOCを導入しない場合（個別ツール＋情シス運用） | SOCを導入する場合（専任のSOCチームによる監視） |
|---|---|---|
| 監視の時間帯 | ・情シスの業務時間内のみの確認になりがち ・夜間・休日が「サイバー攻撃の死角」になる |
・24時間365日の常時監視体制が作れる ・休日深夜のランサムウェア攻撃などにも即応できる |
| アラートの処理 | ・誤検知を含め、大量の通知が情シスに直接届く ・「また誤検知か」と慣れてしまい、重大な通知を見落とす |
・SOCが膨大なアラートから「誤検知（ノイズ）」を除外 ・情シスには「本当に対処が必要な危険なもの」だけが届く |
| 攻撃の検知力 | ・EDRはEDRの画面、FWはFWの画面を見る「点の監視」 ・別々のツールにまたがる巧妙な攻撃に気づけない |
・各ツールのログを組み合わせた「線の監視（相関分析）」 ・単体では見逃すような「一連の不審な動き」をあぶり出す |
| 本業への影響 | ・日々のITサポートや開発業務が、アラート対応で圧迫される ・担当者が疲弊してしまう |
・監視・分析の泥臭い作業をSOCに任せられる ・情シスは「上がってきた脅威をどう防ぐか」の判断に集中できる |
1.5 SOC不要説
(1)情シスで十分
| Q1. 情報システム部がSOCの機能も実施すればいいのではないか？ |
A. 監視に特化した専門チーム（SOC）を分けることに価値はあります。
❶24時間365日の監視体制
情報システム部による兼務では、どうしても業務時間内（平日日中）の確認になりがちです。よって、たとえ土日と夜間だけであっても、外部委託を含め、、24時間365日の常時監視体制を作る意義があります。
❷監視業務はそこそこ大変
セキュリティ機器からは日々大量のアラート（誤検知含む）が飛びます。外部委託を含め、SOCが正しく機能していないと、適切な運用ができません。「本当に対処が必要な危険なもの」だけをフィルターする（＝見極める）役割が必要です。
❸情シスの「本業」を守る
情報システム部は、日々のITサポートやインフラ運用、開発業務を抱えています。そこに監視・分析の泥臭い作業が加わると、担当者が疲弊してしまいます。役割を分けることで、SOCは「監視」に専念します。
(2)SIEMよりオリジナルのツールの方が情報が多い
| Q2. 優秀な専用コンソール（CrowdStrikeやFortiGate等）があるのに、無理にSIEMにログを集約すると可視性が落ちる。「結局元コンソールを見た方が早いし正確」なのではないか？ |
（※画像は生成AIで作成）
専用ツールが優れていても、SOC（SIEM基盤）が必要な理由は以下の通りです。
❶相関分析
EDRは端末の動き、FWは境界の通信というように、各ツールは自らの守備範囲（点）しか見えません。別々のツールにまたがる巧妙な攻撃（例：正規のIDでログインし、FWをすり抜け、端末で標準ツールを悪用する等）は、単体のツールでは「異常なし」と見逃されることがあります。SIEMはこれらを組み合わせた「一連の不審な動き」をあぶり出すために必要です。
❷アラートの起点として機能
・SIEMはあくまで複数ツールをまたいだ統合管理、異常を知らせるトリガー（警報器）」として活用する。
・その後に詳細なコンテキストの把握やプロセスの追跡は、SOCアナリストが直接CrowdStrikeやFortiGateの使いやすいコンソールへ見に行く
❸一元窓口としての機能
複数のセキュリティツールがバラバラに警報を鳴らす状態ではなく、SOCという「一元窓口」が統合的に状況を把握する。また、ログを集約するためのSIEMが必要。
1.6 責任分界点
セキュリティインシデントが起こったら、すべてをSOCがするわけではない。
対策はCSIRTである。また、セキュリティシステム（EDRやFW）などは情報システム部になるであろうが、監視設定部分はSOCになるだろう。また、ログ解析をこえたフォレンジック解析は外部や別の専門チームになるだろう。
| 組織 | 役割・責任分界点 |
|---|---|
| SOC | ・セキュリティシステム（EDRやFWなど）の監視設定の運用 ・アラートの常時監視と一次的なログ解析 |
| CSIRT | ・セキュリティインシデント発生時の具体的な対策の実行 ・インシデント対応全体の指揮と判断 |
| 情報システム部 | ・EDRやFWなどのセキュリティシステム自体の導入とインフラ管理 ・通常時のITシステム運用 |
| 外部機関・専門チーム | ・SOCの日常的なログ解析の範囲を超える、高度なフォレンジック解析（デジタル鑑識・詳細調査） |
2.SOCの基本業務
2.1 SOCのコア業務フロー
ログ収集・監視 → 検知 → トリアージ（優先順位付け） → 詳細分析 → 報告（エスカレーション）分析について
2.2 監視対象機器
| 監視レイヤー | 監視対象の代表例（機器・システム・ソフトウェア） | 主な役割と取得できるログのイメージ |
|---|---|---|
| 1. ネットワーク・境界層 | FW / NGFW (ファイアウォール) | ネットワークの関所として通信を制御・監視する。 |
| UTM (統合脅威管理) | 通信の許可 / 遮断ログ | |
| IPS / IDS (侵入防御 / 検知) | 不正な通信パターンの検知ログ | |
| VPNゲートウェイ | 社内へのVPN接続（アクセス元IP等）のログ | |
| 2. エンドポイント層 | EDR / EPP (PCやサーバーの監視・保護ソフト) | 端末内での不審な挙動やマルウェア感染を監視する。 |
| Windows / Linux OS | 不審なプロセスの起動 / 停止ログ | |
| MDM (モバイルデバイス管理) | 重要なファイルの変更 / 削除ログ マルウェアの検知 / 隔離ログ |
|
| 3. アイデンティティ・認証層 | Active Directory (社内認証基盤) | ユーザーのアカウントや権限、「誰がアクセスしたか」を管理する。 |
| IdP / IAM (クラウド認証基盤：Entra ID, Oktaなど) | システムへのログイン成功 / 失敗ログ アカウントのロックアウト履歴 管理者権限の付与 / 変更ログ |
|
| 4. Web・クラウドアクセス層 | SWG (セキュアWebゲートウェイ / プロキシ) | 社外Webサイトへのアクセスや、公開Webサイトへの攻撃を監視する。 |
| CASB (クラウド利用監視) | 社員のWebアクセス履歴 / ブロックログ | |
| WAF (Webアプリ用ファイアウォール) | 未許可クラウドサービスへの通信ログ Webサイトへのサイバー攻撃（SQLインジェクション等）の検知ログ |
|
| 5. アプリケーション層 | 自社開発Webアプリケーション | アプリケーション固有の動作や、ユーザーの業務操作を記録する。 |
| 社内業務システム (人事・財務・顧客管理など) | アプリケーションエラーログ (システム異常や攻撃によるエラー) | |
| SaaS型業務アプリ (Microsoft 365, Salesforceなど) | 監査ログ (誰がどのデータを閲覧・DLしたか) アプリ内認証ログ (OS認証とは別のアプリ単体のログイン履歴) |
2.3 SOCにおけるログ取り扱い
(1)送信方針（SIEMへ何を送るか）
【共通の考え方】
・「生データ（テレメトリ）」と「意味のあるデータ（イベント/アラート）」を分離する
・SIEMは魔法の箱ではなく、従量課金（データ量）でコストが跳ね上がる高価な分析エンジンです。そのため、何でもかんでもSIEMに送る「全部入り」は絶対に避けます。
▼送らないもの（発生元に留める）
通信の全セッション記録や、PC内の全プロセス起動履歴などの「生データ」。これらは各製品の管理コンソール（クラウド等）に一定期間保存しておき、必要な時だけ見に行きます。
▼送るもの（SIEMに集約する）
各機器が「怪しい」と判定した「セキュリティアラート」、誰が設定を変更したかという「監査ログ（Audit）」、そしてシステム間の相関分析のキーとなる「認証ログ（誰がログインしたか）」に絞り込みます。
(2)蓄積方針（SIEMでどれくらいの期間保存するか）
【共通の考え方】
「即応性のための短期保存（Hot）」と「調査・監査のための長期保存（Cold）」を使い分ける
攻撃者がシステムに侵入してから発覚するまでの潜伏期間（滞留時間：Dwell Time）は、数週間〜数ヶ月に及ぶことがあります。
▼短期〜中期（例：1〜3ヶ月）
高速に検索・分析できる高価なストレージ（Hot層）に保存し、日々のインシデント対応や脅威ハンティングに利用します。
▼長期（例：半年〜1年以上）
検索速度は遅いが安価なストレージ（Cold層/アーカイブ）に保存します。これは、数ヶ月前の侵入経路を特定する「フォレンジック調査」や、法的な「コンプライアンス要件（監査証拠）」を満たすために必要です。
(3)対処方針（人間がどこから介入するか）
【共通の考え方】
「アラート疲労」を防ぎ、リスクベースでトリアージ（優先順位付け）する
送られてきたログ（アラート）すべてに人間が対応しようとすると、オオカミ少年のように警告を無視するようになり、SOCが崩壊します（アラート疲労）。
▼即時対応（Critical / High）
「内部から外部の悪意あるサイトへの通信」「マルウェアの実行」など、実害が発生している可能性が極めて高いもの。深夜でも担当者を叩き起こして対応（ネットワーク遮断など）する基準を明確にします。
▼調査・監視（Medium）
単体では誤検知の可能性もあるが、不審な兆候を示すもの。他のログと組み合わせて相関分析を行います。
▼無視・自動化（Low / Info）
「外部からの攻撃をFWでブロックした」など、防御が成功しているもの。これらは人間が見る必要はなく、週次・月次の「傾向分析レポート」の材料としてのみ使います。
(4)検知方針（SIEMで何を相関分析させるか）
・単一の機器で分かること（例：EDRでのウイルス検知）は、その機器単体でブロックさせます。
・SIEM側では、「VPNで海外からログインした（FW/認証ログ）」直後に、「社内の機密ファイルサーバーに大量アクセスした（ファイルサーバーログ）」といった、「複数のシステムのログを掛け合わせないと気付けないシナリオ（ユースケース）」を定義し、検知ルールとして設定します。
※ただし、相関分析のルールを作るのは、実際には簡単ではない。
(5)チューニング（改善）方針
・SOCは構築して終わりではなく、環境の変化に合わせて育てる必要があります。
・(1)の対処方針で「誤検知（False Positive）」や「過検知（業務影響のない過剰なアラート）」が多発した場合、そのまま放置せず、(1)の送信設定を見直したり、(4)の検知ルールのしきい値（例：1分間に5回失敗したらアラート、を10回に変更するなど）を調整（チューニング）して、ノイズを減らすプロセス（フィードバックループ）を必ず設けます。
2.4 具体的な機器ごとの方針
| 機器・サービス | ①SIEMへ送信するログ | ②SIEMでの蓄積方針 | ③SOCでの対処（トリアージ）方針 |
|---|---|---|---|
| CrowdStrike (EDR) | 検知アラート（Detections） | 送信されたアラート・監査ログはすべて長期間蓄積（事後調査・相関分析用） | High / Critical：即時対応（隔離等） |
| 監査ログ（設定変更等） | Medium / Low：定期的な脅威ハンティングや、他ログとの相関分析の材料として利用 | ||
| Entra ID (認証基盤) | サインインログ（成功 / 失敗） | コンプライアンス・フォレンジックの観点から、送信されたログはすべて長期間（半年〜1年等）蓄積 | リスクイベント（High）：即時対応（パスワードリセット等） |
| 監査ログ（権限変更等） | 特権の付与・異常な失敗の連続：調査 | ||
| リスクイベント（Identity Protection等） | 通常の失敗：無視（ユーザーのミス） | ||
| UTM (IPS) (ネットワーク) | IPSシグネチャ検知ログ | 傾向分析やインシデント調査の起点となるため、送信されたセキュリティログはすべて蓄積 | 内部から外部への通信（C2通信等）の検知：即時対応 |
| 脅威インテリジェンスブロックログ | 検知したがブロックに失敗（Allow）した通信：即時対応 | ||
| （※全通信の許可 / 拒否ログは要件次第） | 外部からの攻撃のブロック（Drop）：原則無視（インターネット上のノイズ） |
3.詳細な方針
3.1 Entra ID ログ監視・対応方針
(1) SIEMへのログ転送条件（Entra ID ➡ SIEM）
すべてのログをSIEM（統合ログ管理システム）に送るとノイズやストレージコストが増大するため、重要度やリスクレベルに応じて以下の通りフィルタリングして転送します。
| 対象ログ / アラート | SIEMへの転送条件 | 具体例・備考 |
|---|---|---|
| サインインログ等 | 重要度「Medium（中）」以上 | 通常とは異なる場所・端末からのサインイン、短時間での複数回失敗など。 |
| 監査ログ（Audit Logs） | 重要な構成変更に関するログ（すべて） | 特権ロール（全体管理者など）の割り当て、MFA（多要素認証）設定の変更、条件付きアクセスポリシーの変更など。 |
| Entra ID Protection等 | リスクレベル「High（高）」および「Critical（緊急相当）」 | 漏洩した資格情報（クレデンシャル）の使用、匿名IPアドレスからのアクセスに伴う高リスク判定など。 |
(2) SOCでの監視・対応方針
SIEMに集約されたログに対して、SOCオペレーターがどのようにトリアージ（優先順位付け）し、インシデントとして対処するかのアクション基準を定めます。
▼基本方針
SIEMへ送信されたログすべてに反応するのではなく、その中から**「対処が必要な重要アラート」を定義して抽出**し、調査・対応を行う方針とします。
▼「対処が必要な重要アラート」の定義（アクション対象）
(1)の転送条件のうち、具体的には以下を即時対応が必要なインシデントとして扱います。
| 1 | Entra ID Protection等 | リスクレベル「High（高） / Critical（緊急）」のアラート |
| 2 | 監査ログ | 「特権ロール（全体管理者など）の割り当て」や「MFA設定の変更」などの重大な構成変更 |
▼アラート以外のログの扱い（Mediumログ等）
サインインログ等の「Medium（中）」はSIEMへ送信・蓄積しますが、単発では即時対応のアラートとはみなしません（原則として静観）。これらは、上記のアラートが発生した際の前後関係の調査や、他の不審な挙動と掛け合わせる相関分析のための「証拠ログ」として活用します。
▼SOCによる主な対応（調査・アクション）例
抽出された重要アラートに対する、具体的な初期対応のガイドラインです。
| 検知シナリオ | 発生条件・概要 | SOCの対応（アクション） |
|---|---|---|
| 特権ロールの不正割り当て疑い | 全体管理者が予期せず付与された場合 | 申請の有無や本人確認を実施。 |
| MFAの回避・不正登録 | 許可されていないMFAデバイスが登録された場合 | アカウントの無効化やセッション切断を実施。 |
| Highリスクのサインイン成功 | Entra ID ProtectionでHigh判定されたにも関わらずアクセスが成功している場合 | 即座にパスワードリセットやネットワーク隔離を検討。 |
4.SOCを支えるテクノロジー
4.1 SIEM
・SIEM（統合ログ管理システム）
・なぜSIEMが必要か
4.2 EDR / XDRによるエンドポイント・統合監視
★整理が必要
侵入後の挙動把握
4.3 脅威インテリジェンス（CTI）の活用
最新の攻撃手法やIPアドレス情報の自動照合
5.SOCの構築モデルとリソース（導入計画）
自社に最適なSOCの形態を検討するための比較・評価軸を提示します。
5.1 内製か、外部委託か
SOCの運用モデル比較
・自社運用（プライベートSOC）：メリット・デメリット
・外部委託（MSSP / マネージドSOC）：メリット・デメリット
・ハイブリッド型（夜間休日のみ委託、一次切り分けのみ委託など）
5.2 SOCに必要な人材要件とスキルセット
Tier1/Tier2/Tier3アナリストの分類
| 組織・階層 | 主な役割・作業内容 | 求められる主なスキル・要件 |
|---|---|---|
| SOC Tier 1 (機器アラート起点) |
・SIEM/EDR等の常時監視と一次トリアージ ・手順書に従い誤検知を除外 ・真の脅威をTier 2へエスカレーション |
・基礎的なネットワーク/OS知識 ・セキュリティ機器の基本操作 ・手順書の正確かつ迅速な遂行力 |
| SOC Tier 1 (利用者申告起点) |
・従業員からの不審メールや異常報告の受付 ・IT障害かセキュリティインシデントかの一次判定 ・初動指示(NW切断等)とTier 2/CSIRTへの連携 |
・状況を正確に引き出すヒアリング力 ・ITトラブルとインシデントを見極めるITリテラシー |
| SOC Tier 2 (詳細分析・実動) |
・ログの相関分析による攻撃全容・被害範囲の特定 ・権限内での初期対応・封じ込め(端末隔離など) ・CSIRTへの詳細なインシデントレポート提出 |
・高度なログ解析・パケット解析能力 ・サイバー攻撃手法(MITRE ATT&CK等)の理解 |
| SOC Tier 3 (脅威探索・高度解析) |
・未知の脅威を自ら探し出すスレットハンティング ・マルウェア解析や高度なフォレンジック ・新たな脅威に対する検知ルールの作成・チューニング |
・マルウェアの静的/動的解析スキル ・メモリ/ディスクの高度な解析技術 ・最新の脅威動向(CTI)に関する深い知見 |
| CSIRT | ・インシデント対応全体の指揮・判断(司令塔) ・具体的な対策の実行と、経営陣への報告・対外対応 |
・セキュリティ全般の深い知見 ・経営判断、社内外との調整力、危機管理能力 |
| 情報システム部 | ・セキュリティシステム(EDR/FW等)自体の導入・インフラ管理 ・通常時のITシステム運用(※監視設定の運用はSOCが担当) |
・自社ITインフラ・ネットワークの構築・運用スキル |
| 外部専門チーム | ・SOCの日常業務を超える高度なフォレンジック解析 ・法的証拠保全(デジタル鑑識)や専門的な詳細調査 |
・専門的なデジタル鑑識技術 ・法的妥当性を持った調査報告手法 |
5.3 アラート疲弊（アラートファティーグ）対策（自動化の必要性）
6. 今後の展望（SOCの高度化）
中長期的なロードマップを示し、将来を見据えた投資であることをアピールします。
