【SCS評価制度】限られた担当者でインシデントにどう対応していくのか
- 2 日前
- 読了時間: 7分
SCS評価制度の大分類6「インシデントへの対応」
「インシデントへの対応」で本質的に求められるものとは
SCS評価制度の大分類5「攻撃等の検知」で本質的に求められているのは、必ずしもSOCやCSIRTなどの専任のチームや部門を新設することではありません。
セキュリティインシデントが起きたときに、「誰が」「何を」「どの順番で」動くのかが、あらかじめ言語化、資料化されているかどうかが問われます。
はじめに
前回の記事「攻撃の検知」では、防御をすり抜けられることを前提に、「気づける仕組み」を持つことの重要性を解説しました。しかし、気づけたとしても、その先に「どう動くか」が決まっていなければ、現場は混乱するだけで終わってしまいます。
お客様に「セキュリティ事故が起きたときに対応するための体制をどのようにしているか」と伺うと、「うちは情シスが一人しかいないし、そんな専門チームは作れない」とお聞きすることがあります。
この感覚は、決して的外れではありません。SCS評価制度の要求事項を読むと、「役割・責任を定める」「セキュリティを統括する役員の役割を定める」といった記載があり、まるで組織図に複数のポジションを用意しなければならないように見えるかもしれません。
しかし実際に求められているのは「大きな組織を作ること」ではなく、「大きなチームでなくとも、有事に迷わず動けるように、あらかじめ決めておくこと」ということです。
限られた担当者であるからこそ、有事の動き方を事前に決めておくことでインシデントの影響を最小限にすることが可能となります。
検知の先にある「対応」という第二のハードル
前回の記事で扱った大分類5「攻撃等の検知」は、「異常に気づけるか」という要求事項でした。大分類6「インシデントへの対応」は、その先にある「気づいた後、実際に動けるか」ということを重視しています。
どんなに高度な監視ツールがアラートを発しても、それを受け取った人が「これは何をすべき事象なのか」「誰に連絡すればいいのか」を判断できなければ、検知はただの通知で終わってしまいます。特に少ない担当者の環境では、アラートを受け取るのも、初動対応をするのも、経営層への報告をするのも、すべて同じ人が担うことになりがちです。だからこそ、「その場で考える」のではなく、「あらかじめ決めておく」ことの価値が大きくなります。
6-1-1：インシデント対応手順に必要な要素—「役割」は複数人でなくてもいい
6-1-1（インシデント対応手順）では、セキュリティインシデントへの対応手順と対応体制を定めることが求められます。具体的には、次のような内容が含まれます。
発見報告・初動・調査対応・復旧・最終報告という一連の対応手順
セキュリティインシデントの判断基準と、発生時に連絡すべき社内外の連絡先・ルート（関係当局や所管省庁への報告を含む）
セキュリティを統括する役員及びセキュリティ担当部署の役割・責任
この体制について、年1回以上の頻度で点検すること
インシデントの報告フォーマットの整備
インシデント事例とその対応策を、年1回以上または重大インシデント発生時に社内へ共有すること
「セキュリティを統括する役員」「セキュリティ担当部署」という表現は、必ずしも”専任の役員や部署を新設しなければならない”という意味ではありません。中小企業であれば、社長自身が有事の最終意思決定者となり、情シス担当者が実務上の初動対応者を兼ねる、という体制でも構いません。重要なのは、役職の数ではなく、「誰が何を判断し、誰が実際に手を動かすのか」が、平時のうちに明確になっていることです。
「対応するのは結局自分しかいない」という場合においても、それが文書として整理されていない状態は多くあります。この場合、頭の中では分かっているつもりでも、実際にインシデントが発生し、動揺している最中に、判断基準や連絡先を一から思い出そうとするのは、想像以上に困難です。6-1-1が求めているのは、まさにこの「思い出す」という負担を、平時のうちに取り除いておくことだと言えます。
自組織対応か、外部委託か—ひとりで全部抱え込む必要はない
インシデント対応手順を整備する中で、ひとり情シスの方が必ず直面するのが、「調査・対応のフェーズを、本当に自分一人でできるのか」という壁です。マルウェアの解析や、被害範囲の特定といった専門的な調査は、片手間でできるものではありません。
ここで重要なのは、6-1-1が「すべてを自組織で完結させること」を求めているわけではありません。
「ここまでは自社で確認する」
「ここから先は保守会社に連絡する」
「重大な事故の場合はセキュリティの専門会社へ相談する」
など、対応手順の中に、外部のセキュリティベンダーやインシデントレスポンス専門の事業者への連絡ルートを組み込んでおくことが重要です。中小企業では社内だけで十分なセキュリティ人材を確保することが難しいため、IPAでも必要に応じて外部の専門家や支援サービスを活用できるよう、中小企業向けの支援策を案内しています。
大切なのは、「自分が対応できる範囲と、外部に頼るべき範囲の境界線を、あらかじめ引いておくこと」です。この境界線が事前に決まっていれば、有事の際に「誰に、いつ、何を頼むか」で迷うことなく、インシデントの被害を最小限にすることが可能です。
社員にも「事故が起きたらどうするか」を伝えておく
インシデントは、監視ツールが検知することもありますが、日々パソコンを操作している一般の社員の気づきにより発覚することも多くあります。「見慣れないメールの添付ファイルを開いてしまった」「PCの動きが急に重くなった」「身に覚えのないポップアップが表示された」――こうした違和感に最初に気づくのは、現場の社員自身であることがほとんどです。
ここで問題になるのが、社員がその違和感を「誰に、どう伝えればいいか」を知らない、という状態です。情シス担当者が限られている環境では特に、社員から見て情シス担当者がどこまで頼っていい相手なのか分かりにくかったり、「こんな些細なことで連絡していいのだろうか」とためらわれたりして、報告が遅れてしまうことがあります。6-1-1が求める「セキュリティインシデントの基準並びに連絡先及びルートを定めること」は、実際に最初の異変に気づく可能性が最も高い、現場の社員にまで伝わることが非常に重要です。
このとき大切なのは、複雑な判断を社員に求めないことです。「これはインシデントかどうか自分で見極めてから連絡する」というハードルを課してしまうと、判断に迷った社員は連絡をためらい、対応が遅れます。そうではなく、「怪しいと思ったら、まず情シス担当（または決めた連絡先）に一報する」という、判断を要さないシンプルなルールとして周知することが重要です。
朝礼や社内チャットで一言周知する、あるいは「怪しいと思ったらまずここに連絡」という一枚の案内を掲示するだけでも、十分に効果があります。限られたリソースだからこそ、自分一人がすべてを監視するのではなく、社員全員を“センサー”として活用する発想が、限られたリソースを補う現実的な一手になります。
おわりに
検知した後に「誰が、どう動くか」までは言語化されておらず、いざという時に現場の判断に委ねられてしまう状態になっているケースは多くあります。
限られている担当者であるからこそ、判断基準・連絡先・外部委託先といった要素をあらかじめ整理しておくことで、限られたリソースの中でも「有事に迷わず動ける状態」を実現可能です。
これで、資産の可視化（大分類3）に始まり、アイデンティティ管理（大分類4-1）、防御（大分類4-2以降）、検知（大分類5）、そして対応（大分類6）まで、SCS評価制度が求める一連の対策を見てきました。何を守るかを定め、誰が入れるかを管理し、面として防御を固め、気づける仕組みを持ち、そして気づいた後に動ける体制を作る――これらはどれか一つだけでは機能せず、すべてがつながって初めて、実効性のあるセキュリティ対策になります。
