安讯士 AXIS 安全开发模型 - 用户手册 设置指南

AXIS心国致力于安全发展

所有 Axis 开发团队都必须遵守 Axis 安全开发模型 (ASDM)。ASDM 是一个框架，它定义了 Axis 在整个生命周期（从开始到退役）中构建内置安全性的软件所使用的流程和工具。

推动 ASDM 工作的主要目标是：

• 使软件安全成为 Axis 软件开发活动不可分割的一部分。

• 降低 Axis 客户的安全相关业务风险。

• 满足客户和合作伙伴日益增强的安全意识。

• 通过早期发现和解决问题创造降低成本的潜力

ASDM 的范围是 Axis 产品和解决方案中包含的软件。

ASDM 由贯穿开发生命周期的多项活动组成。安全活动统称为 ASDM。最新版本为 2024.02，如下所示。

软件安全组 (SSG) 负责管理 ASDM 并随着时间的推移改进工具箱。有一个 ASDM 路线图和一个推广计划，用于实施活动并提高整个开发组织的 ASDM 成熟度。路线图和推广计划都归 SSG 所有，但实际实施的责任（例如与开发生命周期相关的活动）则委托给开发团队。

让团队拥有 ASDM 及其实施的所有权意味着经理负责活动的采用。与 SSG 推动中央 ASDM 推广计划的设置不同，它现在变成了基于拉动的，并由经理控制。

SSG 负责促进安全开发实践并在组织内培养安全文化。该小组由安全教练组成，负责 ASDM 的开发和维护，以及指导卫星和团队确保在开发过程中内置安全性。SSG 是开发组织在安全相关问题上的主要内部联系实体。

拥有 SSG 的原因如下：

• 确保采用结构化的方法来提高 Axis 产品和解决方案的安全性

• 确保 ASDM 适用于所有 Axis 品牌产品和解决方案

• 协调开发团队之间的 ASDM 使用

• 使 ASDM 状态公开透明

• 促进知识共享，包括最佳实践

卫星是开发组织的成员，他们花费部分时间推动软件安全方面的工作。设立卫星的原因如下：

• 无需构建大型中央 SSG 即可扩展 ASDM

• 为开发团队提供 ASDM 支持

• 促进知识共享，包括最佳实践

卫星将协助实施新活动并维护开发团队子集中的 ASDM。

如下表所示，ASDM 中有一些关键实体和角色。下表总结了与 ASDM 相关的角色和职责。

向开发团队推出 ASDM 活动是一个分阶段的过程：

1. 团队通过培训了解新的活动。

2. SSG 与团队合作，针对团队管理的系统的选定部分执行活动，例如风险评估或威胁建模。

3. 当经理、团队和卫星准备独立工作且无需 SSG 直接参与时，将工具箱集成到团队工作流程中相关的进一步活动将移交给他们。

当有新版本的 ASDM 可用且活动经过修改和/或增加时，将重复推出。SSG 与团队共度的时间在很大程度上取决于活动和代码的复杂性。成功移交给团队的一个关键因素是存在可以继续与团队一起开展 ASDM 工作的卫星。SSG 在活动推出的同时推动卫星的学习和分配。

下图总结了推出方法。

SSG 对于移交“完成”的定义是：

• 进行训练

• 卫星已分配

• 团队已准备好执行 ASDM 活动

• 建立与线路和 QA 经理、卫星和 SSG 成员的定期 ASDM 状态会议

SSG 使用来自团队的意见来为高级管理层准备状态报告。

ASDM 状态结构有两个视角：一个以团队为中心，模仿我们的团队和部门结构，对焦关注团队制造的组件；另一个以解决方案为中心，对焦关注我们推向市场的解决方案。这两个视角对于保持模型活力和确保安全工作顺利进行都至关重要。

为了验证组织中的安全状况，这两个视角聚集在一个由不同的研发经理组成的解决方案安全委员会中。经理们有责任确保向委员会报告安全状态。

