最近公開されたベライゾンの『2019 Data Breach Investigations Report(2019年度データ漏洩/侵害調査レポート)』から判明した1つの重要な事実があります。

「侵害の56%はそれが明らかになるまでに6か月以上の期間を要している」と言うのです。そして不幸にも、これは、驚愕するようなニュースではないのです。検知と対応に要している現状の時間はどの業界でも許容できるものではありません。誰に確認しても同じ答えが返ってきます。

これは多くのケースにおいて、セキュリティチームが向き合い備えを固める必要のある現実を表しています。セキュリティの能力を測る場合、どのくらい詳細な調査ができるかといった点や検知の能力ばかりに目を向けて、保持期間の要素を無視しがちです。

ガ―トナーの秀逸なブログ記事の1つのなかで著者のAnton Chuvakin氏は重要ポイントを指摘しています。この記事は6年も前に公開されたものですが、その内容は依然として説得力のあるものとなっています。記事のなかでChuvakin氏は、次の点に焦点を当てています。

「侵害を検知するまでの時間がエビデンスを保持している期間を超過してしまうようなケースでは、データを保持する期間をさらに長くするのがよいのか、それとも検知の能力をもっと高めるのがよいのか、どちらを選択すべきであるのか」と問いを発しているのです。

侵害は発生しているか

既知のマルウェアの攻撃をリアルタイムで防ぐ場合であれ、未知のTTPやゼロデイ脆弱性による高度な攻撃を見つけ出す場合であれ、検知が重要であることに変わりはありません。しかし、Anton氏のブログ記事を読むと、ある考えが浮かんできます。

検知だけでは、組織全体を対象として侵害の調査を完了するまでに何度データが必要になるのかという観点が欠けています。繰り返して言うならば、データの観点が存在しないのです。

一般の人々や経営陣の場合、赤や緑で侵害の発生の有無を知らせるスクリーンのようなものがどこかにあるとのイメージを抱いています。しかし実際には、侵害や侵害の影響は計算によって算出する必要があり、そのために必要なデータが不十分であると正しい結果が得られません。

セキュリティチームは、「侵害は発生しているか」、「侵害の影響は生じているか」といった問いに明確な答えを出す責任があります。

しかし、はっきりとした答えが必要であるのに、セキュリティチームは、答えの出せない問いを際限なく抱えることになるのです。しかも、そういったケースがあまりに多く見受けられます。それはなぜでしょうか。

調査を実施する際に最も多く利用可能で最も頻繁にセキュリティチームが利用する個々のデータソースを確認していきましょう。ここでは、すでに検知が行われているものと仮定し、インシデントレスポンスのプロセスに対する影響、とりわけ、数か月以上の期間が経過している場合の状況に注目します。

  • セキュリティ情報管理とイベント管理(SIEM)のシステムでは、セキュリティアナリストに豊富な機能が提供されますが、SIEMの環境やSIEMによる管理を必要とする主要な要因の1つは、依然としてコンプライアンス上の要件の存在です。それゆえ、データ保持のベストプラクティスを考える場合、コンプライアンスの観点とそれ以外の観点でのデータの必要性を意識する必要があります。そして、収集するデータと個々のデータの保持期間の両面からベストプラクティスを引き出します。コンプライアンス上の義務と、侵害の検知、調査、対応上の必要性の2つの側面について考える場合の適切な例として、PCI DSSのケースが挙げられます。SIEMシステムの場合、考慮すべき2つの側面があります。照会のためのメタデータと、コールドストレージにアーカイブするデータ(または単純に複製するデータ)です。また、セキュリティアナリストがそれぞれのデータを利用してハンティングを行う際の所要時間も考慮します。
  • インシデントレスポンス時に明らかな付加価値を期待できるネットワーク脅威分析(NTA)やネットワークフォレンジックの場合、フルパケットキャプチャの収集と保存に多額のコストがかかり、そのため、Rawデータをキャプチャできる期間は2週間から4週間に限られます。また、対象となるデータはインバウンドとアウトバウンドのデータのみとなり、East-Westトラフィックは除外されます。最もベストな状態でも、さらに数週間分のメタデータが追加で用意されるといった具合です。この場合、法規制の観点よりも、ペタバイトのデータの処理でマシンにかかる負荷や先に述べたコストが問題になります。
  • クラウドから利用するアプリケーション(SaaS)では、SIEM、NTA、EDR、UEBAなどがありますが、いずれのタイプにも長所と短所があります。管理性の欠如や導入面でのウィークポイントについては言うまでもありませんが、データのコストはアプリケーション側にシフトすることになります。「ボックスの購入を始める」つもりがなければ、保存したデータすべてのコストを負担することになります。そして、数か月以上の期間を遡った場合、もう、そこにはデータはありません。

