【SCS評価制度★3徹底解説第6回】「攻撃等の検知」とは？ネットワーク監視・不審通信の検知・アラート対応を実務目線で解説

SCS評価制度★3の攻撃等の検知を解説するアイキャッチ画像。ネットワーク監視、不審通信の検知、アラート確認などの重要ポイントを表現

SCS評価制度★3の要求事項を、7つの分野に分けて解説する本連載。

第5回では「攻撃等の防御」をテーマに、ID・パスワード管理、アクセス権限、ソフトウェアのアップデート、マルウェア対策、ネットワーク境界の防護など、サイバー攻撃を受けにくくするための対策について解説しました。

しかし、どれだけ防御を強化しても、すべてのサイバー攻撃を完全に防ぐことは困難です。

フィッシングによって正規のID・パスワードを盗まれる場合もあれば、公開直後の脆弱性、委託先のアカウント、正規の遠隔操作ツールなどが攻撃に悪用される可能性もあります。

そのため、企業には「侵入させないための対策」だけでなく、侵入や異常が発生したときに、できるだけ早く気付くための対策が必要です。

そこで今回解説するのが、SCS評価制度★3の第5分野である「攻撃等の検知」です。

SCS評価制度の★3は、一般的なサイバー脅威に対処できる水準として位置づけられています。また、取得希望組織が要求事項・評価基準に基づいて自己評価を行い、その内容について、制度上の要件を満たすセキュリティ専門家の確認を受ける「専門家確認付き自己評価」が採用される予定です。

本記事では、SCS評価制度★3で求められるネットワーク監視、不審通信の検知・遮断、ログやアラートの分析、異常発生時の通知について、企業が実務上何を準備すべきかという観点から解説します。

前回までの連載記事

公式資料

IPA公式資料

IPAでは、SCS評価制度の要求事項・評価基準がExcel形式で公開されています。

IPA：SCS評価制度要求事項・評価基準
https://www.ipa.go.jp/security/scs/requirements-criteria.html
IPA：★3・★4 要求事項・評価基準 Excel
https://www.ipa.go.jp/security/scs/rcu1hd0000007a2i-att/20260327001-c.xlsx

また、IPAのページでは、★3・★4の要求事項・評価基準に関する解説書は2026年10月頃公開予定とされています。

経済産業省公式資料

経済産業省では、SCS評価制度の制度構築方針とあわせて、★3・★4の要求事項及び評価基準が公開されています。

経済産業省：「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」を公表しました
https://www.meti.go.jp/press/2025/03/20260327001/20260327001.html
経済産業省：サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針
https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_supply_chain/20260327_report.html
経済産業省：別添 ★3★4要求事項及び評価基準 Excel
https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_supply_chain/downloadfiles/20260327_3.xlsx
経済産業省：参考 ★3★4要求事項・評価基準参考文献 Excel
https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_supply_chain/downloadfiles/20260327_4.xlsx

なお、SCS評価制度は今後も解説書、取得ガイド、申請手続きなどの情報が追加・更新される可能性があります。

実際に★3取得を検討する際は、必ずIPAおよび経済産業省の最新情報を確認してください。

SCS評価制度★3における「攻撃等の検知」とは

攻撃等の検知」とは、社内ネットワークや情報機器で発生している通信を監視し、サイバー攻撃やマルウェア感染の可能性を示す不審な通信を発見するための取り組みです。

IPAが2026年4月21日に公開した「SCS評価制度 ★3・★4要求事項・評価基準」では、★3の「攻撃等の検知」に関する要求事項として、No.5-1-1「ネットワーク接続・データの監視」が示されています。

要求事項No.	要求事項名	主な内容
5-1-1-1	ネットワーク接続・データの監視	インターネットから社内への通信と、社内から不正なサーバーへの通信の双方について、不正アクセスをリアルタイムに検知・遮断する
5-1-1-2	ネットワーク接続・データの監視	ネットワーク機器のログとアラートを分析し、不審な事象がセキュリティインシデントに該当するか判断する
5-1-1-3	ネットワーク接続・データの監視	異常時にアラートを速やかに発報し、インシデントの速報レポートを作成・通知する

