青骥信息安全原创技术系列专题
2021年,VDA发布了网络安全ASPICE的黄皮书,书中列出了网络安全与ASPICE的几个重要群组,简要截图如下:
ASPICE全称叫Automotive Software Process Improvement and Capacity Determination(汽车软件过程改进及能力评定),是汽车行业用于评价软件开发团队的研发能力水平的模型框架。最初由欧洲20多家主要汽车制造商共同制定,于2005年发布,目的是为了指导汽车零部件研发厂商的软件开发流程,从而改善车载软件的质量。
WP.29是CSMS体系简称,CSMS是联合国UN ECE. R155体系中的重点,此章节与ISO 21434中部分条例存在条款重合,二者可结合起来进行。
而在ASPICE之前,我们还有CMMI以及INCOSE等系统流程体系,在如下文章中,我们将最开始介绍系统流程体系,之后介绍网络安全ISO21434对应流程章节与WP.29的绑定,最后对ASPICE和ISO21434二者可能存在的覆盖进行探讨。
咱们从CMMI开始讲起。
CMM全称是Capability Maturity Model,是由卡耐基梅隆大学(CMU)的软件工程研究所(SEI)于1986年在美国防部(DOD)的赞助下开发的一个用于评价企业研发能力水平的模型,被广泛用于软件流程改善和软件研发团队能力评价。
ASPICE模型最初是在CMM基础上发展起来的,最初的ASPICE模型几乎与CMM完全一致,评估结果可直接转换、CMMI评估师也可以直接获得ASPICE审核员资质(近年已改变)。
其中,如下16个群组被称为核心群组:
ACQ.4 Supplier Monitoring
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Test
SYS.5 System Qualification Test
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Integration and Integration Test
SWE.6 Software Qualification Test
SUP.1 Quality Assurance
SUP.8 Configuration Management
SUP.9 Problem Resolution Management
SUP.10 Change Request Management
MAN.3 Project Management
现代很多企业都是已经完成了CMMI,但是若干企业尚未切换到ASPICE,特别是日本企业、台湾企业等之前主要出口导向是美国的,是以CMMI为基础替换到现今的,如下列出了二者之间的转化:(如下部分英文为直接摘录)
Gap analysis | % | % | |
Acquisition Process Group | Contract Agreement | 57.1 | 40 |
Supplier Monitoring | 100 | ||
Technical Requirements | 70 | ||
Legal and Administrative Requirement | 0 | ||
Project Requirements | 33.3 | ||
Request for Proposals | 0 | ||
Supplier Qualification | 60 | ||
Supply Process Group | Supplier Tendering | 0 | 28.6 |
Product Release | 46.2 | ||
System Engineering Process Group | Requirements Elicitation | 66.7 | 65.8 |
System requirements analysis | 62.5 | ||
system arc design | 75 | ||
system integration and integration test | 55.6 | ||
system qualification test | 71.4 | ||
Software Engineering Process Group | software requirements analysis | 62.5 | 64.6 |
software arc design | 66.7 | ||
software detailed design and unit construction | 62.5 | ||
software unit verification | 71.4 | ||
software integration and integration test | 55.6 | ||
software qualification test | 71.4 | ||
Supporting Process Group | quality assurance | 100 | 66 |
Verification | 80 | ||
Joint review | 50 | ||
Documentation | 12.5 | ||
Configuration management | 88.9 | ||
Problem resolution management | 55.6 | ||
Change request management | 87.5 | ||
Management process group | Project management | 90 | 89.3 |
Risk management | 100 | ||
measurement | 81.8 | ||
Reuse process group | Reuse program management | 37.5 | 37.5 |
Process Improvement Process Group | process improvement | 87.5 | 87.5 |
Total | 59.1% |
CMMI | ASPICE | |
CMMI | 100% | 39.5% |
ASPICE | 59.1% | 100% |
网络安全ISO 21434标准中,关于流程或者可能与ASPICE相关的章节如下:
UNECE – WP.29 CSMS需求 | ISO/SAE 21434 流程需求 |
(A) 制造商组织内用于管理网络安全的流程; | 第 5 章和第 6 章定义了在制造商组织中管理网络安全所需的流程。例如: - 5.4.1 网络安全治理 - 5.4.2 网络安全文化 - 6.4.2 网络安全计划 - 6.4.7 网络安全案例 |
(B) 用于识别车辆类型风险的流程:和 (C) 用于评估、分类和处理所查明风险的流程: | 第 8 章定义了风险评估方法,包括: - 8.3 资产识别 - 8.4 威胁场景识别 - 8.5 影响等级 - 8.6 攻击路径分析 - 8.7 攻击可行性 - 8.8 风险确定 - 8.9 风险处理决定 |
(D) 已建立的流程,以验证所查明的风险是否得到适当管理:和 (E) 在整个开发和生产阶段用于测试系统安全性的过程: | ISO/SAE-21434 第 10 章建议开展各种验证活动,以确认网络安全设计的实施: -10.4.2.集成和验证 - 10.4.3.软件开发的具体要求 |
(F) 用于确保风险评估保持最新状态的流程: | |
(G) 用于监测、检测和响应对车辆类型的网络攻击的流程; | 第 7 章定义了持续网络安全活动的必要性,例如: - 7.3 网络安全监控 - 7.4 网络安全事件评估 |
(H) 用于识别新的和不断发展的网络威胁和车辆类型的漏洞的流程; | 第 7 章定义了持续网络安全活动的必要性,例如: - 7.5 漏洞分析 -7.6 漏洞管理 |
(I)用于对新的和不断变化的网络威胁和漏洞作出适当反应的进程 | 第 13 章定义了操作和维护流程,例如: - 13.3 网络安全事件响应 |
网络安全ISO 21434,主要群组如下:
其新增加的群组,可以覆盖如下ISO/SAE 21434的相关章节:
- 5.4.3 Cybersecurity risk management
- 6.4.1 Cybersecurity Responsibilities and Their Assignment
- 6.4.2 Cybersecurity Planning
- 6.4.3 Tailoring of the Cybersecurity Activities
- 6.4.4 Reuse
- 6.4.5 Component Out of Context
- 6.4.6 Off-the-Shelf Component
- 6.4.7 Cybersecurity Case
- 6.4.8 Cybersecurity Assessment
- 6.4.9 Release for Post-Development
- 15.4.2 Request for Quotation
- 15.4.3 Alignment of Responsibilities
即为下图:
从第二、第三,我们可以总结出来,ISO/SAE 21434中的内容,可以被CSMS和网络安全ASPICE覆盖,章节罗列如下:
ISO/SAE 21434对应章节 | 可以被覆盖么? |
5.4.1 网络安全治理 | CSMS |
5.4.2 网络安全文化 | CSMS |
5.4.3网络安全风险管理 | 网络安全ASPICE |
6.4.1网络安全责任及其分配 | 网络安全ASPICE |
6.4.2 网络安全计划 | CSMS及网络安全ASPICE |
6.4.3网络安全活动的定制 | 网络安全ASPICE |
6.4.4 重用 | 网络安全ASPICE |
6.4.5 部件Out of Context | 网络安全ASPICE |
6.4.6现成组件 | 网络安全ASPICE |
6.4.7网络安全档案 | 网络安全ASPICE CSMS |
6.4.8网络安全评估 | 网络安全ASPICE |
6.4.9 量产发布 | 网络安全ASPICE |
- 7.3 网络安全监控 | CSMS |
7.4 网络安全事件评估 | CSMS |
7.5 漏洞分析 | CSMS |
7.6 漏洞管理 | CSMS |
8.3 资产识别 | CSMS |
- 8.4 威胁场景识别 | CSMS |
- 8.5 影响等级 | CSMS |
- 8.6 攻击路径分析 | CSMS |
- 8.7 攻击可行性 | CSMS |
- 8.8 风险确定 | CSMS |
- 8.9 风险处理决定 | CSMS |
-10.4.2.集成和验证 | CSMS |
- 10.4.3.软件开发的具体要求 | CSMS |
13.3 网络安全事件响应 | CSMS |
- 15.4.2 报价 | 网络安全ASPICE |
- 15.4.3职责协调 | 网络安全ASPICE |
如上,我们可以得到如下的ISO/SAE 21434的被覆盖率可以如下所示:
ISO/SAE 21434 Chapter | Can be covered by CSMS or ASPICE or not ? | Coverage Ratio |
Overall Cybersecurity Management 5.4.1~5.4.8 | Yes | 37.5% |
Project Dependent Cybersecurity Management 6.4.1~6.4.9 | Yes | 100% |
Continuous Cybersecurity Activities 7.3~7.6 | Yes | 100% |
Risk Assessment Methods 8.3~8.9 | Yes | 100% |
Concept phase | NA | 0% |
Product Development 10.4.1~10.4.3 | Yes | 66% |
Cybersecurity Validation | NA | 0% |
Production | NA | 0% |
Operations and Maintenance 13.3~13.4 | Yes | 50% |
Decommissioning | NA | 0% |
Distributed Cybersecurity Activities 15.4.1~15.4.3 | Yes | 66% |
Overall | 47.3% |
以上,为本次全部内容,非常感谢各位的阅读。
参考文档:
-Hardware ASPICE and ASPICE VS CMMI
- Mapping WP.29 CSMS Requirements to the ISO_SAE 21434 Standard and Cybellum
END
已完成
数据加载中