間違ったデータが大量に溢れ、正しいデータは失われている

侵害を受けている可能性があり、それを調査する場合、セキュリティチームに求められるのは高い精度で迅速な対応をすることです。しかし現実には、自動化されていない処理に時間のかかる大量の作業に阻まれて、セキュリティアナリストはスピーディーな対応が取れません。

大きな障害となる要因の1つとして、データが全く存在しない状態や、限られたデータしかコールドストレージに存在しない状態が挙げられます。これでは、ばらばらになっているデータポイントを集めて相互に関連付けるのはほぼ不可能です。

適切なデータを入手できたり、アーカイブされたデータを利用できたりしたとしてもそれが完全でなければ、そこから問題が生じます。数年分のデータを自由に利用できると仮定してみましょう。スタート地点として考えたときにそれで十分でしょうか。インデックス化されていないRawデータの取捨選択や、クレーターに落ちた針を探し出すような作業に「楽しみ」を見出す私の場合、求める情報が見つかれば非常にラッキーだと考えていましたが、ほとんどの場合、これは実現不可能です。

具体的な例を使って説明しましょう。新たな攻撃ツールが大規模なかたちで見つかったとします。このツールははたして自社に影響を及ぼすものなのかどうかと、この時点で世界中のセキュリティチームが自問します。

あるいは役員から同じことを聞かれます。この場合、C2 IPや実行ハッシュファイル、不正なdomain.comをCtrl+Fで探そうとしてもうまくいきません。攻撃ツールが残した足跡を見つけ出し、特に重要なこととして、攻撃がどの程度、組織内に広がっているのかを特定するために、もっとスマートな方法でTTPのハンティングを行う必要があります。このケースでは、履歴データを照会して攻撃者のTTPを特定することが欠かせません。

将来も陳腐化しないインテリジェンスで過去へと前進する

映画『バック・トゥ・ザ・フューチャー,』の主人公、Marty McFlyは、将来も陳腐化しないインテリジェンスを過去の時間に適用した草分け的存在です。彼は「未来に影響を与える」ことなく事態を変えることはできませんでした。今日の世界でセキュリティチームが必要としているのはそれとは全く逆のこと、すなわち、「過去への前進」です。際限なく過去に遡って、今利用できるTTPやIOCのインテリジェンスを適用したり、攻撃者の調査をしたりできるならば、固有のTTPや固有のマシン、固有の時間枠に関係なく分析が可能です。

さて、巡り巡って議論の出発点に戻ってきました。メガデータレベルの侵害があたりまえのようにうんざりするほど発生している状況では、新しい侵害が発生したときにその影響を受けるかどうかをこれまで以上に頻繁に判断する必要があります。答えは一刻も早く出さねばなりません。

そのためには、適切なタイミングで適切なデータを、最新の既知の背景情報すべてとともに入手することがきわめて重要です。これは、過去の状態を再現できる能力や既知の事柄を利用し、未来のナレッジの恩恵を受けながら、対象を定めて外科手術の内容を再現するようなものです。

想像してみてください。データの保持期間やクラウドのコンピューティング能力を気にする必要のないときがやがて訪れます。

ホワイトペーパー「インシデントレスポンスで成功するためのチェックリスト」

インシデントレスポンス(インシデント対応)プランを策定する場合、非常に詳細な部分にも注意する必要があります。

しかし、大きな成果を上げているインシデントレスポンス(インシデント対応)プランでさえも、重要な情報が欠落していることがあり、正常に業務を行うことができるよう迅速に復旧作業を実施するうえでの妨げになる場合があります。

本資料は、インシデントレスポンス(インシデント対応)プランに組み込むべきでありながら忘れがちな9つの重要なステップについて詳しく説明します。
https://www.cybereason.co.jp/product-documents/white-paper/2476/

ホワイトペーパー「インシデントレスポンスで成功するためのチェックリスト」インシデントレスポンスプランに組み込むべきでありながら忘れがちな9つの重要なステップ