今回の「攻撃等の検知」に関する要求事項は、No.5-1-1「ネットワーク接続・データの監視」の1項目です。

ただし、評価基準には次の3つの要素が含まれています。

不正な通信をリアルタイムに検知・遮断する
ログやアラートを分析し、インシデントかどうか判断する
異常を速やかに通知し、速報レポートを作成する

つまり、UTMやファイアウォールなどの機器を導入するだけでは、要求事項への対応が完了するわけではありません。

検知・遮断・分析・判断・通知までを、一連の運用として機能させることが重要です。

1．外部から社内・社内から外部への不正通信を検知・遮断する

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

ここで重要なのは、監視対象が一方向だけではないという点です。

確認すべきなのは、次の双方の通信です。

インターネットから社内へ向かう通信
社内から不正な外部サーバーへ向かう通信

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

企業が従来から警戒してきたのは、インターネット側から社内ネットワークへ向かう攻撃です。

代表的なものとして、次のような通信が挙げられます。

VPN機器への不正ログイン
外部公開サーバーの脆弱性を狙った攻撃
ファイアウォールやルーターへの不正アクセス
公開されているポートへのスキャン
不審な送信元からの大量アクセス
ネットワーク機器の管理画面へのアクセス

UTM、次世代ファイアウォール、IDS・IPSなどには、こうした通信を検知・遮断する機能が備わっている場合があります。

ただし、機器を設置していても、必要な機能が無効になっていたり、セキュリティライセンスが失効していたりすれば、十分な効果は期待できません。

社内から不正な外部サーバーへの通信

もう一つ確認しなければならないのが、社内端末から外部へ向かう不審な通信です。

たとえば、社内のパソコンがマルウェアに感染すると、攻撃者が管理するサーバーへ接続する場合があります。

このような通信を検知・遮断できれば、攻撃者が感染端末へ指示を送ったり、社内情報を外部へ送信したりする活動を妨げられる可能性があります。

実務上は、次のような通信に注意します。

マルウェア感染端末から不正なサーバーへの通信
業務上利用していない国や地域への通信
業務に必要のない外部サービスへの継続的な接続
不審なドメインへのDNS問い合わせ
短時間に繰り返される外部接続
通常よりも大量のデータを外部へ送信する通信
深夜や休日など、通常とは異なる時間帯の通信

外部から入ってくる攻撃を遮断するだけでなく、侵入後に発生する内部から外部への通信も監視することが重要です。

現在の環境で何を検知できるか確認する

対策として利用できる製品やサービスには、次のようなものがあります。

UTM
次世代ファイアウォール
IDS・IPS
EDR
NDR
DNSフィルタリング
Webフィルタリング
セキュリティ監視サービス
マネージドセキュリティサービス

ただし、SCS評価制度では特定の製品を導入することが必須とされているわけではありません。経済産業省も、評価基準を満たすために特定のセキュリティ対策製品を導入しなければならない制度ではないと注意喚起しています。

製品名ではなく、次の事項を実現できているかを確認する必要があります。

必要な範囲の通信を監視できる
不正アクセスをリアルタイムに検知できる
必要に応じて不正通信を遮断できる
検知した内容をログとして確認できる
異常時に担当者へ通知できる

2．ネットワーク機器のログとアラートを分析する

2つ目の評価基準では、ネットワーク機器のログとアラートを分析し、不審な事象がセキュリティインシデントに該当するかを判断することが求められています。

ここで注意したいのは、ログを保存していることと、ログを確認・分析していることは異なるという点です。

ログを保存しているだけでは十分ではない

UTMやファイアウォールには、日々さまざまな通信ログやセキュリティアラートが記録されます。

しかし、実際の企業では次のような状態が少なくありません。

ログは保存されているが誰も確認していない
管理画面へ最後にログインした時期が分からない
アラートメールが大量に届くため読まれなくなっている
保守事業者しかログを確認できない
ログの見方が分かる担当者がいない
異常を見つけても次に何をすればよいか決まっていない

この状態では、機器が異常を検知していても、組織として攻撃に気付くことができません。

実務上は、次の事項を明確にしておく必要があります。

