编者按
美国防部首席信息官4月11日发布《DevSecOps 持续授权实施指南》，旨在指导美国国防机构实现持续授权操作（cATO），以操作由软件工厂生产的DevSecOps平台和其他应用程序，从而对抗网络威胁。
该指南文件指出，美国防部必须使其软件开发和交付方法现代化，以跟上不断变化的威胁，从而能够以相关的速度提供弹性软件功能；这种敏捷现代化的一个不可或缺的方面是能够通过持续集成和提供网络安全、弹性和生存能力来快速响应不断变化的威胁；当前的网络安全环境要求美国防部摒弃时间点评估和授权，转向持续监控和评估风险，使用安全自动化和安全态势仪表板来帮助管理近乎实时的网络安全风险；快速交付新功能需要一个能够跟上开发能力的持续变化的授权流程cATO，cATO不再采用控制评估时间点方法，而是通过经过论证的持续评估、监控和风险管理来专注于持续风险确定和授权；该文件重点关注对由包含DevSecOps平台的软件工厂生产的应用程序软件进行持续评估和授权，确定了持续授权的关键实践，并提供了评估组织进入持续授权的方法。
文件提出，cATO是当开发、保护和运营系统的组织已证明其维持弹性网络安全态势的能力足够成熟而无需进行传统的风险评估和授权的状态；该组织必须实施强大的信息安全持续监控能力、主动网络防御和安全软件供应链要求，以实现持续交付功能，而不会对系统的网络态势产生不利影响；寻求cATO的系统必须已获得操作授权（ATO）并已进入风险管理框架（RMF）监控阶段；为实现cATO ，授权官员（AO）必须能够具备三项主要能力，即对风险管理框架（RMF）控制实施强有力持续监控、开展主动网络防御以实时响应网络威胁以及采用和使用经批准的DevSecOps参考设计。
cATO评估可确保软件工厂包含以下三项功能：一是持续的安全态势（或状态）和风险报告，包括仪表板，用于汇总和显示自动（也可能是手动）安全漏洞分析、控制合规性扫描以及环境和托管应用程序的安全控制有效性的结果；二是网络运营部门对安全配置、事件分析、缓解有效性、威胁环境变化以及未经批准行为检测的意外变化的反馈正在受到监控，并用于支持风险响应；三是通过一组完整的信息以及DevSecOps 护栏和控制门提供根据商定的风险承受度执行持续风险分析的能力，以支持持续的风险确定和授权决策。cATO评估方法涉及：确定执行过程评估的团队；对团队进行cATO评估流程的教育和培训；与负责的cATO机构协调评估，并确保组织了解要评估的关键实践、评估过程和评估标准；与授权官员共同审查评估计划，以确保包括关键实践和关注点；收集并审查组织的实践文件和证据；确定并安排与代表关键角色且了解 cATO DevSecOps实践的组织人员的访谈；根据评估和权重标准评估 DevSecOps平台、流程和团队；制定并审查评估结果、建议；提供最终的组织准备风险确定和建议供授权官员考虑。
cATO实施和评估的关键实践涉及DevSecOps平台、cATO流程和DevSecOps团队三个方面。其中，DevSecOps平台实践包括：制定并实行持续监控策略；使用已确定的网络安全服务提供机构（CSSP）来监控系统单一授权边界是否存在恶意威胁操作；识别独特的应用程序事件，实施安全信息和事件管理监控分析并提供给CSSP；配置生产系统及其监控功能以检查应用程序流量并处理事件；由DevSecOps平台安全团队确定应用程序的DevSecOps平台控制继承；通过安全自动化监控生产系统内的应用程序安全状况；在管道控制门中商定并实施操作风险承受度；建立网络运营反馈循环并审查应用程序网络安全事件；显示应用程序和DevSecOps平台的安全状况。cATO流程实践包括：建立网络安全风险治理小组；了解并建立护栏和控制门风险承受能力提升规则；定期使用动态漏洞工具、威胁行为者模拟、渗透测试和操作分析来确定安全控制的有效性；使用安全自动化不断验证子系统安全配置和安全控制合规性；利用CSSP监控来发现未经批准的行为并执行事件取证来改善不间断系统安全状况；不断重新评估工件存储库中的工件；持续显示生产系统的安全状况和剩余风险；建立穿越管道的应用程序所需的技术安全控制和风险承受度。DevSecOps团队实践包括：有流程来确保员工接受教育、培训和认证；根据团队成员的角色制定入职流程；团队成员具有开发安全应用程序、在DevSecOps文化中工作、使用安全自动化工具以及执行应用程序和系统授权的经验；团队成员接受过cATO方法的培训；识别文化变革挑战，并利用培训、协作讨论论坛和高层领导来帮助解决。
文件指出，持续授权指标可深入了解持续授权流程在维护通过软件工厂的应用程序的安全性、质量和完整性方面的有效性，具体包括：网络卫生指标；与护栏和控制门结果相关的趋势指标；反馈沟通频率指标；与缓解措施持续有效性相关的指标；安全态势仪表板指标；容器指标；测试指标。文件还提供了实现cATO的组织和软件工厂的实用建议，包括：通过相关选项构建DevSecOps平台；在商业云上运行DevSecOps平台；给团队带来初始安全感并使其全程参与；创建安全敏捷流程以支持价值的持续交付；必须在所有环境中实施持续监控，包括开发、测试和生产；主动网络防御必须到位，包括本地安全运营中心（SOC）和外部网络安全服务提供机构（CSSP）；保护软件供应链。
奇安网情局编译有关情况，供读者参考。
DevSecOps持续授权实施指南
美国防部首席信息官办公室（DoD CIO）
一、介绍
“用于报告安全事件的实时或近实时数据分析对于实现应对当今网络威胁和在竞争性空间中运行所需的网络安全水平至关重要。”
– 《持续授权操作( cATO )备忘录》。
当今的紧迫需求要求我们能够敏捷地响应不断变化的任务需求，比传统的美国防部流程更快地交付能力。为实现如此快速的速度，业界已开始使用DevSecOps软件开发，通常每天多次交付新功能。美国防部还必须使其软件开发和交付方法现代化，以跟上不断变化的威胁，从而能够以相关的速度提供弹性软件功能。
这种敏捷现代化的一个不可或缺的方面是能够通过持续集成和提供网络安全、弹性和生存能力来快速响应不断变化的威胁。网络安全环境以其高级持续威胁（APT）和利用漏洞的创新方法，鼓励人们放弃时间点评估和授权，而是转向持续监控和评估风险，使用安全自动化和安全态势仪表板来帮助管理近乎实时的网络安全风险。
《美国防部软件现代化战略》中描述了现代化方法，其中包括通过企业提供商推进DevSecOps的目标，以及通过持续授权加速软件部署的目标。
许多美国防部部门将获得操作授权（ATO）视为开发和部署软件的最长步骤。快速交付新功能需要一个能够跟上开发能力的持续变化的授权流程，称为持续授权操作（cATO）。拥有cATO的组织可以持续评估和部署满足在系统授权边界内使用的风险承受度的子系统。cATO不再采用控制评估时间点方法，而是通过经过论证的持续评估、监控和风险管理来专注于持续风险确定和授权。
本文件重点关注对由包含DevSecOps平台（DSOP）的软件工厂生产的应用程序软件进行持续评估和授权，特别是《DevSecOps持续授权操作评估标准》中描述并在本文件附录中体现的两个用例。本文件确定了持续授权的关键实践，并描述了评估组织是否准备好进入持续授权的方法。以cATO形式开展的主动风险管理是通过组织通过风险治理流程建立风险管理能力来实现的。
本文件的受众是寻求cATO的系统的实施者。本文件提供了cATO的概述，其中包括实现cATO必须实施的关键实践。
什么是持续授权？
持续授权操作（cATO）是当开发、保护和运营系统的组织已证明其维持弹性网络安全态势的能力足够成熟时所达到的传统的风险评估和授权变得多余的状态。该组织必须实施强大的信息安全持续监控能力、主动网络防御和安全软件供应链要求，以实现持续交付功能，而不会对系统的网络态势产生不利影响。
寻求cATO的系统必须已获得操作授权（ATO）并已进入风险管理框架（RMF）监控阶段。
cATO是美国国家标准与技术研究所（NIST）风险管理框架（RMF）术语持续授权的超集，该术语已存在多年，但缺乏自动化功能，无法在广泛社区内发挥作用。DevSecOps的持续授权包括其他方面，例如评估团队和用于支持持续风险监控的DevSecOps平台。
二、cATO能力
《持续授权操作（cATO）备忘录》指出，“为实现cATO ，授权官员（AO）必须能够展示三项主要能力：系统边界内关键网络安全活动的持续可见性对风险管理框架（RMF）控制进行强有力的持续监控；进行主动网络防御以实时响应网络威胁的能力；以及采用和使用经批准的DevSecOps参考设计。”
概括来说，这三种能力是：
风险管理框架（RMF）控制的持续监控（CONMON）
主动网络防御（ACD）
使用经批准的DevSecOps参考设计。
此外，cATO备忘录指出了对安全软件供应链 (SSSC) 的需求，并将其与第三项能力联系起来，指出“为防止人为错误、供应链中断、意外代码的任何组合，并支持创建软件物料清单（SBOM），采用经过批准的软件平台和开发流程至关重要。”
评价标准
cATO备忘录指出，不断发展的指南和相关资源将在RMF知识服务（KS）上发布，网址为 https://rmfks.osd.mil。本指南的一个重要部分是发布在此处以及美国防部首席信息官办公室资料库中的《DevSecOps持续授权操作评估标准》。该文件列出了由cATO授权官员评估的活动和文件。
三、方法
基本概念
为了简化讨论，这里定义了一些关键术语。
DevSecOps管道：DevSecOps工具的集合，可以在其上创建和执行DevSecOps流程工作流。（《美国防部体系DevSecOps基础知识2.1版》）
DevSecOps平台（DSOP）：支持软件工厂的一组工具和自动化。它包括使用控制门创建DevSecOps管道以及将软件部署到开发、测试和临时/预生产环境中的能力。它还可以部署到生产中，具体取决于生产环境。
软件工厂：与支持 DSOP 的人员和流程以及云等托管环境相结合的 DSOP；它至少包括开发、测试和临时/预生产环境，并且可能包括生产环境以及集成等其他环境。
软件工厂基于美国防部首席信息官办公室资料库中的《美国防部体系DevSecOps参考设计（RD）》之一。图 1 说明了与cATO相关的一些关键组件。
图1：软件工厂：cATO视角
在美国国家标准与技术研究所（NIST）风险管理框架（RMF）的术语中，软件工厂至少包含一个具有单一授权边界的系统。这通常包含开发系统、测试系统和临时（或预生产）系统。它还可能包含生产系统，或者该系统可能托管在不同的平台上，例如嵌入式系统中。
软件工厂应包括以下内容：
自动化，包括至少一个带有自动护栏和控制门的DevSecOps管道，用于收集证据，以便在软件开发过程中进行持续的风险评估和决策
内置仪表板和自动警报，用于监控和管理生产风险
▫必须包括针对内部和外部生产环境的主动反馈机制
一个应用程序托管环境，该环境使用现代超大规模云（或其他美国防部批准的环境）来提供开发、测试、临时和（可选）生产环境
一个DevSecOps平台，作为自己的系统交付和运行并作为服务提供给应用程序开发人员
来自风险治理流程的输入，为管道中移动的应用程序提供一组通用的可接受的剩余风险承受度
▫当软件工厂包括一个或多个应用程序的生产环境时，例如附录用例1，管理风险的小组是一个协作小组，由平台团队、应用程序团队、授权官员指定风险评估员和任务安全团队组成。cATO颁发给管理环境的软件工厂，该工厂还负责管理托管多个应用程序（子系统）的单个授权边界的风险
▫附录用例2：生产/运营环境在DSOP外，例如当托管环境是嵌入式系统或比开发环境分类更高的系统时，风险治理团队必须与生产环境的授权官员合作确定应用程序的风险承受度
遵守美国防部首席信息官办公室DevSecOps指南，包括《DevSecOps基础指南：活动和工具》
评估方式
NIST《风险管理框架（RMF）》概述了用于授权系统的基于风险的框架。它包括持续评估和授权的机制，并由组织持续监控不间断风险并确保其保持在商定的风险承受范围内的能力提供支持。项目办公室、任务负责人、风险评估人员和授权官员共同制定一套可接受的风险承受度。软件工厂采用与组织风险管理容限相一致的风险阈值。
cATO评估可确保软件工厂包含以下功能：
1、持续的安全态势（或状态）和风险报告，包括仪表板，汇总和显示自动（也可能是手动）安全漏洞分析、控制合规性扫描以及环境和托管应用程序的安全控制有效性的结果
2、网络运营部门对安全配置、事件分析、缓解有效性、威胁环境变化以及未经批准行为检测的意外变化的反馈正在受到监控，并用于支持风险响应
3、一组完整的信息以及DevSecOps 护栏和控制门提供了根据商定的风险承受能力执行持续风险分析的能力，以支持持续的风险确定和授权决策
四、评估方法
cATO的评估过程涉及通过审查实践使用证据、与执行实践的人员面谈以确定组织理解和实施的水平以及审查持续监控活动的结果，来了解组织在软件工厂中的风险管理实践。评估团队使用该信息来根据评估团队制定的评估标准来确定组织管理风险的准备情况。这些标准应基于《DevSecOps持续授权操作评估标准》。
这种评估方法是一个根本性的转变，从对组织安全控制合规性的时间点评估转向对组织在整个应用程序生命周期（从开发到持续集成、交付和部署下的运营）中管理风险的持续准备情况的定期评估。
cATO评估方法
确定执行过程评估的团队。评估DevSecOps平台、流程和人员所需的技能会有所不同，而授权官员将批准评估团队及作为授权流程的一部分的其能力。
对团队进行cATO评估流程的教育和培训。制定评估计划并确定关键实践以及评估和权重标准。详细的cATO评估标准可以在《DevSecOps持续授权操作评估标准》中的知识服务（KS）上找到
高水平评估标准：
▫实践被定义并记录。
▫存在使用风险管理和持续监控实践的证据。这些证据包括展示。
▫员工熟悉cATO实践。
▫cATO实践的实施水平按照附录表2中关于cATO要求目的和目标的定义进行衡量。
与负责的cATO办公室协调评估；确保组织了解要评估的关键实践、评估过程和评估标准。
与授权官员一起审查评估计划，以确保包括关键实践和关注点。
收集并审查组织的实践文件和证据。例如，可以通过各种类型的跟踪系统、会议记录和管道安全扫描报告来提供证据。
确定并安排与代表关键角色且了解 cATO DevSecOps实践的组织人员的访谈
根据评估和权重标准评估 DevSecOps平台、流程和团队。可以针对关键领域（例如软件工厂、流程和团队）建立权重，具体到附录表2中确定的实际实践。
制定评估结果、建议，并与负责cATO的组织办公室一起审查它们。
使用授权官员cATO 决策简报，提供最终的组织准备风险确定和建议，供授权官员考虑，包括授权的所有条件。
cATO备忘录评估交叉
本节将评估软件工厂、流程和人员的评估方法与前面在cATO能力部分讨论的cATO备忘录能力联系起来：
持续监测（CONMON）
主动网络防御（ACD）
将经过批准的DevSecOps参考设计用于具有安全软件供应链（SSSC）的软件工厂。
这些能力是在cATO评估过程中产生共鸣的主题，如表1所示。例如，对于持续监测（CONMON），软件工厂必须具有自动化功能来生成、分析和显示机器证据；此外，必须有良好的使用流程（例如事件响应）；人员必须接受自动化和流程方面的培训。类似地，对于其他每项能力也是如此。
表1：cATO 备忘录能力评估交叉
五、关键实践
本节讨论要实施和评估的关键实践。这些实践被组织成DevSecOps平台、cATO流程和DevSecOps团队（人员）实践。
DevSecOps平台实践
DevSecOps平台必须基于《美国防部体系DevSecOps参考设计（RD）》之一。cATO评估假设DevSecOps平台已获授权运行并处于持续监控状态。适用的持续监控实践将被继承以用于cATO授权。评估的这一部分旨在确保负责DevSecOps平台的组织已有效地制定了所需的支持性cATO实践，以管理应用程序穿越DevSecOps管道的风险。
相对于DevSecOps平台，适用以下cATO实践：
DevSecOps平台制定并实行了持续监控策略。
DevSecOps平台使用已确定的网络安全服务提供机构（CSSP）来监控系统单一授权边界是否存在恶意威胁行为者的操作。
应用程序或子系统管理者识别独特的应用程序事件，开发安全信息和事件管理（SIEM）监控分析，并将其提供给网络安全服务提供机构（CSSP）。
生产系统及其监控功能配置为独特的应用程序流量检查和事件处理。
▫如果系统使用部署在Kubernetes Pod 中的容器和 Sidecar 容器安全堆栈（SCSS），则应将其配置为独特的应用程序流量检查和事件处理。（请注意，SCSS 不是必需的；它的使用取决于所选的参考设计。）
应用程序的DevSecOps平台控制继承由DevSecOps平台安全团队确定。
安全自动化用于监控生产系统内的应用程序安全状况。此外，自动化还可以定期检查安全配置。
通过事件触发路由，操作风险容忍度在管道控制门中得到商定并实施。
建立网络运营反馈循环，并与 DevSecOps 团队合作审查应用程序网络安全事件。
应用程序和DevSecOps平台的安全状况在DevSecOps平台安全仪表板上进行可视化。
cATO流程实践
cATO流程实践提供对风险的持续监控、评估和管理。目标是评估组织实践，以确保建立持续监控和响应，以将生产系统网络风险管理在承受度范围内。其中许多实践可以自动化，包括风险确定和持续进行的授权决策。
图2：网络安全风险治理小组
组织建立一个网络安全风险治理小组，由来自应用程序开发团队、授权官员的安全风险评估团队、DevSecOps平台安全团队的成员以及任务负责人组成，如图 2 所示。
组织了解并建立护栏和控制门风险承受能力提升规则，用于自动确定风险并触发事件以升级解决方案。
▫对于具有单一授权边界的DevSecOps平台，应使用其风险承受度来建立护栏和控制门升级规则。
DevSecOps团队定期使用动态漏洞工具、威胁行为者模拟、渗透测试和操作分析来确定安全控制的有效性。在这个领域，一些测试可能是手动的，例如渗透测试，但其结果可用于控制门通过/失败确定。
DevSecOps团队使用安全自动化不断验证子系统安全配置和安全控制合规性。
DevSecOps团队利用对生产系统的持续网络安全服务提供机构（CSSP）监控来发现未经批准的行为，并执行事件取证来改善不间断系统安全状况。这包括网络运营情报小组对威胁形势变化的反馈。
DevSecOps团队不断重新评估工件存储库中的工件，以确保剩余风险仍然可以接受。
DevSecOps团队持续可视化生产系统的安全状况和剩余风险。
DevSecOps平台团队建立了穿越管道的应用程序所需的技术安全控制和风险承受度。如果需要应用更严格的承受度，开发团队应与DevSecOps平台cATO团队合作来应用它们。
DevSecOps团队实践
DevSecOps团队的目标是在执行开发、执行安全分析和风险管理职能的团队中建立信任。这包括开发团队开发安全代码和解释漏洞报告的能力，安全团队管理安全控制合规性、有效性和风险承受度的能力，以及DSOP 团队实例化与安全工具和控制门集成的管道并监控生产环境中可能存在的恶意行为的能力。这些团队是风险管理治理小组如何管理单一授权边界内应用程序使用风险的组成部分。团队评估会审查已实施的组织实践，以确保人们根据DevSecOps职位所需的知识、技能和能力接受相应的教育、培训和认证。
组织有一个流程，根据员工在组织和DevSecOps平台中的角色，确保员工接受教育、培训和认证。可能的培训领域包括敏捷、DevSecOps、安全编码、安全自动化工具、解释漏洞扫描报告和cATO框架。
▫还应该提供并跟踪领导力教育和培训。
组织根据团队成员的角色制定了入职流程。
团队成员具有开发安全应用程序、在DevSecOps文化中工作、使用安全自动化工具以及执行应用程序和系统授权的经验。
团队成员接受过cATO方法的培训：
▫接受过安全自动化工具、扫描结果解释以及如何在cATO方法中使用它们的培训，
▫接受过关于DevSecOps护栏和控制门升级规则和风险承受度的培训，
▫接受过关于解决和裁决导致超出风险承受度的安全结果的培训，
▫能够对安全结果进行根本原因分析，
▫接受过持续监控反馈循环方面的培训，以确保系统安全状况的持续改进。
▫接受过制定行动计划和里程碑以及安全仪表板监控方面的培训。
组织识别文化变革挑战，并利用培训、协作讨论论坛和高层领导来帮助解决。
六、持续授权指标
以下指标可深入了解持续授权流程在维护通过软件工厂的应用程序的安全性、质量和完整性方面的有效性。
网络卫生指标，例如修补漏洞的平均时间——识别DevSecOps平台或应用程序中的漏洞与成功生产补丁部署间的平均时间。重点关注对应用程序或任务有高到中度影响的漏洞。
随着时间的推移，与护栏和控制门结果相关的趋势指标可显示开发团队在每次新冲刺中开发安全代码方面的努力的改进以及系统安全状况的持续改进。
反馈沟通频率指标，以确保反馈循环到位、得到使用，以及显示安全状况有所改善的趋势。
与针对不断变化的威胁形势的缓解措施的持续有效性相关的指标。
安全态势仪表板指标显示应用程序的阶段及其在风险承受度、安全控制合规性和安全控制有效性结果方面的安全态势。
其他需要考虑的指标包括：
容器指标——根据容器在子系统中使用的次数来衡量容器的使用年限，以及基于总体开放的安全问题衡量容器的剩余风险。
测试指标：通过的测试覆盖率百分比、通过的功能测试百分比、各种严重程度发现的数量、缓解的威胁行为者行动百分比、与风险承受度相比的安全发现以及通过的安全控制合规性的百分比。
七、实际实施建议
本节提供了有关如何开始实施可实现cATO的组织和软件工厂的实用建议。有关cATO评估包中应提供的内容的详细信息，请参阅《DevSecOps持续授权运营评估标准》。
选择以下选项之一来构建 DevSecOps平台。
▫使用现有的 DevSecOps平台（例如Platform One Party Bus）。
▫使用 DSOP 的新实例（例如 Platform One Big Bang）。
▫使用一套集成的云原生工具。
▫使用现有的商业集成DevSecOps工具。
▫用强化组件构建新的DevSecOps平台。这是最耗时的方法，应尽可能避免。
如果可能，目标是在商业云上运行DevSecOps平台。
▫云可以通过联合作战云能力（JWCC）采购工具或通过其他现有的国防部工具来获得。
▫如果目标生产环境不是云（用例 2），则在云中执行一些开发和测试可能仍然有用。
从一开始就给团队带来安全感，并让他们全程参与。
▫设置风险承受度。
▫在控制门和护栏中实施风险承受度。
▫确保实施网络安全最佳实践，包括职责分离和最小权限访问。
创建安全敏捷流程以支持价值的持续交付。
▫在流程中建立安全性。
必须在所有环境中实施持续监控，包括开发、测试和生产。
▫将持续监控与审核相结合，以确定主动事件响应的阈值和触发因素。
主动网络防御必须到位，包括本地安全运营中心（SOC）和外部网络安全服务提供机构（CSSP）。
▫必须制定详细的事件响应计划，并对人员进行培训。
保护软件供应链
▫为DevSecOps平台和通过它的应用程序创建软件物料清单（SBOM）。
下一组建议是在组织中实施DevSecOps 。这是必要的一部分，但它不是cATO包本身的一部分。
文化变革是 DevSecOps 的重要组成部分。实施起来可能比DevSecOps 平台更具挑战性，但如果没有适当的支持文化，DevSecOps 是不可能实现的。
▫专注于创造价值。
▫建立良好的反馈机制。
▫实施心理安全。快速失败，但不要以同样的方式失败两次。
▫让安全成为每个人的工作。
▫扭转康威定律并创建一个模仿该架构的组织。例如，可能会有一个 DevSecOps 平台团队、一个或多个应用程序团队，并且其他主要组件可能有关联的团队。
使用敏捷项目管理技术。
▫创建用户叙述并提供频繁的演示，而不是创建全面的需求。
▫要跟踪任务，请使用Knaban board或类似工具。
▫不要使用瀑布方法。
▫不要使用需要大量开销来维护的重量级敏捷流程。
尽早设置测试（或可选集成）环境。
▫这可用于需要与软件产品集成的其他系统。这使得持续集成成为可能。
▫此环境还可用于展示产品的持续改进。
附录：
用例1：具有集成生产环境的软件工厂
用例2：具有独立生产环境的软件工厂
声明：本文来自奇安网情局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。