使用 LLM 和 ESRE 查找相似的用户会话
在我们之前的文章中,我们探索了使用 GPT-4 大型语言模型 (LLM) 将复杂的 Linux 用户会话浓缩为简洁的摘要。 我们强调了实验的关键要点,阐明了数据预处理、快速调整和模型参数调整的细微差别。 在同一个实验中,我们花了一些时间来检查具有相似之处的会议。 这些类似的会话随后可以帮助分析师识别相关的可疑活动。 我们探索了以下方法来查找用户会话中的相似之处:
- 为了发现相似的用户资料和会话,我们采取的一种方法是根据用户执行的操作对会话进行分类;我们通过指示语言模型 (LLM) 将用户会话分类到预定义的类别中来实现这一点
- 此外,我们利用ELSER (Elastic 的语义搜索检索模型)的功能,对会话摘要实验得出的模型摘要执行语义搜索
本研究重点关注我们使用 GPT-4 进行会话分类和使用ESRE进行语义搜索的实验。
利用 GPT 进行会话分类
我们咨询了一位拥有该领域专业知识的安全研究同事,为我们的 75 个会话数据集定义了九个类别。 这些类别概括了会议中观察到的主要行为和重要特征。 其中包括以下活动:
- Docker 执行
- 网络运营
- 文件搜索
- Linux 命令行用法
- Linux 沙盒应用程序使用情况
- Pip 安装
- 软件包安装
- 脚本执行
- 流程执行
经验教训
在我们的实验中,我们在 Azure AI Studio 中使用了 GPT-4 部署,令牌限制为 32k。 为了探索 GPT 模型在会话分类方面的潜力,我们进行了一系列实验,通过输入我们用于会话摘要过程的相同 JSON 摘要文档来指示模型对会话进行分类。
这项工作包括多次迭代,在此期间我们专注于增强提示和小样本学习。 至于模型参数,我们将温度维持在 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}
小样本调优
要点:为每个类别添加示例可以提高准确性。
同时,我们通过在上述提示中为每个类别包含一个示例来研究提高模型性能的有效性。 这一策略带来了显著的增强,模型的准确率特别提高了 20%。
评估 GPT 类别
GPT 类别的评估对于衡量结果的质量和可靠性至关重要。 在分类结果评估中,将模型的分类与安全专家指定的人工分类(下图中称为“Ground_Truth”)进行了比较。 我们根据分类评估的成功匹配次数计算总体准确率。
我们观察到 GPT-4 在处理具有多个类别的样本时面临挑战。 然而,当分配单个类别时,56% 的情况与人类分类一致。 “Linux 命令行实用程序”类别带来了特殊的挑战,其中 47% 的误报经常被错误归类为“进程执行”或“脚本执行”。 这种差异是由于“Linux 命令行实用程序”和“进程执行”类别的定义密切相关而引起的,并且提示中可能也没有足够的信息,例如进程命令行参数,而这些信息可以作为这些类别的有价值的区分因素。
根据我们的评估结果,我们得出结论,我们要么需要调整提示中每个类别的描述,要么通过少量训练为模型提供更多示例。 此外,值得考虑的是,GPT 是否是最适合分类的选择,特别是在提示范式的背景下。
使用 ELSER 进行语义搜索
我们还想尝试ELSER ,即用于语义搜索的 Elastic Learned Sparse EncodeR。 语义搜索注重上下文含义,而不是严格精确的关键字输入,ELSER 是经过 Elastic 训练的检索模型,可让您执行语义搜索并检索更相关的结果。
我们在会议摘要中尝试了一些语义搜索问题的例子。 会话摘要存储在 Elasticsearch 索引中,按照官方教程下载 ELSER 模型非常简单。 ELSER生成的token存储在索引中,如下图所示:
随后,索引上的语义搜索总体上能够检索到最相关的事件。 关于该事件的语义搜索查询包括:
- 密码相关——产生 1Password 相关日志
- Java – 生成使用 Java 的日志
- Python – 生成使用 Python 的日志
- 非交互式会话
- 互动环节
我们可以通过text_expansion 查询在 Dev Tools 控制台中看到语义搜索的示例。
以下是一些要点:
- 对于语义搜索,提示模板可能会导致摘要包含太多不相关的关键字。 例如,我们希望每个摘要都包含对会话是否应被视为“恶意”的评估,该特定词始终包含在生成的摘要中。 因此,良性会话和恶意会话的摘要都包含“恶意”一词,例如“此会话是恶意的”或“此会话不是恶意的”。 这可能会影响准确性。
- 语义搜索似乎无法有效区分某些相关概念,例如交互式和非交互式。 对于语义搜索而言,少数特定术语可能被认为对会话摘要的核心含义不够重要。
- 当用户没有指定精确的关键词时,语义搜索比BM25效果更好。 例如,使用 ELSER 和 BM25 搜索“Python”或“Java”相关的日志和摘要同样有效。 然而,ELSER 在搜索“面向对象语言”相关日志时可以检索到更多相关数据。 相比之下,使用关键字搜索“面向对象语言”不会产生相关结果,如下图所示。
后续工作计划
我们目前正在研究使用 弹性搜索和关联引擎(ESRE) 中的工具,通过 检索增强生成 (RAG) 进一步改进摘要。与此同时,我们很想听听您对 LLM、ESRE 等的实验。 如果您想分享您正在做的事情或者在此过程中遇到任何问题,请通过我们的社区 Slack 频道和讨论论坛与我们联系。