关键字: [reInforce, Amazon Bedrock, Incident Response Lifecycle, Generative Ai Workloads, Model Invocation Logging, Threat Actor Activities, Security Event Investigation]

本文字数: 1300, 阅读完需: 6 分钟

导读

亚马逊云科技(亚马逊云科技)客户事件响应团队的Anna Macovy和Steve Devarra在Amazon Web Services re:Inforce大会上发表了题为”检测和响应生成式AI工作负载中的威胁”的演讲。在演讲中,他们探讨了如何将事件响应方法应用于生成式AI工作负载;具体阐述了涉及AI/ML的两种类型安全事件(AI/ML应用程序作为源或目标),并概述了一个包含组件(组织、计算基础设施、AI/ML应用程序、私有数据、用户)和元素(访问、计算变更、AI变更、数据存储变更、调用、私有数据、代理)的模型,用于调查此类事件。该演讲重点介绍了如何利用亚马逊云科技服务(如Amazon Bedrock)来检测和响应生成式AI工作负载中的威胁,强调了模型调用日志记录的重要性,并为客户提供了关键的总结建议。

演讲精华

以下是小编为您整理的本次演讲的精华，共1000字，阅读时间大约是5分钟。

安娜·马科维和史蒂夫·德瓦拉是亚马逊云科技客户事件响应团队的成员,他们在亚马逊云科技re:Inforce活动上做了一场题为”检测和响应生成式AI工作负载中的威胁”的演讲。此次演讲旨在向与会者介绍该团队如何将事件响应流程应用于生成式AI工作负载和应用程序。

首先,史蒂夫承认生成式AI是一个相对较新的主题,在深入探讨具体内容之前,有必要先奠定基础。他将生成式AI安全性分为三个领域:1)生成式AI应用程序的安全性;2)将生成式AI用于安全目的;3)来自生成式AI威胁的安全性。本次演讲的重点是第一个领域,假设一个生成式AI应用程序(如聊天机器人)已被入侵,该团队正在调查此事件。

接下来,史蒂夫概述了与生成式AI相关的亚马逊云科技服务。Amazon Q系列,包括Amazon Q Developer,利用大型语言模型(LLM),提供与这些模型交互的托管服务。Amazon Bedrock则是一款为开发人员构建LLM而设计的工具,允许他们发出API调用并更直接地与模型交互。最后,亚马逊云科技还提供了基础模型训练的基础设施,使客户能够开发自己的基础模型,尽管这种情况不太常见。

在安全责任方面,史蒂夫解释说,共享责任模式也适用于生成式AI工作负载。对于Amazon Bedrock,客户负责提供的提示、网络流量保护和防火墙配置。而对于像Amazon Q这样的托管服务,亚马逊云科技则承担更多的安全责任,类似于Amazon S3等服务。

史蒂夫首先介绍了事件响应生命周期,包括准备、检测和分析、遏制、根除和恢复以及事后活动。他强调,这个周期仍然适用于生成式人工智能工作负载,团队将讨论人工智能和机器学习如何应用于每个阶段。

接下来,史蒂夫概述了涉及人工智能/机器学习的两种安全事件类型:1)人工智能/机器学习应用程序或工作负载是安全事件的源头;2)人工智能/机器学习应用程序或工作负载是安全事件的目标。然后,他介绍了一个由五个组成部分的模型:组织、计算基础设施、人工智能/机器学习应用程序、私有数据和用户。

史蒂夫深入探讨了该模型的七个要素:访问、计算变更、人工智能变更、数据存储变更、调用、私有数据和代理。每个要素代表组件在安全事件期间如何相互作用或被作用于。

为了说明这个模型的应用,史蒂夫通过一个示例事件,解释了一个威胁参与者如何通过从GitHub窃取凭证,未经授权访问了一个组织。他解释说,团队将通过检查CloudTrail日志中的事件,如”attach user policy”、“create access key”和”get session token”来调查访问要素。

