セキュリティにおけるMLTK AIコマンドの活用

MLTK 5.6.0のリリースにより、Splunkは新しいaiコマンドを導入しました。これにより、外部の大規模言語モデル（LLM）サービスとのシームレスな連携が可能になります。ユーザーは、MLTKのLLMコネクタを介してOllamaを使用したオンプレミスのLLMに簡単に接続できるほか、さまざまなクラウドベースのLLMを活用することもできます。ai SPLコマンドを利用することで、Splunkサーチから直接LLMにプロンプトを送ることができます。

aiコマンドはセキュリティチームに大きな可能性をもたらし、複雑な分析の自動化、検出ワークフローの強化、データからより深い洞察を得ることを可能にします。本ブログでは、LLM連携による2つの注目すべきセキュリティ用途、すなわちPIIデータの特定、MITRE ATT&CKフレームワークに基づいた検知ルールの提案とセキュリティアラートの分析についてご紹介します。

AIコマンドのセットアップ

はじめに、MLTK内でLLMコネクタを設定する必要があります。MLTK 5.6.0とPython for Scientific Computing 4.2.3の両方がインストールされていることを確認してください。また、ai コマンドの設定および利用に必要な権限がユーザーロールに含まれているかもご確認ください（詳細はドキュメントを参照してください）。次に、MLTKの「Connection Management」タブに移動し、設定したいLLMサービスを選択します。

MLTKプラットフォームの大きな利点のひとつは、LLMサービスへの接続が非常にシンプルであることです。わかりやすいセットアップ手順と直感的なインターフェースにより、組織は多くのエンジニアリングリソースを必要とせずに、オンプレミスおよびクラウドベースのLLMを迅速に統合できます。この導入のしやすさによって、チームは幅広いAI活用事例を素早く試し、展開することができ、さまざまなセキュリティワークフローにおけるイノベーションと価値創出を加速できます。

今回のデモでは、オンプレミスのOllama LLMとクラウドベースのAzure OpenAI LLMの両方を設定しました。オンプレミスLLMは、機密情報が環境外に出ないようにするためにPIIデータ特定とセキュリティアラート分析に使用し、クラウドベースLLMは、一般的なデータのみを扱うMITRE ATT&CKフレームワークに基づいた検知ルールの提案に利用しています。LLM接続の設定が完了したところで、3つのセキュリティユースケースについて詳しく見ていきましょう。

ユースケース1：PIIデータの特定

Personally Identifiable Information（PII）は、セキュリティログに記録された膨大なデータの中に隠れていることがよくあります。PIIは予期しないフィールドや形式で現れることがあるため、手作業による確認は時間がかかり、見落としも発生しやすくなります。こうした課題に対して、LLMなどを活用した自動化手法は、ログ記録内に深く埋もれている機密情報を効率的に特定・保護するために不可欠になりつつあります。

この例では、下図のように複数のフィールドを含むサンプルアプリケーションログを調査します。PIIはContactIDやCommNumberのようなフィールドに現れる場合があり、StatusやTransactionIDなどの非PIIフィールドと混在しています。

PII特定における主な課題のひとつは、フィールド名だけでは機密情報の有無が明確に判断できない場合があることです。そのため、実際のフィールド値を直接確認する必要がありますが、手作業で行うと非常に手間がかかり、ミスも発生しやすくなります。これに対応するために、以下のSPLを使ってLLMにプロンプトを送り、自動的にPIIを特定します。

source="sample_application_log"
| foreach * [ eval k="<<FIELD>>", v='<<FIELD>>' | eval all_fields=mvappend(all_fields, k."=".v) ]
| mvexpand all_fields
| rex field=all_fields "(?<field>[^=]+)=(?<value>.*)"
| stats values(value) as examples by field
| eval examples=mvindex(examples, 0, 2)
| ai prompt = "Based on fieldname: {field} and its sample values {examples}, determine whether it contains PII information and explain why. Return strictly in this format <yes|no>,<reason>"
| rex field=ai_result_1 "(?<decision>\b(?:yes|no|YES|NO|Yes|No)\b|\[(?:yes|no|YES|NO|Yes|No)\]|\<(?:yes|no|YES|NO|Yes|No)\>)\s*[, ]+\s*(?<reason>.+)"
| eval decision=replace(decision, "[\[\]<>]", "")
| table field examples decision reason ai_result_1

このSPLでは、まずログから各フィールド名と、そのフィールドに含まれる3つのサンプル値を抽出します。これらのフィールド名と抽出した値をaiコマンド内のプロンプトに追加することで、ローカルLLMがそのフィールドにPIIが含まれているかどうかを判断できるようにします。フィールド名と代表的な値の両方を提示することで、LLMはより適切な判断を下せます。また、サンプル値の数はSPL内で簡単に調整でき、用途に応じて最適化することが可能です。

最後に、rexコマンドを使って応答フィールド（ai_result_1）からLLMの判断結果と根拠を抽出し、どのフィールドにPIIが含まれているかを特定します。このSPLの実行結果は、下図の通りです。

