SCS評価制度「攻撃等の検知」の要件｜★3で必要なリアルタイム検知・遮断

本記事では、IPA（独立行政法人情報処理推進機構）が公開している「★3・★4 要求事項・評価基準」（2026年3月27日版）のうち、大分類5「攻撃等の検知」に絞って、★3で満たすべき評価基準と、どの製品構成で対応するかの考え方を整理します。★3全体の26要求事項・81評価基準の一覧は★3の要求事項一覧を、検知の前段となる防御側の要件は「攻撃等の防御」の要件をご覧ください。

「攻撃等の検知」とは

大分類5「攻撃等の検知」は、NIST CSF 2.0（サイバーセキュリティフレームワーク）の「検知（DE: Detect）」に対応する領域で、防御をすり抜けた攻撃や不正な通信に気づく仕組みを問います。★3・★4の要求事項を並べると次のとおりです。

★3の要求事項は5-1-1の1件だけで、81評価基準のうち3件を占めるにとどまります。しかし、大分類1〜3のように文書と台帳で対応できる分類と違い、検知・遮断を行う製品やサービスが実際に動いていることが前提になるため、まだ導入していない企業にとっては★3の中で最も費用と期間を要する項目になり得ます。

★3の要求事項：5-1-1 ネットワーク接続・データの監視

要求事項の本文は「ネットワーク上の適切な場所でネットワーク接続およびデータ転送を監視すること」です。評価基準は3件あり、仕組みの導入、人による判断、通知の仕組みの3層で構成されています。

5-1-1-1 リアルタイム検知・遮断の仕組み

社内外ネットワークの境界または端末において、次の双方について不正アクセスをリアルタイムに検知・遮断する仕組みを導入することが求められます。

• インターネットから社内への通信
• 社内から不正なサーバへの通信

読み落としやすいのは2点です。1つは「検知」だけでなく「遮断」まで求められていること。アラートを出すだけの監視製品では足りません。もう1つは、外から内への通信だけでなく、内から外への通信も対象であること。マルウェアに感染した端末がC&Cサーバ（攻撃者の指令サーバ）へ接続しようとする通信や、不正なサイトへのアクセスを止めることが含まれます。入口対策だけの構成では片側しか満たしていないと判断される可能性があります。

5-1-1-2 不審な事象の判断

ネットワーク機器のログやアラートを分析し、担当者または管理者が不審な事象を発見した場合に、インシデントに該当するかを判断することが求められます。製品が自動で止めた通信をそのままにせず、人が見て「インシデントか否か」を決めるところまでが要件です。判断の基準と判断者が決まっていなければ、この基準は満たせません。

5-1-1-3 異常時の通知

5-1-1-1の機器・サービスについて、アラートが速やかに発報され、インシデントの速報レポートが作成・通知される仕組みを導入することが求められます。管理コンソールにアラートが溜まっているだけでは「通知」になっていません。メールやチャットへの通知設定と、速報レポートの様式または自動生成の仕組みが必要です。

どんな製品で満たすか

評価基準は「境界または端末」のどちらで満たしてもよいとしています。自社のネットワーク構成に合わせて選びます。

オフィスがあっても、PCの多くがリモートワークで社外から直接クラウドに接続している企業では、境界機器を通らない通信が増えています。その場合、境界だけで満たしたつもりでも、実態として監視できていない端末が多数あることになります。クラウド中心で業務をしている企業では、端末側での対応が現実的です。Microsoft 365環境であれば、Microsoft Defender for Endpointのネットワーク保護・Webコンテンツフィルタリングが候補になります。

いずれの構成でも、製品を導入したうえで「アラートが誰に届き、誰が判断するか」まで決めておく必要があります。製品は入っていてもアラートの通知先が退職者のメールアドレスのまま、という状態は実際によく見られ、これでは5-1-1-2と5-1-1-3を満たしません。自社でアラートを見る体制がない場合は、監視を外部委託する選択肢もあります。委託する場合でも、インシデントに該当するかの最終判断と社内への報告を誰が行うかは自社側で決めておきます。

具体的にどの構成で要件を満たせるかは、自己評価の段階で★3確認責任者となるセキュリティ専門家に確認することを推奨します。技術対策全体の実装方針は★3対応の技術対策で解説しています。

★4で追加されるもの

★4では大分類5に2つの要求事項が追加され、大分類4に属するログの要求事項も検知の前提として加わります。

