Alex Stamos谈AI网络安全:攻击加速,防御如何跟上
在这期约61分钟的Decoder访谈中,Cognition首席安全官Alex Stamos讨论了AI如何改变攻击技能的分布、攻防成本、企业决策速度与遗留代码治理。他主张用分层调查控制防御成本,以确定性规则约束代理权限,并在构建、行为规格和测试充分的前提下,重新评估修补与重写的取舍。
一、嘉宾背景
这期约61分钟的Decoder访谈由Nilay Patel主持,嘉宾是Cognition首席安全官Alex Stamos。他同时担任斯坦福大学网络政策中心讲师,长期从事网络安全工作。访谈围绕一个具体问题展开:当AI开始改变漏洞研究、攻击执行和防御响应,企业原有的安全体系能否跟上。他的企业安全职责、工具使用经验与教学工作,也让讨论始终贴近组织如何应对风险。
Stamos以自己参与早期安全社区的经历作为参照。他回忆参加早期Defcon,以及后来受企业聘用、测试其系统安全的工作。将稀缺的攻击技能用于受雇防御,是他亲历的行业发展路径;披露、测试和安全服务也逐渐形成相应的制度安排。在他看来,AI正在改变支撑这些安排的经济条件。
他的判断也带有业务参与者的视角。据Stamos介绍,Cognition会使用自身工具帮助遭受攻击的企业修复漏洞,但并不是事件响应公司。访谈中的客户观察与修复方案,来自一位参与相关工作的安全负责人,不能视为覆盖整个行业的独立效果评估。他既在讨论技术变化,也在介绍自身团队正在建设的能力。
二、本期主要内容
传统攻击通常将研究与执行分开:先研究软件、发现漏洞、编写利用程序,再由操作人员将其部署到目标。Stamos认为,AI正在让这些步骤围绕具体目标实时衔接,系统可以在探查过程中生成利用代码,并继续尝试入侵。改变的不只是发现漏洞的速度,从发现弱点到影响业务的间隔也在缩短。
供应链会将这种影响传递给更多组织。依据当时掌握的信息,Stamos描述了一条攻击链:Fireworks泄露的API密钥被用于进入Cursor,攻击者随后通过恶意插件,使约5,000家公司面临潜在入侵风险。这是潜在受影响的数量,节目并未独立确认这些公司全部遭到入侵。一个服务商的凭据,可能成为进入另一个平台、继而接触更多组织的通道。
Stamos回忆的另一宗攻击,直接影响了日常医疗服务。一家医疗及牙科用品分销商遭勒索攻击后,诊所因缺少手套和物资而取消预约。他用约1名安全人员、10至12名IT人员面对约20人攻击团队的配置,说明中型供应商面临的组织不对称。这不是全行业的统一人员比例,但反映了他所担忧的问题:企业需要保护的业务和承担的责任,可能远超其专门防御力量所能覆盖的范围。
防御工作的缺口也不限于代码。Stamos称,软件安全约占自己CSO工作的25%,其余约75%的职责并未获得同等程度的AI改善。他希望更多投入用于日志调查、事件判断与响应,包括如何在处理攻击时避免让公司整体停摆。这些比例来自他的岗位经验,不能直接套用于所有安全团队。他将当前阶段比作安全的“黑暗时代”,但并不认为度过这一阶段后就能永久安全:未来仍会发生入侵,许多攻击甚至不需要软件漏洞。
模型提供方应承担什么责任,也是访谈的议题。Stamos支持追究实验室自有代理环境直接攻击外部系统的责任,同时认为,恶意用户调用不同来源模型实施攻击,是另一类问题。攻防用途难以清楚区分,过严的拒绝机制可能在防御者需要帮助时切断服务。他愿意放慢前沿模型的推进,让廉价防御模型有机会追赶;相较之下,他更关注人类借助AI伤害他人的能力增强。他也批评将AI塑造成朋友和拟真人陪伴者的产品方向,认为模型约束之外,产品如何影响使用者同样需要审视。
三、核心观点:推理、例子与边界
Stamos认为,AI正在同时削弱攻击能力的两重限制。过去,顶尖漏洞研究者数量有限,实际攻击又需要较大的操作团队;研究能力和执行人数共同约束着攻击规模。AI既让更多人获得部分高阶技能,也让更少的人完成更多操作。因此,变化不只在于工具能力提高:即使某项技术早已存在,掌握它的人增加、使用它所需的人减少,也可能加重企业的防御压力。不过,他借助桌面Mac逆向Microsoft补丁、编写稳定利用代码的流程尚未完全自动化,操作者仍需具备技能。这种能力扩散还不意味着任何人都能完成从发现漏洞到入侵的全过程。
防御要跟上,首先得承担得起持续运行的成本。面对TB或PB级日志,Stamos主张先用传统分类器筛选,再由小模型调查,复杂问题逐级交给大模型。海量输入并不都需要昂贵的推理,处理方式应随任务难度调整。他转述同行的说法称,某安全平台调用前沿网络安全模型完成一次调查约需900美元;Cognition则正在重训开放权重模型,以降低成本。900美元并非统一报价,也不足以推断所有自建攻击基础设施都接近零成本。对防御系统而言,更实际的问题是:面对持续、高频的事件,企业能否长期负担所需的调查量。模型效能必须与成本一起衡量。
Stamos也反对用“蜂群”笼统描述AI攻击。对于OpenAI相关的多代理事件,他估算涉及约700至1400个代理、数亿美元级硬件,并对Hugging Face攻击粗算出约百万美元的用电成本;但他判断,访谈中称为Artex等名称的攻击工具可能只需要一两个代理。转录中的工具名称并不一致,这些成本也只是他的粗略推算,并非核验过的账单。不同任务和架构之间的差别,比代理数量本身更值得关注。一次昂贵、低效的多代理事件,不能代表普通攻击的成本,也不能据此认定防御必须部署同等规模的代理体系。
企业还面临另一种成本:决策所需的时间。Patel指出,预防在损益表上被记作开支,事故后的恢复却更容易通过重新获得业务能力来证明价值。Stamos用一个假设场景说明这种差距:19岁攻击者可以在游戏电脑上运行工具、购买token,银行却可能花30天谈合同,并要求供应商提供1亿美元保险。这并非某起银行事故的调查记录,而是他对组织行动速度的比较。如果风险管理只着眼于避免测试造成的损失,真实攻击带来的风险便可能继续存在。
遗留软件进一步增加了防御难度。根据客户观察,Stamos认为,当扫描结果列出约10,000个漏洞时,重写可能比逐一修补更便宜,但前提是已有可工作的构建、充分的测试,以及对既有行为的规格描述。漏洞数量可以促使企业比较两种方案,却不足以单独支持重写。他还以模型升级后Linux内核继续出现大量漏洞和补丁为例,认为新模型可能不断揭示新的漏洞池,而不是逐步清空一个固定集合。这是他对趋势的解释,尚不能证明漏洞永远无法耗尽,也没有形成适用于所有代码库的量化比较方法。
他提出的内核重建倡议,将这一取舍延伸到共享基础设施。Stamos希望Google与Amazon探索使用Rust等安全语言,重建面向生产服务器硬件的内核,舍弃不需要的旧驱动,同时保持glibc及上层软件的ABI兼容。约1亿至可能10亿美元是他的倡议性估算,尚非可执行的项目预算。缩小硬件支持范围,也意味着必须明确保留哪些兼容性。他提出用函数契约描述预期行为,但明确区分了这种方法与完整形式化验证,并承认验证技术超出了自己最熟悉的专业范围。安全语言、函数契约与内核重建都不能被视为绝对安全的保证。
这些主张源于他对补丁部署速度的担忧:漏洞利用越来越快,企业拿到补丁后再逐步部署的节奏可能已经跟不上。他认为,访谈中提到的PHP漏洞因难以在野利用而没有酿成更大灾难,带有侥幸成分。这个例子说明了主动降低风险的紧迫性,也仍然要求企业修补眼前的漏洞,同时评估哪些长期负担值得通过重构减轻。
四、学习与应用
Stamos建议企业在未来90天内开展AI红队自测。这是一项强调紧迫性的建议,并非通用安全标准;他所说的“不自测就会被入侵”,也是预测。他承认,测试工具可能误操作、造成停机,供应商的口头保证也可能与合同中的免责条款脱节。企业要落实这项建议,需要在采购前明确测试范围、可接受的业务影响、暂停条件和事故联系人,并由业务负责人比较测试中断与真实攻击的后果。加快审批仍须处理合同责任与生产环境风险。
代理参与防御,还需要可执行的权限限制。Stamos介绍,团队正在Devin上构建SOC能力,连接日志、EDR和云环境。代理可以停用Okta账户,但受到确定性的数量上限约束,触限后告警,超限操作须经人工批准。这为企业选择代理任务提供了一个参照:先界定操作对象和影响范围,再明确停止条件与接手责任。模型可能判断错误,硬性限制可以控制一次错误造成的损害;但限制也可能中断持续响应,因此触限后的告警必须有人及时处理,人工批准不能成为无人接管的队列。
自动修复同样需要逐环节审查。Stamos称,他协助的一个项目接入了全部代码仓库,使用Mythos等模型发现并修复数千个漏洞、编写验证测试,并自动合并PR。他判断,多年的人工工作因此缩短到了数天,但访谈没有提供独立评估。企业采用这类流程时,需要分别核查漏洞发现是否准确、修复是否保留既有行为、测试是否真正检验缺陷,以及哪些改动可以自动合并。生成测试并不能直接证明修复正确,项目参与者对速度的判断,也不能替代本企业代码和业务条件下的验证。
内容真实性则涉及另一组技术取舍。谈到Instagram时,Stamos根据在Facebook的工作经历指出,投入意愿会影响技术难题如何被处理。他建议结合内容检测、限制对检测接口的探测、延迟执行,以及相机直接采集。随后,他与Patel区分了概率性的虚假检测和密码学来源验证:检测是在判断内容是否可能伪造,短文本尤其缺少可靠信号;来源验证则依赖可信传感器与完整保管链,确认素材经过的采集和处理流程。产品团队可以据此设计受控的采集与编辑路径,但这也会限制导入和编辑自由。来源证明只能支持保管链覆盖的主张,无法单独证明画面中事件的含义、上下文或叙事真实。双方也将真实性问题联系到钓鱼和AI语音诈骗;对于可疑付款或身份请求,来源证明仍不能代替核实。
如何判断安全状况是否改善,不能只看补丁总数。Stamos建议综合追踪重大入侵、可蠕虫传播的基础设施CVE,以及Linux内核、OpenSSL、glibc等组件的漏洞,建立安全趋势指数。他在访谈中口述,Patch Tuesday的补丁规模从约150至200项增至最近900多项,并希望模型发布前约30天出现的补丁潮能够逐轮缩小。Patel同意发布拟议追踪器,但节目没有展示已完成的指数。沿用这一思路观察趋势,还需要记录入侵后果、漏洞性质与发现时间:补丁增多可能意味着发现能力增强,补丁减少也未必意味着风险消失。指数需要保留这些解释,才能帮助判断安全状况,而不是留下一个脱离背景的分数。
来源
More from WayDigital
Continue through other published articles from the same publisher.
Comments
0 public responses
All visitors can read comments. Sign in to join the discussion.
Log in to comment