【SCS評価制度】防げなかった攻撃に、どう気づくか
SCS評価制度の大分類5「攻撃等の検知」
「検知」で本質的に求められるものとは
SCS評価制度の大分類5「攻撃等の検知」で本質的に求められているのは、監視ツールを導入するだけでは不十分です。
導入したツールが実際にアラートを発し、そのアラートを人が受け取り、「これはインシデントなのか」を判断できる状態まで、一連の仕組みとして機能しているかどうかが問われます。
はじめに
前回の記事「防御」では、教育・データ・プラットフォーム・ネットワークという4つの領域を、個別の対策ではなく「面」として設計する重要性について解説しました。しかし、どれだけ防御を強化しても、攻撃を100％防ぐことはできません。
ゼロデイ脆弱性の悪用や設定ミス、従業員の操作ミスなど、防御をすり抜ける要因は必ず存在します。そのため、現代のセキュリティでは「侵入させないこと」だけでなく、「侵入されたことにいち早く気付き、被害を最小限に抑えること」が重要になっています。
「アラートが届く仕組みがある」ことと、「本当に異常に気付き、適切に判断し、迅速に対応できる」ことは別の話です。
実際には、アラートが大量に発生して重要なものが埋もれてしまったり、担当者が内容を判断できなかったり、休日や夜間に誰も気付かなかったりといったケースは珍しくありません。
SCS評価制度が大分類5「攻撃等の検知」で求めているのは、単に監視ツールを導入することではなく、異常を継続的に監視し、適切なタイミングで気付き、対応につなげられる仕組みを構築することです。
防御と検知は、求められる役割が異なる
一昔前のセキュリティ対策は、「侵入させないこと」が中心でした。ファイアウォールやアンチウイルスソフトを導入し、境界を守れば十分だと考えられていた時代です。
しかし現在は、クラウドサービスの利用拡大やテレワークの普及、サプライチェーンとのシステム連携などにより、企業を取り巻く環境は大きく変化しました。さらに、ゼロデイ攻撃や正規アカウントの悪用など、防御を回避する攻撃手法も高度化しています。
こうした状況では、「侵入を完全に防ぐ」という考え方だけでは十分ではありません。
重要なのは、侵入の有無を継続的に監視し、異常をできるだけ早く発見して対応につなげることです。
この考え方から、近年のセキュリティ対策は「防御」と「検知」を別々の役割として考えるようになりました。
SCS評価制度でも同様に、大分類4では攻撃を受けにくくするための対策を求める一方、大分類5では「攻撃等の検知」を独立した項目として位置付けています。
これは、「防御が十分だから検知は不要」という関係ではなく、防御と検知は互いを補完する役割だからです。防御によって攻撃の成功率を下げ、検知によって侵入後の被害を最小限に抑える。この両方がそろって初めて、組織全体のセキュリティレベルを高めることができます。
5-1-1：ネットワーク接続・データの監視 ― 「ログを取る」から「異常に気付く」へ
5-1-1（ネットワーク接続・データの監視）は、大分類5の中でも★3から求められる、検知の土台となる要求事項です。
企業では、ファイアウォールやUTM、EDRなどから日々大量のログやアラートが出力されています。しかし、それらを保存しているだけでは、攻撃を検知しているとは言えません。
SCS評価制度が求めているのは、社内外の通信や端末の通信を継続的に監視し、インターネットからの不正アクセスだけでなく、侵害された端末が外部の不正サーバへ通信するような挙動もリアルタイムで検知・遮断できる仕組みです。
さらに重要なのは、検知した後の運用です。アラートが発報された際に、必要な情報が担当者へ迅速に通知され、その内容を分析し、「本当に対応が必要な事象なのか」を判断できる体制まで含めて、検知の仕組みとして機能していることが求められます。
つまり、「監視ツールを導入している」ことではなく、「異常を見逃さず、対応につなげられる状態」であることが重要なのです。
5-1-2：ハードウェア及びソフトウェアの挙動監視 ― 正常な状態を定義する
★4では、5-1-2: ハードウェア及びソフトウェアの挙動監視が追加されます。
ここで重視されるのは、「何が異常か」を判断するために、まず「何が正常か」を明確にすることです。
具体的には、会社支給端末で利用を許可するソフトウェアを定め、それ以外のソフトウェアを自由にインストールできないようルールを整備すること、さらに実際のインストール状況を年1回以上点検することが求められます。また、外部から受け取ったファイルについても、リアルタイムスキャンやサンドボックスなどを活用し、安全性を確認する仕組みが必要です。
これは、「危険なものだけを止める」というブラックリスト型の考え方ではなく、「許可したもの以外は異常として扱う」というホワイトリスト型の考え方に近いアプローチです。
未知のマルウェアや新しい攻撃手法は次々に登場します。だからこそ、既知の脅威だけを探すのではなく、通常とは異なる挙動そのものを検知できる環境を整備することが重要になります。
5-2-1：セキュリティインシデントの対象範囲 ― 判断基準をあらかじめ決めておく
監視によって異常を検知できても、それだけでは十分ではありません。
その事象が本当にセキュリティインシデントなのか、どの程度の重要度なのかを判断できなければ、適切な対応にはつながらないためです。
そこで★4では、5-2-1: セキュリティインシデントの対象範囲が求められます。
この項目では、どのような事象をセキュリティインシデントとして扱うのか、また、その重要度をどのように分類するのかをあらかじめ定義し、役員・従業員・派遣社員・受入出向者へ周知しておくことが求められています。
例えば、「海外からの管理者ログイン」「深夜の大量ダウンロード」「マルウェアの検知」といった事象でも、組織によって優先度は異なります。判断基準が曖昧なままでは、本来すぐ対応すべきアラートと、経過観察でよいアラートが混在し、重要なインシデントを見逃す原因になりかねません。
つまり、検知とはアラートを出すことではなく、適切な判断につなげる仕組みまで含めて初めて成立すると言えます。
★3と★4で広がる「検知」の考え方
ここまで見てきたように、★3では、主にネットワーク通信を監視し、不正アクセスや異常な通信を検知する仕組みが求められます。
一方、★4では、監視対象がネットワークだけでなく端末上のソフトウェアの挙動へと広がり、さらに、検知した事象をどのように評価し、対応につなげるかという運用面まで要求事項に含まれます。
つまり、★3が「異常を見つける仕組み」の整備であるのに対し、★4では「異常を正しく判断し、組織として対応する仕組み」の整備へと発展していきます。
これは、大分類5が単なる監視機能の導入ではなく、継続的に異常を把握し、適切な初動対応につなげる運用体制を重視していることを表していると言えるでしょう。
検知の仕組みは、運用して初めて機能する
私たちがセキュリティ対策をご支援する中でよく見られるのが、監視ツールを導入した当初はアラートを確認できていたものの、時間の経過とともに運用が形骸化してしまうケースです。
例えば、日々大量のアラートが発生し、担当者が一つひとつ確認しきれなくなると、「いつものアラートだから」と見過ごされるようになります。いわゆる「アラート疲れ（Alert Fatigue）」です。
また、ログを取得していても、定期的に確認する運用がなければ、異常の兆候を見逃してしまいます。さらに、インシデントが発生してから調査を始めようとしても、必要なログが保存期間を過ぎていたり、必要な情報が取得されていなかったりして、原因を十分に追跡できないケースも少なくありません。
こうした状況では、監視ツールを導入していても、「検知」は十分ではありません。
SCS評価制度が求めているのは、監視製品やログ収集基盤を導入することではなく、異常を継続的に監視し、適切に判断し、対応へつなげられる運用体制を維持することです。
そのためには、アラートのチューニングによる誤検知の削減、ログの保存期間や取得項目の定期的な見直し、監視手順や対応フローの整備など、運用そのものを継続的に改善していくことが欠かせません。
検知は、一度仕組みを構築すれば終わるものではありません。「異常を見つける仕組み」と「異常に対応できる運用」が両立して初めて、組織のセキュリティ対策として機能するのです。
おわりに
防御と同様に、検知も「製品を導入すること」が目的ではありません。
監視ツールやEDRを導入していても、アラートを分析する体制が整っていなかったり、インシデントを判断する基準が曖昧だったりすれば、本当に対応すべき事象を見逃してしまう可能性があります。
SCS評価制度が大分類5で評価しているのも、監視製品の有無ではなく、異常を継続的に監視し、適切に判断し、迅速な対応につなげられる仕組みが機能しているかという点です。
自組織の検知対策が、「アラートを出す仕組み」で止まっていないか、そして実際に異常へ気付き、対応につなげられる運用になっているか、この機会にあらためて確認してみてください。
次回は、大分類6「SOC・CSIRT」について解説します。検知した後に、誰が判断し、誰が対応するのか。被害を最小限に抑えるために欠かせない、インシデント対応体制について見ていきます
