配置管理与漏洞管理

配置管理&与漏洞管理实践涉及修补和更新应用程序、版本控制、缺陷跟踪和补救以及事件处理。

1 级配置管理和漏洞管理

[CMVM1.1: 101] 创建或联合事件响应职能。

SSG 已经准备好对事件作出响应,并通过创建自己的事件响应职能,或定期与组织的现有团队接洽,定期参与事件响应流程。SSG 与事件响应团队定期会谈能够保持数据双向流动。有时也需要云服务提供商的参与。许多情况下,事件响应团队在开始意识到自己存在的根本原因是解除软件漏洞的后患时,就会转变为 SSI。

[CMVM1.2: 102] 确定在操作监控中发现的软件缺陷并反馈给开发部门。

通过操作监控发现的缺陷会被反馈给开发部门,用于改变开发人员的行为。生产日志的内容能够揭示内情(或能够揭示改善日志的需求)。有时,似乎可以提供一种将事件分类数据输入到现有的缺陷跟踪系统(使用特殊安全信标)。这种想法旨在闭合信息循环,确保安全问题得到解决。最理想的情况是能够基于操作数据改进 SSDL 中的流程。  

2 级配置管理和漏洞管理

[CMVM2.1: 82] 拥有应急代码库响应措施。

该组织可以在应用程序遭受攻击时快速更改代码。快速响应团队与应用程序负责人和 SSG 合作研究代码和攻击、找到解决方案,并将补丁程序投入生产流程。应急响应团队通常就是开发团队,特别是在使用敏捷方法时。消防演习不计算在内;需要一套明确定义的流程,从未使用过的流程实际上不起作用。

[CMVM2.2: 87] 通过固定流程追踪在操作中发现的软件缺陷。

操作中发现的缺陷被反馈到开发部门,录入既有的缺陷管理系统,并通过修复流程进行跟踪。这项职能可以采用双向衔接缺陷查找和缺陷修复职能的形式。确保完全闭合该循环。在缺陷追踪系统中设定安全信标能够便于开展追踪。

[CMVM2.3: 57] 编制应用程序操作清单。

该组织拥有其软件的部署地图。需要更改代码时,运营或 DevOps 团队能够笃定地找到需要安装更改的所有位置。会在多个项目之间共享的通用组件会被标注,以便在一个应用程序中出错时,也可以修复共享相同组件的其他应用程序。切记,开源组件也是组件。

3 级配置管理和漏洞管理

[CMVM3.1: 5] 修复在操作中发现的所有软件缺陷。

该组织修复操作期间发现的所有缺陷情况,而不仅仅是触发错误报告的少数情况。这就必须具备在出现新的缺陷种类时重新检查整个代码库的职能 (参见 [CR3.3 构建消除整个代码库特定缺陷的职能])。解决这个问题的方法之一是创建一套规则,将已部署的缺陷概括为可以通过自动代码审查进行扫描的内容。

[CMVM3.2: 7] 加强 SSDL 以防御在操作中发现的软件缺陷。

在操作中积累的经验带来 SSDL 的改变,从而改善 SSDL,防止在操作过程中重新引入已经发现的缺陷。为使该流程实现系统化,每个事件响应事后环节都可以包含一个“反馈到 SSDL”的步骤。当根本原因分析查明 SDLC 中可能引入或潜入未被察觉的错误时,这一环节作用最大。有了这一环节,跨职能部门的 DevOps 团队工作起来可能更容易,因为所有参与者都参与进来。只有临时方案是不够的。

[CMVM3.3: 9] 模拟软件危机。

SSG 模拟影响巨大的软件安全危机,确保软件事件响应职能可将损害降至最低。模拟可以测试确定和缓解特定威胁的能力,或者在其他情况下,可以从假设关键系统或服务已经受到损害着手,并评估组织的响应能力。模拟攻击成功之后需要考虑的一个重要问题是清理所需的时间。无论如何,模拟必须关注安全相关的软件故障,而不是自然灾害或其他类型的应急演习。在数据中心要被夷为平地时,SSG 不会率先作出响应。

[CMVM3.4: 13] 运行缺陷赏金计划。

该组织向外部研究人员征集漏洞报告,收到的漏洞报告一经验证和接受,就会给予赏金。奖金通常按照浮动比例支付,该比例与多种因素相关,例如漏洞类型(例如,远程代码执行价值 10,000 美元,而 CSRF 价值 750 美元)、可利用性(可论证的利用将获得更高奖金),或特定的服务和软件版本(获得广泛部署或重要服务可获得更高赏金)。夺旗赛等临时性或短期活动不计算在内。