>
>
公開日
最終更新日
MSS、MDR、SOCはいずれもサイバー攻撃の検知・対応を支える仕組みですが、意味も契約範囲も同じではありません。MSSは監視・運用を外部へ委託するサービス群、MDRは侵害兆候の分析と初期封じ込めに重点を置くサービス、SOCは監視・分析を行う組織または機能です。
情シス部門が比較時に見るべきなのは、サービス名や「24時間365日」という表現だけではありません。どのログを収集するか、誰がアラートを分析するか、深夜に端末隔離を誰が承認するか、誤隔離した端末を誰が復旧するかまでを契約と手順に落とし込む必要があります。本記事では、MSSとMDR、SOCの違いを整理したうえで、現実的な選定基準と運用設計を解説します。
MSSとは
MSSとは、セキュリティ機器やクラウドサービスの監視・分析・運用業務の一部を外部の専門事業者へ委託するサービスの総称です。英語ではManaged Security Serviceと呼ばれ、略してMSSと表記します。
本記事のポイント
MSS、MDR、SOCは同義ではなく、監視対象と一次対応の範囲で区別します。
MDRの価値はアラート通知ではなく、人間による調査と封じ込め判断にあります。
端末隔離の可否は機能比較ではなく、業務停止リスクとRACIで設計します。
導入直後のチューニングを契約に含めないと、アラート疲れが起こりやすくなります。
MSSの対象範囲
MSSは従来、ファイアウォール、UTM、IDS/IPS、WAF、VPN装置など、ネットワーク境界にある機器のログ監視や設定運用を中心に提供されてきました。現在は、SIEMに集約したログ、EDRの検知情報、Microsoft 365などのSaaS監査ログ、AWSやAzureのクラウドログ、ID基盤の認証ログまで扱うサービスもあります。
ただし、MSSという名称だけでは対象範囲を判断できません。あるサービスではWAFのアラート通知まで、別のサービスではSIEMの相関分析、脆弱性情報の通知、設定変更支援までを含みます。提案書では「監視対象」「ログ保存期間」「分析方法」「通知方法」「実行可能な対処」を分けて確認し、監視の空白を資産台帳と照合します。
MSS・MDR・SOCの概念
MSSは外部サービスの契約形態、MDRは検知・調査・対応に焦点を当てたサービス、SOCは監視・分析・対応を担う組織または機能です。したがって、外部SOCがMSSを提供することも、MSSの一部としてMDR機能を提供することもあります。
区分 | 主な監視対象 | 主な提供価値 | 対応範囲の例 |
|---|---|---|---|
MSS | FW、WAF、VPN、SIEM、クラウド、IDなど | ログ監視、機器運用、相関分析、報告 | 通知、設定変更支援、遮断支援など |
MDR | EDR、XDR、端末、サーバー、ID、クラウド | 侵害兆候の調査、脅威ハンティング、初期封じ込め | 端末隔離、プロセス停止、証跡収集など |
SOC | 企業全体のIT・クラウド・ネットワーク | 24時間監視、分析、インシデント統括 | 内製・外部委託を問わない運用機能 |
Gartnerは2025年10月公表のMarket Guide for Managed Detection and Response（Gartner, 2025年10月、閲覧にはGartnerアカウントが必要）で、MDRをリモートで提供される人間主導のモダンなSOC機能として位置付けています。自動検知だけでなく、アナリストが脅威の優先度を判断し、攻撃の阻止や封じ込めにつなげる点がMDRの特徴です。なお、同レポートの内容はGartner契約者向けに公開されており、予測・定義は改訂される場合があります。
MSSセキュリティ運用の留意点
MSSを導入しても、事業継続に関する最終判断まで外部へ移るわけではありません。基幹システムを停止するか、顧客へいつ通知するか、バックアップからどの時点へ復旧するか、監督官庁や取引先へ何を報告するかは、通常、利用企業が説明責任を持ちます。
たとえばVPNの異常通信をMSSが検知しても、ID停止権限が社内だけにある場合、封じ込めは情シスまたはID管理担当が実行します。MSS導入の効果は、判断を不要にすることではなく、夜間を含む監視と一次分析を補い、自社が事業影響の判断に集中できる状態を作ることにあります。
MSSが必要になる背景
MSSの必要性は、侵入後の攻撃対策、人材不足、取引先や業界から求められる監視・報告体制の整備によって高まっています。
侵入後対策の必要性
警察庁は2025年3月に公表した令和6年におけるサイバー空間をめぐる脅威の情勢等について（警察庁サイバー警察局、2025年3月公表）で、ランサムウェア被害が継続している状況を報告しています。攻撃者はVPN機器、リモートデスクトップ、フィッシングメール、認証情報の窃取、委託先経由など複数の入口を利用するため、境界機器だけを監視しても侵害の把握が完結しない場合があります。
IPAは情報セキュリティ10大脅威 2025（独立行政法人情報処理推進機構、2025年公表）で、組織向け脅威としてランサムウェア、サプライチェーンや委託先を狙った攻撃、脆弱性を悪用した攻撃を挙げています。VPN、端末、ID、SaaS、クラウドのどこで異常を見つけるかを資産ごとに整理すると、MSSとMDRのどちらを先に補うべきかを判断できます。
人材不足の実態
NTTセキュリティ・ジャパンは、従業員101名以上の企業に所属する情報システム担当者933名を対象にした調査で、38.7％がセキュリティ人材不足を課題に挙げたと公表しています（NTTセキュリティ・ジャパン公表資料より。同社のWebサイトで公開状況を確認できます。非公開となっている場合は同社へお問い合わせください）。人材不足は人数だけの問題ではなく、夜間の一次分析、脅威インテリジェンスの参照、ログ検索、隔離判断を継続できる担当者を確保しにくい点にあります。
24時間365日で常時1人を配置するだけでも、休日、休暇、教育、引き継ぎを含むシフトを考慮すると複数人が必要です。マクニカは、24時間365日の運用体制維持には最低4.5人程度の人員が必要になるという試算を紹介しています（マクニカ公表資料より。資料の公開時点や前提条件はマクニカのWebサイトで確認できます。試算の前提が自社環境と異なる場合は参考値として扱います）。これは一次監視のみを前提にした目安であり、二次調査、脅威ハンティング、復旧作業まで内製するなら必要な体制はさらに変わります。
制度・業界ガイドラインの論点
サイバー対処能力強化法は、重要なインフラ機能などを担う事業者の対処能力を高めるための制度です（所管：内閣官房・NISCほか）。すべての中小企業に24時間監視を直接義務付ける制度として理解するのは正確ではありません。対象事業者、義務内容、施行・適用の状況は政令や省令で具体化されており、今後改正される可能性があります。自社が対象に該当するかどうかは、内閣サイバーセキュリティセンターの政策情報で事業区分と対象範囲を照合し、法的判断が必要な場合は法律の専門家に相談のうえで確認します。対象に該当する場合は監視・連絡・報告の要件をRFPに反映して設計します。なお、本記事の記述は法的助言ではありません。
医療機関は厚生労働省の医療情報システムの安全管理に関するガイドラインを踏まえ、委託先を含めた安全管理を検討します。金融、放送、製造、物流などでも、自社に適用される監督指針や取引先の質問票にログ保存、事故連絡、委託先管理の条件があるなら、その条件を満たす監視対象と保存期間をRFPに記載します。
脅威エクスポージャーへの拡張
Gartnerは、前述のMarket Guide for Managed Detection and Response（2025年10月公表）の中で、2028年までにMDRの検出結果の50％が、攻撃そのものだけでなく脅威エクスポージャー、つまり設定不備や露出した脆弱性に関する内容になると予測しています。この予測の前提条件や詳細はGartner契約者向けレポートで確認できます。MDRを導入する場合も、アラート対応だけに閉じず、外部公開資産、特権ID、未適用パッチ、クラウド設定の不備を月次で改善する運用へつなげると、侵害後対応に偏りません。
MSSとMDRの違い
MSSとMDRの違いは、境界防御と侵入後対応という単純な区分ではなく、収集するテレメトリと検知後の実行権限で判断します。
機能範囲の比較
MSSは広い概念であり、ネットワーク監視、SIEM運用、クラウド監視、脆弱性情報の通知、EDR運用を含む場合があります。一方のMDRは、EDRやXDRを中心に、侵害の可能性があるイベントを人間が精査し、脅威ハンティングや初期封じ込めを行うことに重心があります。
比較項目 | MSS | MDR |
|---|---|---|
主な目的 | 監視・ログ分析・機器運用を継続すること | 侵害兆候を調査し、封じ込めを速めること |
主なデータ | ネットワーク、WAF、SIEM、クラウド、ID、EDRなど | EDR/XDR、端末、サーバー、ID、クラウドの行動データ |
分析方法 | アラート監視、相関分析、定例報告、設定運用 | アラート精査、脅威ハンティング、侵害調査 |
一次対処 | 通知から設定変更支援まで契約により異なります | 通知から端末隔離・プロセス停止まで契約により異なります |
確認すべき条件 | 監視対象、保持期間、SLA、ログ検索権限 | 隔離権限、対応時間、例外端末、復旧分担 |
「MSSは通知だけ」「MDRは必ず隔離まで実行」と決めつけると、契約後に認識差が生まれます。提案書の「対応可能」という記載は、通知のみ、対処案の提示、利用企業の承認後に実行、事前合意により無承認で実行の4段階に分解して比較します。
メーカー型MDRの特徴
なお、「メーカー型MDR」「MSSP型MDR」という区分は本記事での比較を整理するための枠組みです。業界全体で統一された分類定義があるわけではなく、実際のサービスはその中間や複合形態をとる場合があります。
メーカー型MDRは、CrowdStrike、Microsoft、SentinelOne、Trend Microなど、EDRやXDRの製品ベンダーまたは直系の運用チームが、自社製品のテレメトリを中心に提供するモデルです。特定のEDRを全社標準として導入済みで、その製品の検知ロジック、隔離、フォレンジック情報収集を深く活用したい環境に適します。
利点は、自社製品の機能、API、脅威インテリジェンスに詳しいアナリストが対応しやすい点です。注意点は、他社製ファイアウォール、SaaS、複数クラウドのログをどこまで相関分析するかがサービスごとに異なる点です。単一製品の深い運用を優先する場合はメーカー型を比較対象にします。
MSSP型MDRの特徴
MSSP型MDRは、通信事業者、SIer、セキュリティ専門事業者がSOC基盤を使い、複数ベンダーのEDR、ネットワーク、クラウド、IDログを横断して提供するモデルです。複数のEDRが混在し、AWS、Azure、Microsoft 365、オンプレミス機器を一つの窓口で監視したい環境では候補になります。
利点は、SIEMやXDRを介した横断分析、既存機器を活かした運用設計、日本語での連絡手順や個別プレイブックを組み込みやすい点です。注意点は、ログ連携の初期設計、ログ量に連動する費用、製品ごとに実行できる隔離・遮断操作の差です。複数環境を統合する場合は、連携可能なログ一覧と操作一覧が提出されるならMSSP型の限定検証へ進み、提出されない場合は監視空白を別途補う設計にします。
▲ MSSとMDRにおける監視対象と一次対処範囲の比較
MSSとSOCの違い
SOCはセキュリティイベントを監視・分析・対応する組織または機能であり、MSSはその機能の一部または全部を外部サービスとして利用する形態です。
内製SOCの運用条件
内製SOCでは、自社の業務、重要システム、停止できない時間帯を深く理解した担当者が判断できる利点があります。その一方で、SIEMのルール作成、ログ基盤の保守、脅威情報の収集、アナリスト教育、夜勤と休日対応まで維持しなければなりません。
「内製SOCには5名以上が必要」といった数字は、常時監視を前提とした概算です。マクニカが紹介する最低4.5人という試算も、24時間365日で常時1人を置くための人数目安であり、二次調査や復旧を含む体制の必要人数ではありません。平日日中のみ監視するのか、夜間もアナリストが調査するのか、オンコールで専門家を呼ぶのかで、必要人数と費用は変わります。
外部SOCの契約形態
外部SOCには、MSS、SOC-as-a-Service、SIEM運用支援、MDR、インシデント対応支援などがあります。SOC-as-a-Serviceは監視・分析チームを利用する形態、SIEM運用支援はログ収集基盤と検知ルールの運用に重点を置く形態、MDRは侵害兆候の調査と対応に重点を置く形態です。
契約形態を比較する際は、監視、一次分析、二次調査、脅威ハンティング、封じ込め、復旧支援、経営報告の各工程について、実施者を並べます。自社SOCと外部SOCを併用するなら、外部は24時間の一次分析、社内CSIRTは業務影響と対外報告の判断というように、重複を許容する工程と責任を一つにする工程を区別します。
ログ保存期間の判断
ログ保存期間は、侵害が判明してから過去の活動を遡るための重要な条件です。NTTセキュリティ・ジャパンは、他社サービスでは30〜90日程度の保存が一般的な例として紹介する一方、同社サービスでは標準400日間の保存を案内しています（NTTセキュリティ・ジャパン公表資料より。最新の仕様は同社のサービス案内ページで確認できます。仕様変更がある場合は実際の契約条件が優先されます）。保存期間だけでサービスの優劣は決まりませんが、監査要件や過去調査の必要性がある場合は、検索可能な状態で何日保持するかを比較表に入れます。
クラウド事業者やSaaS側のログ保持期間が短い場合、MSSやSIEMだけで調査要件を満たせないことがあります。監査ログを外部へ出力できるならSIEMまたはログ保管基盤へ集約し、出力できない場合はSaaSの上位監査プランや代替証跡を組み合わせる判断になります。
▲ SOC機能を軸としたMSS・MDRと自社体制の役割関係図
MSS・MDRの選定ポイント
MSS・MDRの選定では、監視対象、対応時間、権限委譲、誤隔離時の復旧、ログ保存、初期チューニングを同じ重さで評価します。
契約前の評価項目
価格や知名度だけで比較すると、「クラウドが監視対象外だった」「夜間は分析だけで隔離できなかった」「調査したい期間のログが残っていなかった」という問題が起こります。以下の表は、RFPや見積依頼に転記できる評価項目です。
確認項目 | 質問内容 | 判断への影響 |
|---|---|---|
監視対象 | 端末、サーバー、VPN、SaaS、クラウド、IDの収集・分析範囲 | 対象外資産は別サービスまたは自社運用で補います |
対応時間 | 監視、分析、電話連絡、隔離操作の対応時間 | 夜間隔離ができないなら当番または事前承認を設計します |
一次対処 | 通知、提案、承認後実行、事前合意実行のどこまで可能か | 夜間承認者がいないなら対象限定の事前合意を検討します |
誤隔離の復旧 | 隔離解除の権限、連絡手段、復旧目標時間 | 止められない端末は例外リストと代替手順を設けます |
オンボーディング | 業務アプリの調整、例外設定、定例レビューの支援工数 | 支援がない場合は自社の調整要員を確保します |
料金体系 | 端末数、ログ量、拠点数、緊急対応、初期設定の課金単位 | 増員・クラウド移行後の費用を試算します |
RACIによる責任分担
RACIは、実行責任者をResponsible、最終責任者をAccountable、相談先をConsulted、報告先をInformedとして整理する方法です。MDRのベンダーが技術的な封じ込めを実行しても、業務停止や対外説明の最終責任は利用企業に残るため、契約前に役割を文書化します。
対応工程 | MDR・MSSP | 情シス・CSIRT | CISO・経営層 |
|---|---|---|---|
脅威検知・一次分析 | R | I | I |
標準PCの事前承認済み隔離 | R | A | I |
重要サーバー・VIP端末の隔離判断 | C | R | A |
根本原因の調査 | RまたはC | AまたはR | I |
復旧・利用者連絡 | C | R | A |
顧客・監督官庁への報告 | I | R | A |
この表では、標準PCの隔離をベンダーが実行できても、重要システムの停止判断は自社が持ちます。生産設備、医療機器、放送設備、決済端末など、隔離自体が業務停止に直結する資産は、自動隔離対象から除外し、電話承認後に段階的な遮断を行う設計が現実的です。
端末隔離の段階設計
端末隔離は横展開を止める有効な手段ですが、誤検知で会計端末やコールセンター端末を切り離せば、攻撃とは別に業務停止を招きます。隔離機能の有無ではなく、脅威度と資産重要度に応じた段階的な対応を決めます。
一般業務PCは、高信頼度のランサムウェア挙動やC2通信を条件に事前承認で隔離します。
重要端末は、悪性プロセス停止や特定通信先の遮断を先行し、オンコール担当者の承認後に完全隔離します。
隔離解除は、誤検知の判定だけで終えず、再スキャン、認証情報の確認、利用者への復旧連絡までを一つの手順にします。
夜間に15分以内の電話連絡を求めるなら、主担当と副担当の二重化、電話不通時の自動実行条件、連絡記録の保存までをSLAとプレイブックへ記載します。連絡先が平日日中のメールアドレスだけなら、24時間監視を契約しても初動は止まります。
導入後90日間の設計
オンボーディングの初月から完全自動化を目指すと、正規業務の通信や管理スクリプトを攻撃と誤認しやすくなります。導入後90日間は、運用の安定化期間として扱います。
期間 | 実施内容 | 確認できる成果 |
|---|---|---|
1〜30日 | 資産台帳とログ収集状況の突合、連絡先登録 | 監視対象外の端末・クラウドを特定します |
31〜60日 | アラート分類、業務通信の限定例外化、定例レビュー | 誤検知の原因と除外範囲を記録します |
61〜90日 | 夜間連絡訓練、隔離・解除の演習、RACI見直し | 初動時間と復旧手順の実効性を測定します |
例外設定は、フォルダやプロセスを広く除外するのではなく、端末群、実行アカウント、時間帯、通信先を限定します。管理ツールは正規利用でも攻撃者に悪用されるため、無条件の除外は検知能力を下げます。
国内企業の導入事例
国内企業の導入事例では、ツール名よりも、少人数の情シス部門が何を外部へ移し、何を社内判断として残したかを見ると導入後の運用を具体化できます。
キヤノンマーケティングジャパンの事例
業種・規模：キヤノンマーケティングジャパンは、グループ10社で約23,000台のPC・サーバーを管理する環境でMDR運用を検討しました。
導入時期：公開済みの導入事例を基にした整理です。
課題→施策→成果：多数の端末で発生するアラートを社内スタッフだけで継続的に調査する負荷が課題となり、ESET PROTECT MDRを活用して監視・分析を外部アナリストへ委託しました。キヤノンマーケティングジャパンが公開するESETビジネス導入事例では、類似プロセスの調査や端末挙動の把握を外部分析と組み合わせ、社内IT部門の監視負荷を抑える運用が紹介されています。
23,000台規模では、通知件数だけでなく、類似アラートを束ねて優先順位を付ける能力が運用品質を左右します。この事例は、技術的な調査を外部に寄せ、業務影響の判断を社内に残す運用の参考になります。
タニタの事例
業種・規模：タニタは健康計測機器の製造・販売を行う企業です。公開事例では詳細な端末台数は確認できません。
導入時期：トレンドマイクロが公開する導入事例を基にした整理です。
課題→施策→成果：テレワーク拡大とクラウド移行により端末対策の必要性が増える一方、少人数の情報システム部門で常時監視を行うことが課題でした。トレンドマイクロのMDR機能を含むサービスでアラート分析と優先度付けを外部化し、公表事例では誤検知・過検知への対応工数を抑え、予防施策などの企画業務へ時間を配分しやすくなったと紹介されています。
同社の事例はトレンドマイクロの顧客導入事例で参照できます。公開情報で導入前後の削減時間は確認できないため、費用対効果を試算する際は、自社の月間アラート件数、一次分析時間、夜間対応回数を基準に見積もります。
静岡第一テレビの事例
業種・規模：静岡第一テレビは放送事業を行う企業です。
導入時期：セグエセキュリティが公開した事例を基にした整理です。
課題→施策→成果：放送を止めにくい環境でランサムウェアなどの脅威へ備え、PCの社外持ち出しやIP化した放送設備を含めた監視体制が課題でした。SSC-MDRを利用して24時間365日の監視体制を構築し、ベンダー公表事例では安全な端末利用環境と運用管理負荷の軽減を実現したと紹介されています。
放送、製造、医療、物流のように停止影響が大きい環境では、検知後に即時隔離するだけでは不十分です。一般端末は即時隔離、重要設備は緊急電話と事業部承認後に隔離というように、資産区分ごとのプレイブックを作成すると、封じ込め速度と事業継続を両立しやすくなります。
MSS・MDRで起きやすい失敗パターン
MSS・MDRの失敗は製品性能の不足よりも、責任分担、初期設定、夜間連絡、業務影響の設計不足で起こります。
丸投げによる責任の曖昧化
ベンダーへ監視を委託したことで、社内の判断担当者が不要になったと考えるのは失敗です。深夜に「端末隔離を推奨する」と連絡されても、承認者、代替連絡先、事業部門の責任者が決まっていなければ、朝まで封じ込めが進みません。
対策は、深刻度ごとにRACIと連絡順を決めることです。たとえば横展開が確認された一般PCはベンダーが即時隔離し、基幹サーバーは情シス当番と事業責任者の電話承認後に隔離する、と条件を明文化します。連絡先が一人しかいない体制では休日や休暇に機能しないため、主担当・副担当・最終不通時の処置を設定します。
MSSとMDRの役割誤認
ネットワーク監視型MSSを契約しているのに、感染端末の遠隔隔離まで実施されると考える例があります。反対にMDRを契約していても、ID停止、メール削除、SaaSのセッション無効化、クラウド設定変更が範囲外なら、侵害アカウントの活動を止められません。
フィッシングを想定した机上演習で、誰がサインインログを確認し、誰がパスワードをリセットし、誰が利用者と取引先へ連絡するかを書き出します。空欄になる工程があれば、契約追加、自社手順、別ツールの連携のいずれかを選び、対応の空白を残さないようにします。
アラート疲れと過剰な除外設定
導入直後に正規の管理ツール、バックアップ通信、業務スクリプトが大量に検知され、担当者が通知を読まなくなる状態をアラート疲れと呼びます。通知が多いからといって、業務ツールや特定フォルダを広く除外すると、攻撃者が同じ経路を利用した場合に検知できなくなります。
エムオーテックスは、MDR利用者から「アラート通知だけでなく具体的な対処方法まで知りたい」「マルウェア感染時の対応を速めたい」という要望が挙がっていると調査結果として公表しています（エムオーテックス公表資料より。調査時期・対象・方法の詳細はエムオーテックスのWebサイトで確認できます）。アラートを閉じる前に、発生端末、実行ユーザー、親プロセス、通信先、時刻、業務上の必要性を記録し、例外化は限定条件で行います。
夜間連絡不通と誤隔離
24時間監視を契約しても、緊急連絡先が平日日中しか確認しないメールアドレスでは初動が遅れます。また自動隔離は横展開を抑える一方で、営業、工場、コールセンター、放送制作の端末を止める危険があります。
電話、SMS、緊急通報アプリなど複数の連絡経路を用意し、四半期ごとに連絡訓練を実施します。誤隔離の解除手順は、解除権限、再スキャン、認証情報の確認、利用者への案内、業務データ整合性の確認まで記載します。隔離解除が数クリックでできても、端末が安全である根拠を確認せずに復帰させる運用は避けます。
よくある質問
MSS、MDR、SOCの比較で残りやすい疑問を、導入判断に必要な条件とともに整理します。
MSS・MDRのデメリット
Q：MSSやMDRのデメリットや導入時のリスクはありますか？
A：監視対象外の資産は検知できず、ログ連携、初期チューニング、緊急連絡設計には社内工数がかかります。端末隔離を使う場合は誤隔離による業務停止リスクがあるため、重要端末の例外ルールと復旧手順を契約前に決めます。
メーカー型とMSSP型の選択
Q：メーカー型MDRとMSSP型MDRはどちらを選ぶべきですか？
A：全端末で特定のEDRまたはXDRを統一し、その製品の隔離・調査機能を深く使うならメーカー型を比較します。複数のEDR、ネットワーク機器、クラウド、IDログを横断して扱うなら、連携可能なログと実行可能な操作が文書で示されるMSSP型を比較します。
MSSとMDRの導入順
Q：MSSとMDRはどちらを先に導入しますか？
A：夜間に感染端末の調査や隔離ができない場合は、EDRを前提としたMDRを先に検討します。VPN、WAF、クラウド設定、IDログの監視が不足している場合は、MSSまたはSIEM運用支援で監視の空白が大きい領域から埋めます。
以下は環境ごとの優先判断の目安です。EDRを未導入の場合は、まずEDRを全端末へ展開してからMDRの対象範囲を決めると、ログが存在しない状態での契約を防げます。Microsoft 365を中心に利用している場合は、Entra IDのサインインログとMicrosoft 365の監査ログをSIEMまたはMSSで収集できるか確認し、空白があればMSSの監視対象に追加します。工場やOT環境がある場合は、ITネットワークと制御系の接続点を資産台帳に記載し、OTログを扱えるベンダーかどうかを提案書の「監視対象一覧」で確認します。医療・金融・放送など規制業種の場合は、業法や監督指針に定められたログ保存期間と報告義務を先に整理し、その条件を満たす保存期間と連絡手順をRFPに明記します。
少人数情シスでの夜間対応
Q：夜間・休日に対応できる社員がいなくても運用できますか？
A：通知だけの契約では初動が止まるため、事前合意に基づく封じ込め条件を設ける必要があります。一般端末は条件付き自動隔離、停止影響が大きい端末は電話承認というように対象を分ければ、少人数でも対応範囲を明確にできます。
▲ 自社の体制とセキュリティ課題に応じた導入優先度の判断フロー
まとめ
MSSとは、セキュリティ監視・分析・運用の一部を外部へ委託するサービスであり、MDRは侵害兆候の調査と初期対応、SOCはそれらを担う組織・機能を指します。選定時はサービス名ではなく、監視対象、ログ保存、夜間対応、端末隔離権限、復旧手順、RACIを比較します。明日から始めるなら、まず資産台帳に端末・クラウド・ID・ネットワークを並べ、各資産について「誰が夜間に隔離判断をするか」を記入します。空欄になった工程が、MSSやMDRで補うべき優先領域です。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