誰がログやアラートを確認するのか
どのようなアラートを確認対象とするのか
いつ、どの程度の頻度で確認するのか
不審な事象をどのように調査するのか
インシデントかどうかを誰が判断するのか
判断が難しい場合に誰へ相談するのか

すべてのアラートを同じように扱わない

セキュリティ機器からは、多数のアラートが発生する場合があります。

すべてのアラートを同じ緊急度で扱っていると、担当者の負担が大きくなり、本当に重要なアラートが埋もれる原因になります。

そのため、アラートの内容に応じて、優先順位を設定することが重要です。

緊急性が高い可能性があるものとしては、次のような事象が挙げられます。

マルウェア感染端末から不正なサーバーへの通信
管理者アカウントの不審な利用
同一端末から繰り返される不正通信
情報の外部送信が疑われる通信
ランサムウェア感染を示す挙動
VPNや公開サーバーへの不審なログイン成功

一方で、単発の外部スキャンや、機器によって正常に遮断された通信などは、直ちに重大インシデントとは限りません。

「重大」「高」「中」「低」などの基準を設け、重要度に応じて確認方法や報告先を変えることで、現実的な運用につなげられます。

インシデントかどうかを判断する

不審な通信を検知した場合は、次のような情報を確認します。

通信元となった端末
端末を利用していた従業員
通信先のIPアドレスやドメイン
通信が発生した日時
通信回数やデータ量
実行されていたソフトウェア
同じ端末で発生した他のアラート
同じ通信先へ接続した他の端末
業務上必要な通信かどうか

これらの情報を確認したうえで、

通常の業務通信である
誤検知の可能性が高い
マルウェア感染の疑いがある
直ちに端末を隔離する必要がある

といった判断を行います。

自社だけで判断することが難しい場合に備え、保守事業者や外部のセキュリティ専門家へ相談できる体制を準備しておくことも重要です。

3．異常時にアラートと速報レポートを通知する

3つ目の評価基準では、異常時にアラートを速やかに発報し、インシデントの速報レポートを作成・通知する仕組みが求められています。

異常を検知できても、その情報が担当者へ届かなければ、対応を始めることはできません。

通知先が現在も機能しているか確認する

実際の企業では、次のような問題が発生している場合があります。

退職した担当者のメールアドレスに通知されている
人事異動前の担当者だけに通知されている
通知メールが迷惑メールフォルダへ振り分けられている
通知先が担当者個人のアドレスだけになっている
夜間や休日の通知を誰も確認していない
通知が多すぎて重要なアラートが埋もれている
保守事業者には通知されるが、自社には通知されない

導入時には正しく設定されていても、人事異動や担当者の退職、メール環境の変更、保守契約の変更などによって、通知設定が機能しなくなることがあります。

そのため、設定画面を見るだけではなく、実際にテスト通知を発生させ、現在の担当者へ届くか確認する必要があります。

担当者一人だけに依存しない

担当者一人だけに通知する運用では、その担当者が休暇中や外出中の場合に対応が遅れる可能性があります。

実務上は、次のような通知先を組み合わせることが考えられます。

セキュリティ担当者の共有メールアドレス
情報システム部門の複数担当者
部門責任者
外部の保守事業者
セキュリティ監視事業者
重大時に報告する経営層
社内チャットやチケット管理システム

通知先を増やすだけでなく、次の役割も決めておきます。

最初にアラートを確認する担当者
インシデントかどうか判断する責任者
端末隔離などの対応を指示する担当者
経営層や関係部門へ報告する担当者
外部事業者へ連絡する担当者

速報レポートに記載する内容

速報レポートは、すべての調査が完了した後に作成する最終報告書ではありません。

異常の発生を早期に共有し、初動対応の判断につなげるための資料です。

速報レポートには、次のような項目を記載します。

検知日時
検知した機器またはサービス
アラート名
アラートの重大度
通信元の端末やIPアドレス
通信先のIPアドレスやドメイン
検知された通信の概要
通信が遮断されたかどうか
影響が疑われる端末やシステム
現時点で判明している内容
実施済みの初動対応
今後確認すべき事項
担当者と連絡先

外部の監視サービスを利用している場合は、どのような条件で速報レポートが作成され、誰へ通知されるのかも確認しておきましょう。

「攻撃等の検知」で重要なのは製品ではなく運用

