Cortex XDRとPrisma Access 連携ソリューションの紹介

はじめに

こんにちは、今回のSEバーチャルチームシリーズを担当するCross Platform 2チームの島です。

唐突ですが、読者の皆さんが社内セキュリティ製品を使って脅威ハンティングをしているとき、時間がかかって面倒だなあ、嫌だなあ、と思う作業は何でしょうか。

たぶん、

• 大量のログやアラートが出て流れを追うのに苦労する
• 様々なLog Viewer画面を切り替えて確認する作業が大変

などが筆頭に上がるのではないかと考えます。

これが、1つのダッシュボード画面に関連するログや脅威情報が一元管理されていたり、アラートのサマリや一元管理されたダッシュボードへのリンクをSlackなどで通知してくれたら便利だし、時間も短縮できるし、かなり作業ストレスを減らせそうですよね。

そこで今回は、Cross Platform2 チームによる Cortex XDRとPrisma Accessの連携ソリューションを解説して、皆さんの調査ハンティング時間の短縮と効率化を応援したいと思います。

連携ソリューションの環境

我々はPalo Alto Networks製品の横断ソリューション環境を具現化するため、より多くの製品連携を試行錯誤しながら継続的に構築しています。

ここでは、最初に我々がめざしている最終形の構成案を紹介し、次に今現在の構成を紹介します。

構成案 (最終形)

最終形では、ログやアラート情報が以下の製品群からCortex Data LakeやCortex Data Layerに送信され蓄積されるようになります。

• PC上のCortex XDR endpoint agentとGlobalProtect app
• PA-Series Next-Generation Firewalls
• VM-Series Virtual Next-Generation Firewalls
• CN-Series Container Next-Generation Firewalls
• Panorama
• Prisma Access
• Prisma SD-WAN
• Prisma Cloud
• 3rd Party Data

Cortex Data LakeやCortex Data Layerに蓄積されたログやアラートは、Cortex XDRによって、アラートの集約や相関分析が行われます。

分析結果は、SlackやGmailなどに通知したり、Cortex XSOARのプレイブックによる自動化処理が行われます。

最終形の構成では、このような環境で横断ソリューションを具現化していきます。

現在の構成

一方、最終形に向けて構築中の現在の環境は上記のようになっています。

ログやアラート情報は、以下の製品群からCortex Data LakeやCortex Data Layerに送信・蓄積されています。

• PC上のCortex XDR endpoint agentとGlobalProtect app
• Microsoft Azure上のVM-Series Virtual Next-Generation Firewalls
• Prisma Access

現在の環境でもすでに前出の最終形と同じくアラートの集約や相関分析が可能です。

分析結果はSlackに通知できる状態になっています。

以下にこの現在の環境を使用したCortex XDRとPrisma Accessの連携ソリューションをご紹介します。

アラート検出のデモシナリオ

Cortex XDRとPrisma Accessの連携ソリューションでは、Prisma Accessで検出したアラートをCortex XDRに取り込みます。

Prisma Accessには以下のアラートを検出させます。

1. WildFire
2. Virus
3. Vulnerability
4. DNS Tunneling
5. DNS Query

1～3をデモシナリオ1として、4～5をデモシナリオ2としてそれぞれ紹介します。

デモシナリオ1: Eicar、WildFireサンプルファイルの検出

Prisma AccessのMobile Userを使用して、以下のファイルを端末にダウンロードすることにより、アラートを検出させます。

そして、そのアラートをCortex XDRに取り込んだ後、Slackに通知させます。

• Eicarファイル
• WildFireサンプルPE

Prisma Access

以下はPrisma AccessのActivity > Log Viewerにて、Firewall/Threatで検出したアラートです。

WildFire、Virus、Vulnerabilityのアラートが検出されています。

Cortex XDR

以下はCortex XDRのIncident Response > Incidentにて表示したものです。赤枠で囲んだ部分について、Prisma Accessでは3つのアラートが出力されていましたが、Cortex XDRでは自動的にアラートを集約したインシデントという形式で表示されます。

Slack

以下がCortex XDRのインシデントのAlert Sources (前出のCortex XDRの赤枠部分) をSlackに通知した内容です。

デモシナリオ2: DNS Tunnelingの検出

デモシナリオ1と同様にPrisma AccessのMobile Userを使います。ここではDNS Tunnelingトラフィックを発生させることでアラートを検出させるようにします。その後、アラートをCortex XDRに取り込んでSlackに通知します。

今回のデモシナリオでは、Cortex XDRのAnalyticsアラートの閾値を超えるトラフィックを発生させることがポイントです。

DNS Tunnelingについて

DNS Tunnelingは「10分間に10KB以上のDNS Tunnelingトラフィックがサブドメイン名でエンコードされて送信され、照会されたすべてのサブドメイン名が単一の疑わしいドメインだった場合」に「Analyticsアラートの閾値を超えた状態」になります。

この詳細はCortex XDR Analytics Alert Reference by detectorのDNS Tunnelingを参照してください。

Prisma Access

以下はPrisma AccessのActivity > Log Viewerにて、Firewall/Threatで検出したアラートです。

ここでは、ドメイン名が「teatrarmii[.]ru」の疑わしいドメインが spyware として検出されています。

Cortex XDR

以下はCortex XDRのIncident Response > Incidentの表示内容です。以下の赤枠で囲んだ部分で、Prisma Access のアラートが「PAN NGFW」として検出されています。これに加えて、「XDR Analytics」のアラートが「DNS Tunneling」として検出されています。

DNS Tunnelingでは、通常のDNSクエリであるかのように見せかけて、サブドメイン部分に暗号化した情報を含め、C&Cサーバーに送信します。以下の赤枠で囲んだ部分が暗号化されたサブドメインの例です。C&Cサーバーは、送られてきたDNSクエリのサブドメイン部分を繋ぎ合わせ、復号やエンコードを行い、送られた情報を復元します。このようにしてやりとりされる情報には、組織の機微情報、侵害したホストに関する情報、C&Cサーバーからのコマンドを実行した結果などがあります。

Slack

以下は上記のCortex XDRのインシデントのAlert SourcesをSlackに通知した例です。

さいごに

今回はCortex XDRとPrisma Access の連携ソリューションとして、2つのアラート検出のデモシナリオを紹介しました。これら2つのプラットフォームを連携させれば、1つのダッシュボード画面にアラートを集約してくれるので、イベントチェーンを追うのは楽になるし、相関分析までを一気通貫に行えます。また通知をSlackと連携すれば、Slackから通知のあった時だけダッシュボードを確認すればよくなり、アラート対応の効率化が期待できます。

我々Cross Platform 2 チームは今後、以下の2つの活動を検討中です。

• 追加のデモシナリオ作成
• Cortex XSOAR環境の構築

1つめでは、今回のデモシナリオよりも、もう少し具体的なアラート検出によるデモシナリオを作成したいと考えています。

2つめでは、現在の環境にCortex XSOARを導入することにより、Cortex XDRのインシデント発生後の自動化処理を実現したいと考えています。

いずれも皆さんにご興味を持って頂けるようなデモシナリオや環境構築を進めていきますので、今後の投稿にもご期待ください。

SEバーチャルチームによるブログシリーズはこちらからお読みになれます。