プロンプトは、企業のガイドラインに応じて柔軟に調整することができ、PIIフィールドの特定に役立ちます。さらに、プロンプト内に具体的な例を追加することで、精度の向上も期待できます。

ユースケース2：MITRE ATT&CKフレームワークに基づく検知ルールの提案

効果的な検出ルールの作成は困難な作業であり、最も関連性の高いルールを選定するには、最新の攻撃手法と自組織の業界特性の両方について深い理解が求められます。攻撃者の戦術や手法は業界ごとに異なることが多いため、自社環境に最も適したMITRE ATT&CKテクニックを特定することが重要です。これらのテクニックを特定した後は、それらに対応するSplunk検出ルールへとマッピングすることで、セキュリティ監視を最新かつ自社向けに最適化できます。

近年のLLMの進化により、MITRE ATT&CKフレームワークや、特定業界を狙った最新の攻撃手法への理解度が大幅に向上しました。これらのモデルを活用することで、セキュリティチームは自社の脅威状況に最も関連性の高いテクニックを効率的に特定できます。そのため、LLMは検出すべきテクニックの選定を支援する有用なツールとなり、検出活動が最新かつ業界固有の脅威に合わせて行われることを保証します。

この例では、LLMとSplunk Security Essentials（SSE）フレームワークの両方を活用し、最適な検出コンテンツを特定します。このプロセスで使用するSPLクエリは以下の通りです。