SCS評価制度★3の「攻撃等の検知」では、UTM、ファイアウォール、EDRなどの製品が重要な役割を果たします。

しかし、製品を導入したこと自体が対策の目的ではありません。

UTMを導入していても、次のような状態であれば十分に機能しているとはいえません。

不正侵入検知・防御機能が無効になっている
脅威情報を更新するライセンスが失効している
社内から外部への不審な通信を確認できない
アラートの通知設定が行われていない
通知先が現在の担当者と一致していない
ログを確認する担当者が決まっていない
異常を検知しても判断できる担当者がいない
異常発生後の対応手順が決まっていない

EDRについても同様です。

アラートを検知する機能があっても、誰も内容を確認せず、必要な対応へつなげられなければ、導入効果は限定的です。

重要なのは、次の流れが実際に機能することです。

異常を検知する
↓
不正な通信を遮断する
↓
ログやアラートを確認する
↓
インシデントかどうか判断する
↓
必要な担当者へ通知する
↓
初動対応を開始する

製品導入ではなく、この運用全体を整えることが「攻撃等の検知」への対応です。

24時間365日の監視体制が必須なのか

すべての中小企業が、自社で大規模なSOCを構築し、専任担当者を24時間365日配置することは現実的ではありません。

その場合は、次のような方法を組み合わせることが考えられます。

UTMなどによる自動検知・遮断
重大なアラートの自動通知
外部監視サービスの利用
保守事業者による一次確認
自社担当者による定期的なログ確認
重大時に外部専門家へ相談する体制
夜間・休日の連絡ルールの整備

重要なのは、自社の規模やリスクに合わせて、重大な異常が放置されない仕組みを構築することです。

外部へ監視を委託する場合でも、端末の隔離、アカウントの停止、業務の継続・停止などについては、自社側の判断が必要になる場合があります。

自社と委託先の役割分担を明確にしておきましょう。

攻撃者の目線から考えると「侵入後に気付ける環境」が効く

攻撃者にとって都合がよいのは、組織内部へ侵入した後も、長期間にわたって誰にも気付かれない環境です。

攻撃者は、組織内部へ侵入すると、すぐにランサムウェアを実行するとは限りません。

侵入後に、次のような活動を行う場合があります。

ネットワーク構成を調査する
重要なサーバーや端末を探す
管理者権限の取得を試みる
他の端末へ侵入する
バックアップの保存場所を確認する
機密情報や個人情報を探す
情報を外部へ送信する
再侵入するための経路を確保する

攻撃者が自由に活動できる時間が長いほど、被害が拡大する可能性も高くなります。

一方、不審な通信を早期に発見し、

通信先を遮断する
端末をネットワークから隔離する
不審なアカウントを停止する
関係する端末やサーバーを調査する

といった対応を行えば、攻撃者の活動を途中で止められる可能性があります。

セキュリティ対策では、「絶対に侵入させないこと」だけを目標にするのではなく、侵入された場合でも早期に気付き、被害の拡大を防げる状態をつくることが重要です。

SCS評価制度★3への対応は、現在の環境確認から始める

「攻撃等の検知」への対応を進める際に、最初から新しい製品を購入する必要があるとは限りません。

まずは、現在利用している機器、サービス、設定、契約内容、運用体制を確認しましょう。

1．インターネットとの接続点を確認する

最初に、自社のネットワークがどこでインターネットと接続しているかを確認します。

本社だけでなく、次の環境も対象にします。

支店や営業所
工場
VPN接続
リモートアクセス環境
クラウドサービス
データセンター
委託先とのネットワーク接続
インターネットへ直接接続する端末

ネットワーク構成を把握できていなければ、どこで通信を監視すべきか判断できません。

第4回で解説した「リスクの特定」と、今回の「攻撃等の検知」は密接に関係しています。

2．現在の機器とサービスを確認する

次に、現在利用している機器やサービスを一覧にします。

メーカー名と製品名
設置場所
管理担当者
保守事業者
ライセンスの有効期限
有効になっているセキュリティ機能
ログの保存期間
アラートの通知先
管理画面へアクセスできる担当者

新しい製品を購入する前に、既存の機器で利用できる機能を確認することが重要です。

