ISO 21434汽车网络安全标准深度解读系列（六）：概念阶段网络安全工程

前言

概念阶段是汽车网络安全工程的起点，在这个阶段确定的网络安全目标和要求将指导整个产品开发过程。本文将深入解读ISO 21434标准第9条"概念阶段"，详细阐述如何在概念阶段建立坚实的网络安全基础。

1. 概念阶段概述

1.1 概念阶段的定位

概念阶段在ISO 21434标准中的位置：

ISO 21434生命周期：
​
组织管理（第5条）
    ↓
项目管理（第6条）
    ↓
概念阶段（第9条）← 本文重点
    ↓
产品开发（第10条）
    ↓
网络安全验证（第11条）
    ↓
生产/运营/维护（第12-13条）

1.2 概念阶段特点

1.2.1 车辆级视角

概念阶段涉及对车辆级功能的考虑：

• 功能层面：关注车辆实现的功能

• 系统层面：考虑E/E系统架构

• 环境层面：分析运行环境特征

• 风险层面：识别网络安全风险

1.2.2 高层抽象

概念阶段的分析具有高层抽象特征：

• 概念性描述：基于概念设计进行分析

• 假设性分析：可能基于假设进行分析

• 迭代性完善：随着设计深入不断完善

• 指导性作用：为后续阶段提供指导

1.3 核心目标

概念阶段的三大目标：

1. 项目定义：在网络安全背景下定义项目、运行环境及其相互作用

2. 目标确定：明确网络安全目标和网络安全声明

3. 概念规范：指定网络安全概念以实现网络安全目标

2. 项目定义

2.1 项目定义概述

2.1.1 定义目的

项目定义为后续网络安全活动提供基础：

• 分析基础：为威胁分析提供分析对象

• 边界界定：明确网络安全分析的边界

• 环境描述：描述项目的运行环境

• 接口识别：识别与外部的接口

2.1.2 定义内容

项目定义包含三个核心要素：

• 项目边界：区分项目与运行环境

• 项目功能：描述项目实现的功能

• 初步架构：项目的初步架构设计

2.2 项目边界定义

2.2.1 边界要求（RQ-09-01a）

应确定项目边界，项目边界将项目与它的运行环境区分开来。

2.2.2 边界描述内容

项目边界描述应包括：

• 物理边界：硬件组件的物理边界

• 逻辑边界：软件功能的逻辑边界

• 通信边界：与外部系统的通信接口

• 数据边界：数据流的输入输出边界

2.2.3 边界定义示例

项目边界示例：
​
项目：自动驾驶控制系统
物理边界：
├── 包含：感知ECU、决策ECU、执行ECU
├── 接口：CAN总线、以太网、传感器接口
└── 排除：发动机ECU、制动ECU（作为执行对象）
​
逻辑边界：
├── 包含：环境感知、路径规划、车辆控制算法
├── 接口：车辆状态信息、控制指令接口
└── 排除：基础车辆功能、信息娱乐功能
​
通信边界：
├── 内部：ECU间CAN/以太网通信
├── 输入：传感器数据、V2X信息、云端数据
└── 输出：执行指令、状态信息、日志数据

2.3 项目功能定义

2.3.1 功能要求（RQ-09-01b）

应确定项目功能，描述项目在生命周期各阶段的预期行为。

2.3.2 功能描述维度

项目功能描述应涵盖：

1. 车辆功能：项目实现的车辆级功能

2. 生命周期功能：各生命周期阶段的功能

3. 运行模式：不同运行模式下的功能

4. 异常处理：异常情况下的功能行为

2.3.3 功能描述示例

功能描述示例：
​
主要功能：
├── 环境感知功能
│   ├── 多传感器数据融合
│   ├── 目标识别与跟踪
│   └── 环境建模
├── 路径规划功能
│   ├── 全局路径规划
│   ├── 局部路径规划
│   └── 动态避障
└── 车辆控制功能
    ├── 纵向控制（加速/制动）
    ├── 横向控制（转向）
    └── 安全监控
​
生命周期功能：
├── 开发阶段：测试模式、标定功能
├── 生产阶段：EOL测试、参数配置
├── 运营阶段：正常驾驶、OTA更新
└── 维护阶段：故障诊断、数据导出

2.4 初步架构定义

2.4.1 架构要求（RQ-09-01c）

应确定初步架构，描述可以包括识别项目的组成部分及其连接。

