SplunkのCIM化 - Sansan Tech Blog

こんにちは！技術本部情報セキュリティ部 CSIRTグループ所属の川口です。普段は検知ルールの運用やSIEM基盤の開発・運用などの業務に取り組んでいます。

2023年2月から2024年2月の間でSIEM基盤をAOS（Amazon OpenSearch Service）からSplunkへ導入・移行しました。その移行については、弊社の吉山がブログで紹介しているので、ぜひご覧ください。
buildersbox.corp-sansan.com

今回はSplunk導入後にSplunkを活用していく上で重要となるCIMの適用について、どのように進めたのかをまとめていきます。

本記事は、Sansan Advent Calendar 2024 - Adventar10日目の記事です。

CIMとは

Splunkには、CIM（Common Information Model）というフレームワークが用意されています。これにより、さまざまなベンダーから収集したログを統一的に管理・分析できるようになります。このCIMに基づいて構築され、特定のユースケースに最適化されたデータ構造は「データモデル」と呼ばれます。これにより、異なる形式のログを統一されたデータモデルとして扱うことが可能です。
たとえば、認証イベントに関するデータモデル（Authentication）では、次のようなフィールドが用意されています。

src_ip（ログイン元のIPアドレス）
dest（接続先のシステム名またはホスト名）
user（認証を行ったユーザー）
action（成功、失敗などのアクションの結果）

CIM導入によるメリット

所持しているログにCIMを適用することで、さまざまなメリットを得られます。

1つ目はデータの標準化と一貫性の確保です。異なるデータソースから収集したログは、通常、形式やフィールド名が異なります。たとえば、サービスAのログとサービスBのログでは、送信元IPや送信先IPのフィールド名が異なる場合があります。CIMを適用することで、これらの異なるログを統一されたフィールドで扱えるようになり、複数のデータソースを一貫して分析することが可能になります。具体例を挙げると、CIM適用前のログでは、以下のように異なるフィールド名を個別に指定して検索する必要があります。

(index=A client_ip="192.168.1.1" dst_port="22") OR (index=B ClientIp="192.168.1.1" dport="22")

一方、CIMに準拠したデータモデルを適用すると、共通のフィールド名を使用して検索できるようになります。これにより、ログの理解や分析が容易になり、効率的な運用が可能になります。

| datamodel Network_Traffic src_ip="192.168.1.1" dest_port ="22" search

2つ目は検索におけるパフォーマンスの向上です。CIMで定義されたデータモデルには、データアクセラレーション*1がという機能があります。特に、ネットワークログのように大量のデータを扱う場合でも、データモデルを使用することで効率的に検索でき、結果を短時間で取得できます。
これにより、大規模なデータセットでもパフォーマンスを維持しながら迅速な処理が可能となります。

3つ目はセキュリティ運用の強化です。CIMに準拠したデータモデルは、セキュリティ運用の強化にも貢献します。たとえば、Splunk Enterprise Security (ES)*2 との連携が容易になり、以下のようなセキュリティ機能が活用しやすくなります。

相関検索: 複数のデータソースから関連するセキュリティイベントを分析し、異常を検知する
インシデント対応: 異常が検知された際の対応を迅速に行う

これにより、異常の早期発見や迅速な対応が可能となり、セキュリティ運用の効率が向上します。結果として、より強固な防御体制を構築できるようになります。

ログデータのCIM適用プロセス

所有しているログをCIMに適用させる際には、次の手順で進めました。それぞれのステップについて詳しく説明します。

取得したログがどのデータモデルに適しているかを調査

最初に、取得したログがどのデータモデルに適しているか調べる必要があります。最初にログの各フィールドを確認し、どのような情報が含まれているかを把握します。次に、CIMの参照テーブル*3とログのフィールドを比較し、大まかな対応関係を確認します。ログが1つのデータモデルに対応する場合もあれば、複数のデータモデルに対応する場合もあります。ログがどのような用途で使用されるかを考慮し、該当するデータモデルを特定することが重要です。この段階で大まかなマッピングを行うことで、後の作業が楽になります。

イベントタグの構築

実際にデータモデルを適用する際は、ログに対してイベントタイプを作成し、各データモデルで定義されているタグ情報と設定したイベントタイプを紐づける必要があります。また、1つのログが複数のデータモデルに対応する場合は、分類できるようデータモデルごとにイベントタイプを付与する必要があります。例えば、EDRはエンドポイントで発生する多種多様なセキュリティイベントを収集します。このため、1つのEDRログが次のように複数のデータモデルに対応しているケースもあります。

Endpoint データモデル
Network_Traffic データモデル
Malware データモデル

イベントタイプを付与する際に重要なのは、イベントをデータモデルごとに特定できるフィールドを見つけることです。先ほど説明したEDRログを例に考えると、もしイベントを分類するフィールド（event_type）が存在すれば、イベントがどのカテゴリに属するかを特定できます。もしそのようなフィールドがない場合は、イベント特有のフィールド値を元に分類し、イベントタイプとタグを付与する必要があります。

ログフィールドをデータモデルのフィールドにマッピングさせる

いよいよログフィールドを適切にデータモデルのフィールドにマッピングしていきます。以下に、マッピング作業時のポイントについて説明します。