3．検知・遮断できる通信を確認する

現在の環境で、次の通信を検知・遮断できるか確認します。

外部から内部への不正アクセス
内部から不正な外部サーバーへの通信
マルウェア感染が疑われる通信
不審なWebサイトへの通信
不審なDNS通信
VPNへの不正ログイン
公開サーバーへの攻撃

設定内容が分からない場合は、保守事業者やセキュリティ事業者へ確認しましょう。

4．ログとアラートの確認体制を決める

次の事項を明確にします。

一次確認担当者
担当者不在時の代理者
判断を行う責任者
外部の相談先
重大度ごとの対応方法
夜間・休日の対応方針
確認結果の記録方法

5．通知設定を確認する

設定画面に登録されているメールアドレスを見るだけではなく、テスト通知を実施します。

実際に現在の担当者へ通知が届き、内容を確認できることを確認しましょう。

6．異常検知後の対応へつなげる

異常を検知した後は、必要に応じて次の対応を行います。

端末をネットワークから隔離する
不審な通信先を遮断する
アカウントを停止する
パスワードを変更する
関係端末を調査する
経営層へ報告する
外部専門家へ相談する
取引先や関係機関へ連絡する

この部分は、次回解説する「インシデントへの対応」につながります。

★3対応では「設定」と「運用記録」の両方が必要

SCS評価制度★3では、取得希望組織が作成した自己評価について、制度上の要件を満たすセキュリティ専門家が書類を確認します。

そのため、「UTMを導入しています」「ログを確認しています」と口頭で説明するだけではなく、実際の設定や運用を説明できる資料を整理しておくことが重要です。

「攻撃等の検知」に関しては、次のような資料が考えられます。

ネットワーク構成図
インターネット接続点の一覧
UTMやファイアウォール等の一覧
セキュリティ機能の設定画面
ライセンスの有効期限が分かる資料
ログやアラートの画面
アラート通知先の設定
テスト通知の実施記録
ログやアラートの確認記録
不審な事象を判断した記録
速報レポートのサンプル
異常検知後の連絡先一覧
保守事業者との役割分担
インシデント対応手順書

重要なのは、資料を大量に作成することではありません。

実際に行っている対策と、自己評価に記載する内容を一致させることが大切です。

「攻撃等の検知」でよくある不備

1．UTMを設置しただけで対応済みと判断している

UTMを設置していても、必要な機能が無効になっていたり、ライセンスが失効していたりすれば、十分な監視はできません。

2．外部からの攻撃だけを監視している

インターネットから社内への通信だけでなく、社内から不正な外部サーバーへの通信も監視する必要があります。

3．ログを保存しているだけで分析していない

ログが保存されていても、誰も内容を確認していなければ、攻撃の兆候を発見できません。

4．アラートを確認する担当者が決まっていない

担当者が曖昧なままでは、重大なアラートが発生しても、誰も対応しない可能性があります。

5．通知先が古いままになっている

退職者や異動前の担当者へ通知されていると、異常の発見が遅れる原因になります。

6．アラートが多すぎて確認されていない

通知件数が多すぎる場合は、重大度に応じて通知条件や確認方法を整理する必要があります。

7．保守事業者へ任せきりにしている

保守事業者が一次確認を行う場合でも、端末隔離や業務停止などの意思決定は、自社で行わなければならないことがあります。

8．アラート発生後の対応が決まっていない

異常を検知しても、誰へ報告し、何を調査し、どの端末を隔離するのかが決まっていなければ、初動対応が遅れます。

9．設定や確認結果の記録を残していない

実際に運用していても、記録が残っていなければ、自己評価や専門家確認の際に説明することが難しくなります。

「攻撃等の検知」セルフチェック

現在の対応状況について、次の項目を確認してみましょう。

インターネットとの接続点を把握している
ネットワーク構成図が最新の状態になっている
外部から社内への不正通信を検知・遮断できる
社内から不正な外部サーバーへの通信を検知・遮断できる
UTMやファイアウォール等の必要な機能が有効になっている
セキュリティライセンスの有効期限を確認している
ネットワーク機器のログやアラートを確認している
ログやアラートを確認する担当者が決まっている
不審な事象がインシデントかどうかを判断できる
判断が難しい場合の相談先が決まっている
重大なアラートが速やかに通知される
現在の担当者へ通知が届くことを確認している
担当者不在時の代理者が決まっている
インシデントの速報レポートを作成・通知できる
異常検知後の連絡・初動手順が決まっている
設定や運用状況を説明できる記録を残している
保守事業者や監視事業者との役割分担が明確になっている

対応できていない項目が多い場合でも、直ちに高額な製品を購入する必要があるとは限りません。

まずは、現在利用している機器、契約、設定、担当者、通知先を整理し、既存の環境で何ができるのかを確認することから始めましょう。

まとめ

SCS評価制度★3の「攻撃等の検知」では、次の対応が求められます。

外部から社内への不正通信をリアルタイムに検知・遮断する
社内から不正な外部サーバーへの通信をリアルタイムに検知・遮断する
ネットワーク機器のログやアラートを分析する
不審な事象がインシデントかどうかを判断する
異常時にアラートを速やかに発報する
インシデントの速報レポートを作成・通知する

重要なのは、高価なセキュリティ製品を導入することではありません。

自社のネットワークで異常が発生したときに、それを検知し、担当者が気付き、インシデントかどうかを判断し、次の対応へつなげられる状態をつくること

これが「攻撃等の検知」の本質です。

UTM、ファイアウォール、EDR、セキュリティ監視サービスなどは、そのための手段です。

製品を導入したことをゴールにせず、

現在の設定で何を検知できるのか
アラートは誰に届くのか
届いたアラートを誰が判断するのか
重大な場合にどのように対応するのか

を確認する必要があります。

SCS評価制度への対応をきっかけに、自社が本当に異常へ気付ける状態になっているか、改めて確認してみてはいかがでしょうか。

SCS評価制度★3への対応でお困りではありませんか

株式会社クロイツでは、SCS評価制度への対応を、単なるチェックリストへの回答やセキュリティ製品の導入で終わらせるのではなく、企業が実際に継続できる運用として整備することを重視しています。

「攻撃等の検知」に関しては、次のような支援が可能です。

SCS評価制度★3要求事項に対する現状確認
未対応項目や課題の整理
ネットワーク構成やインターネット接続点の確認
UTMやファイアウォール等の運用状況の確認
セキュリティ機能や通知設定の確認
通信ログやアラートの確認
ログ確認方法や判断基準の整理
異常時の連絡体制の整備
速報レポートや確認記録の様式作成
インシデント対応手順書の整備
サイバーBCPの策定
従業員向けセキュリティ教育
継続的なログ確認・脆弱性情報の提供
セキュリティ以外を含むIT運用相談

弊社には、情報処理安全確保支援士およびCISSPの資格を有するセキュリティ専門家が在籍しています。

制度上の形式を整えるだけではなく、実際の攻撃者から見て、現在の環境にどのような弱点があるのかという視点も踏まえ、企業の規模や環境に合った対策を検討します。

「現在のUTMで要求事項に対応できるのか分からない」

「ログは保存されているが、誰も確認できていない」

「アラートが届いた後の対応が決まっていない」

「★3取得に向けて、何から始めるべきか整理したい」

「新しい製品を購入する前に、現在の環境を確認してほしい」

このようなお悩みがございましたら、株式会社クロイツまでご相談ください。

現在の機器や契約をすべて入れ替えることを前提とせず、既存環境を確認したうえで、必要な対策を優先順位順に整理します。

お問い合わせ

次回予告

次回の連載第7回では、SCS評価制度★3の第6分野、「インシデントへの対応」を解説します。

サイバー攻撃を検知できても、

誰が最初に対応するのか
端末をどのように隔離するのか
誰へ報告するのか
どの外部組織へ相談するのか
どのような記録を残すのか

が決まっていなければ、被害が拡大する可能性があります。

次回は、SCS評価制度★3で求められるインシデント対応手順、社内外の連絡体制、役割と責任、報告様式などを、実際の企業運用を意識しながら解説します。

【SCS評価制度★3徹底解説 第6回】「攻撃等の検知」とは？ネットワーク監視・不審通信の検知・アラート対応を実務目線で解説