2.4.2 架构描述内容

初步架构描述包括：

• 组件识别：项目内部的主要组件

• 连接关系：组件间的连接关系

• 外部接口：与外部系统的接口

• 数据流：主要的数据流向

2.4.3 架构描述方法

架构描述方法：
​
1. 分层架构描述
   应用层：业务逻辑、算法实现
   中间层：通信协议、数据处理
   硬件层：ECU、传感器、执行器
​
2. 功能模块描述
   感知模块：传感器数据处理
   决策模块：路径规划、行为决策
   控制模块：车辆控制执行
​
3. 通信架构描述
   内部通信：ECU间通信协议
   外部通信：V2X、云端通信
   诊断通信：OBD、以太网诊断

2.5 运行环境描述

2.5.1 环境要求（RQ-09-02）

应描述与网络安全有关的项目操作环境信息。

2.5.2 环境描述内容

运行环境描述应包括：

• 物理环境：车辆使用的物理环境

• 网络环境：连接的网络环境

• 用户环境：用户使用环境

• 服务环境：相关服务环境

2.5.3 环境分析示例

运行环境分析：
​
物理环境：
├── 使用场景：城市道路、高速公路、停车场
├── 环境条件：温度、湿度、振动、电磁干扰
└── 物理安全：车辆停放、维修环境
​
网络环境：
├── 蜂窝网络：4G/5G网络连接
├── Wi-Fi网络：热点连接、家庭网络
├── V2X通信：车车通信、车路通信
└── 近场通信：蓝牙、NFC
​
用户环境：
├── 驾驶员：技能水平、安全意识
├── 乘客：使用习惯、隐私需求
└── 维修人员：专业水平、工具使用
​
服务环境：
├── 云端服务：地图服务、交通信息
├── OEM服务：OTA更新、远程诊断
└── 第三方服务：应用商店、内容服务

3. 网络安全目标确定

3.1 TARA分析执行

3.1.1 分析要求（RQ-09-03）

应根据项目定义进行分析，包括：

• 资产识别（按照15.3）

• 威胁情景识别（按照15.4）

• 影响等级评估（按照15.5）

• 攻击路径分析（按照15.6）

• 攻击可行性评级（按照15.7）

• 风险值确定（按照15.8）

3.1.2 概念阶段TARA特点

概念阶段的TARA分析具有以下特点：

• 高层抽象：基于概念设计进行分析

• 假设驱动：可能基于假设进行分析

• 迭代完善：随着设计深入不断完善

• 指导作用：为详细设计提供指导

3.2 风险处理决策

3.2.1 决策要求（RQ-09-04）

根据TARA分析结果，应按照15.9的规定为每种威胁情况确定风险处理方案。

3.2.2 处理方案类型

风险处理方案包括：

• 风险规避：通过消除风险源规避风险

• 风险降低：通过控制措施降低风险

• 风险分担：通过合同等方式分担风险

• 风险接受：接受残留风险

3.2.3 处理决策示例

风险处理决策示例：
​
威胁情景：远程攻击导致车辆控制权被劫持
风险等级：5（严重）
处理决策：风险降低
具体措施：
├── 网络隔离：关键控制网络与信息娱乐网络隔离
├── 身份认证：实施强身份认证机制
├── 通信加密：关键通信数据加密传输
└── 入侵检测：部署网络入侵检测系统
​
威胁情景：物理接口攻击
风险等级：3（中等）
处理决策：风险降低+风险接受
具体措施：
├── 访问控制：限制物理接口访问
├── 监控机制：记录物理接口访问
└── 残留风险：接受专业攻击者的高级攻击风险

3.3 网络安全目标制定

3.3.1 目标要求（RQ-09-05）

如果威胁情景的风险处理决定包括减少风险，应规定相应的网络安全目标。

3.3.2 目标特征

网络安全目标具有以下特征：

• 概念级要求：高层次的安全要求

• 威胁导向：针对特定威胁情景

• 保护导向：保护资产免受威胁

• 可验证性：能够验证是否实现

3.3.3 目标制定示例

网络安全目标示例：
​
目标ID：CSG-001
威胁情景：远程网络攻击导致车辆控制功能被恶意操控
保护资产：车辆控制功能的完整性和可用性
安全目标：车辆控制功能应能够抵御来自远程网络的恶意攻击，
         确保只有经过授权和验证的控制指令才能被执行
​
目标ID：CSG-002  
威胁情景：个人数据未经授权访问导致隐私泄露
保护资产：用户个人数据的机密性
安全目标：用户个人数据应受到适当保护，防止未经授权的访问、
         使用或泄露
​
目标ID：CSG-003
威胁情景：诊断接口攻击导致系统配置被篡改
保护资产：系统配置数据的完整性
安全目标：系统配置数据应受到保护，防止通过诊断接口
         进行的未授权修改

3.4 网络安全声明制定

3.4.1 声明要求（RQ-09-06）

如果威胁情景的风险处理决定包括分担风险或保留风险，应规定相应的网络安全声明。

3.4.2 声明内容

网络安全声明应包括：

• 风险描述：被接受或分担的风险

• 接受理由：为什么认为风险可以接受

• 前提条件：风险接受的前提条件

• 监控要求：对风险的持续监控要求

3.4.3 声明示例

网络安全声明示例：
​
声明ID：CSC-001
风险描述：专业攻击者通过高级持续威胁（APT）攻击
         可能获得系统访问权限
接受理由：此类攻击需要极高的技术水平和资源投入，
         攻击概率极低，且有其他安全措施提供保护
前提条件：
├── 实施多层防护措施
├── 建立安全监控机制  
├── 制定应急响应预案
└── 定期进行安全评估
监控要求：持续监控相关威胁情报，定期评估攻击技术发展
​
声明ID：CSC-002
风险描述：供应商组件可能存在未知漏洞
接受理由：供应商具有良好的安全记录，且提供安全保证
前提条件：
├── 供应商通过安全认证
├── 建立漏洞管理流程
├── 实施定期安全评估
└── 制定应急响应机制
监控要求：持续监控供应商安全公告，及时应用安全补丁

3.5 验证活动

3.5.1 验证要求（RQ-09-07）

应进行验证以确认：

• TARA结果的正确性和完整性

• 风险处理决定的完整性、正确性和一致性

• 网络安全目标和声明的完整性、正确性和一致性

• 所有网络安全目标和声明的一致性

3.5.2 验证方法

验证方法：

1. 文档审查
   - 检查分析的完整性
   - 验证逻辑的一致性
   - 确认要求的可追溯性

2. 同行评审
   - 技术专家评审
   - 跨领域专家参与
   - 独立第三方评审

3. 形式化验证
   - 模型检查
   - 定理证明
   - 一致性检查

4. 原型验证
   - 概念原型构建
   - 关键场景验证
   - 假设有效性验证

4. 网络安全概念

4.1 概念制定概述

4.1.1 概念目的

网络安全概念的目的是：

• 目标实现：描述如何实现网络安全目标

• 要求分配：将高层目标分解为具体要求

• 设计指导：为详细设计提供指导

• 验证基础：为验证活动提供基础

4.1.2 概念组成

网络安全概念由以下部分组成：

• 网络安全要求：分配给项目的具体要求

• 环境要求：对运行环境的要求

• 控制措施描述：技术和操作性控制措施

• 实现理由：实现网络安全目标的理由

4.2 网络安全要求制定

4.2.1 要求制定（RQ-09-08）

应描述技术和/或操作性网络安全控制措施及其相互作用，以实现网络安全目标。

4.2.2 控制措施类型

网络安全控制措施包括：

控制措施分类：

技术控制措施：
├── 访问控制：身份认证、授权管理
├── 通信安全：加密传输、安全协议
├── 数据保护：数据加密、完整性保护
├── 系统安全：安全启动、代码签名
└── 监控检测：入侵检测、异常监控

操作控制措施：
├── 安全管理：安全策略、管理程序
├── 人员安全：培训教育、权限管理
├── 物理安全：设备保护、环境控制
├── 应急响应：事件处理、恢复程序
└── 持续监控：安全监控、定期评估

4.2.3 要求制定示例

网络安全要求示例：

要求ID：CSR-001
网络安全目标：CSG-001（车辆控制功能保护）
控制措施：网络隔离 + 身份认证
具体要求：
├── 车辆控制网络应与信息娱乐网络物理隔离
├── 跨网络通信应通过安全网关进行
├── 所有控制指令应经过身份认证和授权验证
└── 异常通信应被检测和阻断

要求ID：CSR-002
网络安全目标：CSG-002（个人数据保护）
控制措施：数据加密 + 访问控制
具体要求：
├── 个人数据应采用强加密算法加密存储
├── 数据访问应实施基于角色的访问控制
├── 数据传输应采用端到端加密
└── 数据访问应记录审计日志

4.3 要求分配

4.3.1 分配要求（RQ-09-09、RQ-09-10）

应根据控制措施描述，为网络安全目标确定项目的网络安全要求和对运行环境的要求，并将网络安全要求分配给项目及其组成部分。

4.3.2 分配原则

要求分配应遵循以下原则：

• 功能相关性：要求分配给相关功能组件

• 技术可行性：考虑技术实现的可行性

• 成本效益：平衡安全效果和实现成本

• 维护便利性：考虑后续维护的便利性

4.3.3 分配示例

要求分配示例：

项目：自动驾驶控制系统

组件级分配：
感知ECU：
├── CSR-003：传感器数据完整性验证
├── CSR-004：传感器通信加密
└── CSR-005：异常数据检测和处理

决策ECU：
├── CSR-006：算法执行环境隔离
├── CSR-007：决策数据完整性保护
└── CSR-008：安全状态监控

执行ECU：
├── CSR-009：控制指令验证
├── CSR-010：执行状态反馈
└── CSR-011：安全模式切换

环境要求：
运行环境：
├── ENV-001：车辆应停放在安全环境中
├── ENV-002：维修应在授权服务中心进行
└── ENV-003：软件更新应通过安全渠道

用户环境：
├── ENV-004：用户应接受安全使用培训
├── ENV-005：异常情况应及时报告
└── ENV-006：个人数据使用应获得授权

4.4 概念验证

4.4.1 验证要求（RQ-09-11）

应验证网络安全要求和分配的结果，以确认：

• 与网络安全目标的完整性、正确性和一致性

• 在网络安全声明方面的一致性

4.4.2 验证方法

概念验证方法：

1. 追溯性验证
   - 要求到目标的追溯
   - 目标到威胁的追溯
   - 威胁到资产的追溯

2. 完整性验证
   - 目标覆盖完整性
   - 要求覆盖完整性
   - 控制措施完整性

3. 一致性验证
   - 要求间一致性
   - 要求与目标一致性
   - 要求与声明一致性

4. 可行性验证
   - 技术可行性
   - 经济可行性
   - 时间可行性

5. 工作产品管理

5.1 必需工作产品

概念阶段应产生以下工作产品：

1. WP-09-01：项目定义

2. WP-09-02：TARA分析结果

3. WP-09-03：网络安全目标

4. WP-09-04：网络安全声明

5. WP-09-05：网络安全目标的验证报告

6. WP-09-06：网络安全概念

7. WP-09-07：网络安全概念的验证报告

5.2 工作产品质量

5.2.1 质量要求

每个工作产品应满足：

• 完整性：涵盖所有必需内容

• 准确性：信息准确可靠

• 一致性：内部逻辑一致

• 可追溯性：能够追溯到源需求

• 可理解性：清晰易懂

5.2.2 质量保证措施

质量保证措施：

过程质量：
├── 标准化流程
├── 检查点设置
├── 评审机制
└── 持续改进

产品质量：
├── 模板标准化
├── 内容完整性检查
├── 逻辑一致性验证
└── 可追溯性确认

人员质量：
├── 能力要求
├── 培训认证
├── 经验积累
└── 知识共享

6. 实施指导

6.1 实施策略

6.1.1 分阶段实施

概念阶段实施计划：

准备阶段（1周）：
- 团队组建
- 工具准备
- 培训实施

分析阶段（2-3周）：
- 项目定义
- TARA分析
- 初步评估

设计阶段（2-3周）：
- 目标制定
- 概念设计
- 要求分配

验证阶段（1-2周）：
- 内容验证
- 同行评审
- 管理评审

完善阶段（1周）：
- 问题修正
- 文档完善
- 基线确立

6.1.2 关键成功因素

概念阶段成功的关键因素：

• 高层支持：获得管理层的支持和资源保障

• 专业团队：配备具备专业能力的团队

• 充分分析：进行充分深入的威胁和风险分析

• 有效沟通：与相关方保持有效沟通

• 质量控制：实施严格的质量控制措施

6.2 常见挑战

6.2.1 主要挑战

概念阶段面临的主要挑战：

• 信息不足：概念阶段信息有限，分析困难

• 假设依赖：分析结果依赖假设，可能不准确

• 经验缺乏：团队缺乏相关经验

• 时间压力：项目时间紧张，分析不充分

• 复杂性高：现代汽车系统复杂，分析困难

6.2.2 应对策略

挑战应对策略：

信息不足：
├── 利用类似项目经验
├── 参考行业最佳实践
├── 咨询领域专家
└── 建立合理假设

假设依赖：
├── 明确记录假设
├── 定期验证假设
├── 建立假设管理机制
└── 制定应急预案

经验缺乏：
├── 加强团队培训
├── 引入外部专家
├── 参考标准指南
└── 建立知识库

时间压力：
├── 合理规划时间
├── 并行开展活动
├── 使用工具支持
└── 分阶段实施

复杂性高：
├── 分层分解分析
├── 使用建模工具
├── 采用标准方法
└── 加强团队协作

7. 最佳实践

7.1 分析最佳实践

7.1.1 TARA分析实践

TARA分析最佳实践：

1. 系统性方法
   - 使用标准化方法
   - 遵循系统性流程
   - 确保分析完整性

2. 多视角分析
   - 技术视角：系统架构、实现技术
   - 业务视角：业务流程、商业价值
   - 用户视角：使用场景、用户行为
   - 攻击者视角：攻击动机、攻击能力

3. 迭代完善
   - 初步分析：基于概念设计
   - 细化分析：随设计深入完善
   - 验证分析：基于实现结果验证
   - 维护分析：基于运行反馈更新

4. 工具支持
   - 威胁建模工具
   - 风险评估工具
   - 文档管理工具
   - 协作平台工具

7.1.2 目标制定实践

网络安全目标制定实践：

1. SMART原则
   - Specific：具体明确
   - Measurable：可测量
   - Achievable：可实现
   - Relevant：相关性强
   - Time-bound：有时间限制

2. 分层设计
   - 战略层：高层安全目标
   - 战术层：功能安全目标
   - 操作层：技术安全要求

3. 平衡考虑
   - 安全性与可用性平衡
   - 安全性与性能平衡
   - 安全性与成本平衡
   - 安全性与用户体验平衡

7.2 管理最佳实践

7.2.1 项目管理

概念阶段项目管理：

1. 计划管理
   - 制定详细工作计划
   - 明确里程碑和交付物
   - 合理分配资源
   - 建立风险管理机制

2. 团队管理
   - 明确角色职责
   - 建立沟通机制
   - 提供培训支持
   - 激励团队士气

3. 质量管理
   - 建立质量标准
   - 实施过程控制
   - 进行定期评审
   - 持续改进优化

4. 风险管理
   - 识别项目风险
   - 评估风险影响
   - 制定应对措施
   - 监控风险状态

7.2.2 沟通管理

有效的沟通管理包括：

• 内部沟通：团队内部的技术沟通

• 跨部门沟通：与其他部门的协调沟通

• 外部沟通：与供应商、客户的沟通

• 管理沟通：向管理层的汇报沟通

8. 与其他阶段的关系

8.1 向前追溯

概念阶段应考虑：

• 组织要求：组织网络安全管理的要求

• 项目计划：项目网络安全管理的规划

• 法规要求：相关法规标准的要求

• 业务需求：业务层面的安全需求

8.2 向后指导

概念阶段为后续阶段提供：

• 设计输入：为产品开发提供设计输入

• 验证基础：为验证活动提供验证基础

• 评估标准：为安全评估提供评估标准

• 监控要求：为持续监控提供监控要求

8.3 迭代关系

概念阶段迭代关系：

初始概念 → 产品开发 → 概念细化 → 验证确认
    ↑                                    ↓
    ←←←←←←← 反馈完善 ←←←←←←←←←←←←←←←←←

小结

概念阶段是汽车网络安全工程的基础阶段，通过系统的项目定义、深入的威胁分析、科学的风险评估和合理的目标制定，为整个网络安全工程奠定坚实基础。

成功的概念阶段需要专业的团队、系统的方法、充分的分析和严格的验证。在实施过程中，应特别关注TARA分析的质量、网络安全目标的合理性和网络安全概念的可实现性。

概念阶段的成果将指导后续的产品开发、验证测试和运营维护，其质量直接影响整个项目的网络安全水平。因此，应给予概念阶段足够的重视和资源投入。

---

下期预告：《ISO 21434汽车网络安全标准深度解读系列（七）：产品开发阶段网络安全实施》将详细解读第10条产品开发的要求和实施方法。