ラックが無償公開した「標的型攻撃 対策指南書(第1版)」を読み解く最終回である。前回では対策組織をまずは立ち上げて、自組織が攻撃を受けていることを知らせてくれる外部機関への窓口を開くことの重要性などを訴えた。今回は不幸にも被害に遭った時にどう復旧させるかの部分に踏み込む。ここで間違うと信用回復はさらに難しくなる。

写真●「標的型攻撃 対策指南書(第1版)」の「2.6. ダメージコントロールと被害の対処の備え」
写真●「標的型攻撃 対策指南書(第1版)」の「2.6. ダメージコントロールと被害の対処の備え」
[画像のクリックで拡大表示]

 第2章【2. 標的型攻撃の対策】の後半に込めた思いを解説していこう。「2.6. ダメージコントロールと被害の対処の備え」の節では、事故対応を行う専門組織「CSIRT(シーサート=Computer Security Incident Response Team)」が外部から連絡を受けた時に、取るべき初動対応について概要を示している(写真)。

 事故が発生した際、真っ先に考えなければならないのは、被害範囲を最小限にとどめ攻撃者の活動を封じ込めることである。通信を全部止めるのか、見張りながら許可するところはどこか(表1)。年金機構の初動のミスにも学び、この点はあらかじめ議論しておいてほしい。

表1●初動対応時に最低限、押さえておくべき事項のチェックリスト
 項目
 インターネットへの接続を制限する
 攻撃者グループのC&Cサーバへの通信を遮断する
 電子メールの送信を制限する
 被害状況の確認に必要なログを確保する
 C&Cサーバと通信していた機器を特定し、隔離する
 侵害機器のアカウントパスワードを全て変更する
 侵害機器のコピーを取得し、コピーに対してウイルススキャンを実施する
 自動実行に登録されたプログラムが正規のものであるか確認する
 ウイルスをウイルス対策ソフトベンダーへ提供し、パターン作成を依頼する
 ウイルスの通信先C&Cサーバのアドレスを確認する
 情報漏洩の有無を確認する
 専門業者への調査依頼を検討する
 標的型攻撃に特化した監視装置の臨時設置を検討する
 報道発表を行うかどうかを判断する

事故の発表は決してマストではない

 事件自体の発表に関しては、攻撃を受けたり感染が確認されたりしたからといって、必ずやらなければならないというものではない。発表の最大の目的は被害拡大を防止すること。個人情報の流出により二次被害が発生したり他の組織までダメージが及んだりする場合で、かつ個別に連絡していては間に合わない場合、発表する。ここも発表するケースを社内であらかじめ想定しておくことが重要だ。