【SSE】[Zscaler] [ZIA] [設計] [個別] [非インライン] SOAR

はじめに

前回までは、NSSやCloud NSSを利用したログ転送について紹介しました。

ログをSIEMへ転送すると、様々なセキュリティイベントを検知・分析できるようになります。

しかし、アラートが発生するたびに管理者が手動で調査・設定変更を行っていては、迅速な対応は難しくなります。

そこで利用されるのが、SOAR（Security Orchestration, Automation and Response）です。

本記事では、SOARの概要と、ZIAと連携した運用イメージについて紹介します。

SOARとは

SOARとは、簡単に言えば、セキュリティ運用を自動化するための仕組みになります。

例えば、SIEMが悪意のあるURLへのアクセスを検知した場合、SOARはプレイブックに従って、

• 関連ログの収集
• 脅威情報との照合
• 管理者への通知
• ZIAの設定変更

などを自動で実施します。

つまり、SIEMは「検知する仕組み」、SOARは「対応を自動化する仕組み」

という役割になります。

ZIAとSOARの連携

ZIAでは、NSSやCloud NSSを利用してSIEMへログを転送します。

その後の流れは、

ZIA → NSS / Cloud NSS → SIEM → SOAR → ZIA API → 設定更新

となります。

SOARはSIEMで発生したイベントを受け取り、ZIAが提供するAPIを利用して、必要な設定変更を自動で実施します。

つまり、SOAR自身が通信を遮断するわけではありません。

ZIAのポリシーを更新することで、結果として通信を遮断する仕組みです。

SOARで自動化できること

SOARは、ZIAのAPIを利用して様々な設定を自動で更新できます。

実際の運用では、URLカテゴリなど、あらかじめ設計しておいたポリシーの参照先を更新する使い方が一般的です。

例えば、

• URLカテゴリへのURL追加・削除
• URLカテゴリを利用したURL Filteringの制御
• URLカテゴリを利用したSSL Inspection対象の変更
• URLカテゴリを利用したCloud Browser Isolationの適用
• Sandbox結果や通信ログの取得
• 管理者への通知など

つまり、SOARが直接通信を制御するのではなく、ポリシーが参照するカテゴリを更新することで、

結果として通信の動作を変更します。

URL Filteringとの連携

SOARと最も組み合わせられることが多いのが、URL Filteringです。

例えば、SOAR専用のURLカテゴリを作成し、

SOARにはそのカテゴリだけを更新できるAPI権限を払い出します。

すると、SIEMが悪意のあるURLを検知すると、SOARが自動でURLカテゴリへ追加し、

ZIAがそのURLへのアクセスを即座に拒否できるようになります。

イメージとしては、

SIEM → SOAR → SOAR用URLカテゴリ → URL Filtering → 通信拒否

という流れになります。

SOARは新しい制御を行うのではなく、既存のURL Filteringを自動更新するという考え方になります。

設計で重要なこと

SOARを利用する場合は、SOAR専用のURLカテゴリとURL Filteringルールを用意しておくことをおすすめします。

例えば、「SOAR Block」というURLカテゴリを作成し、

そのカテゴリを参照する拒否ルールをURL Filteringへ設定します。

SOARはAPI経由で、このカテゴリへURLを追加・削除するだけになります。

こうすることで、SOARが管理する範囲と、管理者が手動で管理する範囲を明確に分けられます。

ルール順序に注意

SOARによるブロックを期待通りに動作させるためには、URL Filteringのルール順序が重要です。

例えば、

1. Custom URL Category – Allow
2. Custom URL Category – Caution
3. Custom URL Category – Block
4. Zscaler URL Category – Allow
5. Zscaler URL Category – Caution
6. Zscaler URL Category – Block
7. SOAR – Block

という順番では、カスタム もしくは カテゴリURLに対して制御した許可・注意ルールが先に評価されるため、

SOAR – Blockに適用されるカスタムURLへ登録しても、許可もしくは注意アクションになる可能性があります。

そのため、SOAR用の拒否ルールは、通常の許可ルールより前・最初 に配置することをおすすめします。

1. SOAR – Block
2. Custom URL Category – Allow
3. Custom URL Category – Caution
4. Custom URL Category – Block
5. Zscaler URL Category – Allow
6. Zscaler URL Category – Caution
7. Zscaler URL Category – Block
8. SOARが追加したURLは最優先で評価され、確実に通信を遮断できます。

おわりに

SOARは、新しいセキュリティ機能を追加する製品ではありません。

SIEMが検知したイベントをもとに、既存のセキュリティポリシーを自動で更新する仕組みです。

ZIAと組み合わせることで、検知から遮断までの時間を短縮でき、SOC運用の効率化にもつながります。

設計では、API連携だけでなく、どのポリシーをSOARに管理させるかまで含めて設計することが重要になります。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン補助] URL Category

管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！