セキュリティー・インテリジェンス

EDR/MDR導入を成功させる秘訣とは

2022-02-18

記事をシェアする:

クラウドサービスの利用やリモートワークの推進など、あらゆる場所から業務ができるような環境でのセキュリティ対策を考えるうえでは、従来型の、既存のインターネット(Untrust)とイントラネット(Trust)におけるNW境界防御・監視のみではなく、エンドポイント、クラウド等、各境界における防御・監視が重要となります。

エンドポイントにおける防御・監視の対策として、エンドポイントにてリスクを可視化して攻撃の検知・防御を実現するEDR（Endpoint Detection and Response）ソリューションの導入、及びそれらを外部のセキュリティサービスプロバイダによって監視するMDR（Managed Detection and Response）が話題になっておりますが、導入を進めるにあたってはいくつか考慮すべきポイントがあります。

本稿では、EDRとMDRの導入にあたり、考慮すべきポイントについてご紹介します。

以下に構成イメージを示します。

一般にEDR製品は端末側に専用プログラムをインストールするエージェント側製品と、インストールを必要としないエージェントレス型の製品がありますが、ここではエージェント型のEDRについて解説します。

エンドポイントのクライアント端末やサーバーにはEDRセンサーと呼ばれる軽量実行モジュールを導入し、クラウド上のEDR管理サーバーと連携します。EDR管理サーバーではEDRセンサーの動作を一括管理するポリシーの設定を行い、EDRセンサーと通信することでポリシーの適用や検知情報の分析が行われます。

EDRセンサーでは脅威の検知・マルウェアの自動遮断等が行われ、MDRではEDRコンソール上で検知されたイベントの確認、遠隔からのエンドポイントの操作などを行うことになります。

このようなEDR・MDRを構築するために考慮すべきポイントは以下の通りとなります。

考慮すべきポイント1：現在の環境を把握する

先ず初めに、導入前の環境を正しく把握することが重要です。特にEDRセンサーはクライアントOSによってサポートと非サポートのものがあります。またWindows OSにおいては延長サポート期限などの制約があるため、対象OSの調査と制約に対する対応方針を決定する必要があります。またLinux OSにおいてはKernel Versionを取得しEDRセンサーがサポートされているか確認が必要となるケースもあります。

また、既存で導入されているエンドポイント上のセキュリティ製品の把握も必要となります。導入予定のEDRの他に既に他社のエンドポイント製品、特にシグネチャベースのAV製品が既に運用されていることが想定されます。

この場合ユーザー側ではEDR導入期間の当初は既存AV製品と共存したいニーズを持っているケースがあります。ウィルス検疫の機能を既存AV製品側が実行している場合は、EDR側ではウィルスの検疫しない設定を行うことで、検疫処理の重複による不具合などを避けることが出来ます。

考慮すべきポイント2：グループとポシリーの設計

クライアント端末やサーバーは運用ポリシーが異なるケースがあります。具体的にはOA環境で使用しているPCと基幹系システムで使用しているサーバーは、新しいソフトウェアの導入に必要な検証プロセスが異なるケースがあります。

特にサーバーにEDRセンサーを導入する場合は、過検知等で業務アプリケーションに影響を与える場合がありますので、EDRセンサー導入に際しては十分な評価・検証が必要となります。

また、エンドポイントに適用するポリシーをクライアント端末やサーバーの種類により異なる設定とする際に必要となるのが、グループとポリシーの設計になります。例えば、通常の業務用エンドポイントでは、重要なインシデントが検知した場合は即遮断する一方で、各種アプリケーションの評価・検証用のエンドポイントでは検知のみで遮断はしないなど、どの種類のエンドポイントにどういったポリシーを適用するのか、またどういったグループ分けをするのかをあらかじめ検討し、方針を持っておく必要があります。

考慮すべきポイント3：ＮＷパフォーマンスへの影響

EDRセンサーとなる専用エージェントソフトウェアはセキュリティ対策用の情報を最新に保つため、ソフトウェアの更新が頻度高く行われる傾向にあります。クライアント端末やサーバーのエージェントソフトウェアに対して一斉に更新がかけられると、更新用のプログラムモジュールが一斉にダウンロードされるため、NW帯域をひっ迫してしまい、通常の業務通信に影響を与えてしまう可能性があります。このためエージェントソフトウェアの更新に関しては自動で行うか、手動で行うかなどパフォーマンス影響を考慮した方針作成が必要です。例えば更新の適用について、一度に適用する数を限定するようなポリシーを設定することで回避できる場合があるため、あらかじめ自社環境のNW帯域幅とその利用状況を把握しておき、更新ポリシーを検討する必要があります。

考慮すべきポイント4：移行ステップと動作モードについて

EDR製品を導入するにあたり、最初からマルウェアや不審な動作をブロックする動作モードにしている場合、業務アプリケーションを過検知する場合があります。既存の業務アプリケーションやサーバーに影響を与えたくない場合はあえて最初の導入時にはブロックは行わないようにする所謂「検知モード」で導入することが必要になります。このような過検知を「検知モード」で検出しチューニングを行う期間を設けることも重要です。その後、実際にブロックを行う本番の動作モード「ブロックモード」へ切り替えを行います。切り替えはポリシーの適用により実施します。

但し、検知モードはマルウェアや不審なアプリケーションであっても自動ブロックをしない設定であるため、既存セキュリティ製品の動作モードを確認しセキュリティレベルが低下しないよう、チューニング期間とモード切り替え方法を決定する必要があります。動作モードと機能についてはステークホルダーと十分にコミュニケーションを行い、事前に相互理解を行うことが重要となります。

導入期：グルーイングとポリシー設計、コンソール設定、説明会の実施、センサーの導入開始まで
プレ本番期：暫定運用から本番運用への過渡期、チューニング期間
本番期：本番運用開始

考慮すべきポイント5：脅威検知のカスタマイズと通知について

EDR製品は独自の脅威検知ロジックにより、マルウェアや不審なプログラムを検知、防御します。顧客が過去に経験したセキュリティインシデントを、新たに導入するEDRによって防ぐ事が出来るのか、効果測定を求めるケースがあります。また既に経験した攻撃については予めブロックリスト化しておきたいニーズもあります。このような場合にEDR製品独自の脅威検知ロジックのみではなく、ある程度カスタマイズ可能な静的ブロックリストなどの作成を行えることも重要となります。またグローバルな環境への導入においては、各国でEDR導入により検知される望ましくないアプリケーションなどが異なるケースが多く見られます。各国のIT担当者に個別の検知情報を通知し対応させるか、または本社側にすべて通知がされ対応判断を経たのちに各国へ対応を指示するか、方針を決定する必要があります。

考慮すべきポイント6：外部の監視運用サービスとの連携

外部の監視運用サービスにおけるインシデントレスポンスの内容についても事前にステークホルダー間で合意しておく必要があります。運用サービスベンダーによってサポートされる内容が異なるため、平時運用、有事運用の要件が選択している運用サービスベンダーで満たせるのか、事前に確認することが重要です。また多言語（日英中など）のグローバル環境においては運用サービスとの連絡言語などを事前に決定しておく必要があります。

なおEDR製品によっては運用サービス業者のドメインに対して、管理連携を行うためのプロセスがあります。具体的には書面に対する顧客のサインとドメイン許可通知のメール応答などがあります。運用サービスの開始時期に応じて滞りなく行う必要があります。