最新资讯
在ISO 21434标准框架下，网络安全目标（Cybersecurity Goal）的定义及其向安全控制的技术映射是汽车网络安全工程的核心流程。
这一过程贯穿了从概念阶段的需求分析到产品开发阶段的具体实现，确保了抽象的风险管理要求能够转化为可执行、可验证的技术措施。
以下是从需求分析到安全控制技术映射的详细流程解析：
ISO 21434定义了一个严密的逻辑链条，
将高层级的风险转化为底层代码或硬件配置：相关项定义 (Item Definition) → 威胁分析与风险评估 (TARA) → 网络安全目标 (Cybersecurity Goals)
→ 网络安全需求 (Cybersecurity Requirements) → 架构设计与安全控制 (Architecture & Controls)
这一阶段主要对应ISO 21434标准的第9章（概念阶段）。
首先明确“保护对象”及其运行环境。
内容：定义车辆功能、E/E架构、外部接口（如蓝牙、蜂窝网络）、资产（数据、代码）以及信任边界。
目的：划定TARA分析的范围。
TARA（第15章规定的方法）是推导网络安全目标的引擎。
资产识别：识别需要保护的资产（如用户隐私数据、车辆控制指令）。
威胁场景识别：基于STRIDE等模型，分析潜在攻击路径（例如：攻击者通过OBD接口刷写恶意固件）。
影响分析 (Impact Analysis)：评估威胁成功后的后果（安全、财务、操作、隐私），通常分为高/中/低。
攻击可行性分析 (Attack Feasibility)：评估攻击难度（时间、专业知识、窗口期、设备），通常分为高/中/低。
风险等级确定：结合影响和可行性，确定风险等级（例如：高风险）。
针对不可接受的风险（通常是高风险和部分中风险），必须制定网络安全目标。
定义：网络安全目标是高层级的陈述，旨在降低特定威胁场景的风险至可接受水平。
格式示例：
原始风险：攻击者通过Wi-Fi接口未经授权访问车辆网关，导致刹车失灵（高风险）。
网络安全目标：“防止未经授权的用户通过Wi-Fi接口向车辆发送控制指令。”
属性：每个目标必须关联到具体的威胁场景ID，并指定所需的保密性、完整性或可用性属性。
这一阶段主要对应ISO 21434标准的第10章（产品开发）。在此阶段，高层级的“目标”被分解为具体的“需求”，并最终映射为“技术控制”。
将自然语言描述的目标转化为可测试的技术需求（Cybersecurity Requirements, CSR）。
映射逻辑：一个网络安全目标可能分解为多个系统级、硬件级或软件级需求。
示例：
目标：“防止未经授权的用户通过Wi-Fi接口向车辆发送控制指令。”
系统需求：
系统应仅接受经过认证的Wi-Fi连接请求。
系统应对所有传入的控制指令进行完整性校验。
系统应记录所有失败的认证尝试。
这是真正的“技术映射”环节，选择具体的安全机制来实现需求。这通常涉及纵深防御 (Defense in Depth) 策略。
| 网络安全目标 (Goal) | 派生出的技术需求 (Requirement) | 技术映射/安全控制 (Security Control) | 涉及技术/协议示例 |
|---|---|---|---|
| 防止非法访问 | 系统必须验证外部设备的身份 | 双向认证 (Mutual Authentication) | TLS 1.3, IEEE 802.1X, 数字证书 (PKI) |
| 防止指令篡改 | 关键控制消息必须具备完整性保护 | 消息认证码 (MAC) / 数字签名 | SecOC (Secure Onboard Communication), HMAC-SHA256 |
| 防止密钥泄露 | 加密密钥不得以明文存储在内存中 | 安全存储与密钥管理 | HSM (硬件安全模块), SHE, Trusted Platform Module (TPM) |
| 防止恶意代码执行 | 仅允许执行经过签名的软件 | 安全启动 (Secure Boot) | UEFI Secure Boot, RSA/ECC签名验证 |
| 防止运行时攻击 | 系统需检测并响应异常行为 | 入侵检测与防御 (IDPS) | 基于规则的IDS, 异常流量分析 |
| 防止调试接口滥用 | 生产环境下禁用调试端口 | 端口锁定与访问控制 | JTAG/SWD熔断, 密码保护的调试模式 |
在系统架构设计中，需要将上述控制措施分配到具体的组件中：
通信层：部署SecOC协议栈，配置CAN FD或以太网的安全帧格式。
计算层：选用带有HSM的MCU，配置内存保护单元 (MPU) 隔离关键进程。
应用层：实施输入验证逻辑，集成加密库（如mbedTLS）。
映射完成后，必须验证技术控制是否真正实现了网络安全目标：
单元测试/集成测试：验证安全机制（如加密算法、认证流程）是否按需求工作。
渗透测试 (Penetration Testing)：模拟攻击者，尝试绕过已部署的安全控制，验证风险是否已降低到可接受水平。
模糊测试 (Fuzzing)：向接口发送随机数据，验证系统的健壮性。
回归分析：如果架构变更，需重新评估TARA，确保原有的网络安全目标依然有效。
可追溯性 (Traceability)：必须建立从 威胁场景 -> 风险 -> 网络安全目标 -> 安全需求 -> 架构设计 -> 测试用例 的双向追溯矩阵。这是ISO 21434审核（Audit）的重点。
CAL等级匹配：根据TARA确定的风险等级，选择相应网络安全保证等级 (CAL, Cybersecurity Assurance Level) 的开发和验证方法。高风险（CAL 3-4）需要更严格的代码审查和渗透测试。
持续更新：随着新漏洞（CVE）的发现，TARA需重新评估，可能导致新的网络安全目标产生，进而触发新一轮的技术映射和控制更新。
ISO 21434中的技术映射不是简单的“一对一”转换，而是一个层层分解、多对多映射的系统工程。
起点是TARA识别出的具体风险。
桥梁是清晰定义的网络安全目标。
终点是落实到代码、硬件配置和网络协议中的具体安全控制（如HSM、SecOC、Secure Boot）。
只有通过这种严谨的映射，才能确保汽车在面对不断演变的网络威胁时，具备实质性的防御能力，而不仅仅是合规文档的堆砌。
推荐阅读：
亚远景-从仿真测试到实车验证：ISO/PAS 8800 的测试策略
亚远景-ASPICE评估：汽车软件开发过程评估的方法与经验总结
亚远景-ISO/PAS 8800与全球汽车AI监管趋同下的中国企业合规策略与技术适配
亚远景-ASPICE与ISO 26262：汽车软件安全与质量的双标
推荐服务：
点击查看亚远景ASPICE、ISO26262实施工具-APMS研发过程管理平台
