ZscalerのセキュリティアラートをMicrosoft Sentinelで分析できるようにしてみた

1. ZscalerのアラートをSIEMで監視する理由

企業のセキュリティ運用では、複数の製品から発生するアラートを効率的に管理することが重要です。NTT東日本ではMicrosoft製品のログはすでにSentinelでの統合監視を行えていますが、Secure Web Gateway製品であるZscalerのセキュリティアラートはSentinelと連携する機能が無く、Zscalerのポータル画面上で確認していました。

しかし、下記の課題からZscalerのアラートロジックと同等の機能をSentinel上に実現し、アラートをSentinelに統合することで監視運用を効率化する検討を行いました。

• 複数製品から発生するアラートを集約し、アラート管理を一元化してインシデント調査・アラート抑止設定を簡略化したい
• Zscalerポータル上でのログ検索に時間を要しているため、インシデント調査をより高速に進めたい
• ZscalerとMicrosoft製品のログを突合する際に発生する複数ポータル間の往復を解消し、運用負荷を低減したい

Microsoft Sentinelを用いた監視・分析・インシデント運用でお悩みの方NTT東日本のセキュリティエンジニアがご相談にお応えします。お気軽にお問い合わせください！

2. 実現したい機能

本取り組みでは、Microsoft Sentinelを活用したセキュリティ監視の高度化を目的に、主に以下の3点の実現を目指しました。

Zscalerのアラート抽出ロジックをSentinelで再現

まず取り組んだのは、Zscalerが生成するアラートを、Sentinelの分析ルール上で再現することです。

取り込んだログに対してKQL（Kusto Query Language）を用い、Zscalerのアラートと同等の条件でイベントを抽出できることを目標としました。

ただし、Zscalerが内部的に使用しているアラート抽出ロジックは公開されていません。そのため本稿で紹介する内容は、公開情報や実際のログ内容をもとに「可能な限り近い形」で再現したものとなります。完全に同一の検知ロジックを構築できるわけではない点については、あらかじめご理解ください。

インシデント調査に有用な情報（エンティティ）を付与する

次に重視したのが、インシデント調査を効率化するための情報付与です。

Sentinelの分析ルールでは「エンティティマッピング」を設定することで、ユーザー名やホスト名といった識別情報をアラートに紐づけることができます。

これにより、アラート発生後のインシデント調査において、影響を受けたユーザーや端末を即座に把握できるようになり、調査の初動対応をスムーズに行えることを狙いました。

複数アラートを1つのインシデントに集約する

最後に、運用面での負荷軽減を目的として、インシデントの集約にも取り組みました。

アラート単位でインシデントを生成してしまうと、類似事象であっても多数のインシデントが発生し、管理や調査が煩雑になります。

そこで、宛先ホスト名やユーザー単位といった共通要素を軸に、複数のアラートを1つのインシデントとしてグループ化する設計としました。これにより、インシデント数を抑えつつ、調査工数の削減につなげることを目指しました。

Microsoft Sentinelを用いた監視・分析・インシデント運用でお悩みの方NTT東日本のセキュリティエンジニアがご相談にお応えします。お気軽にお問い合わせください！

3. 設定方法

本章では実際の設定内容についてご説明します。

本コラムでは、分析ルールの全体的な設定手順のすべては記載しませんが、理解の助けになる概要と重要なポイントに絞ってご紹介します。

3-1. Zscalerのアラート抽出ロジックをSentinelの分析ルールで再現

Sentinelの分析ルールで設定できる「ルールのクエリ」を利用して、Zscalerのアラート抽出ロジックを参考にしつつ、独自のアラート抽出ロジックを再現します。

「ルールのクエリ」にはKQLを記載することができ、自由度の高いクエリを作成することが可能です。

ここで、アラート判定条件および除外条件をKQLで定義し、実運用を想定したアラート抽出ロジックを構築します。

