マクニカが見た「XDR」の理想と現実──関心高まる今だからこそ知っておくべきポイントとは

XDRはディテクション・アンド・レスポンスのハードルを下げる

　"eXtended Detection and Response"を直訳すると、「拡張された検知と対応」となる。一般的にXDRは「複数のセキュリティ防止、検出、対応コンポーネントからのデータとアラートを統合、関連付け、コンテキスト化するプラットフォーム」と捉えられている。また、マクニカでは「さまざまなセンサーからの情報を横断的に分析することで、可視性と検知を向上させ組織、企業を守る」としている。

　XDRは単体のセキュリティ技術ではなく、既存のさまざまなセキュリティ技術を組み合わせた考え方だ。その中では、EDR（Endpoint Detection and Response）が大きな存在であり、これを中心として構成される。その周囲には、NDR（Network Detection and Response）、SASE（Secure Access Service Edge）、ITDR（ID Threat Detection and Response）、SIEM（Security Information and Event Management）、UEBA（User and Entity Behavior Analytics）など、さまざまなセキュリティソリューションがあり、運用にはMDR（Managed Detection and Response）も入ってくるという。

　マクニカでは、こうしたXDRの構成要素を下図のように“3階層”で表している。

　一番下にデータソースがあり、EDRやNDR、SASEなどからアラートやログを収集・集約。センサー以外に、IDaaSや脆弱性管理のシステムなどから取得できるログも活用する。2層目の“データストア・エンジン”では、情報をデータレイクに蓄積し、正規化、相関する。さらにSearch & Huntingでログやアラートの中身を分析し、得られたインテリジェンスを用いて検知。そして、3層目にあたるユーザーインタフェース層がコンソールやダッシュボードにあたり、可視化して具体的なアクションに移していく。

　旧来のセキュリティ対策では、ディテクション（検知）し、それをブロックすることが主流だった。しかし現在では、あくまでも検知はきっかけに過ぎず、そこから“どのようにレスポンスをするか”が重要視されている。そして、レスポンスのためには、攻撃手法とその対策のトレンドを抑える必要があるのだ。

　たとえば1990年代から2000年代までは、DoSやウイルスをばらまく攻撃が多く、愉快犯が中心だった。ところが、2010年代から様相が変わり、パターンマッチングでは検知できない未知のウイルスが大量に出現すると「標的型攻撃」に潮流が変化。C2通信やドライブバイダウンロードといった手法が登場し、ラテラルムーブメント（Lateral Movement：組織内における感染の水平展開）により、一度侵入されると組織内に被害がどんどん広がっていった。加えて、OSコマンドを利用したフィッシング、ランサムウェアも大きな脅威となっている。外部公開済みのVPNやWebサーバー、アプリケーションサーバーなどの脆弱性を狙うような高度化した攻撃も目立つ。

　特に最近の攻撃は、「目的を達成するために入念な準備と能力を整え、組織化された“見えない攻撃”に変化しています」と笠井氏は指摘。脅威が高度化したことで検知できない部分が残るために、XDRではそれらすべての見える化を目指す。

　XDRの“DR”にあたる「ディテクション・アンド・レスポンス」から見てみよう。たとえば端末でEDRが不審なプロセスの振る舞いを検知すると、アラート内容からどのような攻撃かを判断し、被害内容を確認。端末の利用者や業務内容を把握した上で、端末や利用者のアクセス権限などから業務情報への影響を把握できる。必要であれば、初動対策としてネットワークを遮断して隔離することが可能だ。

　また、ここで終わらずにActive Directoryの認証ログ、盗まれた可能性のあるアカウントの履歴などを参照することで、いつ侵入されたのかを明らかにできる。さらに、情報漏えいしていないかを確認するためにファイルサーバーのログを確認。これら調査分析をすることで、ようやく原因の整理と恒久的な対策に進むことができる。こうした一連の流れが重要だとして、「初動対策で終わらないことがポイントです」と笠井氏は説明する。

　もちろん、実現に向けては、適切な製品選定と導入、脅威や脆弱性に対する知識、アラートやログを分析するスキル、さらに深夜でも対応可能な体制などが必要だ。その分だけコストが発生するなど、ディテクション・アンド・レスポンスを理解すればするほど、その大変さがわかると笠井氏。結果として対策に踏み出せず、セキュリティ成熟度をなかなか上げられない。これが組織の典型的な現状だと警鐘を鳴らす。そのような状況だからこそ、ディテクション・アンド・レスポンスのハードルを下げてくれる、XDRに注目が集まっているのだ。

XDR実現への一歩目は、「オープンXDR」のアプローチが有効

　XDRの設計プロセスでは、どのような製品、ログやアラートを使うのか。また、セキュリティ製品以外を含めて“何を見るべきか”考えて、ログ設計も必要だ。実際に複数製品を組み合わせるには、API開発も必要となる。ここには「オープン（ハイブリッド）XDR」のアプローチが役立つ。これは、サードパーティー連携を基本とした考えであり、APIを積極的に提供しているベンダー製品で構築するというもの。一方「クローズド（ネイティブ）XDR」では、単一ベンダーでルールを統合し、“統合力”を高める考え方だ。マクニカでは、前者にあたるオープンXDRのアプローチを推奨している。

