合体って燃えますよね？ SIEM と SOAR 、合体っTDIR へ！！

ついに姿を表したSplunk Enterprise Security 8.0!

未だに”合体”とか”変形”とかに微妙に気持ちが高ぶってしまいますが、フィリピンでは1977年頃に日本で放映していた某5つのメカが合体して活躍する合体ロボが未だに人気で、今年になって映画も作られたというニュースが春頃に流れていましたね。

思えば、昔のTVアニメはロボやメカの合体・変形系統が数多く、日本人は鳥のヒナや動物のようなインプリンティングが施されてしまっているのかもしれません。敵が強大になって今までのような戦いでは対応できなくなってしまう・・・そこで新たな武器やロボが現れるとか、新しいフォームに変形するとか合体するとか、オジサンになってもアツい場面です。（え？私だけ？？？）

Splunkも強大な攻撃に対応するため、新たなバージョンをリリースしました！（アツいですよね！？）
その名も Splunk Enterprise Security 8.0 です。バージョン番号だけしか変わってないというツッコミは置いておいて、今回はかなりの大規模バージョンアップとなっており、今までのものとは一味も二味も違うものになっています。
今回は、何が変わったの？という事を中心に書いてみたいと思います。

Splunk Enterprise Security 8.0のココが変わった！

新しい用語に Transform!

まず最初に気がつくのは Enterprise Security で使用されている用語が変わったことです。どのように変わったのか、対応表を下記に示します。

旧バージョン	Enterprise Security 8.0
注目すべきイベント/Notable Event/Risk Notable	Finding
Risk Event	Intermidiate(中間) Finding
ルール(サーチ)/Rule	Detection
相関ルール(サーチ)/Risk Rule	Event Based Detection
リスクインシデントルール/Risk Incident Rule	Finding Based Detection
コメント/Comment	Note
インシデント レビュー/Incident Review	Mission Control Analyst Queue

なぜこれらを変えたのか？ということが疑問として上がってくるかもしれません。これはOCSF（ https://github.com/ocsf ）のtaxonomyに準じた変更として今後この用語を利用して製品を構成して行くということになる様です。
当初は少し混乱するかもしれませんが、今のうちに慣れておくことにしましょう。

Detection（検知ルール/サーチ）の作成を強化！

SIEM をはじめ攻撃を見分ける手段が超重要です。今までも Splunk は ESCU（Enterprise Security Contents Update）を定期的に配信し続けていて、Detection の数つまり検知用のサーチが1791個にもなっています。
(検知用のサーチだけでなくサーチを組み合わせて実現できるユースケース、Analytic Story も263を数えています。ESCU についてはこちらをご覧ください）
Splunk はこれらを全て公開しており、このサイトやGithubで Detection や Analytic Story を確認することができます。今回の Enteprise Security での強化とは、オーサリング、つまり Detection を作成する機能が強化されました。

Event Based Detection

用語の変更により、検知ルール/サーチを Detection と言い換えることになりましたが、加えて2つの Detection 方法が提供される様になっています。
まず、昔からある相関サーチで取り込んだログを検索して結果を求める場合、これを Event Based Detection と言います。Event Based Detection は各種ログのレコードを検索してヒットしたものをリストしますが、このリストされた Event を Finding と言います。
Finding は Enterprise Security の旧バージョンでいうところの Notable Event（注目すべきイベント）にあたります。つまり、Event Based Detection = 相関ルール/サーチ であると考えて良いでしょう。また、後述のFinding Based Detection の対象となるFindingを作るためのサーチでもあります。1点注意すべき点としては、Finding Based Detection は2種類のFindingを作成することができます。1つは単純にNotable Eventと同等と考えて良い Finding で、これは一発アウトのルールに引っかかったアラートと同様なものと考えてください。
もう一点は Intermediate finding（中間 Finding）と呼ぶものです。こちらは、上記の Finding とは異なりAnalyst Queue の一覧には表示されません。次に説明する Finding Based Detection に主に利用するものと考えて差し支えないでしょう。

Finding Based Detection

では、もう一方の Finding Based Detection とは何か？というと、前の項目にならっていうと旧Enterprise Security の Risk Incident Rule にあたります。　Risk Incident Rule とは、Enterprise Security に搭載されている機能の一つである RBA（Risk Base Alert)を構成するサーチの一つです。つまり、Finding Based Detection はRBAの機能をより使いやすく、わかりやすく、作りやすくした進化バージョンであると言えます。具体的には、Event Based Detection と異なり生のログを検索するのではなく、Event Based Detection が生み出した Finding をさらに検索して Findingグループを作成します。つまり、個別に検知したものをグループ化して一つの固まりとして判別することを行います。（Finding と 中間Finding のいずれも対象とすることができます）
以前のRBAもそうでしたが、この Finding Based Detection を利用することによって Finding（アラート）の集約を行うことができ、セキュリティ担当者を大量のアラートから救い出すことができる機能であると言えます。
RBA時代の Risk Incident Rule の作成は、お世辞にも簡単とは言えませんでしたが Finding Based Detection はかなりの改善が行われて有効に使用することができる様になりました。
Risk Incident Rule は基本的にリスクスコアの集計や、MITRE Att&ck の Technique や Tactic を元に集計する方法が主に利用されていましたが、Finding Based Detection は集計するFindingのタイプを選択します。また、Detection（ルール）といばSPLを書く、というイメージが強いと思いますが集計タイプ Custom 以外はSPLを書く必要もありません。

