Google如何利用生成式AI加速事件响应流程

本文主要介绍了谷歌如何将生成式AI技术应用到网络安全事件响应流程中，特别是在撰写事件总结和高管更新报告方面。通过对比试验，他们发现AI生成的事件总结在质量和效率上都优于人工撰写。报告还讨论了应用AI的最佳实践，包括搭建数据管道、设计输入提示、保护敏感信息等。此外，他们还展望了将AI技术拓展到代码安全审计、事件响应指引生成等更多场景的可能性。

1.介绍

作为安全专业人员，我们一直在寻找降低风险和提高工作流效率的方法。今天，我们要强调使用生成式AI（generative AI）帮助防御者获得优势的另一种方式：利用大语言模型（LLM）加速安全和隐私事件工作流。

事件管理是一项团队运动。我们必须为不同的受众（包括高管、主管和合作团队）总结安全和隐私事件。这可能是一个繁琐且耗时的过程，在很大程度上取决于目标群体和事件的复杂性。我们估计，写一个全面的总结可能需要将近一个小时，而更复杂的沟通可能需要几个小时。但我们假设，我们可以使用生成式AI更快地汇总信息，让我们的事件响应人员可以专注于其他更关键的任务——事实证明这是正确的。使用生成式 AI，我们可以将撰写摘要的速度提高51%，同时也提高了摘要的质量。

2.Google的事件响应方法

例如，当怀疑潜在的数据事件时，我们遵循严格的流程来管理它。从问题的识别、专家和工具的协调，到解决方案和结案。在 Google，当报告事件时，我们的检测和响应团队会努力尽快恢复正常服务，同时满足监管和合同的合规性要求。他们通过遵循 Google 事件响应计划中的五个主要步骤来实现这一点：

1. 识别：监控安全事件以检测潜在的数据事件并报告，使用先进的检测工具、信号和告警机制提供潜在事件的早期指示。 

2. 协调：通过收集事实和评估事件的严重性来分类报告，评估因素包括对客户的潜在危害、事件的性质、可能受影响的数据类型以及事件对客户的影响。然后确定与适当主管的沟通计划。

3. 解决：收集有关事件的关键事实，如根本原因和影响，并根据需要整合其他资源，以实施必要的修复措施作为补救的一部分。 

4. 结案：在补救努力结束后，以及在数据事件得到解决之后，审查事件和响应，以确定需要改进的关键领域。

5. 持续改进：对于事件响应计划的制定和维护至关重要。团队根据经验教训努力改进计划，确保维护必要的团队、培训、流程、资源和工具。

3.利用生成式人工智能

我们的检测和响应流程对于保护我们全球数十亿用户免受不断增长的威胁形势至关重要，这就是为什么我们不断寻求使用最新技术和技术来改进它们的原因。生成式 AI 的发展带来了这一领域巨大的潜力，我们渴望探索它如何帮助我们改进事件响应流程的某些部分。我们首先利用LLM不仅开创事件响应的现代方法，而且还要确保我们的流程在规模上高效和有效。

管理事件可能是一个复杂的过程，另一个因素是就威胁和事件状态与领导、高管和利益相关者进行有效的内部沟通。有效的沟通至关重要，因为它可以使高管适当了解情况，以便他们可以采取任何必要的行动，并满足监管要求。利用 LLM 进行这种类型的通信可以为事件响应负责人节省大量时间，同时提高质量。

4.人类与LLM

鉴于 LLM 具有摘要功能，我们想探索它们是否能够生成与人类相同或同样好的摘要。我们进行了一项实验，从母语和非母语英语使用者那里获取了50份人工撰写的总结，以及使用我们最好的（也是最终的）提示生成的50份LLM撰写的总结，并在不透露作者的情况下将它们提交给安全团队。

我们了解到，LLM撰写的摘要涵盖了所有关键点，它们的评分比人工撰写的等效摘要高出10%，并且将起草摘要所需的时间减少了一半。

人类与LLM内容完整性比较

人类与LLM写作风格的比较

5.管理风险和保护隐私

利用生成式AI并非没有风险。为了降低潜在的幻觉和错误风险，任何LLM生成的草稿都必须由人类进行审核。但并非所有风险都来自LLM——人类对LLM生成的事实或陈述的误解也可能发生。这就是为什么确保人类问责制以及随着时间的推移监控质量和反馈很重要。

