はじめに
セキュリティオペレーションセンター（SOC）におけるアラート対応負荷は年々高まっています。これには、セキュリティツールの増加、監視対象領域の拡大、発見される脆弱性の増加、攻撃の活発化など、様々な要因が組み合わさっています。
こうした状況の中、Cortex XSIAM による SOC ソリューションにおける基本コンセプトの１つが、アラートの生成からそのトリアージといった、アラート対応プロセスの前段から中段にかけてを可能な限り自動化することで、アナリストの対応負荷を軽減させ、対応・復旧までの時間（MTTR）を短縮することにあります。
Cortex XSIAM におけるアラートとインシデント
アラート対応の自動化について話を進める前に、Cortex XSIAM には「アラート」と「インシデント」という概念がありますので、まずはじめにこれらについて整理しましょう。
アラート
「アラート」は様々なサービス・デバイス・データソースなどにおいて、ルールや分析モデルなどによって生成される、単一のリスクを示す情報です。これらには以下のようなものがあります。
- エンドポイントのアクティビティに対して Cortex Agent が生成する Cortex Agent アラート
- 次世代ファイアウォールの Threat Log に記録される Threat アラート
- Cortex XSIAM に取り込まれたログに対して相関分析ルールを適用して生成される Correlation アラート
- Cortex XSIAM の Analytics Engine によって生成される Analytics アラート
- IOC や脅威インテリジェンスの情報との一致に対して生成されるアラート
- サードパーティファイアウォール製品から取り込んだアラート
これらは実際には一例で、これら以外にも、Cortex XSIAM は様々な異なる場所・データ・方法によって生成、または、それらを取り込み、アラートとして管理します。これらすべてのアラートは、単一の Alerts 画面に集約され管理されます。
図：アラート一覧画面
インシデント
一方、Cortex XSIAM のコンセプトにおいては、 この個々の「アラート」に対してSOC のセキュリティアナリストが対応するということはしません。
アラートは、あくまでもそのアラートの検知器が対象としている領域において検知した単一のリスクを示すものでしかありません。そのため、セキュリティアナリストが発生したリスクのより全体的な像を把握するには、様々な領域で検知されたアラートの相関関係などから推測する必要があります。
Cortex XSIAM では関連するアラートを自動的にグループ化し、それを「インシデント」として起票します。そのため、Cortex XSIAM においては、セキュリティアナリストが確認・対処していくものは、この「インシデント」になります。
アラートへの考え方
セキュリティアナリストがリスクの全体像を把握するために、様々な場所で発生した関連するアラートの関係性を確認することが必要となるということは、アラートはそのための貴重な情報源といえます。
一方で、様々なサービスやデバイスで発生するアラートは、それぞれ異なるデータソースと異なるポリシーによって生成されます。つまりは、リスク検知の精度や信頼性、アラートに対して付与される重大度の方針、などがそれぞれ異なっているということです。それらを収集し一元管理するということは、そうした異なる信頼性の重大度のアラートが混在することになり、それを利用した優先順位付けなどの対応は混乱をもたらす可能性があります。
また一般に、限定された領域やデータソースから生成されるアラートは、その精度や信頼性が低くなります。そのため、そのような領域のサービスやデバイスから数多くのアラートが生成され、それがセキュリティアナリストの対応負荷を高めている場合、その対策として過検知と考えられるアラートを生成しないようフィルタリングする、などの対応が行われることがあります。しかしながら、これは真のリスクも検知からふるい落とされてしまう可能性があり、良い方法とは言えません。
アラートをイベントとして扱う
過検知そのものは決して悪いものではありません。問題はそれが「アラート」として生成されることです。もしそれが、もっと Informational なイベント情報として生成され、普段は目立つことのない領域に蓄積される一方、リスク調査の際には一般のログなどとは異なる、リスクの可能性のあるイベントとして可視化できるなら、それは非常に役立つ情報源となります。逆に、過検知であるからとそれらを出さない方向にしてしまうことは、リスク検知漏れにつながるだけでなく、真にリスクが発生した際の調査において、情報不足により調査に時間がかかる可能性があり、個々のリスク対応においては、結果的にセキュリティアナリストの作業時間が増えるという結果になりかねません。
つまり、フィルタリングによりアラートの数を減らすのではなく、アラートを適切にトリアージし、「アラート」に足るリスク、精度、および、信頼性を持たないものはイベントに格下げすることが重要になってきます。当然、これらを人手で行うのであれば、負荷軽減という目的を達成することはできないため、こうした部分を自動化することが必要になってきます。
アラートのグループ化とインシデント
Cortex XSIAM において、「インシデント」はアラートがグループ化されたものであることを説明いたしましたが、アラート対応の自動化を考える上で、これについてもう少し深堀りしたいと思います。
アラートのグループ化とリスク可能性
まず、グループ化されたという言葉通りインシデントは複数のアラートを含むことが可能ですが、グループとなる他のアラートがなければ、インシデントは１つのアラートしか持ちません。
また、インシデントに含まれるアラート群は固定化されたものではありません。例えば、攻撃者が活動を行い、その活動期間中に行った様々な場所でのリスク活動がそれぞれアラートとして報告されたとします。当然それらのアラートはあるタイミングで一括して生じるものではなく、基本的には活動の時系列にしたがって、検知されたタイミングで時間差を伴ってそれぞれから上がってくる形になります。
そのため、インシデントへのアラートのグループ化は、蓄積されたアラートに関連性が見いだされてインシデントとして起票される一方で、時間経過とともに生じたアラートが既に起票済みのインシデントに関連する場合は、それに追加される形でインシデントのグループ化が成長します。
玉石混合のアラートから、「アラート」に足るリスクや精度・信頼性を持たないものを格下げするか判断を行うという観点からこれらのことを考えると、たとえ質の低いアラートを生成するサービスやデバイスであっても、異なる様々な場所から関連するアラートが出ているとすれば、それが実際にリスクである確率は高くなると考えられます。一方で、過検知の多いサービスやデバイスから生成されたアラートが、他からの関連するアラートがまったくない状態で単独でインシデントとして存在している場合、それはイベントに格下げしてもよいリスク可能性の低いものであると考えることもできます。しかしながら、単体アラートがインシデントとなっている場合は、そのインシデントが時間の経過により他のアラートと結びつき、後にリスクである可能性が高まることがある点に注意する必要があります。
アラートステータスとインシデントステータス
Cortex XSIAM では、「アラート」と「インシデント」それぞれに対応ステータス（New, Under Investigation, Resolved）が定義されています。先に説明した通り、Cortex XSIAM のコンセプトでは、セキュリティアナリストが確認・対処していくものは「インシデント」になります。つまり、セキュリティアナリストの目標は起票されたそれぞれの「インシデント」に対応し、それらの対応ステータスをすべて Resolved とすることが目標となります。
セキュリティアナリストがインシデントステータスを Resolved に変更した場合、そのインシデントは解決済みとなります。この状態においてそのインシデントに関連するようなアラートが発生した場合、それは既に解決済みのインシデントにグループ化されるようなことはなく、新規のインシデントとして起票されます。
一方 Cortex XSIAM では、アラートに Playbook を紐づけてアラートごとの自動化処理を実行することができます。Playbook の自動化処理の中でアラートをクローズ （Resolved に変更）し、インシデントに含まれているすべてのアラートが Resolved になると、そのインシデントは自動的に Resolved ステータスとなります（Resolved - Auto Resolve）。このインシデントはセキュリティアナリストが設定した Resolved とは異なり、このインシデントに関連するようなアラートが発生した場合、自動的に再オープンされてそのインシデントにグループ化されます。
アラートのイベントへの自動格下げ
この Auto Resolve のインシデントが自動再オープンされるという動作を、アラートのイベントへの格下げという観点で考えてみます。そうすると、アラート Playbook の処理において、その時点の情報でアラートに足るかどうか判断し、アラート足り得なければそれをクローズすることでイベントへの格下げが達成できることになります。この理由は次の通りです。
- インシデントに Resolved のアラートしかなければ、インシデントは自動的に Resolved になる
→ アラート足りえないアラートからなるインシデントは、セキュリティアナリストの対応対象から自動的に外れる - 後に別のアラートがグループされ、インシデントが再オープンされれば、クローズしたアラートとともに確認できる
→ その時点ではリスクと捉えられていなかったとしても、追加されたアラートにより再度リスクとして表面化できる
→ 過検知と思われていたアラートが、実はリスクであったものとして可視化できる
ファイアウォールアラートのイベント格下げ
これまでの話をもとに、過検知の比較的多いサービスやデバイスからのイベント格下げの自動化シナリオを考えてみましょう。
今回は１つの具体例として、ファイアウォールからのアラートのイベント格下げを挙げたいと思います。
アラートを生成するセキュリティ機器や機能で代表的なものをいくつか挙げると、エンドポイントにおける EDR/EPP 製品、ファイアウォールや IDS/IPS といったネットワークセキュリティデバイス、SIEM などによる相関分析アラートなどがあります。
これらが生成するアラートに対して、SOC がセキュリティリスクへの対応を行うという観点をプラスして考えると、生の侵害活動そのものを監視できるエンドポイントで生成されるアラートや、広範囲のデータソースに対して、そもそもリスク対応を視野においてルール設定を行った相関分析アラートと比較すると、特定のネットワークエッジだけを情報源にしたファイアウォールや IDS などから生成されるアラートは一般に精度が低い傾向があります。
これは対象領域の性質という点だけでなく、そもそもの生成ポリシーの違いとも言え、人が対応するレベルの他のアラートと同列に考える方が間違っているとも言えるかもしれません。そうしたところから、今回は Cortex XSIAM で取り込んだ次世代ファイアウォールの Threat Alert を、アラートのまま残すか、それともイベントに格下げするかを自動的にトリアージするユースケースを一例として紹介したいと思います。
自動トリアージの方針
では具体的にどのように格下げの判定するかの方針を考えてみます。今回は次の通りの条件を設定し、これらの条件をすべて満たす場合、イベントに格下げすることにします。
- アラートがファイアウォールアラートである
- アラートが紐づいているインシデントに他のアラートがない（自身のアラート単体がインシデントになっている）
- アラートとして検知したセッションを Drop (リスクとして遮断) している
- アラートとして検知したセッションの Source IP が Cortex Agent がインストールされている端末で、正常に稼働している
これらの条件を設定した理由ですが、まず
1. は今回の大前提であるため割愛します。
2. の条件はアラートの精度を考慮したもので、その時点で複数のアラートがインシデントにグループ化されている場合、真リスクに関連している可能性があるとし、格下げの条件を満たさないこととしました。
3. の条件はリスクの大きさを考慮したものです。2. の条件から既に単体のファイアウォールアラートとなっており、かつ、そのアラート示す意味が遮断したことを通知するものであることは、未然防がれたリスクと考えられます。そのため、今後他のアラートがインシデントにグループ化されない限り、あえてセキュリティアナリストが追加調査を行う意味はないものとしました。
4. の条件はリスクの精度をはかるものです。Cortex Agent が展開されている環境では、もしそれらのエンドポイントでリスクが発生していればそこからのアラートが生成されているはずです。つまり、Cortex Agent からのアラートがない場合、ファイアウォールの過検知である可能性が高いという条件を設定しました。もちろん、何らかの原因により、Cortex Agent がインストールされているにもかかわらず動作していない場合はリスクと考えられるため、当該 Agent が稼働しているかどうかを条件としました。
また、イベントへの格下げは、単にアラートをクローズするだけでなく、アラート重大度（Severity）を Low に設定することにします。
自動化対応の実施
この方針をもとに作成した playbook が下記の図になります。処理はシンプルで、まず最初にアラートデータを確認し、アラートデバイスがファイアウォールかどうか、また、セッションを Drop した旨のものかを確認しています。次にインシデントにグループ化されたアラート一覧を取得（SearchAlertsV2 コマンド）し、単体アラートのインシデントかどうかを確認しています。そして、アラートとして検知したセッションの Source IP をキーに Cortex Agent の動作状態を取得（core-get-endpoints コマンド）し、確認しています。最後に、イベントへの格下げ条件を満たしていれば、Severity を Low に変更したのち、アラートをクローズしています。
これを実際に Cortex XSIAM に適用すると、Cortex Agent の端末からの通信セッションに対して、単体のファイアウォールアラートだけの検知があっても自動的にイベントに格下げすることができます。これにより、インシデントも自動的にクローズされ、セキュリティアナリストがこの過検知アラートに対応する必要がなくなります。
さいごに
このように Cortex XSIAM が提供するアラートのグループ化機能と、Playbook を利用した自動化プロセスを利用すると、アラート生成ポリシーや精度・信頼性の異なるアラートを、セキュリティレベルを損なうことなく適切な形で自動的に対処することが可能になります。これにより、SOC のセキュリティアナリストが抱えるインシデントへの対応負荷を大幅に軽減できるとともに、真のリスクに対する対応・復旧までの時間（MTTR）を大きく短縮することが可能になります。
今回は一例としてファイアウォールアラート対応のユースケースを紹介しましたが、Cortex XSIAM の Playbook による自動化機能の可能性は無限大です。新しいアイデアや工夫次第で SOC 運用プロセスを劇的に改善することが可能です。今後とも様々なユースケースを紹介していきたいと思います。