最新资讯
本系列文章是亚远景科技结合ASPICE for Cybersecurity Guideline，对ASPICE for Cybersecurity进行的一些标准解读和应用说明，希望向更多的人明晰化标准的一些要求，也帮助推动标准在行业的发展。
当前推出的ASPICE for Cybersecurity标准中新增加了6个过程，分别是
ACQ.2 Supplier Request and Selection
供应商要求与选择;
MAN.7 Cybersecurity Risk Management
网络安全风险管理;
SEC.1 Cybersecurity Requirements Elicitation
网络安全需求获取;
SEC.2 Cybersecurity Implementation
网络安全实施;
SEC.3 Risk Treatment Verification
风险处理的验证;
SEC.4 Risk Treatment Validation
风险处理的确认。
上一篇文章解读了：
ACQ.2 Supplier Request and Selection供应商要求与选择
本篇要讲解的过程是：
MAN.7 Cybersecurity Risk Management网络安全风险管理
网络安全风险管理过程的目的
是识别、优先考虑和分析对相关利益相关者造成的损害的风险，并持续监控和控制各自的风险处理方案。
风险管理是项目的核心部分，可应用于所有技术、组织和商业风险的识别和分析。
风险管理过程确保了对潜在风险的系统识别。潜在的风险可以在项目开发之前、期间和之后的任何时间都被识别——甚至在生产和后期生产中。它们需要进行系统的分析和估计。应按照ISO26262和ISO/SAE21434等技术标准对潜在风险和风险进行区分。一旦潜在风险被赋予了概率和严重程度，它们就被称为风险。
在复杂的项目开发过程中，潜在的风险可能会变得很高。在运行密集分析阶段之前，应该执行第一个优先级排序。这种初始优先级是基于潜在风险可能造成的损害或潜在危害。风险分析的工作可能是项目中的一个瓶颈，影响时间线；因此，最初的优先级应确保首先分析最相关的潜在风险。
风险分析
包括：风险识别、可利用性和评估攻击可行性发生的标准，以及在发生错误的情况下。分析可以是结构性的、数值上的或它们的组合。已建立的结构性风险分析，例如，FTA或鱼骨图分析。结构化分析是汽车工程中常用的分析方法(详细内容可参考SWE.2的BP6中使用的制造-购买-重用分析)。数值化分析可以使用跨行业的方法及其各自已建立的评级方案（如果适用）。
TARA（Threat Analysis and Risk Assessment）
是ISO/SAE21434标准中定义的关键活动，也是网络安全威胁分析和风险评估的最成熟方法，适用于MAN.7的实施。
风险管理根据风险、损害和危害的确定，制定了基本的风险处理方案。这种风险处理方案可以是避免、减少、转移（分享）或接受风险。风险管理过程不包括风险处理措施或提供解决方案。应在项目管理、工程过程或者采购等相关过程中定义相应的风险处理措施。
风险管理是一个重要的过程，它可以对计划外的和突然的变化、新闻、普遍缺乏进展以及利益相关者接口中的差距做出反应。因此，对相关变化和采取纠正措施能力的监控是1级和2级的先决条件。
评级建议
1) 网络安全风险管理范围Cybersecurity Risk Management scope
风险管理范围需要定义应用在风险管理过程及其运行环境中的边界。范围定义需要包括：
a）资产：产品、其组件，以及与资产相关，用于项目风险防护目的的系统/软件元素。
b）需要被管理和控制的损坏场景
c）网络安全属性是这些资产的属性。例如：
1．保密性
2．完整性
3．可用性
d）可能受到风险不良后果影响的相关干系人，包括：
1．道路使用者（例如，车辆使用者）
2．客户
3．供应商
e）影响类别与它们可能给相关干系人造成的不利后果相关。影响类别包括但不限于：
1．功能安全 - 例如，对于车辆使用者
2．隐私 - 例如，司机的个人信息
3．财务 - 例如，客户服务网络或道路使用者可能无法克服的经济损失
4．操作性 - 例如，重要车辆功能的损害或在客户制造过程中对基础设施的影响等。
5．质量 - 与在其他影响类别中没有特别涵盖的涉众期望相关(例如，对控制可用性的非技术影响)
f）在资产管理范围内的阶段：
1．创新或演示性构建
2．前期开发
3．开发
4．生产和制造
5．维护和保养
6．终止
范围定义应代表最低限度的定义，包括初始损坏场景。以后确定的损坏场景不应视为不完整的范围定义。
现成的组件的集成应该包括在范围定义中（例如，免费和开源软件）。
与风险相关的属性可以被重叠，并由不同的解释。例如，“身份验证”可以被解释为“机密性”或“可用性”，这取决于涉众的观点。
相关的干系人应该在供应链和分布式开发中进行评估和协调。 例如，子供应商可能对现成组件的初始风险管理有不同的观点。范围必须至少包括道路使用者。
范围内的阶段可能是有限的。如果不满足最低要求，这是合理的。
建议和规则：
[MAN.7.RL.1]：If the risk management scope does not consider relevant assets (aspects a and c) that are significant for a process related product risk, BP1 cannot be rated higher than P.
解读：如果风险管理范围没有考虑对过程相关产品风险重要的相关资产(a和c方面)，则BP1的评级不能高于P。
这些建议和规则的核心是希望能够有效的识别“资产”：
a) 其网络安全属性（机密性/完整性/可用性，或者基于STRIDE的机密性/完整性/可用性/真实性/不可否认性/授权/时效性）的丧失而将导致损失的产生。
b) 分为四种类型：外部实体、功能单元、数据存储、数据流。
资产的网络安全属性除了上文提及的保密性、完整性和可用性(CIA模型)之外，常用的属性模型如下图：
[MAN.7.RC.1]：If the scope does not consider cost- (financial) and schedule (organizational)-related risks (aspect e) but these are covered when estimating work packages in the project planning, this should not be used to downrate the indicator BP1.
解读：如果范围没有考虑成本(财务)和进度(组织)相关的风险(方面e)，但在项目策划中估算工作包时已经包括了这些风险，那么不应该用它来对BP1扣分。
[MAN.7.RL. 2]：If the scope does not consider the road user as stakeholder (aspect d), BP1 cannot be rated higher than P.
解读：如果范围没有考虑道路使用者为干系人(方面d)，则BP1的评级不能高于P。
[MAN.7.RL. 3]：If the scope does not consider the impact category “Quality”, it must not be used to downrate BP1.
解读：如果范围没有考虑影响类别“质量”，则不能用于对BP1的扣分。
相关内容：
BP1：Determine cybersecurity risk management scope 确定网络安全风险管理范围
Output WP 08-19: Risk management plan 风险管理计划
Output WP 14-51: Cybersecurity scenario register网络安全场景登记册
Output WP 14-52: Asset library资产库
2) 风险管理实践Risk management practices
用于建立网络安全风险管理的活动源自于汽车网络安全管理系统(ACSMS)中所需的策略定义。
风险管理实践应包括以下方法、角色、工具、评审和发布标准：
a）潜在风险识别：用于识别和记录威胁场景和损害场景的仓库和实践，例如:
1. 检查欺骗、篡改、拒绝、信息披露、拒绝服务和提升特权等结构化威胁建模实践的评估方案 (STRIDE)
2．故障树分析（鱼骨图）
3．头脑风暴
b）风险分析：用于攻击路径分析和攻击可行性评估的仓库和实践，例如:
1．归纳法 - 例如：通过知识重组
2．演绎法 - 例如：用攻击树分析
3．数值分析方法，像常见的漏洞评分系统
4．b) 1-3的组合
c）加权和评分实践：
1．比例和评分方法
2．加权标准，如热图变体的选择
3．网络安全保证等级(CAL)的使用情况。
d）过程中的风险分解：
1．专家委员会
2．包含的角色，RASIC
3．相关的相关项唯一标识和可追溯性
e）相关的内部和外部接口：
1．当前和历史数据评估的来源和实践
2．监控的标准
3．已接受风险的验证
4．分包商和承包商的合作
f）纠正措施管理：
1．项目的内部依赖
2．项目的外部依赖
适当的实践文档可以在文本、工具、图表、脚本、流程图以及培训材料中建立。
建议和规则：
[MAN.7.RL.4]：If the practices do not include aspects a–d, the indicator BP2 cannot be rated F.
解读：如果实践不包括a-d方面，则指标BP2不能被评为F。
STRIDE威胁建模是由微软提出的一种威胁建模方法，该方法将威胁类型Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）和Elevation of Privilege（权限提升）。这六种威胁的首字母缩写既是STRIDE。STRIDE威胁模型几乎可以覆盖目前绝大部分安全问题，也是业内的常用方法。
[MAN.7.RC.2]：If the use of practices is obvious by the implementation in a tool but not explicitly documented, this should not be used to downrate the indicator BP2 to N or P.
解读：如果实践的使用很明显是在工具中实施的，但是没有明确的文档记录，则这不应该被用来将BP2降为N或P。
[MAN.7.RL.5]：If the practices do not address interfaces (aspects e and f) between multisite organizations or projects, subprojects, management systems, and/or groups in cases of corresponding complex projects, the indicator BP2 cannot be rated higher than P.
解读：如果实践没有解决组织或项目的多点办公、子项目、管理系统、和/或复杂项目相对应的多个组之间的接口，则BP2的评分不能高于P。
相关内容：
BP2：Defined cybersecurity risk management practices 已定义的网络安全风险管理实践
Output WP 08-19: Risk management plan 风险管理计划
3) 优先级Prioritization
在包括许多资产和利益相关者的复杂项目中，潜在风险的识别可以迅速导致大量的风险。因此，风险分析和评估可能需要大量的时间和精力。
因此，网络安全风险分析的工作分解应首先优先考虑相关损害可能造成的影响。这个初始的优先级(BP4)确保了首先分析与最高潜在损害相关的风险。
在网络安全风险管理过程的后期阶段，进一步的分组、排序和分类是必要的，以支持优先级排序，并可能覆盖或与BP4的结果相矛盾。例如，一个潜在的风险可能会造成严重的影响，并且最初是高优先级的，但可以很容易地通过建立工作区来避免，从而在以后的评估阶段成为低优先级的。
建议和规则：
[MAN.7.RC.3]：If initial risk prioritization for impact is not created before risk analysis – despite this being relevant to the project – BP4 should not be rated F.
解读：如果在风险分析之前没有对影响进行初步的风险优先排序 - 尽管这与项目相关 - 则BP4不应评为F。
[MAN.7.RC.4]：If initial prioritization of potential risks is not in line with grouping, sorting, or categorization in later process steps, the indicator BP4 should not be downrated.
解读：如果潜在风险的初始优先级与后续流程步骤中的分组、排序或分类不一致，则不应对BP4扣分。
资产识别完成后的核心工作：是基于会对资产造成危害和威胁的场景进行识别，然后对识别的危害场景和威胁场景进行风险的评估以决定处理的优先级。
而风险优先级的判断往往来自这些危害和威胁的影响评级结果，每个危害场景对SPFO四个维度可能造成的影响，基于一定的判断标准，分别对SPFO进行分级，进而确定相关威胁的等级。
相关内容：
BP4: Prioritize potential risks initially for damage 首先优先考虑损害的潜在风险
Output WP 08-19: Risk management plan风险管理计划
Output WP 14-08: Tracking system 跟踪系统
4) 潜在风险分析和风险确定Potential risk analysis and risk determination
风险分析是选择合适的处理方案和所有后续行动的基础。网络安全风险可能会发生变化。这使得风险假设和约束的文档化是必要的。风险分析应包括可能引发识别和利用风险的一系列行动，以及对每个行动单个概率的评估。
这种对行动序列的分析被称为网络安全风险管理的攻击路径分析。
攻击路径分析的形式为:
a) 攻击可能性分析：
专业知识、相关项知识、机会窗口、装备和运行时间分别进行评估，并最终进行可行性级别汇总。
b) 攻击向量分析：
描述四个依赖于逻辑和物理距离的漏洞的可行性评级， 攻击向量分析也可用于评估网络安全保证级别(CAL)
c) 数值分析：
考虑a和b的几个方面，有定义的，特定于模型的数字和计算算法
d) a-c的裁剪组合。
攻击路径分析可以由研究、经验和历史数据来支持，以评估和验证攻击的易用性。 这样的情报数据可以来自:
e) 汽车网络安全管理系统(ACSMS) - 例如，以前的项目、披露计划和共享信息的漏洞数据。
f) 外部情报服务提供者 - 例如，测试中心
g) 信息共享和分析中心(ISACS)
h) 模拟
所有产生风险的攻击路径都要考虑在内。 在风险分析中，进一步的攻击路径可能会导致其他(甚至未知的)威胁和损害场景。 分析应确保对这些风险进行类似的考虑，包括必要时合理的优先排序。
威胁场景所产生的网络安全风险可以用不同的级别来表示，并应源于网络安全风险确定——在项目背景下对影响和相关攻击可行性的评估。
建议和规则：
[MAN.7.RL.6]：If none of the described approaches (aspects a–d) for attack path analysis is observable in the assessed project, PA 1.1 shall be downrated.
解读：如果在所评估的项目中，观察到攻击路径分析没有应用上述方法(a-d方面)，则应降低PA1.1的评级。
[MAN.7.RL.7]：If the cybersecurity risk analysis does not evaluate the ease of exploitation, the indicator BP5 shall be downrated.
解读：如果网络安全风险分析未评估攻击容易性，应对BP5扣分。
上述内容主要是对可能引发威胁场景的攻击路径进行分析的相关要求。
攻击路径识别后，需要对每一种攻击路径的攻击可行性进行分析。当一个攻击路径的实施所需条件越难获取，那么攻击的可行性就会越低。对于攻击所需的各类条件会引用到一些固定的模型，典型的模型如下：
基于此模型进行攻击可行性评级的范例如下：
基于上述所有内容中讲到的资产识别、威胁场景识别、影响评级、攻击路径分析和攻击可行性评估，都是为了最终分析出对资产可能造成威胁场景的风险值。常用确定风险值的方法是风险矩阵，如下图所示：
基于此风险矩阵进行风险值的确定，见下图所示：
相关内容：
BP5: Analyze potential risks and evaluate risks 分析潜在风险并评估风险
Output WP 08-19: Risk management plan 风险管理计划
Output WP 14-08: Tracking system跟踪系统
Output WP 14-51: Cybersecurity scenario register网络安全场景登记册
Output WP 15-08: Risk analysis report风险分析报告
5) 定义风险处理方案Define risk treatment option
对于每种风险或一组风险，应选择风险处理选项（风险处理决策）：
a) 避免风险 – 例如，使攻击路径变得不可能。
b) 降低风险 – 例如，降低了攻击路径的可行性。
c) 转移（分担）风险 – 例如，分配具有更高规避或降低风险知识的资源。
d) 接受风险 – 例如，如果风险不能再降低，则保持不变
风险处理方案可以是连续的和重叠的，因为一个风险可能有多个攻击路径，其中每一个都在项目的不同阶段被单独处理。 一个攻击路径的元素可以有不同的所有者和接口，需要不同的处理方案。
在风险处理决策过程中，应包括对风险选项可追溯性的限制。例如，使用平台解决方案、免费和开源软件或提供的软件可能会导致限制。 此外，这些限制可能来自于各自的时间限制，例如，更新报告的长周期。
所有风险都需要一致的理由来重新审视和评估风险。网络安全声明（c和d方面）也不例外。
相关内容：
BP6: Define risk treatment option 定义风险处理方案
Output WP 07-07: Risk measure 风险措施
Output WP 08-14: Recovery plan恢复计划
Output WP 08-19: Risk management plan 风险管理计划
Output WP 13-20: Risk action request 风险行动请求
Output WP 14-08: Tracking system 跟踪系统
Output WP 15-08: Risk analysis report风险分析报告
Output WP 15-09: Risk status report 风险状态报告
6) 网络安全风险的监控和控制Monitoring and control of cybersecurity risks
网络安全风险面临突发和频繁的变化，对管理和控制构成挑战。 因此，网络安全风险管理需要识别相关变化并进行相应监控。
风险监控包括：
持续监控新的威胁和攻击路径。
持续监测攻击路径的变化 - 例如，自上次风险分析以来，已公布的攻击证明其可行性已增加。
持续监控已接受的风险（网络安全申明），同时提供未缓解风险的隐性验证。
基于对现成组件（例如，免费和开源软件）集成的分析进行重新验证。
识别在分析和评估网络安全风险时所考虑的假设和约束的变化
识别涉及过时的技术、价值、相关项和资产的风险。
在项目实施、概念、验证和确认过程中条件和结果的变化。
相关接口的条件和结果的变化，如转移风险。
与汽车网络安全管理系统的主动交流，如5.1.4小节e-h中所述的情报数据进行交流，可能为监控的有效性提供进一步的证据。
应采取适当的纠正措施，以保持网络安全风险评估和处理的有效性，并随时适应变化的情况。
监控或跟踪系统可以支持推（事件驱动）或拉（轮询）原则。需要为轮询系统建立适当的监控周期。
建议和规则：
[MAN.7.RL.8]：If monitoring does not assess fulfillment of activities (i.e., risk action request), the indicator BP7 must not be rated higher than L.
解读：如果监控未评估活动的完成情况（即风险行动请求），则BP7的评分不得高于L。
[MAN.7.RC.5]：If action items or corrective actions are not properly tracked, the corresponding indicators BP7 and BP8 should be downrated.
解读：如果未正确跟踪行动项或纠正行动，则应下调相应的指标BP7和BP8。
[MAN.7.RC.6]：If the confirmation of a successful implementation of a risk action request is not based on documented criteria, the indicator BP7 should be downrated.
解读：如果风险行动请求成功实施的确认未基于文档化的标准，则应对BP7扣分。
相关内容：
BP7: Monitor risks监控风险
BP8: Take corrective action 采取纠正措施
Output WP 08-14: Recovery plan恢复计划
Output WP 08-19: Risk management plan 风险管理计划
Output WP 13-20: Risk action request风险行动请求
Output WP 14-08: Tracking system跟踪系统
Output WP 15-09: Risk status report 风险状态报告
评级一致性
下图显示了MAN.7各BP之间的关系：
这些关系被用作以下章节中定义的评级规则和建议的基础.
MAN.7内的评级一致性Rating consistency within MAN.7：
BP1：Determine cybersecurity risk management scope 确定网络安全风险管理范围
[MAN.7.RC.7]：If the determination of the cybersecurity risk management scope (BP1) is incomplete, then the indicator BP2 should be downrated.
解读：如果网络安全风险管理范围（BP1）的确定不完整，则BP2应被扣分。
[MAN.7.RL.9]：If the determination of the cybersecurity risk management scope (BP1) is downrated, then the indicator BP3 and BP5 shall be downrated as well.
解读：如果网络安全风险管理范围(BP1)的确定被扣分，则指标BP3和BP5也应被扣分。
BP2：Defined cybersecurity risk management practices 已定义的网络安全风险管理实践
[MAN.7.RL.10]：If the practice-related activities are not performed according to the defined practices (BP2), the indicators BP3, BP4, BP5, BP6, BP7 and BP8 shall be downrated, respectively.
解读：如果与实践相关的活动没有按照规定的实践(BP2)执行，则应分别对BP3、BP4、BP5、BP6、BP7和BP8进行扣分。
BP5：Analyze potential risks and evaluate risks 分析潜在风险和评估风险
[MAN.7.RC.8]：If the analysis of potential risks and evaluation of risks (BP5) is rated P or N, the indicator BP6 should be downrated.
解读：如果潜在风险分析和风险评估（BP5）被评为P或N，则应对BP6扣分。
关于亚远景科技
上海亚远景信息科技有限公司是国内汽车行业咨询及评估领军机构之一，深耕于汽车ASPICE、ISO26262功能安全、ISO21434网络安全领域，拥有10年以上的行业经验，专精于咨询、评估及培训服务，广受全球车厂及供应商赞誉，客户好评率行业领先。坚持以“探索、研发、融合”引领创新发展，秉持“用心服务、专业技术、合作发展”的理念，不断以新技术新模式为客户提供更有效更敏捷的服务。