下图说明了 ASDM 状态结构。

我们对组件的定义很广泛，因为我们需要涵盖各种架构实体，从平台中的 Linux 守护程序、服务器软件到云服务。每个团队都应该清楚了解所有高风险组件，包括新组件和旧组件。对于解决方案，我们希望深入了解其所有部分的安全状态。

首先，我们需要知道组件是否已经过安全分析，以确定其安全态势是已知还是未知。为了确保这一点，我们根据每个组件的安全分析覆盖范围将其分类为已完成、未完成或正在进行。

我们用来捕获组件安全质量的指标基于与组件相关的待办事项中的安全工作项。这可能包括尚未实施的对策、尚未执行的测试用例以及尚未解决的安全漏洞。

组件覆盖是 ASDM 线路会议活动的一部分。

团队的状态包括对其 ASDM 熟练程度的评估、与其安全分析活动相关的指标以及他们负责的组件的安全状态汇总。所有这些都在 ASDM 线路会议上讨论。

团队的成熟度与团队执行的活动相关。刚开始使用 ASDM 的团队预计会执行很少的活动，而精通安全工作的团队则预计会执行更多活动并向模型提供反馈。

解决方案状态汇总了组成解决方案的一组组件的安全状态。

解决方案状态的第一部分是组件的分析覆盖率。这有助于解决方案所有者了解解决方案的安全状态是已知还是未知。从某种角度来看，它有助于识别盲点。

解决方案状态的其余部分包含衡量解决方案安全质量的指标。我们通过查看与解决方案中的组件相关的安全工作项来做到这一点。

安全状态的一个重要方面是解决方案所有者定义的错误栏。解决方案所有者必须为其解决方案定义适当的安全级别。例如，这意味着解决方案在发布到市场时不应有未解决的关键或高严重性工作项。

这在 ASDM 产品/解决方案安全状态活动中有所涉及。

参与 Axis 软件开发的每个人都应该被授权这样做。授权的一个方面是拥有必要的知识水平。培训的目标是强调安全的重要性，促进分散所有权，并让人们了解 Axis 软件开发中的 ASDM 活动和责任。

这些培训包括从数字课程到基于讨论的会议。

定期召开后续会议的目的是在持续改进过程中提供必要的反馈循环。经理、卫星和 SSG 在这些会议上开会并讨论以下主题：

• 处理 ASDM 的组织能力

• 执行 ASDM 活动

• 组件安全状态

定期评估 ASDM 模型及其各项活动的有效性。目的是找出活动、方法和工具方面的差距。评估依赖于通过外部渗透测试和漏洞赏金计划从外部来源获得的反馈，也依赖于内部回顾。

目标是开发团队只需遵循 ASDM。因此，SSG 会定期评估不同的安全相关标准并将其映射到 ASDM。这被用作 ASDM 持续评估和改进的输入（众多输入之一）。

ASDM 的一个关键目标是优化团队内部安全活动的效率，以避免减慢开发速度。风险评估是根据上下文因素和与新旧代码相关的固有风险确定适当安全工作水平的基本方法。

风险评估需要判断新产品或现有产品中添加/修改的功能是否会增加风险。请注意，这还包括数据隐私方面和合规性要求。具有风险影响的更改示例包括新 API、授权要求的更改和新的中间件

当 Axis 从供应商处购买代码（或包含代码的产品）以将其用于 Axis 品牌产品时，我们需要评估供应商如何开展安全活动。供应商评估是一种工具，可以了解他们现有的安全实践、找出需要改进的领域，并提倡将安全活动整合到他们的开发过程中。

Axis 在评估第三方软件供应商时考虑的事项：

• 如果第三方代码存在漏洞并被利用，对 Axis 品牌的影响

• 开发环境/IT安全

• 安全的软件开发活动

• 漏洞和事件管理

信任是 Axis 关注的对焦领域，因此，在处理我们的产品、解决方案和服务收集的私人数据时遵循最佳实践非常重要。

