欢迎观看 FS-ISAC 的播客节目《FinCyber Today》。我是 FS-ISAC 首席企业事务官 Elizabeth Heathfield。随着生成式 AI 从酷炫的创新方法转变为经济刚需，企业和团队不仅需要了解 AI，更需要学会像 AI 一样思考。Akamai 副总裁兼首席技术官 Patrick Sullivan 兴致勃勃地与我深聊了一番，探讨了安全团队该如何学会驾驭 AI 工具的非确定性特质。非常感谢您能来做客，真的非常感谢。能跟您聊这个话题我真的超级兴奋，因为我知道咱们都是 AI 极客。我们先来聊聊如何管控非确定性风险吧。咱们先来理清基本概念，把基础打好。什么是生成式 AI 模型中的非确定性? 这个问题问得很好，是的,我认为先做好背景铺垫非常重要。你知道,我认为当我们去看那些令人如此兴奋的生成式 AI 模型时，从本质上讲,它们真正做的就是大量复杂的矩阵乘法，然后尝试用最高概率的结果来预测下一个词。根据模型的配置,它可能会输出概率最高的结果，或者你也选择对概率较低的方案进行采样。但这背后的含义,以及我们为什么称它具有非确定性，就在于如果你现在给定一组输入来运行这个模型，即便模型本身是完全静态的，系统也没有发生变化，下一次再运行时，你仍然会得到一组不同的结果,对吧? 接着你再运行一次，得到的又是另一组结果。从某种程度上来说,这和我们以往运行的很多系统有所不同。所以,人们需要转变思维方式才能真正理解这一点。例如,在进行安全测试时，如果存在某种会触发注入攻击的潜伏式载荷，哪怕它某一次没有被引爆，也并不意味着你可以确信系统不存在漏洞，因为下一次你用完全相同的载荷再次去测试同一个应用时，它就有可能被引爆，最终导致糟糕的后果。所以,我认为人们确实需要转变思维去理解这一点。而且我发现，仅仅在理论上明白这一点远远不够，你得亲眼看看它是怎么发生的。你必须亲自动手实操，眼睛盯着屏幕,亲眼见证这个现象。一个载荷原本处于潜伏状态，然后当你在完全相同的条件下再次执行时，你看到它突然触发并产生了影响。只有这样,你才会真正明白背后的真正含义,以及它对安全领域产生的影响。
大家应该如何思考并真正理解这件事? 尤其是在企业层面上来说,对吧? 我认为人们需要明白一点,我们讨论的并不仅仅是聊天机器人，而是更复杂的工作流、智能体工作流等等。当然,我认为,好消息是,在各成员企业的安全团队中,一定有一些积极进取的骨干人才，他们正在充分利用现有的丰富培训资源来提升自我，他们在这方面遥遥领先。所以我认为,负责人需要关注的其实是基准线，如何提升基准线，并确保在更广泛的安全合规企业中，每个人都能真正实现这种认知觉醒,对吧? 这涵盖了从审计、红队到应用安全团队的所有人员。有些人可能会对基准线训练感到厌倦，但我认为,设定一个明确的基准线非常重要。你可以举办研讨会来实现这种转变，比如 AI 主题研讨会或者 AI 黑客马拉松。在这样的活动中,能够让大家亲自动手实操并直观地感受到这种现象。我认为,眼见为实非常重要。接下来就是审计环节,当你在思考"获得安全保障到底意味着什么"时,就会有人去执行审计。仅仅因为某次测试通过，如果从更宏观的角度去看,你怎么看待这个问题? 下一次在同一个静态系统上测试时,会不会测试不通过? -没错 -你需要让所有人都参与进来。明白。好的,我们已经做好了背景铺垫。接下来,我们言归正传，聊一聊您目前在金融行业里都看到了哪些利用 AI 的机会。尤其是,生成式 AI 的这种新特性带来了哪些机会? 问得好。我认为大家都注意到了，不同的企业在业务中采用 AI 技术的步伐是各不相同的,对吧? 有些负责人明确表态,"我们是成熟的企业，但不会把 AI 带来的机会拱手让给那些规模更小的初创公司或金融科技企业，我们将积极把握这些机会。"企业展现出这种风险偏好令人欣慰，不过在这个过程中，我们也发现,在企业着手布局的过程中,他们最先部署的一些 AI 工具往往是开发协作助手这类产品,对吧? 所以我认为,随着开发人员生产力的提升，我们已经开始看到一些成效了。上周我读到一份来自我们合作伙伴 Apiiro 的最新研究报告，其中提到,在开发生成式 AI 协作助手时，随着你提交的 PR 增加，软件的更新次数可能会提升四倍，随后,所有各类 AST 工具触发的告警数量平均可能增加了 10 倍，虽然其中有很多是重复的，但总体来看,速度确实加快了，这对企业来说是件好事。但如果安全团队，尤其是应用安全团队，找不到实现自动化的方法，势必无法跟不上业务的发展节奏。所以这是一个机会。我觉得另一个机会，可能在于覆盖面,对吧? 我们的各种优秀工具不断触发告警，数量多得惊人，而且,如果你仔细翻阅泄露事件报告，通常会发现，确实发生过一次严重事故，而且,这并不是说完全没有工具触发告警，通常情况是,这边触发了告警，那边也触发了告警，但这些告警往往没有达到人类分析师介入的阈值。所以,如果我们能够扩大监控覆盖面，比如借助 AI 系统来自动处理掉其中部分告警，从而降低需要深入排查的门槛。-没错。这对我们来说也是一个机会。
好了,我们刚才讨论了机会，现在,让我们把目光转向风险吧。在您看来,随着企业开始落地生成式 AI，他们正面临哪些风险? 在风险管理方面，他们是否也需要以一种不同于以往的思维方式来应对? 这样做会带来哪些风险? 当然。我认为首先第一点，拿应用安全领域来说，我们已经花了...就我个人而言，已经花了大约二十年的时间来处理应用安全风险。在应用安全问题发生问题时，我们观察到的核心反模式之一是将代码或指令与数据混为一谈,对吧? 你希望数据放在这里，指令放在那里，SQL 指令则应该放在数据库中。这是一系列问题。如果操作系统指令被解析执行，将会带来一系列不同的风险。我们观察到的一种情况是，人们在使用这些生成式 AI 应用程序时，会把指令和数据混在一起，丢进搅拌机里。-没错 -像做鸡尾酒一样。这样做是有问题的。所以我认为,在这个问题上,我们应当关注三大危险,对吧? 也就是,如果您有外部数据，无论是传入的查询还是进入系统的训练数据，第二个,通过 RAG 或某一类型系统获取的内部数据,该系统会访问机密数据，而我们目前对如何保护这些机密数据以及谁能访问它们,有着很多规定。第三个危险是通信渠道，API...你知道的,直接访问算是最糟糕的情况，还包括访问电子邮件、软件控制模块、公开的代码仓库,或者 Slack 之类的工具。当你把这三者汇聚在一起，形成所谓的三大危险时，很可能意味着你正面临一定的风险,对吧? 你需要采取一些非常强有力的措施来应对这些风险。所以,只要你能想办法把风险因素控制在这三项里的两项以内，你的防御胜算通常就会大得多，这绝对好过这三大要素同时齐聚。具体来说,我指的是那些企业正在使用的、基于前沿模型构建的工具，就像是,所有的碰撞与融合都在那里发生的吧? -是的,可以这么理解。所以我认为,前沿模型可以为我们提供这些外部数据，从一开始-你就会接触到各种各样的外部数据-没错。而这些数据可能会被攻击者操纵,对吧? 如果他们掌握了其中的一些信息，就可以用自己生成的输入来触发它。当你把这些数据和其他信息混合在一起，你就会发现自己陷入了困境。所以,这显然就是我们目前面临的风险之一。
当面临看似合理、实则不合理的风险时，您会如何应对? 如何掌控这种情况? 因为,你知道,过去我们的处境更像是"非此即彼"，"非黑即白"的模式。而现在,我们所处的情况是...我的意思是,模型给出了某个结果，看起来一切正常,也基本说得通。我们是否应该使用不止一个模型? 又该如何弄清楚"好吧,我们如何验证这个结果是正确的?" 是的,这确实是个难题，因为我觉得这些系统通常是正确的，有时也会出错，但总是一副自信满满的样子。我认为有多种不同的方法。一种方法是,让一个模型监督另一个模型，查看以往请求的各种变体。其他系统则取决于其重要性，我确实看到一些企业会说,"我们目前不具备完全去人工化的条件,必须设置人工安全防线。" 公平地说,在安全领域,我们常说人是最薄弱的环节，所以有点讽刺的是,我们又回到了最原始的做法上。这些都是一些补偿性控制措施，但这一点我们确实需要牢记，因为在现阶段的技术成熟度下，我们会看到一些看起来非常自信、实则错得离谱的回答。我想从这个角度谈一谈，我们如何界定什么是失败? 当然,有评估机制，整个行业都在尝试设计，基本上就是让 AI 检查 AI。我还见识过"人工把关"的模式，但实际上,这可能会让人类花费更多的时间去核实结果，还不如当初直接进行人工检查-而不引入这种全新-是的，又昂贵的系统。有多种方法可以用来评估和检验，无论是自动化、人工检查,还是其他情况。但我们也面临很多监管要求。您觉得,在我们搞清楚这一切的过程中，我们应当如何去满足现有的通用 GRC 要求以及其他类似要求? 毕竟,这不是一朝一夕能完成的...需要花费一些时间。你也知道,这个领域的创新速度其他方面存在着巨大的脱节，它的更新换代之快，或者说技术"半衰期"之短，绝对是我职业生涯中前所未见的。相比之下,我们都心知肚明，监管机构的运转节奏要慢得多。所以,我们肯定得体谅那些在 GRC 领域里努力应对这种速度差异的朋友们。但与此同时，许多非常严格的法规都是基于基本原则制定的，而其中的许多做法也将延续到这个领域中。这里的关键问题是:你是否拥有关于这些技术部署情况的完整资产清单?
我们讨论了确定性与非确定性。当然,需要指出的是，如果你了解某个模型，并能够对系统进行管理控制，那么你就可以操纵这个模型。你可以对这些系统进行配置，将温度设置为零，或者强制让其输出具有确定性。在这方面,安全和合规团队对企业施加一定的压力,可能会起到帮助作用。毕竟有些系统可能并不需要非确定性,对吧? 比如所谓枯燥的应用，法律、会计或类似领域，就不需要天马行空的创造力。你可能希望某智能体具备一定的可预测性。而在其他一些方面,人们可能会认为需要对那些不太可能出现的结果进行更广泛的采样，以便让系统生成人类眼中的-创造性结果-没错。但我认为需要提出一些尖锐的问题，在一个系统中,是否真的需要那种高度的非确定性行为，这一点应当受到质疑，并且需要给出理由。是的,所以您希望尽可能让系统具有确定性。我还听说,有人会把一项任务拆解开来...这其实智能体工作流和子智能体工作流的一部分...子智能体只负责完成特定任务，这样一来,你就能清晰地追踪问题出在哪里。然而,如果只有一种工作流，所有人都要执行大量步骤，那就很难看出问题出在哪里了。所以,如果能够把工作流拆解成最小、最基础的组成部分，即便整个过程仍然是自动化的，也能让其更具确定性。非常同意,我认为这是另一个非常好的例子。而在这一点上,再次强调的是来自安全与合规团队的审查，往往能够带来更好的结果。这就像是一种职责划分。-没错-你可以把某些事情套到这个原理中。我们的优势在于，我们拥有非常坚实的第一性原理作为基础，这为我们开展工作提供了有利支撑。因此,在某些情况下，对这些系统一视同仁，进行一些传统的审查，可能会对我们有所帮助。但另一方面,攻击者正是在利用这种非确定性来采取非常随机的行动,比如...他们会到处试探，希望出现某种我们未曾预料的创新性结果。所以,我们不想看到这样一种情况...如果我们过于追求确定性，以至于限制了系统的能力，那么我们可能就会将优势让给了攻击者。您是否同意这种观点? 是的,我认为...如果我们展望未来的话...我再以应用安全示例进行说明。你知道,我们一直以来都是为人类构建 API 和应用程序-让人类能够以某种方式使用它们-没错，通过搜索功能来进行引导。在未来,我们开发 API 和 Web 应用程序，可能是为了给智能体或聊天机器人提供数据，对吧? 如果人们需要做出决策，比如在特定条件下选择最适合自己的金融机构，他们可能会借助智能体或聊天机器人来完成这一决策。而我们为这些用于辅助训练的机器人提供服务的方式，以及我们对这些智能体作出响应的方式，可能需要采用不同的处理，以针对该场景进行优化，而不是沿用我们目前面向普通网站访客的做法。所以,这是一种理想的情况，在这项技术背后确实存在一个真正的客户。显然,这样一来就会出现模仿者，以及利用这些工具从事不法活动的人。我们需要应对的将是更多的自动化操作，更多的爬虫程序访问我们的网站，以及处理委托身份认证等问题。如果我是自己身份的合法所有者，但又希望由智能体来替我办事，这种情况我们已经开始看到，不过目前仍处于非常早期的阶段。这将给 IAM 团队以及授权团队带来不小的挑战。在这方面还有很多工作要做。是的,这也是我们之前在小组讨论中提到过的内容。此外,我们还面临着一个全新的层面，即第三方及供应链风险,或者说是第 n 方风险。因为一旦变成智能体和智能体之间在交流...比如我们的供应商，让他们的智能体互相对话，那我们几乎无法了解其中到底发生了什么。它们就像是一层层嵌套的黑匣子，层层叠叠,都是黑匣子。那么,我们应该如何看待这个问题? 我们本来就面临着管理供应链风险的难题，而现在又增加了一层，使我们更难了解其中的情况。所以,我们应该如何看待这个问题? 是的,我认为我们面临的首要挑战在于,在客户端层面，如果用户正在使用智能体，我们需要准确识别这种情况，并进行恰当的处理。还要确认这确实是我们希望授权的委托身份，这是我们的第一步。然后,在我们的后台系统中，可能会使用第三方，而他们又会进一步调用第 n 方。我认为这就是我们管理供应链风险的方式。而且我认为,其中一家成员公司在今年年初就已经这样做了，也就是 Pat Opet 向 SaaS 提供商发出的那封公开信，指出了当前生态系统中存在的某些缺陷。而且我认为,解决方案的一部分可能就在于 SaaS 提供商更清晰地展示下游发生的事情。我们已经看到对手在这么做了，确实挺有先见之明。
我们已经对 LLM 进行了大量讨论，这在很大程度上代表了大家对于生成式 AI 的普遍看法。但同时,您也听到了很多关于小语言模型潜在能力的讨论，尤其是在你有非常具体的应用场景时，或许并不需要广阔的海洋，一片湖泊就能够以满足需求。这是否可以作为应对某些非确定性风险的一种潜在方法? 我认为是这样的，我觉得这是安全团队对企业施加压力的另一个方面，他们会提出一些尖锐的问题:"你们真的需要完整的 LLM，并能承受随之而来的所有风险吗?" 针对 LLM 进行威胁建模，简直太疯狂了,对吧? 因为你现在必须考虑:"我能不能问一个财务应用程序如何制造大规模杀伤性武器 (WMD)?"对吧? 根据你训练模型所用的数据，这可能真会成为威胁模型的一部分。-没错-当安全团队对企业提出质疑时...我们讨论过:"你们真的需要采用非确定性模型吗? 还是在这种情景下确定性模型就已经足够?" 这一切其实都属于配置控制的范畴。同样地,我认为有必要进行一些审查:"在这个应用场景中,你真的需要 LLM 吗? 还是 SLM 就已经足够?" 这或许是另一个可以证明安全团队能够引导企业为所有人带来更好结果的例子。这是一个我看到越来越多企业都在思考的问题，而且我认为,这是一种积极变化。
是的,说到模型，我们刚才稍微谈到了温度，还有对上下文的控制,对吧? 你不能让上下文无限延续下去，因为那样显然会降低输出的质量。而且,输出越多，所需的投入就越大，而投入越多，成本也就越高。所以,如果能稍微加以限制就好了。当然,我们也有提示信息，也许可以通过某些方法让这些提示更加可预测。肯定有办法,对吧? 我们有提示模板,也有提示库。如果能够提高提示的可预测性，那么至少系统接收的输入数据会更加规范、受控。所以,你或许也能在这些不同方面控制一些非确定性,对吧? 我觉得,我看到的一个问题是，我们需要让人们知道有这么多不同的方面，这样他们才能明白这些工具的用途，而不只有一个方面。您怎么看? 完全同意。回顾历史我们会发现，从安全角度来看，每次新趋势兴起时，问题也随之而来。当我们开始涉足电子商务时，曾爆发过一波 SQL 注入攻击，简直就是...整个数据库的数据都顺着 Web 应用程序倾泻而出。我们从中吸取了教训,并学会了如何更好地检查传入应用程序的数据。当我们进入云计算时代后，类似的问题再次出现。我希望，在我们拥抱这一趋势时，能否从当年那些将敏感数据接入后端的 Web 应用程序中汲取经验教训? 或者从云计算中学到一些经验教训? 我们能否借鉴之前的经验，而不必等到某个企业真的遭受重创,大家再从中吸取教训? 希望如此。我们可以在真正严重的泄露发生前，降低一些风险。
好的,我们已经讨论了很多。如果希望观众能够从今天的对话中获得一个核心观点，您希望那是什么? 我觉得这里有很多有趣的观点，但我会说,关键是确保信息安全团队理解基本概念。我们之前说过，要为 AI 训练设定一个基准线，最好通过实际操作,让大家在研讨会或黑客马拉松中进行探索。因为我认为,我们有许多基本原则，理解这些原则后,就能看到它们之间的联系,也知道如何运用。所以,大概就是这样。
