セキュリティインシデント対応の現場

第1回:サービスベンダーから見たインシデント発生現場の諸課題

小倉秀敏 (日本IBM) 2019年02月04日 07時00分

  • このエントリーをはてなブックマークに追加
  • 印刷

 本連載は、セキュリティインシデントの対応経験から得られた知見をもとに、インシデントが発生した現場で何が起こっているのかを紹介していきたい。まずは、インシデントが生じた組織と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に責任者が実施すべきタスクを示す。

図1:責任者が実施すべきタスク
図1:責任者が実施すべきタスク

 技術対応範囲は、外部のインシデント対応サービスベンダーに全て依頼してしまうことも可能だ。ただし、一般的に「フォレンジックサービス」と呼ばれるサービス範囲では、影響判断、全体評価、分析の方向性決定などは含まれないので注意しなければならない。

 一方、管理対応範囲のタスクが多いことに気がつくだろう。外部のセキュリティベンダーやコンサルタントに依頼可能な項目もあるが、多くは組織内で主導権を持って実施しなければならないため、外部リソースの活用範囲を事前に定義しておくことが重要だ。「組織内ステークホルダー要求事項優先順位付け」のように、外部に頼ることはできない項目も存在する。

時系列での事象の整理

 事態を把握するためには、何が生じているのか、情報を集約することが近道だ。インシデント対応でよく使われる手法が、「時系列での事象の整理」である。これを「タイムライン」と呼ぶ。各種ログから取得した情報を時間順に並べてまとめていくことでインシデントの流れを可視化することが可能となる。

 表2は、タイムラインの例である。複数のホストが関連していることが分かる。調査が進むにつれて多くの情報が集まり、影響範囲などを含む事態の把握につながっていく。

表2:タイムラインの例
表2:タイムラインの例

 だが表2には、会議や作業の実施などが含まれていないことに気がつくだろう。会議や作業の記録は「ワークログ」としてまとめ、タイムラインとは切り離して管理する必要がある。タイムラインはあくまで事態把握のために利用され、ワークログは作業の進捗や適切なタイミングで意志決定なされていたか、などの把握のために利用する。残念ながら、現場ではこの2つを混同している組織が少なくない。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

関連ホワイトペーパー

SpecialPR

連載

CIO
月刊 Windows 10移行の心・技・体
ITアナリストが知る日本企業の「ITの盲点」
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
セキュリティインシデント対応の現場
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]