01
シナリオ
業種、IT環境、重要業務、想定する脅威を確認して設計します。 公開事例だけでなく、記事化が難しい実務事例から得られた論点も、 特定不能な形に一般化して取り入れます。
TABLETOP EXERCISE
「手順書がある」から「実際に動ける」へ
インシデント対応計画や連絡網を整備していても、実際のサイバー攻撃では、 情報が十分に揃っていない状態で判断しなければならない場面が発生します。
合同会社ロケットボーイズでは、運営しているセキュリティ対策Labの記事、 取材・相談・自社調査の中で把握した、一般公開が難しい情報漏洩・インシデント事例から 得られた知見を反映し、実際のインシデント対応に沿った独自の机上演習を企画します。
WHAT IS TABLETOP EXERCISE
セキュリティ机上演習は、サイバー攻撃や情報漏洩などのシナリオをもとに、 参加者が「自分たちならどう判断し、どう連携するか」を議論する演習です。
実際のシステムへ攻撃を行う技術演習とは異なり、 主に組織の判断、連絡、役割分担、事業継続、対外対応などを確認します。
目的は正解を当てることではありません。 実際のインシデントを想定した状況で、 判断・報告・連携・手順上の課題を可視化し、改善につなげます。
SCENARIO DESIGN
攻撃手法や企業のIT環境は変化しているため、 過去に作成したシナリオを繰り返すだけでは、 現在の実態と合わない場合があります。
当社では、セキュリティ専門メディア「セキュリティ対策Lab」で 日々収集している国内外のインシデントや攻撃動向に加え、 取材、相談、支援などを通じて把握した事例も参考にしながら、 演習実施時点で企業が直面しやすいテーマをシナリオへ反映します。
実際の現場では、すべてのインシデントが公表・記事化されるわけではありません。 企業名や具体的な被害内容を公開できないケースについても、 守秘義務や公開範囲を踏まえ、組織を特定できない形に一般化したうえで、 「初動が遅れた要因」「部門間で判断が止まったポイント」 「情報共有が不足した場面」などを演習の論点として活用します。
TARGET
| 対象 | 主に確認するポイント |
|---|---|
| 経営層・役員 | 事業停止・再開、重要顧客への影響、 情報開示、経営判断 |
| CSIRT | インシデント認定、情報集約、 エスカレーション、対応統括 |
| 情報システム部門 | 調査、影響範囲、 アカウント・端末・ネットワークの対応 |
| 事業部門 | 業務影響、代替手段、 顧客対応、復旧優先順位 |
| 広報 | 公表内容、タイミング、 メディア・SNS対応 |
| 法務・リスク管理 | 契約、法令、報告義務、 証拠・記録 |
| 総務・人事 | 社内連絡、従業員対応、 関係者への周知 |
| 経営企画・BCP | 事業継続、重要業務、 代替運用、復旧判断 |
MANAGEMENT
サイバーインシデントでは、 技術部門だけでは決められない判断が発生します。
システム停止・再開、顧客・取引先への説明、 情報漏洩の可能性をどの段階で公表するかなど、 限られた情報の中で意思決定できるかを確認します。
システム停止・事業継続をどう判断するか
被害範囲が未確定でも説明・公表を判断できるか
経営判断に必要な情報が届く体制になっているか
CSIRT / IT
CSIRT・情報システム部門向けでは、 検知後の初動とエスカレーションを中心に確認します。
TIMELINE
01
従業員・監視担当などから異常の報告を受けます。
02
情報システム部門・CSIRTへ情報を集約します。
03
重大度や影響を踏まえ、組織としての対応を開始します。
04
端末、アカウント、システム、情報への影響を整理します。
05
業務影響とのバランスを見ながら、停止・隔離などを判断します。
06
経営判断に必要な情報を整理してエスカレーションします。
07
顧客、取引先、関係機関への説明や連携を判断します。
08
安全性と事業継続の両面から復旧条件を確認します。
09
判断・連携・手順の課題を振り返り、改善につなげます。
「誰が何分以内に対応すべきか」を一律の固定値として設定するのではなく、 自社の体制、重要システム、業務影響、連絡経路に合わせて目標を設定し、 判断や連携がどこで滞るかを確認します。
CUSTOM DESIGN
01
業種、IT環境、重要業務、想定する脅威を確認して設計します。 公開事例だけでなく、記事化が難しい実務事例から得られた論点も、 特定不能な形に一般化して取り入れます。
02
経営層のみ、CSIRTのみ、部門横断など、 目的に合わせて設定します。
03
初めての机上演習から、 複数部門を巻き込む演習まで調整します。
04
最初から全情報を渡さず、 状況変化に応じて追加情報を提示する形式にも対応します。
05
認証情報流出の可能性、顧客情報へのアクセス履歴、 攻撃者による公開予告などを段階的に追加できます。
06
誰が何を把握できなかったか、 どこで情報が止まったか、判断権限が曖昧でなかったかを確認します。
FLOW
01
演習の目的、対象者、現在のインシデント対応体制、 想定する脅威を確認します。
02
実施時点の最新インシデント、攻撃動向、公開事例に加え、 必要に応じて記事化できない実務事例から得られた論点も 一般化してシナリオを設計します。
03
参加者、進行方法、確認項目、必要資料を整理します。
04
シナリオに沿って状況を段階的に提示し、 参加者が判断・議論します。
05
判断に迷った点、連携上の課題、手順とのズレ、 情報不足が生じた場面などを確認します。
06
必要に応じ、規程、連絡体制、判断権限、手順、 次回演習で確認すべき点を整理します。
PRACTICAL INSIGHTS
公表されたインシデント情報は、 被害の概要や原因、再発防止策を知るうえで重要です。
一方で実際の対応現場では、 公表資料には出てこない判断や連携上の課題が発生します。
当社では、セキュリティ対策Labで継続的に把握している公開インシデントに加え、 取材・相談・支援の中で得た、記事として公開できない事例からの 実務的な示唆も活用します。
非公開情報そのものを共有するのではなく、 守秘義務や公開範囲を厳守し、 特定につながる情報を除外したうえで一般化します。
誰に報告すべきか迷った
影響範囲が分からず公表判断が遅れた
技術部門と経営層で認識が一致しなかった
BEFORE EXERCISE
机上演習では、参加者が一定の前提知識を共有している方が 議論しやすくなります。
最新のサイバー攻撃動向や、 各役職に求められる対応について事前に理解を揃えたい場合は、 セキュリティ研修と組み合わせることもできます。
企業向けセキュリティ研修についてFAQ
研修は知識や役割の理解を深めることが中心です。 机上演習は具体的なインシデントシナリオに沿って、 実際の判断・連絡・部門間連携を確認します。
可能です。事業継続、停止・再開、 顧客対応、情報開示など、経営判断を中心に設計できます。
可能です。初動、情報集約、インシデント認定、 封じ込め、エスカレーションなどを中心に設計できます。
ヒアリングした範囲で、業種、組織体制、 IT環境、重要業務などを踏まえて調整します。
はい。不正アクセス、アカウント侵害、情報漏洩、 サプライチェーン攻撃、SaaS・クラウド関連、 内部不正や誤操作など、目的に応じてテーマを設定します。
はい。実施時点で公開されている国内外のインシデントや 攻撃動向を確認し、演習目的に合うものを シナリオ設計の参考にします。
取材、相談、支援などを通じて得た事例について、 公開や記事化が難しい場合でも、 守秘義務や公開範囲に配慮し、 企業や個人を特定できない形に一般化した 「判断上の論点」や「連携上の課題」として 演習設計に活用する場合があります。 非公開情報そのものを参加者へ開示することはありません。
CONTACT
規程や手順書を整備していても、実際のサイバー攻撃で
想定通りに判断・連携できるとは限りません。
公開されている最新インシデントだけでなく、
記事化できない実務事例から得られた示唆も一般化して取り入れながら、
自社の体制や課題に合わせたセキュリティ机上演習を設計します。