鉴于我们的事件可能包含机密、敏感和特权数据的混合，我们必须确保构建不存储任何数据的基础架构。从用户界面到LLM再到输出处理，该管道的每个组件都已关闭日志记录。而且，LLM本身不使用任何输入或输出进行再训练。相反，我们使用指标和指标来确保它正常工作。

6.输入处理

我们在事件期间处理的数据类型可能混乱且通常是非结构化的：自由格式文本、日志、图像、链接、影响统计数据、时间表和代码片段。我们需要将所有这些数据结构化，以便LLM"知道"信息的哪一部分起什么作用。为此，我们首先用自闭合标签（<Code Section/> 和 <Logs/>）替换冗长且嘈杂的代码/日志部分，既是为了在节省更多重要事实的令牌的同时保持结构，也是为了减少幻觉的风险。

<Security_Incidents><Title> [tool_name_verdict] Abuse verdict for project: id: xyz-v/Title><Metadata> This ticket was filled and submitted on the 2023-10-01. It was marked with the labels:  "Investigation" and "AB". A/B testing was paused.<Description> <Content>Abuse has issued an abuse verdict against a GCP project:</Description><Additional Information> The infraction was regarding the use of phishing templates for the violation of COLA,PIRACY.</Additional Information>The urls can be found in the project xyz-v/Additional Information:<Data Incident> 2023-10-01 11:50:19</Data Incident><Incident Cause> The identified causes are:MISCONFIGURATION, WEAK OR NO PASSWORD</Incident Cause><Actions Taken> The following actions were taken:1) Action2) Action</Actions Taken><Software Involved> Software</Software Involved><Sensitive Data>  NOME: TEST</Sensitive Data><Mitigating History>  <Entry>2022-09-21: Applied a patch VULN-01-01. It was marked with the labels: URL around 85:80. Running application? now.</Comment><Comment index="2" author="[email protected]"> Instance stopped</Comment><Comment index="3" author="[email protected]"> InstanceMigrate</Comment><Comment index="4" author="[email protected]" instanceMigrateFrom="domain.com">URL <Code Section/> </Comment><Comment index="5" author="[email protected]"> Looks like it was compromised through a successful  authentication as root account using SSH with password authentication. <Code Section/> </Comment><Comment index="6" author="[email protected]"> Looks like it was created with the adatum  <Code Section/>. The cron job downloaded a bash script fro IP and executed it. The script was  not present under <Code Section/> at the time of the investigation. <Code Section/> </Comment><Comment index="10" author="[email protected]"> Exec update sent.</Comment></MitigatingHistory></Security_Incidents>

在提示工程期间，我们改进了这种方法，并添加了其他标签，例如<Title>、<Actions Taken>、<Impact>、<Mitigation History>、<Comment>，因此输入的结构与我们的事件通信模板紧密镜像。使用自解释标签使我们能够向模型传达隐式信息，并在提示中为指南或任务提供别名，例如通过声明"总结<Security Incident>"。

7.提示工程（Prompt engineering）

一旦我们为输入添加了结构，就该设计提示了。我们从简单的开始，通过一个简短的任务探索LLM如何查看和总结所有当前事件事实：

这个提示的局限性：

- 总结太长，尤其是对于试图了解事件风险和影响的高管而言 

- 一些重要事实没有涉及，例如事件的影响及其缓解

- 写作风格不一致，不遵循我们的最佳实践，例如"被动语态"、"时态"、"术语"或"格式" 

- 一些无关的事件数据被整合到电子邮件摘要中 

- 模型难以理解哪些信息是最相关和最新的

对于第 2 版，我们尝试了一个更详细的提示来解决上述问题：我们告诉模型要简洁，并解释了一个写得好的摘要应该是什么样的：

You are an Incident Security Engineer working at Google. You are used to writing incident summaries in a concise,non-offensive, understandable way. The summary must tell what happened, what was the impact of the incident andwhat actions were taken to mitigate it so that anyone reading it understands the events that occurred withoutany need for follow-up questions. Today you receive thefull report of a security incident and are tasked withsummarizing it.  Data        <Security Incident>{incident}</Security Incident>Task        Now summarize the previous security incident.

关于主要事件响应步骤（协调和解决方案）。