ここでは、その一部として独自に設計したKQLロジックを紹介します。

＜実装例＞

let SHA256watchlist = (_GetWatchlist('FileHashList') | project SHA256);
CommonSecurityLog
| where DeviceProduct == 'NSSWeblog'
| where DeviceCustomString3Label == 'malwareclass' and (DeviceCustomString3 !in ('None', 'Behavior Analysis') or Activity contains 'botnet')
| where FileHash !in(SHA256watchlist) or EventOutcome == "200"

＜解説＞

• ウォッチリスト取得

let SHA256watchlist = (_GetWatchlist('FileHashList') | project SHA256);

'FileHashList'という名前のウォッチリストを取得し、’SHA256’カラムの情報を’SHA256watchlist’変数に格納しています。

ウォッチリストとは、IPやファイルハッシュ値などの情報を事前に設定することでクエリから参照できるカスタムリスト機能です。

'FileHashList'には監視業務を行う中で監視対象から除外するためのさまざまなファイルハッシュ値が格納されています。

• テーブル指定

CommonSecurityLog

CommonSecurityLogは、Zscalerのログが格納されているテーブルになります。

• 対象ログ指定

| where DeviceProduct == 'NSSWeblog'

DeviceProduct カラムには、Zscalerのログ（ウェブログ：NSSWeblog／ファイアウォールログ：NSSFWlog）が格納されています。

本設定では、ウェブログ（NSSWeblog）のみを対象として抽出しています。

• マルウェア判定

| where DeviceCustomString3Label == 'malwareclass' and (DeviceCustomString3 !in ('None', 'Behavior Analysis') or Activity contains 'botnet')

where DeviceCustomString3Label == 'malwareclass'

DeviceCustomString3Labelカラムにはマルウェアの分類情報が格納されています。

ここでは、'malwareclass'という文字列だけに絞り込むよう設定しています。

(DeviceCustomString3 !in ('None', 'Behavior Analysis')

DeviceCustomString3カラムには”office365”などの通信先サービス名が格納されています。

ここでは、'None'と'Behavior Analysis'という文字列以外を抽出するように設定しています。

or Activity contains 'botnet')

Activityカラムにはログイベントの種類や動作などの情報が格納されています。

ここでは、'botnet'という文字列が含まれているものも絞り込むように設定しています。

| where FileHash !in(SHA256watchlist) or EventOutcome == "200"

| where FileHash !in(SHA256watchlist)

FileHashカラムにはダウンロードしたファイルのハッシュ値が格納されています。

ここでは、事前に取得したウォッチリストに登録されているハッシュ値と一致するものを除外する設定としています。

or EventOutcome == "200"

EventOutcomeカラムにはHTTPステータスコードが格納されています。

ここでは、HTTPステータスコードが”200”のものに絞り込むように設定しています。

今回紹介したKQLはあくまで一部のものになりますが、このように拡張性の高いアラート抽出ロジックを設定することが可能です。

3-2. インシデント調査に利用する情報（エンティティ）を付与

インシデント監視者が実際に調査する上で重要となるファイル名やIPアドレスといったエンティティを表示するための設定を行っていきます。

Zscalerのログの内容を、エンティティとしてアラートに設定することができます。

設定できる内容はKQLでproject演算子を使って表示するように指定したカラムを設定することができます。

1つの分析ルールで最大10個のエンティティを定義することができ、1つのエンティティには最大3個の識別子を設定することが可能です。

例えば、1つのエンティティ内にファイル名とファイルハッシュ値の識別子を設定することで、アラートの分析に利用することができます。

1点注意する点として、エンティティは”Account”や”Host”など決められたものを利用する必要があり、エンティティの名前を自由に設定できません。

また、エンティティに付随する識別子名も決められているものを利用する必要があります。

例として、”IP”というエンティティの場合、“Address”と”AddressScope”という名前の識別子だけ利用することが可能です。

