使用 LLM 总结用户会话

随着 8.8 版本中 AI 助手引入到安全解决方案中，Elastic 的安全机器学习团队一直在探索如何使用 GPT-4 等 LLM 优化安全运营。用户会话总结似乎是一个完美的实验用例，原因如下：

用户会话摘要可以帮助分析师快速决定特定会话的活动是否值得调查。
鉴于 GPT-4 等 LLM 接受过训练的数据的多样性，不难想象它们已经接受过 man page 和其他开放安全内容的训练，这可以为会话调查提供有用的上下文。
会话摘要可以作为会话视图工具的良好补充，该工具自 8.2 版本起已在 Elastic Security Solution 中提供。

在本出版物中，我们将讨论我们使用 GPT-4 总结用户会话的实验中吸取的教训和主要收获。

在我们的后续研究中，我们花了一些时间来检查具有相似之处的会话。这些相似的会话可以随后帮助分析师识别相关的可疑活动。

什么是会话？

在 Linux 和其他类 Unix 系统中，“用户会话”是指用户登录系统期间的这段时间。当用户通过图形登录管理器（GDM、LightDM）或通过命令行界面（终端、SSH）登录系统时，会话开始。

启动 Linux 内核后，会创建一个名为“init”的特殊进程，该进程负责启动已配置的服务，例如数据库、Web 服务器和远程访问服务（例如 sshd）。这些服务以及它们产生的任何 shell 或进程通常都封装在它们自己的会话中，并通过单个会话 ID (SID) 绑定在一起。

会话捕获的详细和按时间顺序排列的流程信息使其成为警报、合规性和威胁搜寻的极其有用的资产。

经验教训

在我们的实验中，我们使用了通过 Azure AI Studio 提供的具有 32k 令牌限制的 GPT-4 部署。令牌是 LLM 用于处理和生成语言的文本或代码的基本单位。我们的目标是了解仅在提示范例中，我们在用户会话总结方面能取得多大的进展。我们在此过程中学到了一些关于数据处理、提示工程、幻觉、参数调整和评估 GPT 摘要的知识。

数据处理

要点：会话的聚合 JSON 快照是一种有效的总结输入格式。

这里的会话只是进程、网络、文件和警报事件的集合。用户会话中的事件数量范围从少数（< 10 个）到数十万个。每个事件日志本身都可能非常冗长，包含数百个字段。对于具有大量事件的较长会话，可能会快速遇到像 GPT-4 这样的模型的令牌限制。因此，将原始日志作为 GPT-4 的输入对于我们的特定用例来说不是很有用。我们在实验中看到了这一点，即使在使用 CSV 等表格格式，以及使用日志中的一小部分字段时也是如此。

为了解决这个问题，我们不得不提出一种输入格式，该格式在尽可能保留会话上下文的同时，还使输入令牌的数量或多或少保持恒定，而与会话的长度无关。我们尝试了几种日志重复数据删除和聚合策略，发现会话的聚合 JSON 快照非常适合总结。示例文档如下

此 JSON 快照使用重复数据删除列表、聚合计数和最频繁术语的前 N 个（在我们的例子中为 20 个），以及不言自明的字段名称来突出显示会话中最突出的活动。

提示工程

要点： 使用高级指令进行少样本微调效果最佳。

除了数据处理之外，我们实验中的大部分时间都花在了提示微调上。我们从一个基本的提示开始，发现该模型很难将各个点联系起来以生成有用的摘要

You are an AI assistant that helps people find information.

然后，我们尝试在提示中提供非常详细的说明，但注意到该模型忽略了部分说明

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?

根据上述提示，该模型未能可靠地遵循 3 段请求，并且还列出了明确告知不要列出的进程名称和文件路径。

最后，我们得到了以下为模型提供高级说明的提示

Analyze the following Linux user session, focusing on:      
- Identifying the host and user names      
- Observing activities and identifying key patterns or trends      
- Noting any indications of malicious or suspicious behavior such as tunneling or encrypted traffic, login failures, access to sensitive files, large number of file creations and deletions, disabling or modifying Security software, use of Shadow IT, unusual parent-child process executions, long-running processes
- Conclude with a comprehensive summary of what the user might be trying to do in the session, based on the process, network, and file activity     
 ###
 Text: {your input here}