| makeresults | eval company_name = "Cisco" | eval num_results = "4"
| ai prompt="What is {company_name} and which industry they are in?" 
| ai prompt= "Are OT and IT usecases relevant to {ai_result_1}?" 
| ai prompt="Based on this organization: {ai_result_1} and attack surface relevancy: {ai_result_2}, suggest the top {num_results} MITRE attack techniques relevant to this organization, ONLY return the list of techniques ID separated by comma."
| rex max_match=0 field=ai_result_3 "(?<technique>T\d{4})"
| mvexpand technique
| dedup technique
| map maxsearches=100 search="
    | inputlookup mitre_detections 
    | eval mitre_id=\"$technique$\"
    | eval TechniquePrefix=mvindex(split(TechniqueIdCombined, \".\"), 0)
    | where TechniquePrefix=mitre_id
    | lookup mitre_data_sources Data_Component OUTPUT Description Data_Source
    | eval Data_Sources = \"** \" + Data_Source + \" **\" 
    | stats values(Data_Sources) as Data_Sources
    | eval technique=\"$technique$\"
    | eval ai_result_1=\"$ai_result_1$\"
    | eval ai_result_2=\"$ai_result_2$\"
    | eval ai_result_3=\"$ai_result_3$\"
"
| map maxsearches=100 search="
    | sseanalytics include_json=true
    | search mitre_technique=*$technique$*
    | eval Rules_Combined = \"** \" + name + \" **\"
    | stats values(Rules_Combined) as Detection_Rules
    | eval technique=\"$technique$\"
    | eval ai_result_1=\"$ai_result_1$\"
    | eval ai_result_2=\"$ai_result_2$\"
    | eval ai_result_3=\"$ai_result_3$\"
    | eval Data_Sources=\"$Data_Sources$\"
"
| rename technique as Related_Mitre_Technique, ai_result_1 as Company_Info, ai_result_2 as Company_Usecase
| ai prompt="Based on this Mitre attack technique: {Related_Mitre_Technique}, explain it in layman's term"
| rename ai_result_1 as Technique_Explained
| table Related_Mitre_Technique Technique_Explained Data_Sources Detection_Rules

このSPLクエリの冒頭では、企業名を指定します（これは任意の組織に合わせてカスタマイズ可能です）。また、出力するMITRE ATT&CKテクニックの最大数も設定します（この例では4件に設定）。最初に、指定した企業名に基づいてLLMにその企業および業界の説明を生成させます。この初回プロンプトの出力結果を、次のLLMプロンプトで利用し、企業および業界に関連するOTおよびITのユースケースを生成するようモデルに依頼します。最後のステップでは、これらのユースケースを標的とする攻撃手法（テクニック）のリストを特定するよう、LLMにさらにプロンプトします。このようにLLMへのプロンプトを連鎖させることで、モデルの推論プロセスが強化され、より精度が高くコンテキストに即した結果が得られます。

なお、最終プロンプトで出力フォーマットを指定しても、モデルの応答にはばらつきが生じる場合があります。これに対応するため、rexコマンドを使って3回目のプロンプトに対するLLMの応答からテクニックコードを抽出します。各テクニックコードは、2つのサブサーチで処理されます。1つ目のサブサーチではSSEのルックアップを使用してSplunk内の関連データソースを取得し、2つ目では各テクニックに利用可能な検出ルールを特定します。最後に、各テクニックの内容を明確に理解できるよう、LLMに再度プロンプトして説明を生成します。

このSPLクエリの出力結果は下図に示されています。

LLMによって提案された各テクニックごとに、対応するデータソースと検出ルールのセットが提供されます。ユーザーは、これらの結果を自社環境の状況に照らして確認することで、追加で取り込むべきデータソースや有効化すべき検出ルールを特定できます。

このSPLクエリは、本ユースケースの一例です。プロンプトは簡単にカスタマイズでき、特定のサービスやソフトウェアタイプに焦点を当てることも可能です。これにより、自社のニーズに最も適した検出コンテンツを柔軟に見つけ出すことができます。

ユースケース３：セキュリティアラート分析

Splunk Enterprise Securityでは、有効化された検知ルールと取り込まれたデータからファインディング（Finding）が生成されます。単一のルールに基づいたファインディングもありますが、累積的なエンティティリスクスコアリングやMITRE ATT&CK、Cyber Kill Chainといったフレームワークなど、高度なメカニズムから派生するファインディングも存在します。これらの高度なファインディングは、複数の関連アラートを相関させ、分析者が複雑な攻撃手法や複数段階にわたるキャンペーンを特定できるよう設計されています。

累積的なファインディングは、関連するイベントを集約することで貴重なコンテキストを提供し、分析者が攻撃の進行や影響を受けたエンティティをより深く理解できるようにします。しかし、インシデント全体を把握するためには、分析者が個々のアラートを確認する必要があり、これは時間がかかるうえに人的ミスのリスクも伴います。

次の画像は、7日間にわたって観測された複数のMITRE ATT&CK戦術の検出に基づくファインディングを示しています。このファインディングは、24件の個別アラートを集約しています。この例では、MLTK AIコマンドを使用して、LLM（大規模言語モデル）を活用し、一連のアラートを分析する方法を紹介します。

LLMを用いて大量のデータを一度に分析する際の課題の一つは、特にローカル環境でLLMを展開する場合に、モデルのコンテキストウィンドウの制約に対応することです。この例では、以下のSPLコマンドを使用することで、この課題に対処しています。

1. Splunk Enterprise SecurityのRiskデータモデルから、リスクオブジェクト（ユーザー「fyodor」）に関連する生イベントを取得します。
2. 各アラートイベントの検知内容（detection description）を取得します。
3. 各アラートごとに、タイムスタンプ、検知内容、リスクオブジェクト、リスクスコアを抽出します。

このようにアラートデータを集約することで、データ量をLLMのコンテキストウィンドウに収まるように削減できます。最後に、aiコマンドを使ってモデルにプロンプトを渡し、ファインディングの構造化された分析結果を生成させます。

| from datamodel:"Risk.All_Risk" 
| normalizeip normalized_risk_object 
| search normalized_risk_object="fyodor" risk_object_type="user" annotations.mitre_attack.mitre_tactic_id=* | `get_correlations` 
| rename annotations.mitre_attack.mitre_tactic_id as mitre_tactic_id, annotations.mitre_attack.mitre_tactic as mitre_tactic, annotations.mitre_attack.mitre_technique_id as mitre_technique_id, annotations.mitre_attack.mitre_technique as mitre_technique 
| noop search_optimization.search_expansion=false
| table _time, rule_name, risk_object, risk_message, risk_score, mitre_technique_id 
| sort _time
| eval details = "Time=" + _time + ", Rule Name=" + rule_name + ", Risk Score=" + risk_score + ", Risk Message=" + risk_message 
| stats values(details) by risk_object
| ai prompt=" Based on respective alerts, where each alert starts with "Time=", and their rule name, risk score and risk message in {values(details)}, where the time value is a epoch time value, provide a concise summary of the security incident which has happened to {risk_object} in chronological order, create a timeline on what happened at what time (in the format of YYYY-MM-DD HH:MM:SS) with details at each time and the potential impacts. Provide an analysis on how the risk score accumulated to a final score based on the behaviors of {risk_object}. Provide an overall analysis of this finding and suggestions on investigation and triaging."

モデルの出力例を以下に示します。LLMは、検知されたイベントのタイムラインと、それぞれに関連付けられたリスクスコアを明確に生成しました。さらに、主要なファインディングを人間が理解しやすい形式で要約し、追加調査のための具体的な提案も提供しています。この分析により、ユーザーはアラート内容を容易に理解し、適切な次のアクションを判断できるようになります。

LLMによる分析はSPL経由で実装されているため、Enterprise Securityフレームワーク内でドリルダウンサーチとして登録することも可能です。これにより、ファインディングから直接シームレスに分析を実行でき、セキュリティ調査の効率と効果が向上します。

まとめ

本ブログでご紹介したように、LLMとSplunk MLTKの連携により、PII特定、検出ルール選定とアラート分析といった複雑な作業が効率化され、セキュリティチームに新たな可能性が広がります。シンプルなセットアップと強力なAI駆動のインサイトによって、組織は進化するセキュリティ課題により柔軟に対応し、業務のイノベーションを推進できるようになります。

謝辞

このブログ記事のユースケース内容は、Feirryanto Winata、Michael Cheo、Calvin Ngおよび阿部浩人と共同で作成されました。