Cato クラウドの XDR
Cato クラウドでは、ネットワークのトラフィックやエンドポイントの振る舞いなどの各種ログを Cato 独自の AI や機械学習アルゴリズムによって分析し、セキュリティ上の攻撃や脅威を自動的に検知する機能が提供されています。
この機能は XDR (Extended Detection and Response) と呼ばれており、問題を早期に発見・対処することを目的として、検知された問題を確認するダッシュボードやそれを分析するための一連のツールが用意されています。
この機能は情報セキュリティにおけるインシデントレスポンスを行う上で非常に有益なものであるのですが、活用するにはハードルが高いものであるとも感じています。そこで本記事では、そのギャップを埋めてお客様に XDR 機能を活用していただくために、XDR 機能を用いた運用例について説明します。
なお、Cato クラウドの XDR の紹介や基本的な利用シナリオについては次の記事にも記載しておりますので、そちらを先にご覧ください。（翻訳記事のため読みにくい部分がありますが、ご容赦ください。）
XDR 機能を用いたセキュリティ運用例
Cato クラウドの XDR 機能では、検知したセキュリティを脅かすインシデントのことを「ストーリー」と呼んでいます。1つのストーリーは基本的に異なるセキュリティ上の問題を示していますので、ストーリー単位で運用を行っていきます。
XDR 機能を用いたセキュリティ運用としては、次のように実施していくのが良いと考えています。
1. 新しいストーリーが作成されたことを認識する
まずは、ストーリー・ダッシュボード画面やストーリー・ワークベンチ画面を定期的に確認し、新しくストーリーが作成されていないか確認しましょう。各画面は、CMA の [Monitoring] > [Stories Dashboard] や [Stories Workbench] から見れます。画面の詳細な見方については、先述の「世界初SASEベースのXDRについて」の記事を参照ください。
また、定期的に確認する運用では新しいストーリーに気付くのが遅れる可能性がありますので、後述のようにメール通知などによって気付けるようにすると良いです。
2. ストーリー一覧を確認する
新しいストーリーが作成されていれば、ストーリー・ワークベンチ画面で現在オープン中のストーリーの一覧を確認しましょう。
一覧画面で注目すべき項目は次の3か所です。
| 注目べき項目 | 内容 |
| Criticality | 重要度を表す 1 (低) ～ 10 (高) の値 Cato クラウド独自のアルゴリズムで算出される |
| Indicator | ストーリーの内容を簡潔に表す識別名 |
| Producer | ストーリーのタイプ |
2024年4月時点では、Producer として次の5種類が定義されています。(参考)
| Producer | 内容 |
| Threat Prevention | IPS 機能で攻撃の振る舞いを検知した |
| Threat Hunting | イベント情報やより多くのトラフィックデータをもとに、広い範囲の攻撃の振る舞いが見つかった |
| Usage Anomaly | アプリケーションで通常とは異なる使用状況の兆候が見つかった (アップストリーム通信の帯域幅が通常と異なるなど) |
| Events Anomaly | 通常とは異なる量のセキュリティイベントを発生させているモノの兆候を検知した |
| Network XDR | ネットワークに関する劣化 (Socket ダウンやリンクダウン) が発生した |
Cato クラウドの Threat Prevention (旧 IPS) オプションを契約のお客様の環境では、「Threat Prevention」と「Network XDR」の2種類がストーリーとして検知されます。全ての種類を検知させるには、XDR Security Pro オプションの契約が必要となります。
また、「Network XDR」タイプは Socket の障害や拠点のインターネット回線の障害などによって発生しますが、障害が回復するとストーリーも自動でクローズされます。そのため、ストーリーに対して具体的に何らかの運用が必要になるというわけではありません。
以下では、「Threat Prevention」タイプに絞って、詳細の確認方法や対処方法について説明します。
3. ストーリーを分析する
ストーリー・ワークベンチ画面でストーリーを選択すると、ストーリーの詳細を確認できます。ストーリーの詳細を確認する目的は、該当のストーリーがセキュリティ上問題があるものなのかどうか分析し、必要なら何かしら対処することにあります。
詳細画面には多くの情報が掲載されていますが、特に注目すべき項目は次の箇所です。
| 注目すべき項目 | 内容 |
| Description (Details の中) | Indicator (識別名) を詳しく表現した説明 |
| Direction (Details の中) | 関連する通信の向き (Inbound, Outbound, WANbound, All の4種類) |
| Mitre Tags (Details の中) | 該当する MITRE ATT&CK の種類 どのようなセキュリティ上の問題の可能性が検知されたか |
| Target Actions | 関連する通信が Cato クラウドのセキュリティ機能 (IPS, DNS Protection, Suspicious Activity など) でどう扱われたか |
| Targets | 関連する通信の相手に関する情報 Target (ホスト名・IPアドレス) や Registant Country (国名) が特に重要 |
| Attack Related Events | 関連する通信のイベント情報 Target (ホスト名・IPアドレス) や Destination Port (宛先ポート番号) が特に重要 |
これら情報をもとに、検知されたストーリーがセキュリティ上問題のあるものなのかどうか分析して判断しましょう。基本的には通信相手のホスト名や宛先ポート番号を見ればどういった通信か推測できることが多いと思います。単一の通信だけでなく、似た通信や異なる時間帯の通信も1つのストーリーに纏めて関連付けられていますので、分析しやすくなっています。それ以外にも、対象の通信の前後の時間帯で他にどのような通信が行われていたか、イベントログを確認すると分析の役に立ちます。
通信を行ったクライアントの情報も画面上で確認できますので、問題のあるものか判断しにくい場合はユーザにヒアリングしてみるのも良いですね。ただし、ユーザが認識していない通信 (例えば、アクセスした Web サイトに表示されている悪意ある広告など) の場合もあるという点に留意する必要があります。
実際は XDR 機能を利用する上でこの分析作業が最も難しく、機械的に行えるものでもないため、経験を積んで知見を蓄積していくしかない部分でもあります…。
4. ストーリーに対処する
ストーリーを分析した結果、それがセキュリティ上問題があるものだった場合、そのような通信がブロックされるように Internet Firewall や WAN Firewall 機能に設定を追加しましょう。IPS などのセキュリティ機能でブロックされていたとしても、将来の通信がセキュリティ機能をすり抜ける可能性や Cato クラウド側のアルゴリズム変更でブロックされなくなる可能性がありますので、Firewall 機能でブロックするのが確実です。
その後、ストーリー詳細画面の右上にある三点アイコンの Story Actions メニューから、ストーリーのステータスをクローズ (Closed) に変更しましょう。
その際、「Analyst Verdict」という入力欄では、どのように分析したか次の4つから選択する必要があります。
- Malicious (悪意ある)
- Suspicious (疑わしい)
- Informational (情報)
- Benign (無害)
選択した項目に応じてタイプや分類など詳細を任意で選択することもでき、入力しておけば将来的な分析にも役立てられるかと思います。
問題あるものか無害なものか判断できない場合は、ステータスを保留 (Pending Analysis または Pending More Info) に変更しておき、状況が変化したときにまた判断を行うというのでも良いです。
また、ストーリーがセキュリティ上問題のない無害なものだった場合、同様のストーリーが今後作成されないようにミュート (抑制) しましょう。この操作は Story Actions メニューにある「Add to new Muted Stories rule」というリンクから行えます。CMA の [Security] > [Detection & Response] > [Mute Stories] 画面からミュートを設定することもできますが、条件を手動で入力する必要があり、入力を間違えると問題あるストーリーまでミュートしてしまう可能性がありますので、ストーリーのステータスを変える際に合わせてミュートすることを推奨します。(参考)
その他：ストーリーの作成・更新通知を設定する
CMA の [Security] > [Detection & Response] > [Reponse Policy] 画面から、ストーリーが作成・更新されたときにメール通知や Webhook 送信などを行うことができます。(参考)
CMA のストーリー・ダッシュボード画面やワークベンチ画面を定期的に確認する運用では新しいストーリーに気付くのが遅れてしまう可能性があるため、確実に気付けるよう通知設定を行うようにしましょう。ストーリーのタイプや重要度などの特定の条件に当てはまるものだけ通知することもできますが、まずは無条件で全て通知するようにしておき、通知量が多くなってきたら条件を付けて調整するのが良いと思います。
所感・課題点
本記事では XDR 機能を用いた基本的なセキュリティ運用の例を説明しましたが、実際に運用しようとすると超えるべきハードルや悩ましい点が多いというのが実情です。
まず、利用上の問題やセキュリティ上の実害が起きない限り、セキュリティ運用を実施する動機も沸かないのではないでしょうか。私自身としても、Cato クラウドが良きに働いてセキュリティ面で守ってくれるよう完全にお任せしてしまいたいと思っています。しかし、Cato クラウドで検知されたストーリーの内容を把握するようにすれば、企業システムの Cato クラウド以外の部分で発生した根本的な問題に気付けるというメリットもあります。例えば、PCがマルウェアに感染して不正な通信を行っているような場合、Cato クラウドの機能でそのことに気付くことができれば、素早く適切な対応を行えます。そのため、Cato クラウドに任せっきりにせずに、セキュリティ運用はしっかりと実施していかないといけません。
次に、やはり検知されたストーリーの内容の把握・分析・判断は難しく、なんとなく理解して推測できるものの確信を持てないことが多いです。ストーリーに該当する通信をブロックしてしまうとどこかで業務上の影響が発生してしまう可能性もあるため、セキュリティ上の問題の有無を判断するための基準や指針が必要となってきます。気軽に通信をブロックし、業務上の影響が発生したら元に戻せば良いという運用で良いのであれば気楽ではあるのですが、お客様の会社の規模によってはそういうわけにいかないこともあるかと思います。
そして、Cato クラウドがストーリーとして検知する際のアルゴリズムが非公開でよくわからないという点も悩ましいです。インターネット上で観測される様々な攻撃パターンや Cato の多数の顧客のトラフィック情報などをもとにアルゴリズムは日々改良されているものと推測されますが、どの程度の精度でストーリーが検知されているのかイマイチよくわかりません。また、故意に検知される方法もわからないため、運用テストも行えないのが困ります…。
とはいえ、いろいろ課題はあるものの XDR 機能は有益であることは間違いありませんので、より活用しやすくなる方法について今後も検討を続けていきます！