以下の表はマニュアルからの抜粋です。

Type	説明
Entity / エンティティ	潜在的なセキュリティ脅威を識別するために Splunk Enterprise Security で使用できる、アセット、ID、ユーザー、またはデバイスごとに検出結果をグループ化します。検出結果がカウント用しきい値を超えるとFinding グループが作成されます。
Threat Object / 脅威オブジェクト	URL、ファイルハッシュ、電子メールアドレス、ドメイン、コマンドライン、IPアドレス、レジストリキー、ファイル名、ファイルディレクトリなど、セキュリティリスクを増大させる値によって Finding をグループ化します。 Finding に同じ脅威オブジェクトが含まれかつ、しきい値を超えた場合に Finding グループを作成します。
Cumulative entity risk / 累積エンティティリスク	資産、ID、ユーザ、システムなどのエンティティ毎にFindingにて設定されたリスク値の合計によって、Findingをグループ化します。 Finding がエンティティのリスクスコアのしきい値に達すると、Finding グループを作成します。
Kill Chain / キルチェーン	サイバー攻撃のフェーズを特定し、攻撃者の連続的な行動を予測するのに役立つ、Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command, Control, Action on Objectives に対する行動などのサイバーキルチェーンフレームワークに基づいて発見をグループ化します。 キルチェーンの各フェーズにおいて、Finding がしきい値を超えた場合、Finding グループを作成します。
MITRE ATT&CK	MITRE ATT&CK フレームワークは、脅威モデルや手法の開発に使用される敵の戦術やテクニックの知識ベースです。 Finding が MITRE ATT&CK の Technique や Tactic のカウント数がしきい値を超えた場合に Finding グループを作成します。
Similar findings / 似ているFinding	同じ Finding あるいは 中間Finding の件数がしきい値を超えた場合に、Finding グループを作成します。
Custom / カスタム	カスタム検索で特定のカスタム条件を満たした場合に、Finding グループを作成します。

SOARとの合体（連携）で真のTDIRを実装！

最後に、SOAR との連携です。古いバージョンの Enterprise Security にもインシデント管理の機能は存在しており、SOAR と組み合わせて利用する場合、「どっちを使うべきか？」という問題が持ち上がることも度々ありました。
今回のバージョンでは SOAR のインスタンス自体は別に存在するものの、統合されて SOAR 側のインターフェースを利用しなくともインシデント管理やケース管理の機能を Enterprise Security のみで利用できるようになりました。
Enterprise Security と SOARの 間を行き来する必要がなくなったことは大変好ましいですね。

また、以前はEnterprise Securityの情報を保持するフィールド形式がSOARと異なるため、App上で「 Enterprise Security のこのフィールドは、SOAR 側のこのフィールドに格納する」といったフィールドマッピングが必要でした。ネイティブに対応することができる様になった Enterprise Security では不要となって、混乱を生じなくなりました。

SOAR の Automation を実装するうえで、Enterprise Security へのアクションを司るコネクタも一新され、手動で行うことができるアクションはすべて SOAR の Automation で行うことができるようになりました。以前の Mission Contorl よりも統合が進んで使いやすく進化しました。

また、特定の Detection にて Finding が Analyst Queue に登録された時点で Playbook を実行したいことがあります。以前の Mission Control では Investigation Type の設定によって定義した対象 Playbook を実行することができましたが、Investigation Type 自体を定義するマクロを書かなければなりませんでした。Enterprise Security 8.0 では新たに Automation Rule Framework が追加され、実行したい Playbook と Detection を選択するだけで簡単に定義でき、Playbook 実行が定義されている Detection で Finding が出力された場合に自動的に実行させることができます。

その他、様々なバージョンアップが施された Splunk Enterprise Security 8.0 ですが、真のTDIRを実現したSIEMとして様々な脅威の検知・分析・対応を行うことができる、セキュリティ担当者の強力な武器・防具としてパワーアップしたと言っても良いかと思います。

今後もさらなる強化が期待できるので、また新しい機能が実装されたらご紹介します！

（了）