セキュリティ運用ツールとは、セキュリティオペレーションセンター（SOC）が、エンドポイント、ネットワーク、ID、クラウドにわたってテレメトリを収集し、脅威を検知し、インシデントを調査し、対応を行うために使用する技術のことです。SOCツールのリストはどれも、おおむね同じカテゴリーを網羅しています。しかし、結果を左右する2つの質問――「ツールは導入後に実際に攻撃を検知できるか」、そして「攻撃者がツールを無効化しようとした場合でも、ツールは機能し続けるか」――に答えているものはほとんどありません。現在、これら2つの質問については、裏付けとなるデータが存在します。 最近の検知に関する調査では、ツールが記録する内容と、実際にアラートを発する内容との間に根強い乖離があることが示されています。また、2026年4月には、MITRE ATT&CK 、「ツールの改ざん」が独立した戦術として追加されました。本ガイドでは、主要なカテゴリー、実際に効果のある手法に関する証拠、そして攻撃者との接触に耐えうるセキュリティ運用ツールの選び方を解説します。
セキュリティ運用ツールとは、SOCがエンドポイント、ネットワーク、ID、クラウドにわたってテレメトリデータを収集し、脅威を検知し、アラートを調査し、インシデントに対応するために使用する統合された技術のことです。SOCでは、これらのツールを人材やプロセスと組み合わせ、監視、トリアージ、調査、対応を一つのシステムとして運用しています。これらの業務を単一のツールだけでカバーすることはできません。
まず、用語の定義を明確にしておきます。このガイドにおいて、「SOC」とはセキュリティオペレーションセンター（Security Operations Center）を指します。コンプライアンス監査のフレームワークである「SOC 2」や、検索結果で同じ名称がヒットするものの、本稿とは無関係な産業用製品ライン「SOC Tools」のことではありません。ここでは、「SOCツール」、「SecOpsツール」、および「セキュリティオペレーションセンターツール」はいずれも、セキュリティチームが運用するソフトウェアを指します。
主なカテゴリーとしては、セキュリティ情報・イベント管理（SIEM）、エンドポイントおよび拡張型検知・対応（EDR/XDR）、ネットワーク検知・対応（NDR）、セキュリティオーケストレーション・自動化・対応（SOAR）、脅威インテリジェンスプラットフォーム（TIP）に加え、脆弱性管理、ID分析、クラウド検知などが挙げられます。これらはすべて、信頼性の高い脅威の検知と対応という単一の成果を実現するために存在しています。 しかし、ツールだけではSOCは成り立ちません。ツールはSOCを構成する要素の一つに過ぎないのです。セキュリティ運用というより広範な実践には、それを取り巻く人材やプロセスも含まれますが、このページでは技術的な側面を中心に解説します。
この視点が重要なのは、ほとんどの企業にはツールが不足しているのではなく、そのツールが実際に検知できるという証拠が欠けているからです。以下のカテゴリ分類は最低限必要なものであり、インターネット上のほぼすべてのガイドにこれらが掲載されています。しかし、それらのほとんどが省略しているのは、実務担当者の満足度データ、改ざん耐性の問題、そして測定された検知効果といった証拠です。これら3つの要素は、このガイドの残りの部分を通じて一貫して取り上げられます。 このガイドの最終的な目標は実用的なものです。つまり、チームが実際に必要とするカテゴリは何か、各カテゴリの運用コストはいくらか、そして既に導入しているツールが実際に検知できるかどうかを検証する方法を把握することです。
以下の分類は、ベンダーのマーケティングではなく、実務担当者の評価に基づいて順位付けされています。Elasticがスポンサーを務めた「SANS 2025 SOC調査」——この点は知っておく価値があります——において、EDR/XDRは、調査の4段階満足度評価で3以上を獲得した唯一のツールカテゴリーであったのに対し、AI/ML主導のツールは最下位にランクインしました。この順位付けは、多くのベンダーが作成するリスト記事とは異なっていますが、それこそが、この分類が有用である理由なのです。
表：SANS 2025の満足度パターンに基づき、EDR/XDRを最初に、AI/ML主導の分析を最後に並べた、セキュリティ運用ツールの主要カテゴリー。
エンドポイント検出・対応（EDR）は、エンドポイントのプロセスや動作を監視し、ホスト上で脅威を封じ込めます。拡張検出・対応（XDR）は、そのモデルをさらなるテレメトリ情報源にまで拡大したものです。 SANS 2025によると、実務者から最も高く評価されているカテゴリーです。欠点：エージェントを実行できないもの（管理対象外のデバイス、IoT、アプライアンスなど）は、その監視範囲外となります。改ざんのリスク：EDRエージェントは、次のセクションで取り上げる「EDRキラー」ツールの主な標的となります。
ネットワーク検出・対応（NDR）は、ネットワークトラフィックから攻撃者の行動を検知し、アウトオブバンドで動作します。その重要な位置づけは、単なる位置付けではなく、実績に基づいています。NDRは、SIEMやEDRと並んでSOCの可視性の三本柱を構成しており、エンドポイントエージェントが停止してもネットワークテレメトリは継続して収集されます。欠点としては、単独ではホストを隔離できないこと、またセンサーの配置や暗号化されたトラフィックへの対応にはエンジニアによる配慮が必要となる点が挙げられます。改ざんのリスク：侵害されたホストから情報を遮断するのが最も困難なカテゴリです。
SIEMは、環境全体のログを集約し、相関分析を行い、アラートを発行します。これはSOCの一般的な中核となるシステムですが、「一般的」であり、「必須」というわけではありません。 チームによっては、SIEMを使用せずに、代わりにXDRや「検出アズコード」を採用したデータレイクを中心に据えてSOCを運用することも可能であり、実際にそうしているケースも時折見られます。欠点としては、データ取り込みのコストがデータ量に比例して増加すること、および相関ルールの継続的な調整が必要なことが挙げられます。改ざんのリスクとしては、上流でのログ改ざんによりSIEMは完全に機能しなくなり、その管理プレーン自体が攻撃の標的となる可能性があります。
SOARは、スタック全体にわたるトリアージ、情報補完、および対応アクションを調整するプレイブックを実行します。欠点：入力されたデータの質に応じて自動化の質も決まるという点です。本ガイドの後半で紹介する査読済みの研究結果によると、速度が向上しても精度が低下する可能性があることが分かっています。自動化戦略の詳細については、「SOCの自動化」を参照してください。改ざんのリスク：SOARプラットフォームが侵害されると、攻撃者に自社の対応体制を握られてしまうことになります。
脅威インテリジェンスツールおよびプラットフォーム（TIP）は、インジケーターや攻撃者のコンテキストを集約し、その情報をSIEMやトリアージワークフローに提供します。欠点：キュレーションを経ない大量のフィードは、コンテキストではなくノイズをもたらすだけであり、その価値は下流の統合に完全に依存します。改ざんのリスク：TIP自体は、自身の侵害やパイプラインへの悪意ある改ざんを検出するようには設計されていないため、それを防ぐための制御はTIP以外の部分で実施する必要があります。
脆弱性管理では、資産を特定し、脆弱性をスキャンして、是正措置の優先順位を決定します。欠点：これは検知型ではなく予防型であるという点です。つまり、開いた窓は見つけるものの、そこから誰かが侵入してくる様子までは把握できません。改ざんのリスク：スキャン範囲を密かに狭めることは容易であり、スキャン対象外の資産は「不明」ではなく「問題なし」と判定されてしまいます。
クラウド・セキュリティ・ポスチャー管理（CSPM）は、クラウドの設定がポリシーに準拠しているかをチェックする一方、クラウド検知・対応（CDR）は、クラウドのコントロールプレーンやワークロードにおける実行時の活動を監視します。欠点：マルチクラウドの無秩序な拡大により監視の死角が生じ、ポスチャーの調査結果には実行時のコンテキストが欠けていることがよくあります。改ざんのリスク：攻撃者は、これらのツールの目をくらますためにクラウドの監査ログを無効化します。クラウドログの改ざんについては、次に説明するATT&CKの手法の中で別途取り上げます。
アイデンティティおよびアクセス管理（IAM）は、誰がどのリソースにアクセスできるかを管理し、ユーザーおよびエンティティの行動分析（UEBA）は、アイデンティティの行動のベースラインを確立して、異常なアクセスを検知します。欠点：行動のベースラインには、継続的な調整と明確な責任の所在が必要であり、多くのチームが過小評価しがちな運用上の負担となります。改ざんのリスク：UEBAは、そのデータ源となるログの完全性に依存しています。つまり、ログが改ざんされれば、ベースラインも改ざんされてしまうことになります。
長年にわたり、セキュリティチームはツールの改ざんを「例外的なケース」として扱ってきました。 MITRE ATT&CK v19（2026年4月28日公開）では、これが主要な戦術として位置づけられた。このフレームワークでは、従来の「防御回避（Defense Evasion）」戦術が、「ステルス（Stealth）」（TA0005）と「防御機能阻害（Defense Impairment）」（TA0112）に分割された。 この新しい戦術は、「防御側が何が起きているかを把握したり信頼したりできないように、セキュリティメカニズム、パイプライン、およびツールを破壊する」攻撃者を指しており、セキュリティ運用ツールへの攻撃に特化したATT&CKの戦術となっています。
TA0112には、ツールおよびエージェントの停止自体を扱う親テクニックである「T1685：ツールの無効化または改変」が含まれており、これには、Windows、Linux、およびクラウドのログ改ざん、ツールインターフェースの偽装、ログの消去といった6つのサブテクニックが含まれています。以下の露出表は、ツールカテゴリとこれらのサブテクニックの対応関係を示しています。
これらは決して理論上の話ではない。2025年、研究者らは、8つの異なるランサムウェアグループによって使用されていた単一のEDR無効化ユーティリティを特定した。報告書によると、「各攻撃では異なるビルドが使用されていた」という。現在、ランサムウェアの手口では、暗号化が始まる前にエンドポイントエージェントを無効化することが常套手段となっている。
主な攻撃手法として「BYOVD（Bring Your Own Vulnerable Driver）」が挙げられます。これは、署名済みではあるものの脆弱性のあるドライバーを悪用し、セキュリティプロセスを停止させるために必要な権限を取得する手法です。「Living Off The Land Drivers」プロジェクトでは現在、1,700件以上の脆弱性のあるドライバーが登録されており、ESETの研究者は2025年にかけてその悪用事例が「急増」したことを指摘しています。この攻撃手法に対する防御策の詳細については、「EDR回避」を参照してください。
この手口は2026年に広まった。ESETが1つのEDRキラーフレームワークを分析したところ、BYOVDドライバーの悪用を通じて配信され、48種類のセキュリティ製品にわたる400以上のプロセスを標的とする8つの亜種が確認された。また、ランサムウェアも、脆弱性のあるドライバーをペイロードに直接組み込むようになり（2026年）、実行時にドライバーを取得する必要がなくなった。
ツールの管理層も攻撃の対象となっています。 2026年、市場をリードするSIEMプラットフォームが、認証されていない攻撃者が任意のファイルを作成または切り詰めることを可能にするCVSS 9.8の脆弱性を公表した。この脆弱性は実際に悪用されており、CISAの「既知の悪用済み脆弱性」カタログにも掲載されている。同年、大手SOAR/SIEMプラットフォームも、CVSS 9.1と評価された重大なアクセス制御の脆弱性を公表した。攻撃を検知するためのツールそのものが、攻撃対象となっているのである。
防御体制は多層的で、厳格に防御に重点を置いています。エージェントが提供する場所ではどこでも改ざん防止機能を有効にし、脆弱なドライバーのブロックリストを適用し、データ取り込みの状態を監視してログソースが沈黙した際にアラームを発し、侵害されたホストが無効化できないアウトオブバンドのネットワークテレメトリを維持します。また、多くのチェックリストには含まれていない、率直な評価質問も加えています。それは、「このツールは攻撃者との接触に耐えられるか、そしてもし耐えられなかった場合、誰かがそれに気づくだろうか」というものです。
表：MITRE ATT&CK （2026年4月）に基づく、ツールカテゴリごとの「防御機能の侵害」への脆弱性。
セキュリティ運用において最も気がかりなデータセットは、侵害・攻撃シミュレーション（BAS）から得られるものです。BASベンダーが発行した『Picus Blue Report 2025』――同社の顧客環境を基に、実際の攻撃ではなくシミュレーションに基づいて作成されたもの――によると、テスト対象となった攻撃活動の54％がログに記録されましたが、アラートが発生したのはわずか14％にとどまりました。 同データセットによると、防御効果は2024年の69％から2025年には62％へと低下したことが記録されている。このバイアスが明示されていることを踏まえても、この調査結果は依然として説得力がある。つまり、アラートを発することなくログを記録するだけのツールは、検知制御ではなく、フォレンジック用のアーカイブに過ぎないのだ。そして、シミュレーションは「穏やかなケース」に過ぎない――実際の攻撃者はさらに創意工夫を凝らすことになるだろう。
実務者のデータも同様の傾向を示しています。SANSの2025年調査によると、SOCの42％が、取得や管理の計画を立てずに、受信したすべてのデータをSIEMに送信していることが明らかになりました。調査でも指摘されているように、「データを収集するのは簡単ですが、それを賢く活用するのが難しいのです」。
結果データは、両方向において必要なニュアンスを加えています。50万時間以上に及ぶインシデント調査に基づくマンディアントの『M-Trends 2026』によると、世界的な平均潜伏期間は11日から14日に延びた一方で、内部で検知された侵入の割合は43％から52％へと改善しました。 外部からの通報を待つのではなく、組織自らが攻撃者を検知するケースが増えている一方で、それらの攻撃者は依然としてより長い期間、システム内に潜伏し続けている。サンプルに留意すべき点がある。インシデント対応ベンダーが扱う事例は、必然的に侵害を受けた組織に偏っているのだ。単純化された解釈に惑わされてはならない。正直なところ、検知能力は向上している一方で、排除のスピードは向上していない――この両方が同時に起こっているというのが実情である。
実用的な結論としては、見方を変えることです。ほとんどのSOCチームはすでに適切なカテゴリを把握しています。残された課題は、それらの制御手段がテストされた際に実際に機能するかどうかです。 検知は「購入する機能」ではなく「測定する特性」です。ATT&CKに基づくカバレッジ測定、スタック全体をエンドツーエンドでテストするパープルチーム演習、そしてログをアラートに変換する検知エンジニアリングを通じて測定されます。検証も年1回ではなく継続的に行う必要があります。主要な設定変更後は再テストを行い、アラートの精度を追跡し、スタックが実証的に検知している手法の割合を監視します。別のカテゴリを導入すれば、紙面上ではカバレッジが拡大しますが、本番環境でそれを証明できるのは測定のみです。
カテゴリ別チェックリストを見ると、ツールの購入は簡単そうに見えます。しかし、前述の証拠は、より厳しい基準――そのツールが自社の環境において有効なシグナルを生成し、攻撃者の注目に耐えられるかどうかを検証する基準――の必要性を示唆しています。貴社のチームにとって最適なSOCツールは、以下の手順をクリアするものです：
カタログ別ではなく、成熟度に基づいてソリューションを導入する：第一に可視性（エンドポイントおよびネットワークのカバレッジ）、第二に相関分析（SIEMまたはデータレイク）、最後に自動化――SOARは、既存の検知品質を飛躍的に高めます。Match 導入項目を人員配置とMatch 。なぜなら、少人数のチームでは、すべての分野を同時に適切に運用することはできないからです。
選択は、断片化した現実の中でも行われています。2026年にPanaseerがセキュリティ責任者400人を対象に実施した調査によると、平均的な企業では61種類のセキュリティツールが導入されていることが明らかになりました。他の調査では集計方法が異なり（以下の表にそのばらつきを示しています）、こうした違いはトレンドというよりは、サンプルや定義の違いによるものです。各調査で一致しているのは、その結果です。つまり、ツールは存在しているものの、それらを連携させて有効に活用するための統合が、しばしば欠如しているということです。
表：よく引用されるエンタープライズツールの導入台数に関する数値は、時系列データではなく、議論の分かれる範囲である。
自動化については、別途注意を払う必要がある。商用SOARツールを対象とした唯一の対照ユーザー調査（査読済みだが、実施から2年以上が経過している）では、24名の参加者に6つのツールを使用させ、現実的な調査タスクを実施させた（Bridges et al., 2023）。 効率は向上したものの、「チケットの正確性と完全性は……SOARの使用に伴い低下した」とされ、上級アナリストたちは過度な自動化をリスクとして指摘した。意思決定を迅速化するために自動化を導入する一方で、品質に対する責任は人間が負い続けるべきである。
2つの選定ミスが繰り返し見受けられます。第一に、リソースを確保できないツールを導入してしまうことです。SANS 2025年の調査では、「企業の経営陣がリソースを全面的に投入する準備ができていないのであれば……そもそも導入しないほうがよい」と率直に指摘されています。第二に、あるカテゴリーの製品を購入しただけで、結果が得られると想定してしまうことです。調達によって紙面上ではギャップは埋まりますが、アラートが何も発せられなければ、午前2時のインシデント対応は依然として失敗に終わります。
このガイドが信頼できる理由：カテゴリーを実務者のデータに基づいて並べ替え、すべての統計データに日付を明記し、各数値の出典を明示し、スポンサーによる偏りがある場合はその旨を開示しています（BASベンダーのデータセット、Elasticがスポンサーとなった調査、インシデント対応ベンダーの対応件数など）。また、特定の商用ベンダー名は一切挙げていません。証拠が相反する方向を示している場合は、その両方を提示しています。
オープンソースのSOCツールを組み合わせることで、実用的なSOCスタックを構築することができ、チームによってはそうすべき場合もあります。WazuhはSIEM/XDRの機能を担います。Security OnionとGraylogは、ネットワークセキュリティの監視とログ管理を担当します。SuricataとZeekはネットワーク検知機能を提供します。TheHiveはケース管理と調査を管理し、Velociraptor、osquery、GRRはエンドポイントの調査とフォレンジックをサポートします。 これらはすべて、GitHubを中心に活発にメンテナンスされており、その背後には実務者によるコミュニティが存在しています。
表：機能別に分類した、SOCスタック用のオープンソース構成要素。
この率直なトレードオフについても、同等に考慮すべきです。オープンソースのスタックを使えば、最低限の機能は実現できますが、統合や保守にエンジニアリングリソースを費やすことになります。つまり、ライセンス費用をエンジニアリングコストと引き換えにすることになり、ベンダーによるSLAのサポートも期待できません。もともとライセンス料ではカバーされていなかった部分――検知コンテンツのメンテナンス、バージョンアップ、センサーのチューニング、そしてこれらすべてを支えるオンコール体制――については、正直に予算を計上すべきです。 エンジニアリングの時間が割かれていない無料ツールは、シェルフウェアと同じように――ひっそりと――失敗に終わります。機能ごとのより詳細な解説については、広く利用されているあるオープンソースSOCツールのリファレンス資料が、エコシステムを深く掘り下げて解説しています。
対象となるのは、本格的なエンジニアリング能力を持つチームや、商用製品への投資を決定する前に実証の場を求めているチームです。また、混合環境にも適しています。多くのSOCでは、スタックの他の部分を独立したアウト・オブ・バンドのチェックとして、商用プラットフォームと並行してZeekやSuricataを運用しています。
セキュリティオペレーションセンター（SOC）のツールは、それを実行できる運用モデルの中で初めてその価値を発揮します。まず決定すべきは、運用を担当するのは自社チームか、外部プロバイダーか、あるいはその両方かということです。社内SOCは管理能力と環境の状況を最大限に把握できますが、人員確保が大きな制約となります。SOCの79％が24時間365日体制で運用されており（SANS 2025）、24時間体制を維持するには、数に限りがあるアナリストを複数シフトで配置する必要があります。
マネージドモデル（マネージド検出・対応（MDR）やSOC as a Serviceなど）は、コンテキストや制御性を犠牲にする代わりに、迅速にカバー範囲を確保し、固定費を削減できます。共同管理型SOCは、その中間的なアプローチを採用しており、トリアージやエンジニアリング業務を社内で担当しつつ、夜間監視はプロバイダーに委託します。この中間的なアプローチは、特にフルタイム従業員（FTE）が5名未満のセキュリティチームなど、小規模なチームに適しています。
表：社内運用とマネージド・セキュリティ運用の間の運用モデルにおけるトレードオフ。
セキュリティオペレーションセンター（SOC）の形態については、4つのモデルが主流となっています。単一の集中型SOC（依然として約38％を占め、最も一般的です（SANS 2025））に加え、仮想型、共同管理型、SOC-as-a-serviceがあります。Match 、ベンダーの意向ではなく、チームの規模、成熟度、予算Match 。また、どのモデルを採用する場合でも、検知結果の検証は社内で実施してください。監視業務の外部委託は有効ですが、説明責任の外部委託は許されません。
3つの潮流が、組織によるこのスタックの購入および運用方法を一新しつつあります。その一つは、ツールの乱立に買い手が抵抗を示す中での統合とプラットフォームの収束です。二つ目は、自動化されたトリアージを可能にするAI SOCツールやエージェントの登場です。そして三つ目は、調達から継続的な検証への移行です。具体的には、検出エンジニアリング、パープルチーム活動、カバレッジ測定などが、年次監査ではなく常態的な実践として行われるようになっています。
AIに関する認識を常に最新かつ客観的なものに保つ必要があります。現在、実務担当者はAI／ML主導のツールを満足度ランキングの最下位に位置付けており、生成型言語ツールのスコアは4段階中2となっています（SANS 2025）。これは主に構造的な理由によるもので、新しいツールが登場する際、明確な責任の所在、予算、あるいはシステム統合の枠組みが定まっていないためです。 低評価のカテゴリーも、かつては成熟期を迎えたことがあります。同じ調査シリーズにおいて、アセットディスカバリーは2017年の最下位から中位まで順位を上げています。AIによる脅威検知は、新興かつ未定の分野として扱うべきです。真に有望ではありますが、実務者のデータではまだ実証されていません。どのツールを最初に学ぶべきか迷っている個々のアナリストは、まずチームがすでに運用しているSIEMおよびEDRコンソールから始めることをお勧めします。SOCアナリストのページでは、キャリアの展望について解説しています。
現在、コンプライアンスの枠組みでは、こうしたツールの利用が前提となっています。2012年以来初の改訂版として2025年4月に発行されたNIST SP 800-61r3では、インシデント対応に関するガイダンスが、NIST CSF 2.0の「検出（Detect）」および「対応（Respond）」機能と整合するよう調整されています。MITRE ATT&CK 、TA0112を含む検出範囲に関する実務上の参照基準として機能しています。
表：セキュリティ運用ツールの選定に関連するフレームワーク。
Vectra AIは、上記の事実から「収集＝検知ではない」という教訓を読み取っています。2025年のBASデータセットによると、攻撃活動の54％が記録されているものの、アラートが発行されたのはわずか14％にとどまり、SANSの調査ではSOCの42％が計画なしにデータを蓄積していることが判明しています。つまり、不足しているのはテレメトリではなく、シグナルなのです。 したがって、Vectra AIの手法では、単純なデータ量よりも攻撃シグナルを優先しています。ネットワークとアイデンティティを網羅することで、攻撃者がエンドポイントエージェントを無力化しても報告を継続する攻撃対象領域をカバーしています。
いいえ。SIEMは単一のツールであり、ログデータを集約・相関分析し、アラートを発信するものです。一方、SOC（セキュリティオペレーションセンター）とは、SIEMに加え、EDR/XDR、NDR、SOAR、脅威インテリジェンスプラットフォームなどを活用する、人材、プロセス、および包括的なツール群を指します。
はい、ただしそれは珍しいケースです。一部のチームでは、XDRやデータレイクを中核に据え、代わりに「検出アズコード」を採用しています。SIEMは必須条件というよりは、一般的な基盤として位置づけられています。また、SANS 2025の調査によると、SOCの42％が、データ取得計画を持たずにすべてのデータをSIEMに送信していることが判明しました。
頼りにしていたテレメトリデータが、多くの場合、何の警告もなく失われてしまいます。ランサムウェアの攻撃者は、暗号化の前にエンドポイントエージェントを無力化するために、「BYOVD（Bring-Your-Own-Vulnerable-Driver）」と呼ばれるEDR無効化手法をますます多用しています。これは、MITRE ATT&CK においてTA0112およびT1685として正式に定義された行為です。対策としては、改ざん防止、ドライバーのブロックリスト登録、およびアウトオブバンドのネットワークテレメトリなどが挙げられます。
EDR/XDR。Elasticが後援した「SANS 2025 SOC調査」では、4段階の満足度評価で3以上を獲得した唯一のカテゴリーでした。一方、AI/MLツールは最下位となり、生成型言語ツールは4段階中2の評価にとどまりました。実務担当者の評価は、ベンダーが作成する「おすすめリスト」とはしばしば食い違うものです。
代表的な構成要素としては、Wazuh（SIEM/XDR）、Security OnionおよびGraylog（監視・ログ管理）、SuricataおよびZeek（ネットワーク検知）、TheHive（ケース管理）、Velociraptorおよびosquery（エンドポイント調査）などが挙げられます。オープンソースを利用することで、統合や保守にかかるエンジニアリング時間のコストを削減できます。
社内SOCは、自社のチームが人員を配置し運営するため、管理体制と環境の状況を最大限に把握できます。マネージドSOC（MDRやSOC as a Service）は、監視と対応をプロバイダーに委託するものです。多くの小規模チームは、この2つの間にある「共同管理」という中間的なアプローチを採用しています。
主に4つのモデルが主流となっています。それは、集中型社内SOC、仮想SOC、共同管理型SOC、およびSOC-as-a-Serviceです。SANS 2025調査によると、単一の集中型SOCが依然として最も一般的なモデルであり、その割合は約38％でした。ベンダーの好みではなく、チームの規模、成熟度、予算に合わせてMatch 。
