伝えたいこと

サイバー攻撃を検知するための新しい検出ルール記述手法に関する記事です。
みなさんはRootAという検出ルール言語についてご存知でしょうか？ 2023年11月ごろにSOC Prime社よりリリースされました。まだ日本語での紹介ブログなどをみかけなかったので、その仕様とSigmaとの違いを簡単に紹介します。

SOC Prime社はサイバー攻撃に関する脅威インテリジェンスの商用プラットフォームを保有しサービス展開している会社です。同時に Threat Bounty Programを提供している数少ない企業で、アメリカの企業ですが、起源はウクライナにあるようです。

RootAとは？

公式サイト：https://roota.io/
ドキュメント：https://github.com/UncoderIO/RootA

RootA は、脅威の検出、インシデント対応、脅威アクターの特定をシンプルにするためにSOC Prime社にて作成された、集団サイバー防御のためのパブリックドメイン言語です。
既存の SIEM、EDR、XDR、およびデータレイククエリ言語の大部分に対するオープンソースラッパーとして機能します。(公式サイトより)

世の中的な背景

攻撃者の脅威インテリジェンスを（攻撃者に悟られないように）共有し合えば、理論的には集団防衛に近づきます。こここ10年ほどで「MISP」のような情報共有プラットフォームや「MITRE ATT&CK」のようなグルーピング、分類が普及し、攻撃者に対する情報を共有しやすくなりました。そしてその情報を検出ルールという形で防御に反映する共通記述フォーマットもYara、STIX、TAXII、OpenIOC、Sigmaと登場してきています。昨今はSIEM間の検出ルールへの変換が取りやすいSigmaに人気がありますね。
今回ご紹介するRootAもその一つと分類できるもので、Sigmaより情報量が多く、たとえば攻撃のタイミング（期間や間隔）などに合わせたルール設計を取れるようです。

誕生理由の考察

Sigmaがあるのになぜまた新しいものが必要のなのか？この疑問の回答を探して公式ドキュメントを漁りましたが、ドンピシャなものは見つかりませんでした。ただ公式サイトの以下の記述らから推察するに、このような想いがあったのではと考えます。

グローバルなサイバーセキュリティ業界のコラボレーションを加速させたい。 (おそらくSOC Primeのビジネス的にも)
2015年から統一された言語とツールキットを確立する夢があった。ツールキットは Uncoder IOでうまくいったので次は統一された言語を作りたい
Sigmaでは表現しづらいキャンペーンのタイムラインや検出後の対応となるコードまで記述に盛り込みたい
Grep的な検索ロジックだけでなく、高度なステートフルなロジックを盛り込ませたい

RootAの目的は、グローバルなサイバーセキュリティ業界のコラボレーションを加速させることです。
RootAはゼロから開発され、現在ウクライナのSOC Primeのチームによって保守されています。2015年以来、私たちは脅威の検出と対応のための統一された言語とツールキットを確立するというアイデアを構築してきました。最初のステップは、SigmaルールとUncoder IOプロジェクトのサポートでした。
2018年にSigma RulesとMITRE ATT&CKを連携させたように、次のレベルに引き上げる時が来ました。RootAの採用により、アクターとキャンペーンのタイムライン、トップCTIプラットフォームとの統合、MITRE TRAMとSightingsへの貢献により、検出と応答コードを強化します。
フラットなIOCのような文字列マッチングではなく、あらゆる高度なステートフル・ロジックを活用することで、攻撃動作の記述の限界を突破します。こうすることで、構築して共有する検出ロジックが攻撃者にバイパスされにくく、計算効率が高く、後で他の言語でレンダリングできることを保証できます。（公式サイトより）

大まかな仕様

広く普及している YAML形式　（Sigmaと同じ）
シンタックスはOCSF と Sigmaをサポート
最小、完全、拡張の３つのテンプレートがある
YAML内で記述できるフィールド名と定義はこちらに一覧があります。
- https://github.com/UncoderIO/RootA/blob/main/RootA_Specification.md

３つのルールテンプレート

最小(Minimal)テンプレート

最小(Minimal)テンプレートは、ルールをシンプルに保つためのもので、名前、説明、作成者、重大度、日付、MITRE ATT&CKタグ、特定の言語での検出クエリ、参照、ライセンスのみを必要とするものです。

公式ドキュメントのサンプル↓

name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
author: SOC Prime Team
severity: high
date: 2020-05-24
mitre-attack:
    - t1003.001
    - t1136.003
detection:
    language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
    body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
references: 
    - https://badoption.eu/blog/2023/06/21/dumpit.html
license: DRL 1.1

完全(Full)テンプレート

完全(Full)テンプレートは、アラートコンテキスト、脅威行為者のキャンペーンタイムライン、SigmaルールまたはOCSF分類法に基づいて定義された特定のログソース属性、およびクロスプラットフォーム相関セクションを追加するためのものです。

上と同じものを完全テンプレートで記載するとここまで書けます。（公式ドキュメントより転記）

name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
author: SOC Prime Team
severity: high
type: query 
class: behaviour
date: 2020-05-24
mitre-attack:
    - t1003.001
    - t1136.003
tram-tags:
    NaiveBayes:
        - t1136.003
    MLPClassifier:
        - t1003.001
    LogisticRegression:
        - t1003
        - t1003.005
detection:
    language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
    body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
logsource:
    product: Windows                # Sigma or OCSF products
    log_name: Security              # OCSF log names
    class_name: Process Activity    # OCSF classes
    #category:                      # Sigma categories
    #service:                       # Sigma services
    audit:
        source: Windows Security Event Log 
        enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process