Axis 与数据隐私相关的工作范围定义如下：

• 履行法律义务

• 履行合同义务

• 帮助客户履行义务

我们将数据隐私活动分为两个子活动：

• 数据隐私评估

• • 在风险评估期间完成

  • 确定是否需要进行数据隐私分析

• 数据隐私分析

• • 在威胁建模期间完成（如果适用）

  • 识别个人数据和对个人数据的威胁

  • 定义隐私要求

开源安全评估是指评估开源项目如何开展安全活动，并制定策略以减轻与项目相关的潜在风险。第三方软件风险会对依赖它的应用程序和系统产生直接影响。

Axis 在使用前评估开源软件组件时考虑的事项：

• 贡献者

• 更新节奏

• 漏洞管理

威胁建模是一种系统方法，用于在开发过程的早期识别威胁、定义对策和规划验证。但是，在识别威胁之前，我们需要确定威胁模型的范围。阐明范围的一种方法是描述我们需要考虑的攻击者。这种方法还使我们能够识别必须包含在分析中的高级攻击面。

威胁范围确定期间的对焦是使用系统的高级描述来查找和分类我们想要处理的攻击者。最好将描述可视化为数据流图 (DFD)，因为它可以更轻松地关联创建威胁模型时使用的更详细的用例描述。

这并不意味着我们识别的所有攻击者都需要考虑。它只是意味着我们对威胁模型中要解决的攻击者有明确和一致的认识。本质上，我们选择考虑的攻击者将决定我们正在评估的系统的安全级别。

请注意，我们的攻击者描述不考虑攻击者的能力或动机。我们选择这种方法是为了尽可能简化和精简威胁建模。

威胁建模有三个步骤，可以根据团队的需要进行迭代：

1. 使用一组 DFD 描述系统

2. 使用 DFD 识别威胁并以滥用案例风格进行描述

3. 定义威胁的对策并验证对策是否

威胁建模活动的结果是一个包含优先威胁和对策的威胁模型。解决对策所需的开发工作通过创建用于实施和验证对策的票据来管理。团队还可以让他们的威胁模型接受审查。

静态代码分析可以自动检测一些安全漏洞类别，减少手动代码审查的工作量。

在 ASDM 中，团队可以通过三种方式使用静态代码分析：

• 开发人员工作流程：开发人员分析他们正在处理的代码

• 代码工作流程：开发人员在代码审查系统中获得反馈

• 遗留工作流程：团队分析高风险遗留组件

软件组成分析可识别软件系统中的开源组件，并提供持续流程来检测与这些组件相关的已知安全漏洞，从而确保主动缓解。就所用组件及其相关漏洞进行公开透明的沟通对于建立信任和透明度至关重要。所有 Axis 软件均附带软件物料清单。

根据威胁模型创建测试涉及开发特定测试用例，以验证对策的有效性并评估系统抵御潜在攻击的能力。为了强调验证对策的重要性，威胁模型测试被视为一项单独的活动，尽管它与威胁建模相结合进行。

在某些情况下，第三方渗透测试会在 Axis 硬件或软件产品上进行。运行这些测试的主要目的是提供有关平台在特定时间点和特定范围内的安全性的见解和保证。

ASDM 的主要目标之一是透明度，我们鼓励客户对我们的产品进行外部渗透测试。我们很乐意在定义适当的测试参数以及讨论如何解释结果时进行合作。

通过外部渗透测试发现的所有漏洞都会收到 CVE ID，并因此公开共享。

定期进行漏洞扫描可让开发团队在产品向公众发布之前识别并修补软件漏洞，从而降低客户部署产品或服务时的风险。扫描在每次发布（硬件、软件）之前或按计划（服务）进行，使用开源和商业漏洞扫描软件包。

扫描结果用于在错误跟踪平台中生成工单，并标有独特的标签，以便开发团队确定优先级。所有漏洞扫描和工单都集中存储，以便进行可追溯性和审计。

