これまでSIEMの話題でリスクベースアラート(RBA)のメリットについて耳にしたことがないアナリストやエンジニア、経営陣の皆さんは、この記事を読めば、自社の環境にRBAをすぐにでも導入すべき理由をご理解いただけるはずです。
2018年のある晴れた日、米国オーランドでSplunkのJim ApgerとStuart McIntosh (現在はOutpost Securityに在籍)がSplunkの.confでRBAについての講演を行いました。そのとき、カンファレンスルームの固い椅子に座って話を聞いていた私は、このテクノロジーにほれ込んだのです。RBAの方法論は別の分野では使用されていましたが、RBAが真価を発揮できるはずのSIEM製品ではなぜか運用化されていませんでした。講演ではSPL (Splunk Processing Language)の柔軟性を生かし、RBAがいかに簡単に使えるかを見せてくれました。いくつかのフィールドを作成してオブジェクトに関する情報をリンクし、この情報にセキュリティのメタデータを追加し、サマリーインデックスでまとめるだけです。Splunk Enterprise Security 6.4ではRBAが相関サーチに統合されているため、フレームワークの基盤を構築する時間さえ捻出できれば、すぐにRBAが使えます。
オーランドから戻った私は、ブルーチームの未来に新たな希望を見いだしていました。コンテンツエンジニアリングに通じている方ならご存じのとおり、通常のビジネストラフィックを除外できるように検出機能をぎりぎりまで無効化するには、何時間もかかります。加えて、セキュリティのすべての穴を検出機能の微調整でふさぐために、アナリストはさらなる時間を費やすことになります。RBAはアラート量の問題の解決策であると同時に、相互に連携した複雑な攻撃活動を追跡する手段でもあると思います。成熟した優れたセキュリティチームならば脅威ハンティングの一環としてこうした追跡をしていますが、多くのSOCでは時間がなくて実現できていません。
RBAを構築してビジョンを実現する時間さえ捻出できれば、多くのメリットが得られるはずです。アラート量は一般的に50～90%減少し、アラートの忠実度も大幅に向上します。RBAがまだ完全稼動していないのにレッドチームの活動が検出されるケースもよくあります。MITRE ATT&CKフレームワークは広範で、ノイズの多いデータからでも価値を引き出せる検出機能がなければ、完全には対応できません。何よりも重要なのは、RBAによって実現した時間の節約、セキュリティを成熟させる機能、運用ソリューションが、組織内の変革を次々と引き起こすことです。私はベンダーがうたうすばらしい成果といったものにはまず疑ってかかるタイプです。しかし、RBAはそのようなものではなくむしろ、独自の問題に対するソリューションをカスタマイズして構築するための方法論です。調子の悪い歯車が1つ動きだすだけで、他の多くの歯車が再び動き始めることがあるのです。
今後数週間かけて、RBA導入を進めるためのステップ(と陥りやすい失敗)について紹介する続編の記事を投稿予定です。しかしまずは、RBAにはどのようなメリットがあるのか、そもそもRBAとは何なのかといった疑問に答えるべきでしょう。
RBAがもたらすメリット
大げさな言い方はしたくないのですが、RBAの優秀さは想像を絶するほどなので、その良さについて熱弁をふるってしまいそうです。
ですが、冷静にお話ししたいと思います。
RBAはどのようなメリットをもたらすのか、役割別にご紹介していきましょう。
経営陣
経営陣は日々さまざまな意見や指標を突きつけられており、現状を大きく変える新たなサイエンスプロジェクトと聞くと、話がうますぎると感じるかもしれません。しかし、RBAプロジェクトは次々と成功を収めています。RBAは以下のメリットをもたらします。
- 時間を浪費する忠実度の低いアラートの量を減らせます。その結果、脅威ハンティング、攻撃手法シミュレーション、セキュリティコンテンツ開発などの価値の高い活動に時間を割けるようになります。
- MITRE ATT&CK、Lockheed Martin社のKill Chain、CIS20などのサイバーセキュリティフレームワークに対応できます。ふさごうとしているセキュリティの穴を定量化するとともに、かつてないほど迅速にその穴をふさぐ力をセキュリティチームに与えます。
- 多数のセキュリティ監査要件を余裕を持ってクリアできるため、監査作業がきわめて円滑に進みます。
エンジニア
エンジニアは常に数え切れないほどの依頼を受け、組織のあらゆる方面からの非現実的な期待にさらされています。多忙な日々の中で、大きなセキュリティの穴や非効率を解決できる見込みのある特別なプロジェクトに取り組む時間だけをどうにか確保しているのではないでしょうか。それなら、RBAを特別なプロジェクトにしましょう。少量で精度の高いアラートを得るために、延々と調整や微調整をする必要がなくなれば、コンテンツ開発はとても速くなります。RBAは以下のメリットをもたらします。
- ノイズの多いセキュリティデータソースから価値を引き出せます。その結果、以前は不可能だったさまざまな検出機能を構築できるようになります。
- 柔軟なリスク検出とアラートの方法論により、許可リストにホストを延々と追加する作業や、SOCがアラートに忙殺されないようロジックを試行錯誤しながら調整する作業から解放されます。
- ゼロリスクイベント、すなわち他の行動との組み合わせや特定のコンテキストでのみリスクとしてカウントされるイベントを作成できます。
アナリスト
とにかくアラートが多い。これに尽きるでしょう。そして、他にも疑わしいアクティビティがないか、複数のソースを調べなければなりません。これを「毎回」行うのは、本当に面倒な作業です。このすべてが関連付けられ自動的に表示されれば、どこから手を付けるべきかが分かりやすくなります。反復的なアラートの数が減ることで、より価値のある作業に取り組む時間を多く確保できるようになります。RBAは以下のメリットをもたらします。
- アラートとともに複数のイベントと多くのコンテキストが表示されるため、調査の最初の仮説を立てるために有用な情報が得られます。
- 脅威オブジェクトにより、環境全体、部門単位、ユーザー単位で行動に異常がないか調査できます。
- RBAの柔軟性とSPLのカスタマイズ性により、アナリストのフィードバックが大きな価値を持つようになり、新機能の開発、新たな検出の実現、調査や対応のQoL改善に役立てられます。
RBAへのシフトは気軽にできるものではありません。しかし、適切な準備を整え、適切な関係者とカルチャーシフトについて話ができれば、ハードルは大幅に下がります。皆さんはすでに多くのことを抱えていると思いますが、話を進めていただくきっかけとしてこの記事が役立つことを願っています。関与するすべてのチームと話をすることで、全員が同じ(少なくとも近い)認識を共有できます。各チームが自分たちのするべきことや、何よりもRBAでどのような問題を解決できそうかが分かるようになります。中には、RBAに可能性を見いだし、組織で見過ごされていた問題の解決策を考え出す人も現れるかもしれません。
そもそもRBAとは？
私たちが慣れ親しんでいる検出の仕組みでは、ログソースを入手し、そのログソースに存在しうる望ましくない何かを検出するロジックを書き、検出されるとアラートが発生します。
RBAの場合、検出ロジックによって得られるのは観測結果だと私は考えています。その観測結果にセキュリティのメタデータをタグ付けし、特権ユーザーや外部接続サーバーといった注目すべき属性に基づいてスコアを調整します。注目すべき観測結果が十分に集まると、はじめてアラートが発生します。
もう少し詳しく見ていきましょう。
リスクの可能性、重大度、緊急度などを示すために何らかのスコアを使用するのは、おそらく誰もが知っている手法です。しかし、これではリスクのほんの一部を把握しているに過ぎません。単純で一次元的な検出法で「不審な活動をしているプロセスを探す」のでは、アラームを妥当な量に抑えるための調整に何週間もかかるおそれがあります。そうではなく、ホスト、ユーザー、IDなど、注目すべき要素を持つデータを何でも、それ専用の「バケツ」に入れて保存しておくのです。比喩的ですが、私はこの表現が気に入っています。そして注目すべき要素がバケツに十分たまったら、そこではじめてアラームを生成します。その結果、アラームの量が驚くほど減少し、忠実度が向上します。このような改善は、お客さまの導入例でも頻繁に目にします。この方法は、忠実度の高いアラートや、必ず調査の必要なアラートを残すことができ、非常に多くの検出ケースで有効な手法です。
このバケツ(risk_objectと呼びます)に何かを入れる際には、有用なセキュリティメタデータ(MITRE ATT&CKの戦術と技法や、そのデータのソースなど)を追加できるだけでなく、そのオブジェクトに関する情報を使用してスコアを調整できます。例えば、「一般公開されている本番サーバーやデータベースである」、「既知の脆弱性のあるシステムである」、「特定のユーザーが属する部門での実行が想定されていないコマンドである」といった情報です。逆に、その種のコマンドを日常的に実行する部門であれば、それらのコマンドについては逆方向に調整することになります。RBAの良いところは、調整のためのノブやレバーを必要なだけ追加して、許可リストを使用せずにアラートの生成方法をカスタマイズできる創造性です。自分たちの問題を解決するために、どのようなカスタマイズを行っているかをお聞きするのは、とても楽しいものです。
また、RBAではrisk_objectがとったアクティビティや行動をthreat_objectとして保存します。これを中心として、環境内の他のどのオブジェクトが特定のIPアドレスとやり取りしているか、特定のコマンドを実行しているかを確認することができ、通常アクティビティや異常アクティビティに対する別の視点を得られます。その結果、まったく新しい視点でログを見て、オブジェクトが何をしているのか、オブジェクトに何が起きているのかを判断できるようになります。例えば、システムのACMEホストをrisk_objectとして調査したり、そのthreat_objectを確認したりできます。123.123.123.123という見慣れないIPアドレスや、powershell.exe ExecuteMaybeBadThingというコマンドライン、ReallySensitiveInfo.xlsxというファイル名など、さまざまなリスクルールをもとに調査できます。
この手法は例えば、あるアクティビティがアラートに上がったときに、それを行っていたシステムやユーザーがどれだけいたか確認したい場合や、レッドチームのアクティビティが検出されたときにどのリスクオブジェクトや脅威オブジェクトが関与していたかを一目で確認したい場合に調整が容易です。その他、脅威オブジェクト自体からアラートを作成したり、これらのオブジェクトを脅威ハンティングキューのように使用してリスクインデックスを絞り込んだりなど、さまざまな創造性を発揮できます。
RBAで何ができるのか？
ここまでは、RBAの仕組みについて説明しました。RBAがもたらすメリットについては、ここまでで全体像が見えてきたことと思います。では、具体的に何ができるのでしょうか？いくつか挙げてみましょう。
- アラートの総数を削減し、発生するアラートの忠実度を向上させる。
- 社内の脅威インテリジェンスをお客さまが定義して作成できるようにし、通常の行動と異常な行動の判別を可能にする。
- 以前からあるノイズの多いデータソースから高い価値を生み出す検出を実現する。MITRE ATT&CK、CIS20、Lockheed Martin Cyber社のKill Chainなど、一般的なサイバーセキュリティフレームワークにも対応する。
- メタデータで強化されたオブジェクトおよび行動に関する有益なリスクライブラリを開発し、手動の分析や機械学習に活用する。
先ほども述べたとおり、作業負荷が軽減され、セキュリティデータ、検出結果、チーム間の連携が容易になることで、サイロの相互連携が進んで多くの人と協力できるようになり、可能性が広範に及んでいきます。
ただし...
RBAはひと手間で完結するソリューションではありません。セキュリティへのアプローチを変革する製品を通じた従業員への投資となります。多くの人が言うように、RBAを導入できる製品は他にも数多く存在すると思いますが、Splunkには可能な限り円滑にRBAを導入して運用していくためのフレームワークを構築した優秀なエンジニアが揃っています。RBAの方法論でセキュリティの問題を解決した人たちが起こしている変革は、次世代のセキュリティチームに対する希望を感じさせてくれます。SIEMの新たなスタンダードとなったRBAの柔軟性と可能性により、今後の作業負荷が軽減され、なおいっそう有能なチームとなっていくことでしょう。
私が考えるRBAの成熟過程は以下のとおりです。今後の記事でさらに詳しく解説する予定です。
RBAの始め方は？
良い質問です。次回の記事で取り上げる予定ですが、ここ数年の.confのビデオでもRBAについて知ることができます。Splunkブログのセキュリティ記事を購読登録するか私のTwitterをフォローすると、最新情報を入手できます。
電子書籍『リスクベースアラート(RBA) エッセンシャルガイド』もぜひご覧ください。Splunk Enterprise Securityを通してRBAがどのようにアラート全体の数を減らし、発生したアラートの精度を高めることができるかについて解説しています。