我们还注意到，当指令在用户提示中提供而不是在系统提示中提供时，模型会更密切地遵循指令（系统提示是对模型的初始指令，告诉它应该如何行为，用户提示是用户向模型提出的问题/查询）。在上面的提示之后，我们对摘要的内容感到满意，但输出格式不一致，模型在段落和项目符号列表之间切换。我们通过少样本微调解决了这个问题，方法是向模型提供了两个用户提示与预期响应的示例。

幻觉

要点： 模型偶尔会在为摘要生成全新内容时产生幻觉。

我们观察到，模型在总结输入中立即显而易见的事实（例如用户和主机实体、网络端口等）时通常不会产生幻觉。有时，该模型会在总结不明显的信息时产生幻觉，例如，在本例中，总结会话中的整体用户意图。我们发现一些相对容易的方法可以缓解幻觉，如下所示：

在总结时提示模型关注特定行为
重申模型应该检查其输出的事实
将温度设置为较低的值（小于或等于 0.2），以使模型生成较少样化的响应，从而减少产生幻觉的可能性
限制响应长度，从而减少模型偏离轨道的可能性 — 如果要总结的文本长度或多或少恒定，则此方法特别有效，在我们的例子中就是如此

参数调整

要点： 温度 = 0 并不能保证确定性。

对于总结，我们探索了调整诸如温度和 Top P 等参数，以从模型获得确定性响应。我们的观察结果如下：

不建议同时调整两者，并且当组合使用时也很难观察到每一个的效果
通常，仅将温度设置为较低的值（< 0.2），而不更改 Top P 就足够了
即使将温度设置为 0 也不会产生完全确定的输出，因为浮点计算固有的非确定性（有关更详细的说明，请参阅 OpenAI 的此帖子）

评估 GPT 摘要

与任何建模任务一样，评估 GPT 摘要对于衡量模型结果的质量和可靠性至关重要。由于文本生成没有标准化的评估方法和指标，我们决定对摘要进行定性的人工评估，以及使用诸如 ROUGE-L、BLEU、METEOR、BERTScore 和 BLANC 等自动指标进行定量评估。

对于定性评估，我们让一位安全研究员为精心挑选的 10 个会话（为了获得短会话和长会话的良好分布）编写摘要，而他们并不知道 GPT 摘要的内容。我们请三位评估员使用三个关键标准将 GPT 摘要与人工生成的摘要进行比较：

事实性：检查模型摘要是否保留了安全专家提供的会话关键事实。
真实性：检查是否存在幻觉。
一致性：检查模型输出的一致性，即所有响应是否都具有稳定的格式并产生相同级别的细节。

最后，根据多数投票结果，为每个 10 个摘要分配“好”或“坏”的最终评级，以整合评估员的选择。

尽管我们承认评估的数据集规模较小，但我们的定性评估表明，GPT 摘要在 80% 的时间里与人工摘要保持一致。对于获得“坏”评级的 GPT 摘要，摘要没有保留某些重要的事实，因为聚合的 JSON 文档只保留了某些字段的前 N 个术语。

自动指标似乎与人类偏好不符，也没有可靠地衡量摘要质量，因为人类和 LLM 生成的摘要之间存在结构差异，尤其是对于基于参考的指标而言。

下一步是什么

我们目前正在研究如何通过检索增强生成 (RAG)，使用 Elastic Search and Relevance Engine (ESRE) 中的工具，进一步改进摘要生成。我们还尝试使用 LLM 对用户会话进行分类。请继续关注本博客的第二部分，以了解有关这些实验的更多信息！

同时，我们很乐意了解您在使用 LLM、ESRE 等方面的实验。如果您想分享您的工作或在过程中遇到任何问题，请通过我们的社区 Slack 频道和讨论论坛与我们联系。祝您实验愉快！

使用 LLM 总结用户会话