まずはマッピングしたフィールドやデータ定義を管理するため、専用のAppを作成すると良いかと思います。このAppにより、各データソースに対するフィールドマッピングや変換ルールを管理・共有できるようになります。
既存のフィールド名がCIMの標準フィールド名と異なる場合は、Aliasを活用してフィールド名を変更します。Aliasの設定方法として、props.conf内で設定を記述することで可能となります。ここでは、FIELDALIASを利用して、srcaddrという既存フィールドにsrcというフィールドを新たに付与しています。

[<source_type>]
FIELDALIAS-srcaddr = srcaddr AS src

一部のフィールドが存在しない場合や形式が異なる場合は、props.confやtransforms.confを活用してフィールドを抽出または修正します。正規表現や変換ルールを定義することで、ログのフォーマットに依存せずCIM準拠のフィールドを生成できます。次の例では、ユーザーのログインメッセージからIPアドレスとバイト数のデータを抽出し、byte_inとbyte_outを合計した新しいフィールドを作成します。

REPORT-ip_extractionはtransforms.confに定義されたextract_ipの変換ルールを適用します。これにより、messageフィールドからIPアドレスが抽出され、ipフィールドに格納されます。
EVAL-bytes = byte_in + byte_outは、byte_inとbyte_outを足し合わせてbytesフィールドを作成します。このようにして、送受信された合計バイト数を得られます。

{
  "message": "User login from IP 192.168.1.10",
  "byte_in": 2000,
  "byte_out": 3000
}

[extract_ip]
REGEX = User login from IP (\d+\.\d+\.\d+\.\d+)
FORMAT = ip::$1

[src_ip]
REPORT-ip_extraction = extract_ip
EVAL-bytes = bytes_in + bytes_out

データモデルの有効化と検証

マッピングが完了したら、いよいよデータモデルを有効化しますが、その前にデータモデルで定義されているマクロ*4を編集する必要があります。デフォルトではすべてのデータが対象となっているため、必要に応じて取り込んだデータのインデックス値や特定の条件をマクロに設定し、データモデルが認識するデータの範囲を明確に指定します。これでCIMへのデータマッピングは完了です！最後に、フィールドのマッピング状況を検証します。これは、Splunk Appを活用することで効率的に行えます。今回使用したアプリケーションは次の通りです。

Data Model Wrangler

フィールドマッピングの状況を視覚的に確認し、正確に行われているかを検証できます。マッピングに問題がないことを確認したら、CIM化は完了です。ただし、データアクセラレーションなどの追加設定が必要な場合は、別途対応する必要があります。

data model wrangler でデータモデルのマッピングを可視化したダッシュボード

CIM適用時の注意点

実際にCIMを適用する際、いくつかの注意すべきポイントがあると感じました。

公式が提供しているAdd-onに頼る

データモデルのマッピングを行う際は、可能な限りSplunkが公式に提供しているAdd-onを利用することをおすすめします。これらのAdd-onは、すでに多くのフィールドがCIMに適合するように設定されており、手動でのマッピング作業を大幅に削減できます。特に、複雑なログ形式や複数のデータソースを取り扱う場合、公式Add-onを活用することで、CIMの適用がスムーズに進みます。

推奨フィールドの優先マッピング

CIMには推奨される標準フィールド*5が定義されており、これらのフィールドを優先的にマッピングすることで、データモデルとの互換性を確保し、検索やレポート作成時に最大限のパフォーマンスを引き出せます。例えば、src、dest、user、actionなどが推奨されているフィールドです。
もちろん、ログ標準フィールドに対応する情報がログに存在しない場合もあるため、その場合はルックアップ*6などを活用し、外部の情報（例：IPアドレスの地理情報やユーザー情報など）を付与することが重要です。ただし、すべてのフィールドを完全に一致させるのは難しい場合があるため、ある程度の妥協も必要だと考えています。

今後の課題

Splunk構築後にCIMの適用を進めていきましたが、やるべき課題はあると思うので取り組んでいきたいと考えています。

新しいデータソースの対応
データソースの変更や新規データソース追加によるCIM適用の継続的なメンテナンス
データアクセラレーション設定の最適化

最後に

今回はSplunkを導入してからちょうど一年ほど経ったので、CIMの適用について振り返ってみました。
CIMの適用は一度行えば終わりというものではなく、継続的な改善とメンテナンスが求められる作業です。これからも新しいデータソースや要件に応じて柔軟に対応しながら、より有用で信頼性の高いログ基盤を目指して取り組んでいきたいと思います。

*1:特定のデータモデルに対して、バックグラウンドでデータを収集してサマリーインデックスを作成しておくことで高速化するslunkの機能

*2:Splunk Enterprise Security（ES）は、高度な脅威の検知を可能にし、インシデントの検知および対応までの時間を大幅に削減するための有償アドオンです。

*3:Splunkの公式ドキュメントで各データモデルのフィールドについて詳細が記載されています。 docs.splunk.com

*4:マクロとは、特定の検索クエリや条件を再利用するために設定するSplunkの機能

*5:推奨のフィールドについてはドキュメントに「recommended」と記載されています

*6:ルックアップは、ログデータに追加情報を組み合わせるための機能です。特に、既存のイベントデータに対して外部データ（CSVファイルや外部ソースから取得したデータなど）を関連付けて、さらなる情報を提供できます。