高性能なセキュリティ製品を導入していても、異常を検知した後の対応が決まっていなければ、初動が遅れ、被害が拡大するおそれがあります。
例えば、重要なサーバーに不審な動きが見つかった場合、被害の拡大を防ぐためにネットワークから切り離すことが考えられます。しかし、そのサーバーが重要な業務を担っていれば、隔離によって事業が停止する可能性もあります。こうした場面で、誰がリスクを評価し、誰が業務停止を判断するのかが決まっていなければ、対応が遅れてしまいます。
インシデントに備えるうえで重要なのは、必ずしも専任部署の人員を増やすことではありません。情報システム部門が必要な情報を速やかに収集し、想定されるリスクを整理したうえで、経営層の意思決定や技術的な対応、社外への説明につなげる仕組みを整えることが大切です。
セキュリティ担当組織の立ち上げ、対応手順の整備、既存製品の見直しは、それぞれ独立した課題ではありません。実際の相談事例でも、これらを一体的に検討する必要がありました。
1. なぜセキュリティ製品だけではインシデントに備えきれないのか
EDR(Endpoint Detection and Response)やNGAV(Next Generation Anti-Virus)のような脅威検知製品は、端末の不審なアクティビティを見つけるのに役立ちます。アラートは重要度に応じて管理者へ通知されますが、過剰検知(False Positive)も一定数存在することから、上述したサービスを利用しても、定期的なチューニング・最終的な担当者による判断が必要になります。
近年では脅威を発見した場合、自律的に隔離・修復を行う機能が内包されたサービスも登場しており、影響度の低い端末・資産の隔離有無を深く考える必要がなくなっているのも事実です。
一方で、業務影響のある端末(例 : サーバや外部提供しているリソースなど)においては、ネットワークから切り離せば被害の拡大を抑えられる可能性がありますが、その端末が担う業務も自ずと停止してしまうことから、「技術担当者だけで遮断を決めてよいのか」、「事業責任者と協議すべきなのか」など多様な要因が絡み合い、結果として双方の意見がまとまらず、判断が遅れたことにより、被害拡大につながるケースがあります
2. セキュリティ担当組織の立ち上げ時に決めること
担当組織を立ち上げるうえで、まず平時に誰が何を担い、問題が起きたときに誰が意思決定をするのかを決めることが先決です。部署の名称や人数は、重要なピースではなく、「誰が」「どういった権限・決定権があるのか」を明確に定める事が重要です。専任のCISO（最高情報セキュリティ責任者）がいなくても、既存部門の兼務と外部専門家の助言を組み合わせることで効果的なアプローチを図ることが出来ます。
（1）経営・情報システム・外部専門家の役割
経営層の役割
- 発生したインシデントに対しての最終決定権
- 事業継続の可否の決定
情報システム部門の役割
- インシデントに関する詳細調査調査
- 影響を受けたシステムの復旧
事業部門(管理・法務部門等)の役割
- 顧客業務への影響の把握
管理・法務部門は契約条件や報告先の確認を受け持ちます。外部専門家に相談しても、社内の決裁まで任せられるわけではありません。
兼務者が複数の役割を担う場合は、業務ごとにRACI(Responsible Accountable Consulted Infomed)を整理すると担当の抜けが見えてきます。RACIは実行者、最終責任者、相談先、報告先を明らかにするための整理方法です。下表は役割分担の一例で、実際には事業内容や人員に合わせて組み替えます。
| 関与者 | 平時に担うこと | 有事の主な役割 |
|---|---|---|
| 経営層・統括責任者 | 対応方針と決裁権限を承認 | 重大事案での停止や公表を判断 |
| 情報システム・担当組織 | 資産、通知先、手順を管理 | 事象を確認し、技術対応と復旧を調整 |
| 事業・管理・法務部門 | 重要業務と契約上の条件を確認 | 業務への影響を見極め、対外連絡を検討 |
| 外部専門家・委託先 | 助言の範囲と連絡条件を合意 | 専門的な助言と契約範囲内の作業を担当 |
（2）判断・報告・エスカレーションの経路
インシデントの報告は多岐に渡り(例:SOCベンダーからの連絡、顧客からの連絡、社内からの連絡)通常の問い合わせから不審な事象、重大なインシデントまで、報告する相手と経路を区別します。担当者の権限では判断できない事案を上位の責任者に報告し、判断を仰ぐのがエスカレーションです。初報には発見時刻、対象、判明した事実、未確認の点、すでに取った暫定措置を記載し、推測と事実を混ぜないようにします。
重大度を決める材料は、情報漏えいのおそれだけではありません。どの業務が止まるか、影響する顧客は誰か、復旧までの見込み、法令や契約に基づく連絡が必要かも確認します。担当者が不在でも判断が止まらないよう、代行者と連絡手段を決め、夜間や休日の通知も想定しておきます。
3. インシデント対応手順を平時から整備する方法
対応手順は、形だけのマニュアルを仕上げることより、通報を受けてから経営層が判断するまでの流れを実際にたどれる形にするトレーニングを行うこと先決です。障害対応や事業継続計画に既存の仕組みがあれば重複を確かめ、受付窓口、責任者、記録先をできるだけ統一します。
対応を段階ごとに分け、担当者、判断が必要になる条件、保存する証拠や記録を決めます。ただし、調査、報告、復旧は必ずしも表の順に進むわけではありません。
| 対応段階 | 実施する内容 | 判断と記録で確認すること |
|---|---|---|
| 受付・初動確認 | 通報内容、影響範囲、判明した事実を整理 | 受付時刻、担当者、最初の連絡先 |
| 重要度判定 | 業務、顧客、情報への影響を確認 | 上位報告と外部連絡の要否 |
| 封じ込め・調査 | 隔離などの措置と原因調査を進める | 措置の承認、証拠保全、実施履歴 |
| 復旧・対外対応 | 復旧条件を確認し、必要な連絡を検討 | 再開を決める人、通知判断の根拠 |
| 振り返り | 原因と手順上の問題を整理 | 改善担当者、期限、次の点検時期 |
アカウントの不正利用が疑われる場面では、担当者がそのアカウントを一時停止できても、全社システムを止めたり顧客へ説明したりするには別の承認が必要なことがあります。すぐに実施できる措置と決裁を要する措置を切り分け、通常の連絡手段が使えない場合の代替経路も決めておきます。
立ち上げ時にそろえるのは、緻密なフロー図より、連絡先一覧と初報の書式、判断の経緯を残す記録、委託先へ連絡する条件です。
4. 既存のセキュリティ製品を棚卸しする視点
セキュリティ製品の棚卸しでは、買い替えを検討する前に、今の環境で何を検知でき、通知を受けた後に誰が動いているかを確かめます。製品があっても、アラートが届かない、対処する権限がはっきりしないといった状態では、その機能を生かせません。
機能の比較だけでは、運用の問題は見えません。製品の使われ方が対応手順と食い違っていないか、対象範囲から担当者、調査時の連携、費用や負荷までを確認します。
| 確認観点 | 確かめたいこと | 見直しが必要な状態の例 |
|---|---|---|
| 対象・重複 | どの端末、アカウント、領域を守るか | 重要な資産に監視の空白がある |
| 通知・担当 | アラートはいつ、誰に届くか | 夜間の受領者や代行者が決まっていない |
| 調査・連携 | 記録をたどり、他の情報と照合できるか | 根拠の確認に時間や手戻りが生じる |
| 運用負荷・費用 | 誤通知や保守の負担は妥当か | 使われない機能や役割の重複がある |
見つかった空白のうち、影響の大きいものから手を付けます。設定変更で直せるのか、担当の割り振りを変える必要があるのか、製品の刷新まで検討するのかを切り分けます。製品選定では価格に加え、現場が継続して使えるか、通知から調査、復旧までのどこを支えるかを見ます。
5. 外部アドバイザーを活用するときの進め方
外部のセキュリティアドバイザーに相談する際は、どういった業務を外部へ依頼するかを含めて優先度を定める事が重要です。進め方は、現状と不足している機能を確かめ、取り組む順序と役割を決めたうえで、運用手順や製品の見直しに進み、社内へ引き継いで定期的に点検するという流れです。依頼する前に、社内の決裁者、外部と共有できる情報、委託する作業の範囲、契約終了後の担当者を決めておきます。
経営判断への助言、規程や運用の設計、常時監視、事故調査は、同じセキュリティ支援でも別の仕事です。監視やデジタル鑑識（フォレンジック）も必要なら、実施者だけでなく、対応時間と責任範囲を別途確かめます。
6. 支援事例 既存環境の見直しと対応プロセスの整理
あるサービス事業会社では、セキュリティチームの発足にあたり、専門的なアドバイザリーを担う人材が必要となり、RSM汐留パートナーズへ相談がありました。相談時点では一定のシステム・製品を導入済みで、組織としてのセキュリティ運用は整備途上にありました。支援は新規導入ではなく、既存環境の堅牢化を検討する段階で始まっています。
支援テーマは、既存プロダクトの刷新に向けた製品選定支援と、インシデント対応プロセスの確立です。製品の入れ替えだけを独立して進めるのではなく、発見された事象への対応を組織としてどう進めるかが、同じ相談の中で扱われていた点に特徴があります。
この事例から読み取れる課題は、対策を一から導入することではなく、既にある環境と新たに発足した担当組織をつなぐことです。一般的な実務としては、製品から受け取る情報、初動担当者、承認者、外部への連絡先を対応プロセス上で突き合わせると、運用上の空白を洗い出しやすくなります。
なお、本事例は相談内容と支援テーマの紹介であり、選定製品や具体的な改善成果を示すものではありません。
7. 体制定着に向けた訓練・振り返り
組織図や手順を整えたら、連絡と意思決定が実際に回るか試してみます。端末の不正利用や重要アカウントの侵害を題材に机上訓練を行い、事態が変わるたびに、担当者が誰へ何を伝えるかを確かめます。
訓練で見るのは、検知に関する数値だけではありません。必要な相手に情報が届き、判断と記録が途切れず続くかも確認します。
- 重要な通報が担当者や代行者に確実に届いたか。
- 重大度や停止措置について、承認者がすぐに分かったか。
- 判断した理由と時刻、担当者を後からたどれるか。
- 訓練で出た課題ごとに担当者と対応期限を決めたか。
訓練で混乱が起きても、個人のミスで片付けず、連絡網や権限、製品の設定、委託先との契約のどこに原因があるのかを調べます。担当が替わったときや新しいシステムを導入したときにも手順を更新し、残る課題は経営層へ定期的に報告します。
8. RSM汐留パートナーズのセキュリティ支援
セキュリティ製品を導入するだけでは、インシデントに対応できる体制が整ったとはいえません。
異常が見つかった際に誰が対応し、誰が判断を下すのか。また、対応後にどのような改善を行うのか。こうした一連の流れを、経営層と現場の双方が理解し、実行できる状態にしておくことが重要です。
RSM汐留パートナーズでは、サイバーセキュリティに関する現状分析やリスク評価、対策方針・計画の策定、プロジェクトの推進、教育などを支援しています。
また、社外CISOサービスでは、専任のセキュリティ責任者を配置していない企業に対しても、セキュリティ戦略やインシデント対応計画の策定、運用状況の継続的なレビューなどを支援しています。
セキュリティ担当組織の立ち上げや、既存製品・運用体制の見直しを検討されている場合は、まず現在の役割分担や連絡経路、対応手順を整理し、課題を明らかにするところからご相談いただけます。