严重漏洞应在发布前或在特殊服务版本中与其他非严重漏洞一起解决，并根据软件发布周期进行跟踪和解决。有关如何对漏洞进行评分和管理的更多信息，请参阅漏洞管理。

内部安全评估的目的是向团队提供有关其安全工作的反馈，并通过目标工作传播有关安全的知识。这是一项通常在团队内进行的更深入的安全测试。此活动不是由团队本身进行的，而是与团队外部的人员一起进行，以了解对正在评估的组件或系统的另一个看法。

内部安全评估的结果将用作以下内容的输入：

• 提高受评估组件或系统的安全级别

• 就团队 ASDM 活动的有效性提供反馈

• 向 SSG 提供有关 ASDM 可能改进的反馈

• 提供有关内部安全评估方法的反馈

自 2021 年起，Axis 成为注册的 CVE 命名机构 (CNA)，因此能够将标准 CVE 报告发布到 MITRE 数据库，供第三方漏洞扫描程序和其他工具使用。

漏洞委员会是 Axis 内部联系点，用于处理外部研究人员发现的漏洞。已发现漏洞的报告和后续补救计划通过product-security@电子邮件地址传达 。

漏洞委员会的主要职责是从业务角度分析并确定所报告漏洞的优先顺序，基于以下几点：

• SSG 提供的技术分类

• Axis 设备运行环境中的最终用户面临的潜在风险

• 补偿性安全控制措施的可用性（无需修补的替代风险缓解措施）

漏洞委员会注册 CVE 编号并与报告者合作为漏洞分配通用漏洞评分系统 (CVSS) 分数。漏洞委员会还通过 Axis 安全通知服务、新闻稿和新闻文章推动与合作伙伴和客户的外部沟通。更多信息请参阅 Axis 漏洞管理政策。

事件是系统中被利用的弱点。处理和管理事件的有组织方法称为事件管理。事件管理的目标不仅仅是提供解决方案，而是以限制损害、减少恢复时间和成本的方式来处理情况。事件管理不同于漏洞管理，因为系统内部可能存在活跃的攻击者。

团队有自己的剧本来管理事件。剧本的目的是有记录的方式来及时响应和解决事件。剧本不仅能让团队在事件发生时做出决策，还能提醒大家，事件管理不仅仅是事件本身。

将安全性集成到发布工作流程中需要每个人都参与发布决策，例如项目经理、产品经理、QA 和开发经理。此外，卫星和 SSG 成员可以以顾问身份参与，帮助解决发布过程中的安全问题。

通过定期讨论产品或解决方案的安全状态，我们：

• 对我们的产品和解决方案的安全性做出明智的决定

• 确保开发线和产品管理与我们的产品和解决方案的安全态势保持一致

• 确保我们对安全状态有完整、透明的了解

漏洞赏金计划是一种众包设置，鼓励独立安全研究人员发现并报告 Axis 产品中的漏洞。成熟团队会利用此活动寻求对其 ASDM 工作的外部反馈。

漏洞赏金计划加强了 Axis 主动识别、修补和披露漏洞的努力。通过漏洞赏金计划发现的所有漏洞都会收到 CVE ID，从而公开分享。

ASDM 是使用常见的最佳实践创建的，但 针对 Axis Communications 的特定环境（例如公司文化和产品组合）进行了专门调整。因此，Axis 可以根据我们的环境调整和优化 ASDM，而不是遵循其他行业已建立的安全开发生命周期或标准。

最初的 ASDM 版本 (2018.01) 在设计上仅包含少量活动。随着 Axis 的开发团队在安全工作方面变得更加成熟，增加了更多活动。一些活动已经发展，特别是那些对焦有限的活动。随着团队和组织的不断成熟，SSG 扩展了活动。一些活动的名称已更改，以更清楚地表明它们包含的内容。

Axis 定义了以下 ASDM 版本。