这个提示的局限性：

- 总结仍然不总是简洁而准确地以我们期望的格式解决事件

- 有时，模型忽略了任务或没有考虑所有指南 

- 模型仍然难以坚持最新更新

- 我们注意到倾向于对一些次要的幻觉做出假设性的结论

对于最终提示，我们插入了 2 个人工制作的摘要示例，并引入了一个 <Good Summary> 标签来突出高质量的摘要，但也告诉模型立即开始总结，而不是首先重复手头的任务（就像LLM通常做的那样）。

You are an Incident Security Engineer working at Google.You are used to writing incident summaries in a concise,non-offensive, understandable way. A <Good Summary> tells what happened, what was the impactof the incident and what actions were taken to mitigateit so that anyone reading it understands the events thatoccurred without any need for follow-up questions.Here are two unrelated <Good Summary> examples that got you promoted for their quality:<Good Summary>{summary_1}</Good Summary><Good Summary>{summary_2}</Good Summary>Today you receive the full report of a security incidentand are tasked with summarizing it.<Security Incident>{incident}</Security Incident><Good Summary>

这产生了出色的摘要，符合我们想要的结构，涵盖了所有关键点，几乎没有任何幻觉。

8.工作流程整合

在将提示集成到我们的工作流程中时，我们希望确保它是在补充我们团队的工作，而不是单独撰写通信。我们以这样的方式设计工具：UI有一个"生成摘要"按钮，它会使用LLM提出的摘要预先填充文本字段。然后，人类用户可以接受摘要并将其添加到事件中，对摘要进行手动更改并接受它，或者放弃草稿并重新开始。

我们新构建的工具产生了写得很好且准确的摘要，由LLM起草每个事件摘要可节省51%的时间，而非人工撰写。

使用LLM生成的摘要节省时间（样本大小：300）

我们看到的唯一极端情况是当输入大小相对于提示大小较小时出现的幻觉。在这些情况下，LLM编写了大部分摘要，关键点是不正确的。我们以编程方式解决了这个问题：如果输入大小小于200个令牌，我们不会调用LLM来生成摘要，而是让人类来写。

9.演进到更复杂的用例：高管更新

除了常规的事件总结之外，他们还在探索将生成式AI应用到更复杂的场景，比如撰写面向高管的事件更新报告。

在事件响应过程中，常常需要定期向公司高层管理人员通报事件进展、影响评估和应对措施。这类"高管更新"通常要求信息更加高度提炼和凝练，突出战略层面的考量，用商业语言表述技术问题，以便领导层快速做出决策。

将AI运用到撰写高管更新报告，可以提高信息梳理和呈现的效率，节省事件响应经理的时间。当然，由于高管更新事关公司决策，对信息的准确性和可靠性要求极高，因此AI生成的报告仍然需要经过人工复核和审查。

鉴于这些结果，我们探索了其他方法来应用和建立总结成功，并将其应用于更复杂的沟通。我们改进了最初的摘要提示，并进行了一项实验，代表事件响应负责人（IC）起草高管沟通。这个实验的目标是确保高管和利益相关者能够快速了解事件事实，并允许IC传达有关事件的重要信息。这些沟通很复杂，因为它们不仅仅是摘要——它们包括不同的部分（例如摘要、根本原因、影响和缓解），遵循特定的结构和格式，并遵守写作最佳实践（例如中性语气、主动语态而不是被动语态、最小化首字母缩略词）。

这项实验表明，生成式AI可以超越高级总结，帮助起草复杂的沟通。此外，LLM生成的草稿将IC花在撰写高管摘要上的时间减少了53%，同时在事实准确性和遵守写作最佳实践方面提供了至少相当的内容质量。

10.未来计划

我们一直在探索使用生成式AI更有效地保护我们用户的新方法，并期待在网络防御者中发挥其潜力。例如，我们正在探索使用生成式人工智能作为雄心勃勃的内存安全项目的推动者，比如教LLM将C++代码重写为内存安全的Rust，以及对日常安全工作流程进行更多渐进式改进，例如让生成式人工智能阅读设计文档并根据其内容提出安全建议。

参考资料：

https://security.googleblog.com/2024/04/accelerating-incident-response-using.html

原文始发于微信公众号（天御攻防实验室）：Google如何利用生成式AI加速事件响应流程