エンドポイントにおける検知と対応(EDR):コンテキストがもつ重要性の解説

By The Cylance Team

本ブログ記事は、2019年2月5日に米国で公開された抄訳版です。原文はこちらからご覧頂けます。

Merriam-Webster 辞典によると、「コンテキスト」という言葉は、「物事が存在する、または発生する状況の前後関係」と定義されています。いささかあっさりとした定義ですが、サイバーセキュリティの分野では、「コンテキスト」の意味を理解できるかどうかで、「実体の伴わない幽霊を追いかける」と「進行中の脅威や侵害を検知できるようになる」への分かれ目になります。

今日の環境において、コンテキストの重要性を示すことは難しくありません。毎日35万件を超えるマルウェアや望ましくないプログラムが発見され、攻撃者が標準のシステムツールを攻撃キャンペーンに利用する状況で、疑わしいイベントを逐一調査して環境を守ることが不可能だというのは誰の目にも明らかです。

こちらからサイランスの「Future of EDR」インフォグラフィックをご覧ください(PDF)

残念ながら、今日多くのセキュリティオペレーションセンター(SOC)が大量のセキュリティイベントへの対応に忙殺されていますが、その多くには、無害なものと判断するか、早急な対応を要する重大または深刻なイベントとして最優先課題に引き上げるかを決めるのに必要なコンテキストが欠けています。セキュリティ攻撃におけるこのようなデータの爆発的増加を助長する極めて厄介な存在として、「 エンドポイントにおける検知と対応(EDR)」と呼ばれるテクノロジーの一種が挙げられます。

EDR テクノロジーの開発に至ったコンセプトは、「アンチウイルスでは環境に対する脅威を漏れなく特定して阻止することはできない。そのため疑わしい動作がないかエンドポイントを監視し、発見した場合はセキュリティアナリストに警告するための別の手だてが必要」というシンプルなものでした。

たいていのアイデアは簡単に伝えることができますが、いざ実践するとなるとたちまち複雑になります。EDRテクノロジーが持つ複雑さは、データに始まり、データに終わると言えます。アンチウイルスが見逃す恐れのある「すべての事象」を特定するには、「すべての」エンドポイントの「すべての事象」を「常に」収集して分析する必要があります。それが膨大な量のデータになるということを理解するのにあえて数学的な解説はいらないでしょう。そこで問題になるのが、そのデータをどこに保存し、どのように収集し、どのように分析するのかということです。

この新たなテクノロジーを採用したたいていの組織が、いつの間にか、ギガバイトやテラバイト、時にはペタバイト単位にまで膨れ上がった巨大なデータの山を目の当たりにしました。ユーザーがラップトップを起動し、電子メールをチェックし、Word文書を新たに作成するたびに、また、オンラインでこのレポートを読むときですら、EDRはあらゆる変化に耳を澄ませ、見逃さないようにします。毎日、いついかなるときもです。

中小企業でさえ500台程度のエンドポイントを稼働させている可能性を考えれば、途方もない作業だとわかります。この際、数十万台に上るエンドポイントが監視対象となるグローバル企業のことは忘れましょう。これほどのデータに対処する上で許容し得る戦略を特定できたとして、次に解決すべき問題はその分析方法の特定になります。

ご存じのとおり、その唯一の問題は、脅威を取り巻く環境が変化していくという点です。攻撃者は絶えず手口の見直しや改良を図っているため、それらの脅威を特定するために設計されたルールもまた、見直しや改良を定期的に行う必要があります。そうしなければ、SOCが目にするEDRの警告数は見る間に減っていくでしょう。これは決して攻撃者の勢いが弱まったということではありません。むしろ、攻撃者がルールの攻略に成功して、環境内を自由に動き回っている可能性があることを意味します。

では、データの問題を解決し、ルールを最新の状態に維持する方法を見つけたと仮定しましょう。そこで、最後に越えなければならない障害となるのが、この記事の冒頭で挙げた「コンテキスト」です。

コンテキストに関する問題点

コンテキストに関する問題点を理解するにあたって、まずは機械のしくみについて考えます。機械、とりわけ特定目的のために設計されたものは、どうしても視野が狭くなってしまいます。たとえば、目覚まし時計を考えてみてください。通常、毎朝6時に起きなければならないとします。アラームをセットすると、毎日あなたの好きな曲または音色で起こされ、1日が始まります。しかし、アラームをオフにするのを忘れると、休日に飛び起きることになります。果たして目覚まし時計は壊れたのでしょうか。いいえ、アラームは完璧に機能しました。問題は、「今日は午前6時に起きる必要がない」というコンテキストが欠けていたことです。

では話をセキュリティの世界に戻しましょう。従来型のルールエンジンは、基本的に設定されたすべての目覚まし時計を管理しており、それぞれの目覚まし時計は、分、秒、さらにはミリ秒単位で鳴るのを待っている状態です。ベッドサイドの目覚まし時計と同様に、適切なコンテキストがない場合の問題点は、それらの目覚まし時計が絶えずSOCのアナリストの耳元で鳴り響いている中で、他の目覚まし時計も鳴っているという概念がほとんど、またはまったくないという点だと言えるでしょう。これはなんとも疲れる状況ですが、幸い、コンテキストによって解決できる問題でもあります。

コンテキストは、午前6時のアラームのように、1つ以上の「ゲート」をアラームごとに追加します。これは、すべての条件または特定の条件が揃ったときにだけアラームが鳴るように指示するためのものです。たとえば、コマンドプロンプトまたはPowerShellが使用されていることを見つけるアラームがあったとして、「条件」が一切設定されていなければ、アラーム攻めに遭うことを覚悟する必要があります。