　オープンXDRでは、EDRやNDRなど、それぞれのカテゴリにおいて最適な製品を選定できることが大きなメリットになる。その一方で課題として、サードパーティー連携となるため構築が難しいと思われがちだが、ベンダーの用意した枠組みにより、複数のセキュリティ製品の組み合わせが容易になる。連携を上手く実現することで複数ソースからのログの統合、関連付けによる最大活用も期待でき、平常時にはダッシュボードでログ状況を把握可能にし、認識レベルを上げていく。インシデントが発生した際には、XDRが迅速に検索や判断を支援。ログやアラートの分析では、AI技術を利用している点も重要だ。最近は、機械学習などで人間の経験やスキル、知識に依存せず異常を検知できる製品が増えている。

　また、XDRに期待されることが運用工数の低減と要求スキルの低下だ。XDRには、SOAR（Security Orchestration, Automation and Response）という要素があり、これによりアラートの取りこぼしを防止できるだけでなく、優先順位に基づいた対処が可能となる。さらには、端末を特定して隔離する作業を自動化できるだけでなく、ネットワークベースでの対処も可能なため、二次被害の拡大も防げる。

　さらに、脅威検知の精度向上も忘れてはいけない。ログやアラートをたくさん収集する分だけ過検知のアラートも発生してしまい、異常を見逃すような負のサイクルに陥ってしまうことも少なくないだろう。XDRの構築においては、ログの何を見るべきかを最初にきちんと設計することで、過検知を抑えることができる。調査分析の機能も充実しているため、追加調査も捗るようなポジティブなサイクルが生まれる。つまり、結果的に取り込むログを増やし、分析の幅を広げられる。

「XDR Lab」で“XDRの真の姿”を明らかにする

　マクニカでは、XDRのメリットを実感するためのプロジェクト「Macnica XDR Lab」を実施している。前述したような効果を実機で検証・理解することで、セキュリティ運用支援につなげることが狙いだ。今回の説明におけるXDR Labの構成は下図の通り。エンドポイントとメールゲートウェイがあり、ログ調査の対象はファイアウォールとActive Directory、それらをSIEMで分析するというシンプルなものだ。また、擬似攻撃シナリオを作り、運用者目線で実際にインシデント対応を体験できる。

　擬似攻撃シナリオでは、メールでRAT（Remote Administration Tool：遠隔操作ツール）入りのZipファイルを送付し、ユーザーがそれを開くところから始まる。PowerShellが起動されると、攻撃者が用意したC&CサーバーからPower Viewというネットワーク探索ツールをダウンロード。組織内で水平展開を行ったうえで、mimikatzというツールをダウンロードすることで、クレデンシャル情報を追加で窃取する。窃取したクレデンシャル情報を用いてサーバーにアクセスし、機密情報を奪うと、C&Cサーバーへアップロードするというものだ。

　では、同シナリオが実施されると、XDRはどのように働くのか。 EDR単体利用でも検知アラートがあがれば端末ごとに脅威を把握でき、組み合わせることで全体像を把握することは可能である。しかし、侵入の流れを把握したり検知できていないリスク範囲を把握したりするためには、IDの観点で調査を行うことが非常に重要だ。そこで一般的にはActive Directoryの認証ログを確認し、組織内におけるラテラルムーブメントを明らかにする。エンドポイントに加えてActive Directoryのログが見ることで、動きが明らかになっていく。これをXDRとして統合することで、シームレスかつスピーディな対応が可能となる。

　また、インシデント発生時に重要な観点となる情報の持ち出しも検知可能だ。EDRでは通信ログの取得が苦手なため被害内容の把握が出来ないケースがあるが、ファイアウォールなどネットワークログと相関分析をすることで、EDRで脅威があると判断された端末が一定期間で外にどれだけのデータを送っているかを一目で把握できる。さらに、Active Directoryの特権ログオンのイベントを見ることでリスク状況の把握もできる。今回XDR Labでは、独自の検知ルールを作成し、SIEMを実装することによって実現している。

　なお、今回のケースではSplunkのAPPを利用してアラートとログを集約しているが、SIEM側でAPPに相当する支援機能などが用意されていなければ、APIによる作り込みが必要になるという。複数ソースからログを取得して統合管理している場合、ルールやダッシュボードの工夫で全体像を把握できるが、一部ログの関連付けで難しい部分もある。

　また、検知ルール・アクションを事前定義して自動化することで、運用の手間が省けた一方で、実現のためには攻撃手法などの十分な理解が必要だ。怪しい振る舞いを検知するためのルール作成にもスキルや検証が必要であり、実際には過検知も発生することからチューニングの必要性があることも憶えておきたい。

　あらためてXDR実現のポイントとしては、適切な製品選定だけでなく、現実的なログ設計が必要となる。とはいえ、レスポンスを自動化するだけでも効果的であるため取り組んで欲しいと笠井氏。「XDRというキーワードの下、各ベンダーがどんどん製品を進化させています。今こそ、それらに含まれるナレッジをあわせて習得することで成熟度を上げるチャンスです」とエールを送った。