LLMとESREを使用した類似ユーザーセッションの検索
前回の記事では、GPT-4 Large Language Model(LLM)を使用して、複雑なLinuxユーザーセッションを簡潔な要約に凝縮する方法を探りました。実験から得られた重要なポイントを強調し、データの前処理、迅速な調整、モデルパラメータの調整のニュアンスに光を当てました。 同じ実験の文脈で、類似点を共有するセッションを検討するために時間を割きました。 これらの同様のセッションは、その後、アナリストが関連する疑わしいアクティビティを特定するのに役立ちます。 ユーザーセッションの類似点を見つけるために、次の方法を検討しました。
- 類似のユーザープロファイルとセッションを明らかにするために、私たちが着手したアプローチの1つは、ユーザーが実行したアクションに応じてセッションを分類することでした。これを実現するには、言語モデルモデル(LLM)にユーザーセッションを事前定義されたカテゴリに分類するように指示しました
- さらに、 ELSER (Elasticのセマンティック検索用検索モデル)の機能を活用して、セッション要約実験から導き出されたモデル要約に対してセマンティック検索を実行しました
本研究では、GPT-4を用いたセッション分類実験と ESRE を用いたセマンティックサーチ実験に着目した研究を行っています。
GPT を活用したセッションの分類
私たちは、ドメインの専門知識を持つセキュリティ研究者の同僚に相談して、 75 セッションのデータセットに9つのカテゴリを定義しました。 これらのカテゴリは、セッションで観察される主な動作と重要な特徴を一般化します。 これには、次のアクティビティが含まれます。
- Docker の実行
- ネットワーク運用
- ファイル検索
- Linuxコマンドラインの使用法
- Linuxサンドボックスアプリケーションの使用
- Pipのインストール
- パッケージのインストール
- スクリプトの実行
- プロセス実行
教訓
今回の実験では、トークン制限が 32k の Azure AI Studio で GPT-4 デプロイを使用しました。 GPTモデルのセッション分類の可能性を探るため、セッション の分類に使用したのと同じJSONサマリードキュメントを入力してセッションを分類するようにモデルに指示する一連の実験を行いました。
この取り組みには複数のイテレーションが含まれ、その間、プロンプトの強化と Few-Shot Learning の強化に注力しました。 モデル パラメーターについては、出力の多様性を少なくするために、 温度を 0 に維持しました。
迅速なエンジニアリング
テイクアウト： プロンプトにカテゴリの説明を含めても、モデルのパフォーマンスには影響しません。
セッションの分類コンポーネントは、セッションの要約プロンプトの拡張として導入されました。 私たちは、各カテゴリーの文脈的な説明をプロンプトと一緒に組み込むことの効果を探りました。 興味深いことに、私たちの調査結果は、説明的なコンテキストを追加することは、そのような補足情報がないプロンプトと比較して、モデルのパフォーマンスに大きな影響を与えないことを明らかにしました。
以下は、モデルの分類プロセスをガイドするために使用したテンプレートです。
You are a cybersecurity assistant, who helps Security analysts in summarizing activities that transpired in a Linux session. A summary of events that occurred in the session will be provided in JSON format. No need to explicitly list out process names and file paths. Summarize the session in ~3 paragraphs, focusing on the following:
- Entities involved in the session: host name and user names.
- Overview of any network activity. What major source and destination ips are involved? Any malicious port activity?
- Overview of any file activity. Were any sensitive files or directories accessed?
- Highlight any other important process activity
- Looking at the process, network, and file activity, what is the user trying to do in the session? Does the activity indicate malicious behavior?
Also, categorize the below Linux session in one of the following 9 categories: Network, Script Execution, Linux Command Line Utility, File search, Docker Execution, Package Installations, Pip Installations, Process Execution and Linux Sandbox Application.
A brief description for each Linux session category is provided below. Refer to these explanations while categorizing the sessions.
- Docker Execution: The session involves command with docker operations, such as docker-run and others
- Network: The session involves commands with network operations
- File Search: The session involves file operations, pertaining to search
- Linux Command Line Utility: The session involves linux command executions
- Linux Sandbox Application: The session involves a sandbox application activity.
- Pip Installations: The session involves python pip installations
- Package Installations: The session involves package installations or removal activities. This is more of apt-get, yum, dpkg and general command line installers as opposed to any software wrapper
- Script Execution: The session involves bash script invocations. All of these have pointed custom infrastructure script invocations
- Process Execution: The session focuses on other process executions and is not limited to linux commands.
###
Text: {your input here}フューショットチューニング
テイクアウト： 各カテゴリの例を追加すると、精度が向上します。
同時に、上記のプロンプトに各カテゴリの例を1つずつ含めることにより、モデルのパフォーマンスを向上させる効果を調査しました。 この戦略により、モデルの精度が20%向上するなど、大幅な向上がもたらされました。
GPTカテゴリの評価
GPTカテゴリーの評価は、結果の質と信頼性を測定する上で非常に重要です。 分類結果の評価では、モデルの分類と、セキュリティの専門家が割り当てた人間による分類(下図では「Ground_Truth」と表記)との比較を行いました。 分類評価のために、成功した一致の数に基づいて合計精度を計算しました。
GPT-4は、複数のカテゴリーを持つサンプルを扱う際に課題に直面していることがわかりました。 しかし、単一のカテゴリーを割り当てると、56%のケースで人間の分類と一致しました。 「Linux Command Line Utility」カテゴリは特に課題があり、誤検出の 47% が「Process Execution」または「Script Execution」と誤って分類されることが多かった。 この不一致は、「Linuxコマンドラインユーティリティ」カテゴリと「プロセス実行」カテゴリの密接に関連する定義が原因で発生し、プロンプトにはプロセスコマンドライン引数などの情報が不十分であった可能性があり、これらのカテゴリの貴重な識別要因として機能した可能性があります。
評価の結果から、プロンプトの各カテゴリの説明を調整するか、少数のショット トレーニングを通じてモデルにより多くの例を提供する必要があると結論付けます。 さらに、GPTが分類に最も適した選択肢であるかどうか、特にプロンプトパラダイムの文脈で検討する価値があります。
ELSERによるセマンティック検索
また、セマンティック検索用のElastic Learned Sparse EncodeRである ELSERも試してみたかったのです。 セマンティック検索は、厳密に正確なキーワード入力ではなく、コンテキストの意味に焦点を当てており、ELSERはElasticによってトレーニングされた検索モデルであり、セマンティック検索を実行してより関連性の高い結果を取得できます。
セッションの要約でセマンティック検索の質問の例をいくつか試しました。 セッションのサマリーはElasticsearchインデックスに保存され、 公式チュートリアルに従ってELSERモデルをダウンロードするのは簡単でした。 ELSERによって生成されたトークンは、次の画像に示すようにインデックスに格納されます。
その後、インデックスのセマンティック検索は、全体的に最も関連性の高いイベントを取得することができました。 イベントに関するセマンティック検索クエリには、次のものが含まれます。
- パスワード関連 – 1Password関連のログの生成
- Java – Java を使用したログの生成
- Python – Python を使用したログの生成
- 非インタラクティブセッション
- インタラクティブセッション
セマンティック検索の例は、Dev Tools コンソールの text_expansion クエリで確認できます。
いくつかのポイントは次のとおりです。
- セマンティック検索の場合、プロンプト テンプレートが原因で、サマリーに関連しないキーワードが多すぎる可能性があります。 たとえば、すべてのサマリーに、セッションを「悪意がある」と見なすべきかどうかの評価を含めるようにし、その特定の単語は常に結果として得られるサマリーに含まれていました。 したがって、良性のセッションと悪意のあるセッションの要約には、「このセッションは悪意があります」や「このセッションは悪意はありません」などの文を通じて「悪意がある」という言葉が含まれていました。 これは精度に影響を与えた可能性があります。
- セマンティック検索では、インタラクティブと非インタラクティブなど、特定の関連概念を効果的に区別できていないように見えました。 少数の特定の用語が、セマンティック検索のセッション要約の核心的な意味にとって十分に重要であるとは考えられなかった可能性があります。
- セマンティック検索は、ユーザーが正確なキーワードを指定しない場合、 BM25 よりもうまく機能します。 たとえば、「Python」または「Java」関連のログとサマリーの検索は、ELSERとBM25の両方で同様に効果的です。 ただし、ELSERは、「オブジェクト指向言語」関連のログを検索するときに、より関連性の高いデータを取得できます。 対照的に、「オブジェクト指向言語」のキーワード検索を使用すると、次の画像に示すように、適切な結果は得られません。
新しいエクスペリエンス
現在、 Elastic Search and Relevance Engine(ESRE)のツールを使用した Retrieval Augmented Generation(RAG) による要約のさらなる改善を検討しています。それまでの間、LLMやESREなどでの実験についてお聞かせください。 あなたが何をしているのかを共有したい場合、またはプロセス中に問題が発生した場合は、 コミュニティのSlackチャンネル と ディスカッションフォーラムでご連絡ください。