ここで、その状況に陥る代わりにアラームに特定のコンテキストを与えると、一度無害と判断されたアラームは回避されるため、SOCに届くアラームがまともな理由で減少するはずです。それでは実例を見てみましょう。オペレーティングシステムにデフォルトでインストールされた一般に信頼されているプログラムを悪用する、「環境寄生型」攻撃と呼ばれる戦術、手口、手順が増えています。この状況は、環境内のセキュリティ担当者が忙殺されることなく最高水準の保護を実現する上で、一連の確実なコンテキストデータが欠かせない理由を示す好例と言えます。

環境寄生型攻撃は、装備が不十分な環境で検知して自動的に適切な対処を行うことが難しいため、ますます一般的になっています。その原因は、これらの攻撃が、オペレーティングシステムの開発チームによって開発され、信頼を得ているプログラムを利用することにあります。その盲目的なレベルの信頼こそが、それらのプログラムにアンチウイルスソリューションの監視の目をすり抜けて実行する余地を与えています。単純にファイルレベルの分析に基づいてこうしたプログラムの 1つを隔離したり削除したりすると、システムが不安定になってしまうためです。

さらに状況を複雑にしているのは、最近までこのような信頼されたプログラムの多くがシステム管理者にもセキュリティスタッフにもほとんど知られていなかったという事実です。しかも、プログラムによっては、搭載されている強力な機能や意外な機能について詳述したドキュメントがほとんど、またはまったく提供されていません。結果的に、セキュリティチームがそもそも何を探すべきかわからなかったり、環境内に存在するさまざまなリスク領域を理解していなかったりといった状況が生まれるのは当然です。

その好例として、2018年全体を通じて多くの企業が直面したことでかなり有名になった、Microsoft Officeに含まれる動的データ交換の脆弱性が挙げられます。この脆弱性では、Microsoft Officeアプリケーションに含まれる知名度の低い「動的データ交換(DDE)」という機能が使用されていました。DDE機能は、基本的にシステム上で任意のコマンドを実行することを目的として、Microsoftのアプリケーション間でデータをシームレスに転送できるようにするために設計されたものです。

一般に出回っている手口では、この脆弱性は、Microsoftアプリケーションに強制的に子プロセス(通常、PowerShell)を生成させた後で、標的となったシステム上で別のペイロード(マルウェア、スクリプト、その他の信頼できないコード)をダウンロードして実行するために使われました。

DDE攻撃の全ライフサイクルについてこのような説明を行うことで、それがなぜ、どのようにして悪意のある目的に使用されるのかがかなりはっきりしてきます。なぜなら、コンテキストに攻撃の全体的な説明が与えられるからです。攻撃の説明をより細かく分解すると、コンテキストの必要性がより一層明確になります。

この攻撃を検知して阻止するために必要とされる最も基本的なレベルのコンテキストでは、アナリストが関連プロセスにアクセスできる必要があります。たとえば、Microsoft Officeアプリケーション(Microsoft Word)やPowerShellなどです。システム上で実行されているこの2つのプログラムを観察していても、アラームの発生要因になることは通常ありません。どちらも多くの環境で一般的に利用されているためです。

次に必要とされるレベルのコンテキストは、プロセスの起源です。この例では、Microsoft WordがPowerShellを生成します。たいていの場合、このようなプロセスの相互関係は多くの環境で不要とされ、異常と見なされるので、このレベルのコンテキストだけで調査を正当化することも、対処することも十分可能だと思われますが、それでも一定の状況下では誤ったアラートが発生しやすくなります。

プロセスを細かく分析するほど、アナリストや対処アクションの自動化に役立つコンテキストが増えます。コマンドライン引数など、いくつかのプロセスの詳細情報は、特定のアクションにおける悪意の有無を判断するための完璧に近いメカニズムを実現する際にこの上ない特性になることが考えられます。特にコンテキストにおけるより基本的な層と組み合わせる場合はなおさらです。前述の例では、遠隔地からコンテンツのダウンロードを試みることを示唆する一連のコマンドライン引数によって、PowerShellが呼び出される可能性があります。

ソリューション:インテリジェントなコンテキスト

コンテキストを細かく分解することで得られる最高のメリットは、さまざまなレベルのシステムアクティビティ(開始されるプロセスや、作成されるファイルなど)を、論理的な方法で自動的またはインテリジェントに関連付けられるようになることです。このレベルのコンテキストによって、検知と対応のロジックを非常に具体的なパラメーターに合わせて微調整することが可能になります。

このレベルの「コンテキスト」にまでイベントを分解することで、悪意のあるシステム動作の検知に関する複雑な問題を説明できるようになるだけでなく、コンテキストスタックの複数のレベルで検知と対応のロジックを導入するための方法を明確に理解して、環境の状態についてセキュリティチームが受け取るアラートの種類と件数を微調整できるようになります。

では、コンテキストによってセキュリティ上のすべての問題が解決されるでしょうか。もちろんそんなことはありません。解決されると断言するのは愚かなことです。攻撃者は確固たる意志を持った集団であり、常に目的を果たすための新たな手段を模索するはずです。

ただ、1つだけ確かなことは、コンテキスト分析の自動化を何らかの形で導入したSOCで働くか、そうでないSOCで働くかを選択できるなら、導入した方を選択すべきだということです。そうすれば、夜間や週末の時間を静かに過ごすことができるかもしれません。

Tags: