乐于分享
好东西不私藏

AI 攻击爆发元年:企业网络韧性自检清单(10 项)

AI 攻击爆发元年:企业网络韧性自检清单(10 项)

点亮上方星标 」更多干货内容,不再错过!

以下正文内容基于英文原文编译,可能存在语义偏差,请以原文为准。

以下为正文

AI 已经在改变网络风险的经济逻辑:攻击者正在扩大攻击规模,缩短从漏洞发现到漏洞利用的时间,并增加企业每天面对的威胁数量。补丁和修复周期也在加速,常常超过组织自身的变更承受能力,使企业暴露在网络攻击者的自动化发现和利用之下。

要在这场技术变革中保持业务韧性,组织必须具备紧迫感、纪律性,并严格执行基础安全实践。这需要企业明确选择:对软件和系统进行现代化改造、隔离控制,或逐步淘汰退出,从而 :
1)减少技术债规模,
2)把安全嵌入自动化软件开发和变更管理实践中。
这也有助于确保开发和技术团队选择最佳路径,从而确保安全。一个重视安全、能够培训和教育技术人员,并能快速建立适应能力的组织,是这一切的基础。在此基础上,以下是组织可以采取的一些关键行动,用于增强网络韧性。

一个全面的网络安全计划需要投入远超本文所述的专项精力。为了便于理解,以下是我们目前应该重点关注的几项最有价值的任务,旨在为漏洞被发现和利用的速度和数量不断提升的环境做好准备。实现这些目标始终是一个持续改进的过程,需要经历不同的成熟阶段。

1、运行最新软件版本:运行过时软件的遗留系统会带来重大风险,其中已停止维护软件中未修补的缺陷,是主要攻击入口之一。当软件版本落后多个大版本时,升级往往非常困难,也会拖慢组织应对新发现漏洞的速度。

  • 应把减少技术债作为当务之急,并由高层管理人员监督推进。考虑到未来新发现漏洞数量可能大幅增加,遗留系统和软件可能不再获得可用修复。

  • 在网络和计算硬件达到生命周期终点之前进行替换。跟踪生命周期结束时间,提前规划替换预算,并在退役过程中执行安全数据删除和合规处置。

  • 将所有不再受支持的操作系统或企业软件升级到受支持版本。

  • 将所有开源依赖升级到当前稳定版本,即经过社区验证的版本。确保更新经过社区验证,并且没有遭到恶意篡改或有针对性的软件供应链攻击,这一点非常重要。相反,旧版本软件包可能无法获得针对新发现漏洞的修复。

  • 通过受管理、可信任的制品仓库获取开源软件。使用工具评估开源软件中的漏洞。

2、用参考数据管理资产和软件组件:你无法修复自己不了解的东西。不完整或不准确的资产清单会留下盲区,而攻击者往往会比你更早发现这些盲区。

  • 维护一份覆盖整个企业的全面、持续更新的硬件、软件和云资产清单,包括影子技术和开发人员自行配置的资源。

  • 为应用组合中的每一个应用建立软件物料清单(SBOM),记录所有软件组件,包括开源组件。

  • 为资产记录补充所有者、业务关键性、互联网暴露情况和数据分类等信息,使漏洞管理和事件响应团队能够结合上下文确定优先级。

  • 将资产和软件组件数据整合到漏洞管理、变更管理和事件响应流程中,这样当新威胁出现时,你可以在几分钟内回答“我们在哪里暴露”,而不是几天后才知道。

  • 定期将资产清单与发现扫描结果进行核对,以识别并修复漂移、孤立资源和未受管理的终端。应将这些流程自动化。

3、建立并运行稳健的漏洞管理计划:快速发现并修复已知漏洞是基础工作,尤其是面向边界的软件和硬件资产,因为这类资产往往会被自动化、立即利用。

  • 现在就修复已知漏洞,并按关键程度排序,从面向互联网的系统开始,减少现有积压问题,并为不断加速的新漏洞披露释放处理能力。

  • 在补丁和更新进入生产环境之前进行测试,以尽量减少运营中断和故障。

  • 建立由 SLA 驱动的漏洞修复和补丁时间表,并按严重程度和暴露程度分层管理;对关键资产和面向互联网的资产设定最严格的目标。以最快速度修复面向互联网的关键漏洞。每当创造一个新的速度纪录,就继续打破它。

  • 持续扫描,而不是定期扫描。将漏洞扫描集成到软件开发流水线、云工作负载部署和变更管理流程中,使新的暴露面能够以与变更同样的速度被发现。如果你使用 AI 开发工具,也应使用它们扫描代码中的漏洞。最新的通用可用模型在发现和修复问题方面非常有效。

  • 将漏洞数据与资产关键性、应用上下文和可达性、威胁情报以及漏洞利用可用性关联起来,把精力集中在风险最高的地方,而不是盲目追逐数量。可以使用美国网络安全和基础设施安全局的已知被利用漏洞清单(CISA KEV)。

  • 在可能的情况下,使用边界控制措施,例如 Web 应用防火墙,来降低暴露并阻止攻击尝试,同时修复存在漏洞的软件。

  • 定期向高级管理层报告漏洞老化情况、修复速度和例外数量;将长期存在的例外视为风险接受事项,并要求高管承担责任。

4、压力测试事件响应和韧性计划:没有在真实条件下演练过的计划,在真正压力下会失效。韧性是在实践中证明的,而不是写在文档里的。

  • 开展桌面推演和实战模拟,场景应专门测试组织从破坏性攻击、勒索软件和供应链入侵中恢复的能力。

  • 通过对关键系统执行完整恢复测试,验证备份和恢复流程是否真正有效,将系统恢复到已知良好状态,并按照业务可承受范围衡量恢复时间。

  • 让高级业务领导层以及法务、沟通、公关和第三方利益相关方参与演练,使压力下的决策经过预演,而不是在真实事件中临场发挥。

  • 测试关于网络分段、故障转移和手动替代方案的假设。识别只有在模拟中断期间才会暴露的单点故障和依赖关系。

  • 每次演练后,都要严格跟踪并修复发现的问题。演练的价值在于弥合它暴露出的差距。

5、了解主要 SaaS 和外包依赖:关键业务流程越来越依赖第三方平台和服务。关键供应商遭到入侵或发生中断,就是你必须管理的事件,无论责任归属在哪里。

  • 识别并维护一份最新登记表,记录所有支持关键业务职能、数据处理或技术运营的 SaaS、云服务和外包服务提供商。

  • 在技术、风险和业务连续性团队之间共享这些依赖信息,使集中风险和级联故障场景变得可见且被理解。

  • 评估每个关键供应商的安全态势、事件响应能力和韧性计划;直接询问其补丁节奏、访问控制和泄露通知承诺。

  • 建立合同要求,明确及时安全通知、审计权条款和恢复目标,并验证这些承诺是否真正得到履行,而不仅仅停留在文档中。

  • 为最关键的依赖制定应急和退出计划;要清楚如果关键供应商长期不可用或遭到入侵,你将如何以降级状态继续运营。

6、优化变更管理以提升速度:为季度发布周期设计的补丁和部署流程,如今已经成为负担。从修复方案可用到修复方案部署之间,每延迟一天,就多一天不必要的暴露。

  • 梳理安全补丁从供应商发布到生产部署的端到端生命周期;识别每一个增加延迟的交接、审批关卡和测试队列。

  • 投资自动化测试、分阶段发布和回滚能力,使变更能够以更高信心和更快速度进入生产环境,减少对人工验证周期的依赖。

  • 为关键安全补丁建立紧急变更通道,在保留可审计性和安全性的同时,绕过非必要关卡。速度和控制并不互相排斥。

  • 将关键漏洞的平均修补时间作为关键运营指标进行衡量和报告;设定明确的改进目标,并让交付团队承担责任。

  • 将安全工具直接嵌入软件构建和交付流水线;漏洞分析、开源依赖扫描和安全配置检查应自动运行,使安全成为内建的质量门禁,而不是流程瓶颈。

7、严格过滤生产系统的出站流量:大多数生产系统没有合法理由访问开放互联网。限制出站流量可以有效抵御软件供应链攻击、命令与控制回连以及数据外泄。

  • 在可能的情况下,为生产环境实施基于允许清单的出站 Web 流量过滤;默认拒绝远比试图阻止已知恶意目的地有效得多。

  • 对于确实需要出站连接的系统,应将访问限制在特定、已批准的端点和协议上。生产环境中的广泛互联网访问应被视为例外,需要提供理由并获得高级审批。

  • 监控异常出站流量模式并发出告警,包括访问异常域名、出现意外数据量,以及连接到新注册的基础设施。

  • 应认识到,这一项控制措施本可以大幅降低 Log4Shell、SolarWinds 以及许多供应链入侵事件的影响;相对于投入工作量,它的投资回报极高。

  • 定期测试出站过滤规则,并将其纳入变更管理进行维护;过时或范围过宽的例外会随着时间推移削弱该控制措施的价值。

  • 将终端用户环境与生产系统分段隔离,终端用户环境可以拥有更宽松的互联网访问权限。

8、移除员工权限中的常驻特权:一台被攻陷的员工工作站,不应自动让攻击者获得生产系统凭据。常驻特权访问是攻击者从初始入侵推进到关键影响的最常见、最可靠路径之一。

  • 为所有生产维护和管理任务实施特权访问管理系统,使用托管凭据和/或即时权限分配。

  • 取消终端和服务器上的持久管理员账户。任何员工都不应在默认配置中始终拥有对敏感系统的访问权限。

  • 对所有特权访问要求多因素认证和会话录制,会话应有时间限制,自动过期,并要求重新授权。

  • 定期审计和认证权限,确保访问权限符合当前岗位和职责;积极清理孤立账户、累积权限和过度授权权限。

  • 将同样的管理纪律扩展到服务账户和机器身份。这些身份经常被忽视、权限过高,并且往往是攻击者在入侵中最先瞄准的凭据之一。

9、管理远程访问并尽可能进行分段:扁平网络和广泛共享的环境会让攻击者轻松横向移动。面向遏制的架构设计可以确保单点入侵不会演变成全企业事件。

  • 对所有远程连接使用强多因素访问控制;当外部设备接入网络时,只允许可信、已验证的设备接入。

  • 在连接不同信任级别的环境时使用分段;对于不需要彼此保持持续连接的系统,也应进行分段。

  • 对系统之间的每一次连接进行身份认证和授权,不要假设来自边界内部的流量就是可信的。

  • 在可能的情况下,设计应用和基础设施时应确保某个环境、业务部门或区域遭到入侵时,不会级联影响其他部分。

  • 通过红队演练和渗透测试定期检验这些控制措施的有效性,确认它们在对抗条件下能够达到预期,而不只是停留在架构图上。

10、将安全嵌入 AI 开发和部署生命周期:AI 既是威胁加速器,也是帮助你更快完成更多工作的变革性能力。不过,组织必须以与关键系统相同甚至更高的严谨程度,保护自身对 AI 的使用。

  • 通过威胁建模,在产品、技术和 AI 系统设计早期就纳入安全。使用 AI 开发软件时,应把安全参考架构作为上下文和技能提供给 AI。

  • 将 AI 模型、训练数据和上下文数据、推理流水线视为高价值资产,并根据其业务影响配置相应的访问控制、完整性监控和审计日志。

  • 验证 AI 生成的代码、配置和建议,在进入生产环境之前,是否接受与人工编写成果相同标准的安全审查和测试。

  • 评估并监控第三方 AI 服务以及 SaaS 平台中的嵌入式 AI 功能,关注其数据处理实践、模型来源和安全控制。AI 供应链风险是软件供应链风险的延伸。

  • 为 AI 系统建立治理和红队测试实践,在对抗性操纵、数据投毒和提示注入风险被生产环境中的攻击者利用之前,提前识别这些风险。

  • 认识到攻击者正在使用 AI 加速侦察、制作更有说服力的社会工程内容,并自动化漏洞利用;应投资 AI 增强型防御能力,以跟上威胁的速度。

* 本文为泽钧编译,https://www.jpmorganchase.com/about/technology/blog/fortifying-the-enterprise-10-actions-to-take-now-for-ai-ready-cyber-resilience注:图片均来源于网络,无法联系到版权持有者。如有侵权,请与后台联系,做删除处理。
— 【 THE END 】—

🎉 大家期盼很久的#数字安全交流群来了!快来加入我们的粉丝群吧!

🎁多种报告,产业趋势、技术趋势

这里汇聚了行业内的精英,共同探讨最新产业趋势、技术趋势等热门话题。我们还有准备了专属福利,只为回馈最忠实的您!

👉 扫码立即加入,精彩不容错过!

😄嘻嘻,我们群里见!

更多推荐