本連載は、セキュリティインシデントの対応経験から得られた知見をもとに、インシデントが発生した現場で何が起こっているのかを紹介していきたい。まずは、インシデントが生じた組織とIBMをはじめとするサービス提供ベンダーの間で生じたさまざまな課題をテーマに、前編ではインシデントが発生した企業側、後編ではサービス提供ベンダー側の状況を取り上げる。
先にIBMにおけるセキュリティインシデントへの対応について説明したい。IBMは、「IBM X-Force IRIS : Incident Response and Intelligence Services」というブランド名で、グローバル規模のインシデント対応サービスを行っている。日本ではその前身である「IBM ERS : Emergency Response Service」を2014年に開始し、2017年に上記のサービスにリニューアルした。現在ではセキュリティ技術者、サイバー犯罪捜査の経験を持つ元警察官、大規模な情報漏えい対応を指揮したCSIRT責任者、CSIRT構築コンサルタントなどがさまざまなセキュリティインシデント対応を支援している。
まずIBM X-Force IRISがインシデント対応を支援する際の行動規範を紹介する。行動規範は、本連載が取り上げる事例において、「なぜそのように行動したのか」という点を理解するための基準である。とはいえ、それは精神論でも小難しい論理でもなく、「事実（証拠、現物）に基づいて判断、行動する」という一点のみだ。
「何だ、そんなことか」と思われるかもしれない。しかし現実には、組織的な力学や思い込みにより、筆者はインシデントの調査結果がねじ曲げられる状況を何度も目にしてきた。IBM X-Force IRISは、あえて「空気を読まず」事実を報告する。極端な事例では、社内調査の結果と真逆の報告になったことさえあった。事実がその組織にとって不都合なものであったとしても、その後の対応を正しく行うためには、事実が最も重要であると確信しているからだ。
インシデント発生現場で生じる課題
IBMのようなインシデント対応サービスベンダーが現場に入った際に困ることをまず紹介したい。それは、「仕事がスムーズに進まない」「技術的な情報共有が難しい」などの簡単なことではなく、「インシデントが解決できない」「間違った結果を導き出してしまう」など、致命的な問題につながる課題である。表1に、現場で見られる課題とその対策をまとめた。この中から特徴的なものをいくつか説明しよう。
表1：サービスベンダーから見た現場の課題
課題1：インシデント現場の混乱
この課題には、「責任者の任命による指揮命令系統の確認」「手続きの文書化」と、事態を把握するための「時系列での事象の整理」が効果的だ。経験不足を補うためには、文書化した手続きの中に、外部セキュリティベンダーの活用を含めてしまうことを検討すべきである。
責任者の任命による指揮命令系統の確認
この中で最も大きな課題は「責任者不在」だろう。責任者が明確化・周知されていなければ、現場で最も重要なものの一つである「優先順位の決定」が行われないまま、いたずらに時間だけが過ぎていく。セキュリティインシデントの発生後、役員会で「責任回避」「責任のなすりつけ合い」が一週間にわたって繰り広げられた極端な事例さえあった。
ここでいう責任者とは、「インシデント対応の責任者」であり、事態の発生に係わる責任者ではない。インシデント対応経験がないことは、このような「責任者」の役割の混同だけではなく、「事態の把握」さえ後手に回り、さまざまな混乱を招くことになってしまう。こうなると、サービスベンダーでさえ「インシデント対応として何をすべきか」ということが難しい。しかしこの状況が長く続けば、被害の拡大など、致命的なビジネスへの影響さえ生じてしまう危険性が出てくる。図1に責任者が実施すべきタスクを示す。
図1：責任者が実施すべきタスク
技術対応範囲は、外部のインシデント対応サービスベンダーに全て依頼してしまうことも可能だ。ただし、一般的に「フォレンジックサービス」と呼ばれるサービス範囲では、影響判断、全体評価、分析の方向性決定などは含まれないので注意しなければならない。
一方、管理対応範囲のタスクが多いことに気がつくだろう。外部のセキュリティベンダーやコンサルタントに依頼可能な項目もあるが、多くは組織内で主導権を持って実施しなければならないため、外部リソースの活用範囲を事前に定義しておくことが重要だ。「組織内ステークホルダー要求事項優先順位付け」のように、外部に頼ることはできない項目も存在する。
時系列での事象の整理
事態を把握するためには、何が生じているのか、情報を集約することが近道だ。インシデント対応でよく使われる手法が、「時系列での事象の整理」である。これを「タイムライン」と呼ぶ。各種ログから取得した情報を時間順に並べてまとめていくことでインシデントの流れを可視化することが可能となる。
表2は、タイムラインの例である。複数のホストが関連していることが分かる。調査が進むにつれて多くの情報が集まり、影響範囲などを含む事態の把握につながっていく。
表2：タイムラインの例
だが表2には、会議や作業の実施などが含まれていないことに気がつくだろう。会議や作業の記録は「ワークログ」としてまとめ、タイムラインとは切り離して管理する必要がある。タイムラインはあくまで事態把握のために利用され、ワークログは作業の進捗や適切なタイミングで意志決定なされていたか、などの把握のために利用する。残念ながら、現場ではこの2つを混同している組織が少なくない。
