「MFAも必要、EDRも必要、セキュリティ教育も必要、SOCも検討したい。しかし、すべてを同時には実施できない」。限られたIT・セキュリティ予算の中では、このような状況は珍しくありません。
このとき、「最も高性能な製品はどれか」「最も安く導入できる対策はどれか」から考えると、自社にとって本当に重要なリスクと投資が結び付かないことがあります。
セキュリティ対策の優先順位は、製品名からではなく、守るべき業務・情報資産、想定する事故、現在の対策状況、事業への影響から考えることが重要です。
本記事では、MFA（多要素認証）、EDR（Endpoint Detection and Response）、セキュリティ教育、SOC（Security Operation Center）など複数の施策候補がある場合に、リスク低減効果、導入・運用コスト、前提条件まで含めて優先順位を整理する方法を解説します。
セキュリティ対策は「全部やる」ことを前提にしない
サイバーセキュリティには、アカウント管理、脆弱性対応、バックアップ、端末保護、ログ監視、インシデント対応、教育など、多数の対策があります。
すべてを同じ時期・同じ水準で実施しようとすると、予算だけでなく、導入・運用を担当する人材も不足します。
NIST Cybersecurity Framework（CSF）2.0も、特定の対策を一律に実装する方法を定めるものではありません。組織の目的、要求事項、脅威環境などに応じて、現在の状態と目標状態を整理し、改善すべき成果を優先する考え方を採っています（Pascoe et al., 2024）。
つまり、最初に必要なのは「製品一覧」ではなく、自社として何のリスクを優先して下げたいかという整理です。
優先順位を決める前に「何を守るか」を整理する
最初に、重要な業務と、それを支える情報資産を整理します。
例えば、メール、クラウドサービス、顧客情報、会計情報、従業員アカウント、端末、生産システム、バックアップなどです。
次に、「何が起きると困るのか」を事故シナリオとして考えます。アカウント乗っ取り、ビジネスメール詐欺、ランサムウェア、情報漏えい、内部不正、サービス停止などです。
同じ攻撃でも、対象が一般的な社内ツールなのか、受注・生産・決済を支える重要システムなのかによって事業影響は異なります。
したがって、脅威や脆弱性だけでなく、売上停止、操業停止、顧客影響、法令・契約上の影響、復旧負荷などまで確認します。
セキュリティ対策を評価する7つの視点
| 確認視点 | 主な確認事項 |
|---|---|
| 1. 業務・資産の重要性 | 止まった場合の業務、顧客、売上、法令等への影響 |
| 2. 脅威・露出状況 | 想定事故、外部公開、攻撃面、発生可能性 |
| 3. 現在の対策と不足 | 既存対策、適用範囲、設定状況、未対策領域 |
| 4. 期待するリスク低減 | 予防、検知、対応、復旧のどこへ作用するか |
| 5. 費用 | 導入費、ライセンス、連携、継続運用費 |
| 6. 実行可能性・依存関係 | 人材、スキル、ログ、既存基盤、導入期間 |
| 7. 必須要件・残存リスク | 法令、契約、社内基準、対策後に残るリスク |
このとき、対策を導入していない状態のリスクだけではなく、現在の対策を踏まえた残存リスクを見ることが重要です。
すでに十分な対策がある領域へ追加投資するより、重要な業務に対して大きな対策不足が残る領域へ投資した方が、優先度が高くなる場合があります。
「リスク×影響×コスト」を単純な計算式にしない
優先順位を数値化したくなると、「リスク×影響×コスト」といった式を作りたくなります。しかし、用語の定義には注意が必要です。
リスクを発生可能性と影響の組合せとして評価している場合、そこへ再度「影響」を掛けると、同じ要素を二重に評価することがあります。
NISTのリスク評価ガイドでも、脅威源、脅威事象、脆弱性、発生可能性、影響などを整理しながらリスクを評価します（Ross, 2012）。
そのため、単一の独自スコアへ急いでまとめるより、「発生可能性・露出」「事業影響」「現在の対策」「対策不足」「期待する低減効果」「費用」「実行可能性」を別々に記録し、判断理由を残す方法が実務では扱いやすくなります。
MFA・EDR・教育・SOCを比較する架空例
架空の企業が、次年度の施策としてMFA、EDR、セキュリティ教育、SOC・MDRの4候補を検討しているとします。
| 施策 | 主な役割 | 確認したい前提 |
|---|---|---|
| MFA | 認証情報窃取やアカウント乗っ取りへの耐性を高める | 対象アカウント、既存認証方式、適用範囲 |
| EDR | 端末上の不審活動を検知・調査し、対応を支援する | 対象端末、既存対策、アラート対応体制 |
| セキュリティ教育 | フィッシング、情報取扱い、事故報告等の行動面を改善する | 技術対策、社内ルール、報告プロセスとの連携 |
| SOC・MDR | 複数のログや検知情報を監視し、検知・分析・対応を支援する | 監視対象ログ、端末可視性、連絡・対応プロセス |
ここで「MFA、EDR、教育、SOCの順で導入する」といった固定順位は付けません。
MFAを優先しやすいケース
メールやクラウドサービスが重要業務の中心であり、管理者アカウントを含めて多要素認証が十分に適用されておらず、認証情報窃取やアカウント乗っ取りを重要リスクとしている場合は、MFAの優先度が上がる可能性があります。
ただし、MFAにも複数の認証方式があります。また、MFAだけで端末上のマルウェアやアプリケーション脆弱性まで対処できるわけではありません。
EDRを優先しやすいケース
主要アカウントへのMFAはすでに導入している一方、端末上で何が起きているか十分に把握できず、マルウェアやランサムウェア等の検知・調査・対応能力が不足している場合は、EDRが優先候補になる可能性があります。
ただし、EDRを導入するだけでは十分ではありません。検知したアラートを誰が確認し、どの条件で隔離・調査・報告するかという運用も必要です。
SOCを導入する前に確認したいこと
SOCは、組織内外のセキュリティ情報を監視・分析し、インシデントへの対応につなげる運用機能です。SIEMのようなログ分析製品そのものと同義ではありません。
監視対象となるログが十分に取得されていない、端末の可視性がない、インシデント発生時の連絡先や対応責任が決まっていない状態では、高度な監視サービスを契約しても活用に制約が生じます。
その場合は、SOC契約の前にログ取得、端末可視化、インシデント対応手順などの基盤を整備する選択肢もあります。
セキュリティ教育を他対策とどう組み合わせるか
セキュリティ教育だけでフィッシングや情報漏えいを完全に防ぐことはできません。一方、フィッシングメールを受け取った際の報告、機密情報の取扱い、事故発生時の連絡など、人の行動が対策の一部になる領域があります。
そのため、教育を「技術対策より弱い対策」として単純比較するのではなく、MFA、メール対策、報告プロセス、インシデント対応などと組み合わせて評価します。
投資額だけでなく「運用できるか」を確認する
セキュリティ対策の費用は、製品の購入費やライセンス費だけではありません。
初期設定、既存環境との連携、ポリシー設計、アラート監視、問い合わせ対応、定期レビュー、教育、契約更新などの継続的な運用が発生します。
高機能な製品でも、運用する担当者やプロセスがなければ期待する効果を得にくい場合があります。逆に、新しい製品を追加しなくても、既存のクラウドサービスやID基盤、セキュリティ製品に含まれる機能の設定を見直すことで改善できる場合もあります。
現在検討している施策がある場合は、製品名の左側に「守る業務・資産」「想定する事故」「現在の対策」「不足している対策」、右側に「期待するリスク低減」「導入費」「継続運用」「必要な前提条件」という列を追加してみてください。
「何を買うか」ではなく、「何のリスクを下げるための投資か」が比較しやすくなります。
必須対策と比較して決める対策を分ける
すべてのセキュリティ施策を費用対効果だけで比較するわけではありません。
法令、取引先との契約、業界要求、グループ会社の基準などによって必須となる対策は、他の施策より費用対効果が低く見えても実施が必要になる場合があります。
一方で、すべてのリスクをゼロにすることも現実的ではありません。対策後に残る残存リスクを把握し、追加対策を行うのか、監視するのか、経営として受容するのかを判断します。
セキュリティロードマップへ落とし込む
優先順位を整理したら、単年度の製品購入一覧ではなく、セキュリティロードマップへ落とし込みます。
| 区分 | 考え方 |
|---|---|
| 必須 | 法令・契約・重大な対策不足など、優先して対応する事項 |
| 優先 | 重要リスクの低減効果が期待でき、実行可能性もある事項 |
| 計画 | 必要性はあるが、前提となる基盤・人材・予算の準備が必要な事項 |
| 監視・受容 | 状況を監視しながら、現時点では追加投資を行わない事項 |
NIST CSF 2.0の組織プロファイルでは、現在達成している状態と目標状態を比較し、組織の目的、脅威環境、要求事項等に基づいて改善対象を優先できます（Pascoe et al., 2024）。
対策の優先順位は一度決めて終了ではありません。事業、新しいシステム、脅威、重大インシデント、契約要求などが変化すれば、優先順位も見直します。
セキュリティ投資チェックリスト
| 確認項目 | 確認内容 |
|---|---|
| 重要業務 | 何の業務を守るための投資か明確か |
| 情報資産 | 対象となるデータ・システム・アカウントを把握しているか |
| 事故シナリオ | どのような事故を想定しているか |
| 現在の対策 | すでに実施している対策を把握しているか |
| 対策不足 | どこに不足があるか説明できるか |
| 事業影響 | 事故が発生した場合の業務・顧客への影響を確認したか |
| 期待効果 | 候補施策がどのリスクを下げるか説明できるか |
| 費用 | 導入費だけでなく継続費用を確認したか |
| 運用負荷 | 導入後に監視・運用できる体制があるか |
| 依存関係 | ログ、端末管理、ID基盤など前提条件を確認したか |
| 必須要件 | 法令・契約等で必須となる対策を区別したか |
| 残存リスク | 対策後に何が残るか確認したか |
| 判断理由 | なぜ今この施策を行うのか説明できるか |
| 再評価 | 導入後に効果とリスクを見直す仕組みがあるか |
まとめ
限られた予算でセキュリティ対策を進める場合、MFA、EDR、教育、SOCなどを一律の順番で導入する必要はありません。
まず重要業務と情報資産を整理し、想定する事故、現在の対策、事業影響、対策不足を確認します。その上で、候補施策によってどのリスクをどこまで下げられるか、導入・運用費や必要な体制を含めて比較します。
また、リスクを単純な点数だけで扱わず、法令・契約上の必須事項、対策間の依存関係、運用できる人材、対策後に残るリスクまで含めて判断することが重要です。
目指すのは、「最も高度なセキュリティ製品を導入した状態」ではなく、限られた予算を、現在の自社にとって重要なリスクへ合理的に配分できる状態です。
SCI総合研究所株式会社のKANAMEBAでは、セキュリティ製品の導入ありきではなく、重要業務・情報資産、想定脅威、現在の対策状況、事業影響、導入・運用負荷を整理し、限られた予算の中で優先する施策と改善ロードマップを検討します。
「MFA・EDR・SOCのどれを先に導入すべきか分からない」「セキュリティ予算を経営へ説明できない」「ベンダーから複数の製品を提案されたが判断できない」といった段階から、対策の優先順位を整理できます。
参考文献
- Pascoe, C., Quinn, S., and Scarfone, K. 2024. The NIST Cybersecurity Framework (CSF) 2.0. National Institute of Standards and Technology. NIST CSWP 29. DOI: 10.6028/NIST.CSWP.29.
- Pascoe, C., Quinn, S., and Scarfone, K. 2024. NIST Cybersecurity Framework 2.0: Quick-Start Guide for Creating and Using Organizational Profiles. National Institute of Standards and Technology. NIST SP 1301. DOI: 10.6028/NIST.SP.1301.
- Ross, R. 2012. Guide for Conducting Risk Assessments. National Institute of Standards and Technology. NIST SP 800-30 Rev. 1. DOI: 10.6028/NIST.SP.800-30r1.