ただし、適切なエンティティ名／識別子名が無い場合には、近い項目へ暫定的に割り当てを行うことがあります（例：HTTP レスポンスコード → Process（エンティティ）、ProcessId（識別子））。このような運用を行う場合は、あらかじめSOCと事前合意する必要があります。

＜設定画面一部抜粋＞

3-3. 複数アラートを1つのインシデントにまとめる

実際の設定画面を元に解説します。

Incident settings

この分析ルールで発生したアラートからインシデントを作成するかどうかを設定します。アラートからインシデントを作成したいため、ここでは”Enabled”で設定しています。

Alert grouping

複数アラートを1つのインシデントにまとめるかどうかを設定します。複数アラートをグループ化したいため、”Enabled”で設定しています。

注意点として、最大150件のアラートを1つのインシデントにまとめられ、超過分は新しいインシデントとして作成されます。

Limit the group to alerts created within the selected time frame

グループ化するアラートの時間範囲を設定します。ここでは”30分”の範囲で発生したアラートをグループ化するように設定していますが、時間範囲については、検証と関連チームで議論を重ねたうえで適切な時間範囲を設定することが重要です。

Group alerts triggered by this analytics rule into a single incident by

このルールで発生したアラートを、指定した条件に基づいて1つのインシデントに集約します。

それぞれの条件については下記の通りです。

Grouping alerts into a single incident if all the entities match (recommended)

すべてのエンティティ（例：アカウント、IP、ホスト名）が一致する場合のみ、アラートを集約します。

Grouping all alerts triggered by this rule into a single incident

このルールで発生したすべてのアラートを、条件に関係なく1つのインシデントに集約します。

Grouping alerts into a single incident if the selected entity types and details match

特定のエンティティ（例：DNS、IP）が一致する場合に集約します。

ここでは、Zscalerログの宛先ホスト名（DNS）が一致するアラートを1つのインシデントに集約するように設定しています。

4. まとめ

本稿では、ZscalerのアラートをSentinelに統合し、分析・調査を効率化する取り組みをご紹介しました。

導入効果として、約1年間の期間でアラート対応件数は3,602件 → 1,716件と”約52%”の減少が確認でき、抑止・除外の仕組みが確実に機能していることが確認できました。

また、実稼働時間も31,549時間 → 20,217時間と”約36%”の減少が確認でき、不要アラートの抑止と件数減少により、総工数は大幅に圧縮されました。

これにより、SOCが本来注力すべき“意味のあるアラート”へリソースを集中しやすくなり、監視の密度と品質の両立が進んだと考えられます。

技術面では、① KQLによる近似ロジック実装（※Zscalerのアラート検出ロジックは非公開のため完全再現ではない）／② ウォッチリスト運用による除外最適化／③ エンティティ付与で識別子を管理／④ アラートのグルーピングでインシデント集約、の4点が鍵となりました。これらを組み合わせることで、誤検知の抑止と監視精度の向上を実現しています。

このコラムが皆さまのセキュリティ運用の効率化に貢献できれば幸いです。

NTT東日本では今までの社内運用で培ったノウハウを生かしたセキュリティ監視サービスを提供し、多くの企業さまにご利用いただいております。

社内の総合的なセキュリティ監視の導入を検討されている方は是非ともご相談ください。

これからゼロトラストセキュリティの導入を考えているが、自分たちではやりきれない、何をしたらいいかわからないという皆さま、是非、NTT東日本へご相談ください！皆さまの新しい働き方を全力サポートいたします！

Microsoft Sentinelを用いた監視・分析・インシデント運用でお悩みの方NTT東日本のセキュリティエンジニアがご相談にお応えします。お気軽にお問い合わせください！

過去のゼロトラストセキュリティのコラムはこちらからご覧いただけます。

• Microsoft Azureおよびその他のMicrosoft商標は、Microsoft Corporationの米国及びその他の国における登録商標または商標です。