XDRは「データ集約」「相関分析」「対応」の自動化を実現するフレームワーク
2020年12月に発覚した、SolarWindsを通じたサプライチェーン攻撃は世界を震撼させた。当時FireEyeに所属しており、Trellix 技術本部 エンタープライズ事業部／パートナー事業部 技術本部長代理を務める清水雅史氏は「攻撃を受けた側の人間なので強く印象に残っています。最初はVPNの不審なログから攻撃を検知でき、調査をしてみるとRed Teamツールの一部が窃取されたことを確認できました。インシデントレスポンスのリーダーであるMandiantがやられたなんて……と衝撃的でした」と語る。
後の調査で、この攻撃は長期にわたり世界中に潜伏していたもので、多くの企業や政府機関が侵害に気づいていない状態だった。ここで検知できていなければ、今も潜伏は続いていたかもしれない。
このSolorWindsに関するインシデントの検知につながった大きな要因は、VPNと関連ログだった。そのため「各種ログを注意深く分析することで多面的に脅威動向を把握し、リスクを最小化するための防御態勢を構築する必要があります」と清水氏は強調する。
しかし現実に目をやるとアラートの量は年々倍増し、対応が追いつかずアラートを無視する様子も見られる。しかし、それは侵害を見過ごすことにもなりかねない。セキュリティ運用担当者へのアンケートでは、セキュリティ製品の課題として「複雑さとコスト」「統合性のなさ」「メンテナンス」などが上位に挙げられている。また、セキュリティ検知や対処など運用の課題では「高度な攻撃検知の改善」「自動復旧の導入」「対応時間の改善」が同じく上位にある。
そして近年では、これまで述べてきた課題に有効な対策として「XDR（Extended Detection and Response）」が注目されている。ただし、XDRは単一の製品ではなくフレームワークを指すため、人により捉え方が異なる。まずはXDRの定義から確認しよう。
XDRは名前が示すように検知と対応を多方面に拡張した（Extended）もの。複数の攻撃に対応するため、単一の製品でカバーできるものではない。複数のデータソースを集約することから始め、相関分析を行い、優先順位を付けることで“対応の自動化”を実現することが要件となる。
それでは次のような運用はXDRと言えるだろうか。
- SIEMを使用している
- ログはネットワーク、エンドポイント、メールから取り込んでいる
- 相関ルールを定義している
- チケット管理システムで対応している
実は、上記については要件を満たしているため「XDRに該当する」と清水氏は語る。
ガートナーが出しているガイドによるとXDRは、「オンプレミスとクラウドの垣根なく、部分最適化された複数のシステムを統合する必要があります」と清水氏は説明する。他にも、集めたテレメトリデータに脅威インテリジェンスをマッチングさせ、リアクティブではなく“プロアクティブな検知”を実現し、対応時間を短縮するための自動化や効率化も含む必要があるという。
[画像クリックで拡大]
現状課題を「統合性・検知・分析・自動化」から見る
現実のXDRはあるべき姿をどこまで実現できているだろうか。次の4つの観点から、現状と課題を見てみよう。
1. 複数システムの統合
XDRでは多種多様な攻撃に対応できるように、複数のシステムを統合する必要がある。子会社やグループ会社をもつ場合には、組織横断的に一元管理できるような対応も求められる。そのためには、全体を統合できる基盤（プラットフォーム）を導入することや、各種テレメトリデータを「正規化」していく必要がある。
しかし現実的には、製品が多数あることから一元管理は難しく、データの正規化も追いついていない。統合には工数も人材も要る。そこで特定のベンダー製品で固めるという割り切りもあるが、ベンダー依存が強くなり他社製品が選択できないなどの制約が生まれてしまう。
2. 脅威の検知
検知ルールは常にアップデートしていく必要があるため、収集したテレメトリから検知ルールを自動作成できることや、必要に応じて独自ルールを追加できる必要がある。そこで「SIEM（Security Information and Event Management）」活用に舵を切るが、SIEM自体の検知ルールや相関ルールが導入当初のままでルールが陳腐化していることも少なくない。うまく機能しないことを避けるためにも、更新を続ける必要があるのだ。
3. 分析
収集したデータを分析するのなら、アラート単位で分析するのでは不十分だと言う。アラートと相関した結果を基に優先順位をつけ、対応に必要な情報を自動的に出力する必要がある。
4. 対応の自動化
セキュリティ運用担当者のワークロードを減らすために、事前に定義できるワークフローは可能な限り自動化しておく必要がある。しかし、処理自動化の作り込みについてもシステム統合と同様に、工数や人材の壁がある。
清水氏は「XDRを実現するためにはこうした観点を考慮し、最小限の工数で課題解決することを念頭におきましょう」とアドバイスする。XDRの理想と現実とのギャップを埋めるためのポイントとなるのが「学習と適応」「ネイティブかつオープン」「専門家と組み込み」の3つ。
「学習と適応」とは、AIや機械学習を用いること。常に学習を続け、柔軟に適応していくことで次々と変化する脅威に動的に対応し、プロアクティブに検知できるようになる。「ネイティブかつオープン」とは、幅広い製品群の機能そのもの（ネイティブ）をオープンAPIでつなげることでシームレスな統合を実現できる。また、「専門家と組み込み」とは、専門家が分析した検知ルール、推奨プラン、自動化アクションを製品に組み込むことで、人材不足にも対応することだという。
こうしたことを実現しようとしているのが「Trellix XDR Platform」だ。なお、“Trellix”という新しいブランド名には「セキュリティに命を吹き込む」という意味が込められている。
Trellix XDR Platformは、旧FireEyeと旧McAfee Enterpriseが統合したことで網羅性が広がり、さらにオープンAPIを通じて650以上のセキュリティ機器を統合できるようになっている。10億以上のセンサーから収集したデータを基に、AIや機械学習で研さんを重ねることで検知能力を常に高めているという。統合により両社の脅威ラボにいる専門家も1つのチームとなったため、製品に組み込まれている専門家の知見はより厚みを増した。
XDRの有効性：広範な監視、検知の可能性、調査や対応の効率化
では、ここからは活用事例からXDRの有効性を見ていこう。
「UNC2452」によるサプライチェーン攻撃
冒頭に述べたSolorWindsを通じたサプライチェーン攻撃（UNC2452）は、旧FireEyeのXDRプラットフォームで検知されている。VPNログの接続元も含めるなど、UEBA（User and Entity Behavior Analytics：ユーザーとエンティティの行動分析）の観点から網羅的に確認できる状況が検知につながった。
[画像クリックで拡大]
最終的に攻撃はエンドポイントにたどり着くため、EDRさえあればいいと思うかもしれないが、実際にEDRでの検知を強化するほど過検知や端末負荷を招き、かえって検知が難しくなることもある。清水氏は「この事例から、XDRは単一製品で実現できないということ、統合すべき製品の幅を広げる“ネイティブかつオープン”の必要性、さらにVPNのログから不審さに気づいて深堀していくことができた専門家の存在、その知見を組み込むことの必要性に気づくことができるでしょう」と話す。
監視範囲を広げることで、侵害後の検知や対応を実現
統合性の観点から、特定ベンダー製品で固めるケースは少なくない。そうすると第三者の専門家による知見を得づらく検知精度が落ちるなど、侵害を広げてしまうことにもつながりかねない。実際にフィッシングから従業員のアカウントが乗っ取られたことにより、ビジネスアプリケーションを通じて侵害が広まり、データ漏えいを生じさせてしまったケースもある。とはいえ、オープンな製品を組み合わせるとなると、検知ルールの作成に追われてしまうことも事実だ。
侵入後の検知精度を高めるにはアプリケーション監視、フィッシングに関わるメッセージング監視、活動監視、データ漏えいに関わるDLP（Data Loss Prevention）監視など幅広い範囲で相関分析を行う必要がある。さらに、ネイティブの良さとオープンな接続性を両立できると望ましい。清水氏は「適切にXDRを実現できれば、第三者視点で構成ミス、脅威の監視を行いつつ、何か見つかれば自動的に分析・対応する仕組みを構築できます」と話す。
メールセキュリティを“すり抜けた”メールの対応
メールセキュリティを導入していても、脅威を含むメールがすり抜けてしまうこともある。そうなるとセキュリティ担当者は、侵害の調査やメールの隔離などの対応に追われてしまう。しかし、多くのメールセキュリティではシステムをすり抜けてしまったものについてはハッシュ値など情報を持ち合わせてないことが多い。
そこで清水氏は「（XDRで）適切にレスポンスを行うためには、悪意がないと判断されたものに対しても情報を提供し、シームレスにプラットフォームに取り込めることが必要になります。センサーを選定する際には、こうした連携も念頭においてください」と語る。
セキュリティ業務の自動化
アナリストの業務負荷を軽減するためには自動化が欠かせない。工数や人材が課題となっているが、固定的な作業から順番に自動化を実現していくことが現実的な最短経路となる。一般的なセキュリティオペレーションプラットフォームであればログを取り込めば初動対応ができたり、よく使われる自動化アクションも用意されたりしている。まずは、そうした自動化につながる機能を積極的に活用することが欠かせない。
実際にTrellixのSOCでは、L1とL2セキュリティにおけるアナリスト業務はほぼ自動化されており、一部のL3に関するアナリストがインシデント対応に集中できる体制を構築している。それだけ自動化が進んでいるということだ。なお、Trellix製品だけではなく他社製品も統合しているという。
Trellix XDR Platformでは、初動対応として脅威情報との突合やVirusTotal検索、関連ログの洗い出しなどを自動的に実施。その後、各センサーからの簡易解析結果を自動的に表示する。対応におけるプロセスについても、過去対応の参照、簡単な作業なら自動化が可能だ。
最後に清水氏は「ご興味があればTrellix SOCツアーやプロフェッショナルサービスの相談も受け付けておりますので、ぜひお声かけいただければと思います。今回のお話を今後のXDR導入検討の参考にしていただけると幸いです」と述べて講演を締めた。