• 5-1-2 情報機器及びソフトウェアの挙動監視: 会社支給PCで利用を許可するソフトウェアの一覧を作成し、インストール状況を年1回点検すること。外部から受け取ったファイルをリアルタイムにスキャンするか、仮想環境で安全性を確認すること
• 5-2-1 セキュリティインシデントのレベルごとの対象範囲: インシデントのレベルと対象範囲を定めて周知し、不審な認証試行やアラートを受けた際にどのレベルに該当するかを判断すること
• 4-4-3 ログの取得（大分類4）: ファイアウォール、プロキシサーバ、認証サーバのログを6か月保管し、認証サーバのログは月1回以上モニタリングして不審な認証試行を検知すること。クラウドサービスの利用も対象

★3の段階ではログの6か月保管は求められていません。しかし、5-1-1-2で不審な事象を判断する際にはログやアラートの分析が前提になるため、使っている製品のログがどの期間まで参照できるかは★3の段階で確認しておくと、★4へ進む際の手戻りを防げます。ログの取得範囲と保存期間の考え方はSCS評価制度のログ管理要件で、★4全体の差分は★4で追加される17項目と72評価基準で整理しています。

必要になる証跡

大分類5は、製品が導入されていることの証跡と、運用が回っていることの証跡の両方が求められます。評価基準ごとに整理すると次のとおりです。

導入直後でアラートの実例がない場合は、テスト用の検知（製品ベンダーが提供する無害な検証ファイルや検証用URL）を使って発報から通知までの流れを確認し、その記録を証跡にする方法があります。設定画面のスクリーンショットには取得日を明記し、確認時点と設定が変わっていれば再取得します。

よくある質問

ウイルス対策ソフトが入っていれば5-1-1-1を満たせますか？

従来型のウイルス対策ソフトだけでは満たせない可能性が高いです。評価基準5-1-1-1が求めているのは、インターネットから社内への通信と社内から不正なサーバへの通信の双方について、不正アクセスをリアルタイムに検知し遮断する仕組みです。ファイルのマルウェアスキャンは大分類4の4-4-5（マルウェア感染からの保護）で評価される別の基準であり、通信の監視・遮断とは対象が異なります。端末側で満たす場合は、ネットワーク保護や不審な通信先への接続ブロック機能を持つEDR・次世代エンドポイント製品が候補になります。

オフィスを持たず全員リモートの会社はどう対応すればよいですか？

社内ネットワークの境界が存在しないため、UTMやファイアウォールではなく端末側で満たす構成が現実的です。評価基準5-1-1-1は「社内外ネットワークの境界または端末において」と定めており、端末での対応を認めています。全社の会社支給PCにEDRなどのエンドポイント製品を導入し、アラートを管理コンソールで集約して通知先を決めておけば、境界機器がなくても3つの評価基準に対応できます。

アラートを見る担当者が社内にいない場合はどうすればよいですか？

監視を外部に委託する選択肢があります。評価基準5-1-1-2は「担当者または管理者が不審な事象を発見した場合にインシデントに該当するかを判断する」ことを求めているため、一次的な監視と切り分けを外部のサービスに任せ、インシデント該当の最終判断と社内への報告を自社の担当者が行う分担にすれば要件に対応できます。委託する場合は、通知の宛先と判断の権限を契約や手順書に明記し、証跡として提示できる形にしてください。

★3の段階でログを6か月保管する必要はありますか？

いいえ。ファイアウォール・プロキシサーバ・認証サーバのログを6か月保管し、認証サーバのログを月1回以上モニタリングすることを求める「ログの取得」（4-4-3）は★4からの要求事項で、★3の評価基準には含まれていません。ただし、5-1-1-2で不審な事象を判断する際にはログやアラートの分析が前提になるため、使っている製品のログがどの期間まで参照できるかは★3の段階で確認しておくことをおすすめします。

まとめ

大分類5「攻撃等の検知」で★3が求めるのは、5-1-1の3つの評価基準です。インターネットから社内への通信と社内から不正なサーバへの通信の双方をリアルタイムに検知・遮断する仕組みを、境界（UTM・次世代ファイアウォール）または端末（EDR等）に導入し、アラートを人が判断し、速報レポートが通知される流れまでを作ります。

件数は3件でも、製品の導入が前提になるため、★3の中では費用と期間がかかる項目です。製品選定と並行して、アラートの通知先・判断者・報告の様式を決めることで、導入と同時に3基準をそろえられます。検知したあとの初動と報告の手順は大分類6の「インシデントへの対応」の要件で定めるため、通知先と判断者は両方の手順書で揃えてください。