使用LLM总结用户会话
随着在8.8版本中将AI助手引入安全解决方案,Elastic的安全机器学习团队一直在探索如何使用GPT-4等LLM优化安全操作。用户会话总结似乎是一个完美的用例,可以开始进行实验,原因如下:
- 用户会话总结可以帮助分析师快速确定特定会话的活动是否值得调查。
- 鉴于GPT-4等LLM接受过各种数据的训练,不难想象它们已经接受过man手册页和其他开放的安全内容的训练,这可以为会话调查提供有用的上下文。
- 会话总结可以作为会话视图工具的良好补充,该工具从Elastic安全解决方案8.2版本开始可用。
在本篇文章中,我们将讨论使用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生成的总结与人工生成的总结进行比较。
- 事实性:检查模型总结是否保留了安全专家提供的会话关键事实。
- 真实性:检查是否存在幻觉(hallucinations,即模型编造事实)。
- 一致性:检查模型输出的一致性,即所有响应是否共享稳定的格式并产生相同级别的细节。
最后,根据多数投票结果,将10个总结中的每一个最终评定为“好”或“坏”,以整合评估人员的选择。
虽然我们承认评估的数据集规模较小,但我们的定性评估显示,GPT生成的总结在80%的时间里与人工总结一致。对于那些被评为“坏”的GPT总结,其未能保留某些重要事实,原因是聚合的JSON文档仅保留了某些字段的前N个术语。
自动化指标似乎与人工偏好不符,并且由于人工生成的总结和LLM生成的总结之间存在结构差异(尤其是在基于引用的指标方面),它们也无法可靠地衡量总结质量。
下一步
我们目前正在研究如何通过检索增强生成 (RAG)进一步改进总结,并使用Elasticsearch 和相关引擎 (ESRE)中的工具。我们还尝试使用LLM对用户会话进行分类。敬请关注本博客的第二部分,了解更多关于这些实验的内容!
同时,我们非常乐意听到您使用LLM、ESRE等的实验结果。如果您想分享您的工作,或在过程中遇到任何问题,请通过我们的社区Slack频道和讨论论坛联系我们。祝您实验愉快!