第14回:SCS★3の要求事項を読む⑨――「攻撃等の検知」リアルタイム検知・ログ分析・アラート通知の3つの評価基準

作成日: 2026-06-29


はじめに

「攻撃を検知したら速やかに対応する——では、その”速やか”はどれくらい?」

セキュリティの文書には「速やかに」という言葉がよく出てきます。ただ、この言葉が実際にどれくらいの速さを意味するのか、具体的なイメージを持てている方は少ないのではないかと思います。

私自身、自社でゼロデイ脆弱性(発見された時点では対応方法がない脆弱性)を攻撃されたことがありました。脆弱性情報が公開されてすぐに情報をキャッチして、翌日にメーカーから出てきた暫定対応を実施し、24時間以内には対応できたのですが——それでも攻撃者はすでに不正アクセスしていました。「速やかに」とは、とてもシビアで人間が対応するのは限界に近づいていると思います。そのため、AIを使った自動防御が期待されています。

今回は大分類「攻撃等の検知」を確認します。私がこの連載の中で一番技術的に難しいと感じている大分類です。要求事項は1つ・評価基準は3つとコンパクトですが、内容は決して軽くありません。


「攻撃等の検知」今回の全体像

今回確認するのは、1つの要求事項・3つの評価基準です。

NO要求事項評価基準の数
5-1-1ネットワーク接続・データの監視3つ

なお、5-1(継続的監視)にはもう1つの要求事項として5-1-2(情報機器及びソフトウェアの挙動監視)がありますが、こちらは★4のみの要求事項です。★3と★4で何が違うかにも触れようと思います。


1. 5-1-1 ネットワーク接続・データの監視(評価基準3つ)

5-1-1は、ネットワーク上でサイバー攻撃をリアルタイムに検知・分析・通知する仕組みを求める要求事項です。評価基準は以下の3つです。

  1. 5-1-1-1: 社内外ネットワークの境界または端末において、インターネットから社内への通信・社内から不正なサーバへの通信の双方について、不正アクセスをリアルタイム検知・遮断する仕組みを導入すること
  2. 5-1-1-2: ネットワーク機器のログ・アラートを分析し、セキュリティ担当部署の担当者または管理者により不審な事象が発見された場合に、それがセキュリティインシデントに該当するかが判断されること
  3. 5-1-1-3: 5-1-1-1で設置したネットワーク機器またはサービスについて、アラートが速やかに発報されること、インシデントの速報レポートが作成・通知されることの要件を満たす異常時通知の仕組みを導入すること

前回(第12回・第13回)で確認した防御の要求事項とつながっていることがわかると思います。第12回で「ファイアウォールを設置して通信制御ルールを定める」という要求事項を確認しましたが、今回の5-1-1はその続きとして「設置したファイアウォールやネットワーク機器のログを実際に見て、攻撃を検知する」ことが求められています。防御の仕組みを入れただけでは不十分で、ちゃんと運用しなければならない——まさにその運用の核心がこの要求事項です。

第12回:SCS★3の要求事項を読む⑦――「攻撃等の防御③」プラットフォームとネットワーク境界防護の15の評価基準


「速やかに」の難しさ

5-1-1-3でアラートを「速やかに」発報することが求められていますが、冒頭の実話が示す通り、攻撃者の動きは非常に速いです。ゼロデイ攻撃に限らず、標的型攻撃では侵入から情報窃取まで数時間〜数日というケースもあります。

「速やかに」を実現するためには、24時間365日体制でネットワークを監視する仕組みが必要になります。自社の社員でこの品質を維持しようとすると、夜間・休日も対応できる体制を作ることになり、現実的ではありません。これが、この要求事項で外部の専門家や専門会社の支援を検討してほしい最初の理由です。


「ログの分析」の難しさ

5-1-1-2でログ・アラートを「分析」することが求められていますが、これも簡単ではありません。

インフラの運用とセキュリティの運用には、見つけようとするものが根本的に異なるという違いがあります。インフラ運用では、障害の予兆や発生を検知するためにエラーを探します。一方、セキュリティ運用では、正常に見える通信の中に攻撃が隠れていることがあるため、「正常の中の異常」を探す必要があります。

具体例を出すと、ある端末の通信量が急に増えたとします。エラーは何も出ていない。ただ、通信量が普段と違う——これがマルウェアに感染して外部に情報を送り続けているサインだった、ということがあります。エラーを探すだけの運用では、こういったケースは見つかりません。

もちろん、パスワードを繰り返し試行して認証エラーが多発することで気づく、というケースもあります。ただ、「正常の中から攻撃の予兆を見つけ出す」という視点を持って運用することは、インフラ担当者にとってはなかなか難しいスキルの転換が必要です。


★3と★4で何が変わるか

★3で求められているのは「ネットワークの監視」です。社内外の通信を見て、不審な通信を検知・遮断するという、ネットワークの出入口を見張る仕組みです。

★4になると、5-1-2「情報機器及びソフトウェアの挙動監視」が追加されます。これは端末の中の動きも監視するという要求で、EDRのような「端末の挙動を監視するツール」の活用が念頭にあります。

まとめると、以下のような対比になります。

★3★4
監視の対象ネットワーク(通信の出入口)ネットワーク+端末の内部
主なツールFW・UTMなどのログ分析FW・UTM+EDR
難しさ通信の分析スキルが必要さらに端末の挙動分析も必要

★3の段階でもすでに難易度は高いですが、★4ではさらに一段上の監視体制が求められています。段階的にステップアップしていく制度の設計がここにも表れています。


外部の専門家・専門会社への相談を検討してほしい理由

脆弱性対応(第12回)、ネットワーク境界防護(第12回)、そして今回の検知と、外部の専門家や専門会社の支援を検討してほしい要求事項が続いています。費用が心配になってくる方もいると思います。

ただ、これらの要求事項はつながっています。ネットワーク機器の導入・設定・運用・脆弱性管理・ログ監視・アラート対応をバラバラに別々の会社に依頼するより、これらをまとめてワンパッケージで提供できるベンダーに依頼するほうが、コスト面でも管理面でも効率的です。

さらに言えば、ネットワーク側の監視だけでなく、端末側の分析(EDRの活用)やアラートが出たときの対応(初動調査・影響範囲の確認)まで含めてパッケージにすると、より実践的な体制になります。「アラートが出たけど何をすればいいかわからない」という状態では、せっかく検知できても意味がありません。

こういった相談ができるベンダーの一覧をIPAが掲載しています。ぜひ参考にしてみてください。

→ IPA 中小企業向けサイバーセキュリティ対策相談窓口(おたすけ隊)

 https://www.ipa.go.jp/security/sme/otasuketai/index.html


まとめ

今回の「攻撃等の検知」は、ツールを入れるだけでは実現できず、24時間365日の運用体制と、ログを分析して攻撃を見つけ出すスキルが必要になります。

自社だけで対応しようとするのが難しい場合は、外部の専門家・専門会社への相談を検討してみてください。


このブログが目指していること

私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。

その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。

「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。


次回の予告

次回は6つ目の大分類「インシデント管理」を確認します。いよいよ終わりに近づいてきました。


相談してみませんか?

「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。

→ このブログについて → お問い合わせはこちら(メール)

なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。

→ サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html


CISSP・情報処理安全確保支援士 | けい

コメント

タイトルとURLをコピーしました