はじめに

今回のブログでは2回に分けて、Endpoint Detection and Response（EDR)の仕組み・導入効果と、運用上の課題について取上げます。

世の中のセキュリティソリューションにEDRが登場して以降、数年が経とうとしています。EDRはこれまで検知が難しかったシステムに侵入した攻撃者の行動やマルウェアの活動を明らかにすることができ、且つ組織に所属する数千ものエンドポイントの活動を横断的に分析・モニタリングし、インシデント対応者がアラートに応じたアクションを実行することが可能な製品です。

これまで様々なベンダーのEDR製品がリリースされていますが、運用の難しさが議論される機会は少ないのが実態です。本トピックでは、EDR製品が防御する側の人間にとってどのように有益に働くのか、また運用における課題とその対策について取上げます。

EDRアーキテクチャ

まず本題に触れる前に改めて、EDRの役割とその基本的なアーキテクチャについて振り返ります。

ここで取上げるEDRとは、一般的に攻撃者の環境侵入後の活動であるPost-Exploitフェーズの検出に役立つセキュリティソリューションを指します。エンドポイントであるPCやサーバ上のイベントに関するデータを収集・分析するためのエージェントと、データを中央集約することで一元的に分析・モニタリング・インシデント対処を可能とするバックエンドのシステムにより構成されます。

EDRは概ね以下のコンポーネントを有する分散的なシステムを有します。

エージェント

エージェントはテレメトリからデータを制御およびエンドポイント上で発生するイベントのログを取得し、それらを特定のアクティビティまたは一連のイベントが攻撃者の行動と一致するかどうかを判断するために基本的な分析を実行する役割を担います。また、エージェントは、テレメトリが取得したイベントのログをバックエンドであるメインサーバーに転送する役割も果たします。

エージェントは自身がインストールされたエンドポイントの何らかのアクティビティが、悪意のある活動と関連するものと判断した場合、バックエンドシステムにその活動のデータを送信し、ダッシュボードにセキュリティインシデントおよびイベントアラートの形でその悪意のあるアクティビティを記録します。またアクションを実行しているプログラムに失敗を示す値を返すことによって、悪意のある操作の実行を失敗させるようなアクティブディフェンスが可能です。

テレメトリ

EDRにおけるセンサーの目的は、エンドポイント上のテレメトリの収集です。これは、エンドポイント上で生成されるRawデータです。ファイルを開く行為や新しいプロセスを生成するなどのエンドポイント上のイベントにより発生するデータであり、システム上のすべての動作は、何らかの形のテレメトリデータを生成します。これらのデータは、EDR製品における攻撃者の悪意のある活動を検出するためのアラートロジックのデータソースとなります。

センサー

センサーは、テレメトリであるプロセスがどのように作成されたか、またはファイルがどのようにアクセスされたかに関する情報を収集し、エージェント、若しくはバックエンドシステムの検出ロジックにデータを渡します。この検出ロジックは、環境ヒューリスティック的な分析や静的シグネチャによるプログラムのスキャンなど方法を使用してアクティビティが良性か悪性かを確認しようとします。

Windowsには多数のテレメトリソースがありますが、EDRでは通常、一部のみに焦点を当てています。

これは特定のソースがデータの質や量を欠いているか、ホストのセキュリティに関連しないか簡単にアクセスできない可能性があるためです。また、EDRベンダーによって製品設計や価格設定、ライセンス形態などを理由とし、これら情報源のテレメトリソースの種類が異なる場合も考えられます。

このテレメトリリソースの差異は、直接EDR製品間の性能の優劣を決定づけるものではありません。通常EDRにおけるセンサーはシステムプロセスの経路上にいなければなりません。

つまりOSがディスクからプログラムをメモリにロードし、プロセスとしてCPUにより実行される途上でEDRはこれらのエンドポイントの動きの一部をテレメトリとして収集しています。この動作はEDRの存在しないシステムと比較し少なからず処理時間の遅延として現れる場合があります。特にこの点は、ジョブスケジューリングシステムのような昼夜問わず処理をせわしなく動かすようなサーバにとって気を払うべきです。またPCにおいても年々処理性能は向上しており、利用者にとってそのリソースを最大活用するためのプログラミングの垣根はノーコード開発ツールやRPAの普及により低くなり、さらに処理は複雑化しています。

センサーがどのようなテレメトリを収集しているか把握することはインシデントレスポンスにおいて重要であり、これらの情報はEDRの導入を検討する担当者にとって考慮すべきポイントの1つです。幸いなことにインターネット上には有志によるEDR製品毎のテレメトリリソースの差異を比較するプロジェクトが存在しており、これらのリソースは検討の大きな助けになります。

・EDR Telemetry
https://github.com/tsale/EDR-Telemetry

検出

EDRにおける検出とは、単一のテレメトリ、若しくは別々のテレメトリとシステムで実行されるいくつかの動作を関連付けるロジックです。これは例として以下の様な、特異な条件をチェックすることが可能です。

• ハッシュが既知のマルウェアと一致するファイルの存在
• 多くの異なるソースからくる複雑な一連のイベント（Webブラウザのプロセスから子プロセスが生成され、環境内のドメインコントローラーと通信を開始するような通常不可解な挙動）

EDRの検出ロジックは、通常エージェント、またはバックエンドに存在します。これらはそれぞれ単独で攻撃を検出することもあれば、2つの組み合わせで検出することもあります。各アプローチにはそれぞれ長所と短所があり、エージェントでの検出は、バックエンドに依存せずにマルウェアのブロックや簡単な分析をおこなうことができますが、環境横断的な分析や、複雑な状況を分析する能力はありません。対象的にバックエンドでの検出は膨大な検出ロジックに対応できますが、エージェントと通信しなければなりません。

EDRの運用における課題

これまで触れてきたようにEDRは、従来のセキュリティ製品では対応できなかった攻撃者の環境侵入後の活動をリアルタイムに可視化することができ、次世代FWと組み合わせることで多層防御の実現や、中央集約的な運用が可能なことによりインシデントレスポンスにおける運用コストが削減できるメリットがあります。しかし同時にEDRには運用においていくつかの解決しなければならない課題が存在します。

次回は、多くの組織が直面するEDRの運用における課題とその対処法について取り上げます。