ラックが 無償公開した「標的型攻撃 対策指南書(第1版)」を読み解く 最終回である。
前回では 対策組織を まずは立ち上げて、自組織が攻撃を受けていることを知らせてくれる 外部機関への 窓口を 開くことの重要性など を 訴えた。
今回は 不幸にも被害に遭った時に どう復旧させるかの部分に 踏み込む。
ここで間違うと 信用回復は さらに難しくなる。
第2章【2. 標的型攻撃の対策】の 後半に込めた思いを 解説していこう。
「2.6. ダメージコントロールと被害の対処の備え」の節では、事故対応を行う専門組織「CSIRT(シーサート=Computer Security Incident Response
Team)」が 外部から連絡を受けた時に、取るべき 初動対応について 概要を示している。
事故が発生した際、真っ先に考えなければならないのは、被害範囲を最小限にとどめ攻撃者の活動を封じ込めることである。
通信を全部止めるのか、見張りながら許可するところはどこか(表1)。
年金機構の 初動のミスにも学び、この点は あらかじめ議論しておいてほしい。
  | 項目 |
ⅴ | インターネットへの接続を制限する |
ⅴ | 攻撃者グループのC&Cサーバへの通信を遮断する |
ⅴ | 電子メールの送信を制限する |
ⅴ | 被害状況の確認に必要なログを確保する |
ⅴ | C&Cサーバと通信していた機器を特定し、隔離する |
ⅴ | 侵害機器のアカウントパスワードを全て変更する |
ⅴ | 侵害機器のコピーを取得し、コピーに対してウイルススキャンを実施する |
ⅴ | 自動実行に登録されたプログラムが正規のものであるか確認する |
ⅴ | ウイルスをウイルス対策ソフトベンダーへ提供し、パターン作成を依頼する |
ⅴ | ウイルスの通信先C&Cサーバのアドレスを確認する |
ⅴ | 情報漏洩の有無を確認する |
ⅴ | 専門業者への調査依頼を検討する |
ⅴ | 標的型攻撃に特化した監視装置の臨時設置を検討する |
ⅴ | 報道発表を行うかどうかを判断する |
事故の発表は決してマストではない
事件自体の発表に関しては、攻撃を受けたり感染が確認されたりしたからといって、必ずやらなければならないというものではない。
発表の 最大の目的は 被害拡大を防止すること。
個人情報の流出により二次被害が発生したり 他の組織までダメージが及んだりする 場合で、かつ 個別に連絡していては 間に合わない場合、発表する。
ここも 発表するケースを 社内で あらかじめ想定しておくことが重要だ。
続く「2.7.被害からの復旧手段の確保」の節では、事故発生後にいったん停止した事業を 復旧させるための手順を示している。
目を通していただければ、復旧がいかに大変か、理解できるだろう(表2)。
  | 項目 |
ⅴ | 侵害機器のディスクをフォーマットし、OSを再インストールする |
ⅴ | アプリケーションをバージョンアップして最新の状態にする |
ⅴ | バックアップデータを復元する |
ⅴ | 侵入経路・原因を特定し、対処する |
ⅴ | パスワード変更後も一定期間、不審なログオンがないかを監視する |
ⅴ | 復旧後も一定期間、ネットワーク通信を監視する |
ⅴ | Active Directoryの完全性を復旧する |
ⅴ | 事態収拾後、一連の対応について手順書を作成・改訂する |
ⅴ | 回復作業完了後、通信を復旧する |
ⅴ | 事業を再開する |
ⅴ | 被害情報の公表などにより企業として信頼回復に努める |
復旧はできるだけ早期に、侵害された領域が少ない段階で着手するのが望ましいが、全社が単一のネットワークで一元的につながっていたりすると
感染が一瞬にして広がり、被害範囲が確定できない事態に 陥ることも多い。
最悪の場合は 社内のOSを すべて再インストールするという 決断を せざるを得ないことにも つながりかねない。
日頃から 管理するセグメントを 重要度に応じて 区切るなど、被害を 最小限にとどめられるよう 考えておく 必要がある。
復旧を考える上での重要なポイントは、事業継続と 再発防止策だ。事業継続については、取引先や 関係先の 事業継続を 優先して進める 必要がある。
自社が 事業継続するには 関係先が 事業継続できなければならないからだ。
もちろん、行政機関や サプライチェーンのトップにいる企業は 自身の事業再開 イコール、裾野企業の 事業継続 となるため、自身の再開を
優先させることになるだろう。
再発防止策では、「何を」再発させないかを明確にする 必要がある。
気付くことも 完璧に防ぐことも困難な 標的型攻撃について、事故そのものの再発防止を 対外的に 約束するのは 経営にとって 致命傷になりかねない。
「事後対応のミスで関係のない組織にまで被害が及んでしまった」「予兆段階で気付けるはずだったのにうっかり見逃してしまった」――。
こういったケースは ミスをした部分についての 再発防止を 約束すればよい。
「万全を尽くして二度と事故を起こさない」と 言いたくなるのは 十分理解できる。
しかし、できることと できないこと、費用対効果を 考え、「何を」再発させないかを 冷静に 判断する。
そして、約束したものについては 何が何でも 果たすことだ。
標的型攻撃の中には、対象組織に 信用失墜や 風評被害といった「ダメージ」を与えることを 目的にしている場合もある。 その場合、果たせもしない 再発防止を 約束することは 犯人側を利することになる ということを 視野に入れた 対応が必要となる。
「割れ窓」を放置しない経営を
2章の「2.8. 継続的に対策するための実施評価と予算措置」では、継続的にセキュリティ対策を実施する上での 評価の考え方などを示している。
重要なのは、被害が出るかどうか ではなく、組織としてやると決めたことが できているかどうかだ。
事件や事故が発生した時になって、「やるべきことができていなかった」と 露見するケースは多い。
繰り返すが、重要なことは、第2回で示した 4つの 外部からの連絡といった、標的型攻撃の被害を 認識した時に 適切に行動できるかが 第一、
第二に、被害を認識した時に 「割れ窓(ルール違反の放置)」が 起きていないか である。
些細な内規違反でも 放置すれば 割れ窓と化し、いずれ 重大な事故や事件に つながりかねないのだ。
割れ窓の放置は 経営の怠慢だと 認識し、継続的に チェックする 必要がある。
現実問題として、どの組織も 金や人といったリソースの問題から、実施できる範囲は おのずと定まってくる。
継続的に対策をするポイントは、「やること」と「やらないこと」を 明確にすること、そして、できないことは 実行可能な内容に 改めることである。
内部監査などにより、やるべきことが行われていないと 判明した場合は 厳重注意する。
場合によっては 処罰するなど、先手を打って 対処することが 欠かせない。事件が 発生したときになって 処罰するなど 愚の骨頂と 心得てほしい。
「不審なメールに注意」では 注意できない
最終節の「2.9. 標的型攻撃を見越した人の教育」は 締めとして、人への教育を進める際の 考え方を まとめている。
教育について考える場合は、まず「高信頼性組織」と「低信頼性組織」に 分けたほうがよい。
高信頼性組織とは、社員が 目的を共有し、相互に 信頼し合って、例えば 個人情報を取り扱うなどの 高度な業務を推進する 組織をいう。
こうした組織では、社員は 信頼にこたえる行動をとるために 厳しいルールを 守り、高い意識で 業務に取り組む。
もし関係者を裏切るような行動を取った場合は、厳しい罰則によって組織として適正な方向に向かうようにさせる。
一方、性悪説を前提としなければならない 低信頼性組織は、社員が 相互に信頼せず、目的意識も 共有しようとしないような 組織を指す。
こうした組織では、社員から目を離すと 事故や不祥事が 発生しやすくなる。
システム的に 防止策を施す、全貌が見えないような 仕掛けを 施しておくことが 欠かせない。
程度の差はあれ、一般の多くの組織は 高信頼性組織に 分類されるだろう。
高信頼性組織での 教育のポイントは、守るべきことを ルール化して 破った場合の罰則を 設けておき、そのことを よく理解させておくことだ。
標的型メールで 言えば、「こういった内容のメールは開封してはならない」「このようなメールが届いた場合は報告するように」と、具体的に 示す。
よくありがちな 「不審なメールは開かないように」では、不審かどうかを メール受信者の 判断に委ねることになり、ルールには 適さない。
ITリテラシーや 常識は 人によって 大きく異なり、全員が 同程度に 「不審」と 判断できるわけではない からだ。
もし「不審なメール」との 文言で ルール化するならば、ヘッダーや 実行ファイルを 見分けることができる、怪しいリンクが
どのようなものかが わかるなど、社員の 一人ひとりが 最低限の ITリテラシーを 身に付けている ことが 前提となる。
ここまで 到達できる 組織は まだ 少ないだろう。
もちろん、攻撃者の技術は はるかに 上回っており、これだけで 攻撃が 防げるわけではない。 それでも、最低ラインから 一歩一歩、社員の リテラシーを 高め、組織全体の 対応力向上に つなげてほしい。 そこに 本対策指南書が 役立てば 幸いである。