timeline:
    2022-04-01 - 2022-08-08: Bumblebee
    2022-07-27: KNOTWEED
    2022-12-04: UAC-0082, CERT-UA#4435
references: 
    - https://badoption.eu/blog/2023/06/21/dumpit.html
tags: Bumblebee, UAC-0082, CERT-UA#4435, KNOTWEED, Comsvcs, cir_ttps, ContentlistEndpoint
license: DRL 1.1
version: 1
uuid: 151fbb45-0048-497a-95ec-2fa733bb15dc
correlation: 
    timeframe: 1m
    functions: count() > 3
#response: []    # extended format

最小テンプレートとの差分メタデータとして

type (queryかalertか。alertを指定するとFalsePositiveが低いことを示唆する)
class (OCSFイベントクラス名：OCSFとの紐付け)
logsource (SigmaやOCSFに基づく必要なログソース。auditセクションではログの有効化方法を記述)
timeline (脅威アクターの名前、攻撃の時期、TLP情報などを記述し、時期と公開度合いによるルール有効性の参考となりうる)
tags (プラットフォームで検索するときのタグとなりうる)
version （検出ルールのバージョン情報、更新管理しやすい)
uuid (利用推奨。おそらくプラットフォームでのユニークな管理ID)
correlation (検出結果に対するtimeframeとfunctionを設定でき、ふるまいをもう一次元後処理できる仕組み)
などがあります。

また末尾の responseというのが、次の拡張テンプレートで利用される開発中のフィールドで、検出された後の対応の自動化に繋げるコードを各箇所と考えられています。

拡張[Extended]テンプレート (予約のみ)

拡張[Extended]テンプレートは現在ではまだ利用できず、コードとしてのレスポンス（対応）と実験的機能を追加するために予約されています。

Uncoder.IOでの変換サンプルの紹介

上のRootAの完全テンプレートのサンプルをUncoder IOのプラットフォームにてSigmaに翻訳変換した例です。

逆 (Sigma -> RootA) はできません。（選択リストにRootAがない）

※ 2024.05.31 時点では、RootA -> Sigmaや他のSIEMプラットフォームのクエリ言語のみ Uncoder IOでは対応しています

Sigmaと比べた比較

Sigmaの拡張仕様まで踏まえて詳しく比較できているかは自身がないのですが、私の知る限り、SigmaからRootAへの大きな拡張ポイントは以下３点と考えています。私がこのメタデータは充実すれば有益だと思う順に記載します。

timelineの記述
logsourceのauditの記述
correlationの記述

timeline:
    2022-04-01 - 2022-08-08: Bumblebee
    2022-07-27: KNOTWEED
    2022-12-04: UAC-0082, CERT-UA#4435

上のサンプルにあるこの記述は　このComsvcs.dllを利用したクレデンシャルダンプの攻撃がこれらのマルウェアや攻撃アクターなどに関連していることだけでなく、その活動が確認された大まかな時期を参考情報として知ることができます。このメタデータが充実すると検出ルールに引っかかったときの脅威アクターとの紐付けがしやすくなると思うのですが、一方でルールを書く側からするとここまで調べてかけるのは長期的に追いかけている脅威リサーチャーぐらいなんじゃないかと思います。あとは"少なくとも"という目で見た方がよいですね。

logsource
    ~~
    audit:
        source: Windows Security Event Log 
        enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process

上のサンプルにあるこの記述は、この検出ルールで引っ掛けるためのログの取り方（監査ログの有効化）の方法を記載するメタデータで、この例だとデフォルトのイベントログでは取れてないよ、拡張設定を入れてねということを示唆しています。
検出ルールをみつけたときにそもそも自社ログで対応できるかを把握するのにあればわかりやすいと思います

correlation: 
    timeframe: 1m
    functions: count() > 3

上のサンプルにあるこの記述は、簡単にいえば検出結果についてもう一段ふるいにかけられる相関分析の機能です。
この例では1分以内に３つ以上ヒットがあればという閾値の役割を果たしています。
このfunctionsはまだ開発中であり現時点で利用できるものはこれだけのようです。

count() - count of field values
by - group by field
dcount - unique field values

特定のフィールドの特定の閾値を満たした場合にのみアクショントリガーをかけるなど、クエリ結果の相関のために関数を使用することができるという独自性があり、今後に期待したい機能ではあります。

そして、おそらくcorrelationの結果も踏まえて現在開発中というresponseメタデータで自動対応の機能を記述するのだと推察しています。

今後の展望についての考察

timeline、correlationとresponseがどこまで脅威リサーチャーをはじめ、SOCアナリストやスレットハンターに歓迎されるかはわかりませんが、上のcount()ぐらいだったらYaraルールでも昔からできるわけで、個人的にはもっと発展したcorrelationのルールをかけるようにしないと、detectionのルール部分で統一的にやればよいのではと考えてしまいます。

しかし検出ルールの結果に対するアクションや攻撃者の時期まで一歩踏み込んでいるなとは感じたので、今後も時間があるときに眺めていこうと思います。

まとめ

RootAはSigmaのような脅威インテリジェンスを検出ルールに落とす共通記述言語でUncoder IOで、各種SIEMプラットフォームのクエリ言語に翻訳変換できます。

RootAではSigmaにはなかった検出後のアクションまで考慮して設計されており、その大部分はまだ開発中でした。

SOC PrimeのThreat Bounty ProgamにてRootAフォーマットで検出ルールを提出できるようになり、SOC PrimeのプラットフォームやGithubなどで今後RootA記述を見る機会も増えるのかもしれません。

以上、ご一読ありがとうございました。

Happy RootA!