对于计算变更,团队将查找”run instances”、“delete db instances”以及CloudTrail中的CloudFormation事件。关于人工智能变更,他们将检查与自定义模型创建、操作和防护措施变更相关的事件。数据存储变更将涉及监控知识库和代理修改。

史蒂夫强调了调用日志的重要性,它捕获了发送给人工智能/机器学习模型的提示和响应。威胁参与者可能试图删除此日志配置,因此团队将查找诸如”delete model invocation logging configuration”之类的事件。

私有数据访问将通过数据事件进行验证,例如S3中的”get object”和RDS中的”delete db instance”。最后,对于代理要素,团队将检查源自”amazonbedrock”或”sagemaker”的事件,以确定人工智能/机器学习应用程序是否代表用户调用了资源。

在通过示例事件的讲解后,Anna Macovy探讨了如何让客户将所学内容付诸实践。她重申,事件响应的基本原则依然适用,但客户应当投入时间学习其AI/ML工作负载,了解内部使用案例,以及敏感数据在这些工作负载中的使用方式。

Anna还介绍了一个新的日志源:Amazon Bedrock中的模型调用日志记录。这些日志捕获了AI/ML模型的输入数据(提示)和输出,为事件响应提供了宝贵的数据平面信息。客户可以启用将日志记录到S3、CloudWatch或两者,出于成本考虑,建议使用S3。

本次会议的重点包括:

1. 通过制定新的行动手册和提供关于生成式AI的培训,为事件做好准备。
2. 了解组织内部对AI/ML工作负载的使用案例,以及敏感数据在其中的使用方式。
3. 在调查期间利用Amazon Bedrock中的新日志源——模型调用日志记录,获取数据平面信息。
4. 确保最小特权访问,并监控IAM身份和凭证,因为这些对于亚马逊云科技的安全性仍然至关重要。

Anna和Steve强调,虽然生成式AI带来了新的考虑因素,但事件响应和安全最佳实践的基本原则依然适用。他们鼓励与会者学习所提供的资源,包括亚马逊云科技AI/ML工作负载事件响应指南。

总之,本次会议为检测和响应生成式AI工作负载中的威胁提供了一个全面的框架,强调了理解技术、制定行动手册以及利用新的日志记录功能的重要性,同时坚持既定的事件响应实践。

下面是一些演讲现场的精彩瞬间：

安娜·马科维和史蒂夫·德瓦拉介绍了亚马逊云科技客户事件响应团队,并探讨了如何检测和应对生成式AI工作负载中的威胁。

在涉及AI/ML的安全事件中,AI/ML应用程序或工作负载可能是安全事件的源头,亦或是安全事件的目标。

当安全事件发生时,客户需要自问是否仍能访问其计算环境,因为威胁行为者可能会锁定客户的账户,导致客户无法控制环境。

在CloudTrail中,他们发现了22个运行实例事件,这可能是威胁参与者想模仿泰勒·斯威夫特的歌曲”22”。

总结

在这个富有洞见的会议中,Anna Macovy和Steve Devarra深入探讨了在生成式AI工作负载中检测和响应威胁的复杂性。他们首先阐明了生成式AI安全性的基础,区分了确保AI应用程序的安全性、将AI用于安全目的以及解决来自AI本身的威胁。他们的主要重点是调查被入侵的生成式AI应用程序,例如聊天机器人。

两位演讲者概述了事件响应生命周期及其在AI/ML工作负载中的应用,强调了所涉及的组件和元素。他们提供了一个详细的事件示例,逐步介绍了调查未经授权访问、计算更改、AI模型操纵、数据存储篡改、调用日志记录、私有数据访问和代理操作的步骤。

重要的要点强调了培训的重要性、制定新的行动手册、了解新的日志源(如BEDROCK调用日志)以及利用现有的安全工具(如GUARDDUTY和CONFIG)。最小特权访问、事件响应规划和了解敏感数据使用等基本原则仍然至关重要。会议最后强调了从事件中学习、改进防御措施以及在不断发展的AI/ML领域保持警惕的必要性。