青岛网站排名方案,互联网服务商,福田蒙派克10座黄牌报价,jquery 素材的网站目录
第七章-分布式网络安全活动
1. 供应商能力评估
2. 报价
3. 网络安全职责界定 第八章-持续的网络安全活动
1. 网路安全监控
2. 网络安全事件评估
3. 漏洞分析
4. 漏洞管理 第九章-概念阶段
1. 对象定义
2. 网路安全目标
3. 网络安全概念 第十章 - 产品开发
第十… 目录
第七章-分布式网络安全活动
1. 供应商能力评估
2. 报价
3. 网络安全职责界定 第八章-持续的网络安全活动
1. 网路安全监控
2. 网络安全事件评估
3. 漏洞分析
4. 漏洞管理 第九章-概念阶段
1. 对象定义
2. 网路安全目标
3. 网络安全概念 第十章 - 产品开发
第十一章 - 网络安全确认 第七章-分布式网络安全活动
第7章规定了分布式开发中的网络安全活动可以理解为在网络安全角度如何进行供应商管理。21434是一份面对整个汽车行业的指导标准因此对供应商管理要求的适用范围不仅限于OEM同时也适用于Tier 1, Tier 2等供应链上各环节的企业和组织此外组织的内部供应商也需要遵循本章要求。在21434中分布式的网络安全活动主要有3项
供应商能力评估报价网络安全职责界定
1. 供应商能力评估
此评估支持供应商选择可以基于供应商符合本标准的能力也可以基于对先前实施的有关网络安全工程的另一个国家或国际标准的评估。
网络安全能力的记录可以包括 — 组织有关网络安全能力的证据例如来自开发、开发后、治理、质量和信息安全的网络安全最佳实践。 — 持续的网络安全活动见第8章和网络安全事件响应见第13章的证据以及 — 以前的网络安全评估的摘要
2. 报价
顾客向候选供应商提出的报价要求应包括 a) 符合本标准的正式要求。 b) 供应商根据7.4.3章节的规定所承担的网络安全责任的预期以及 c) 与该供应商报价的项目或部件有关的网络安全目标和/或网络安全要求集。
3. 网络安全职责界定
客户和供应商应在网络安全接口协议CIA Cybersecurity Interface Agreement中规定分布式网络安全活动包括 a) 指定客户和供应商关于网络安全的联络点。 b) 确定由客户和供应商分别开展的网络安全活动。 c) 如果适用按照6.4.3的规定共同定制网络安全活动。 d) 要共享的信息和工作产品。 e) 关于分布式网络安全活动的里程碑以及 f) 对该项目或组件的网络安全支持结束的定义。 第八章-持续的网络安全活动
第8章主要描述持续的网络安全活动。车辆网络安全工程是一项贯穿产品全生命周期的持续性的活动OEM不仅要进行TARA分析、安全概念设计、网络安全开发测试和生产还要在项目的全生命周期中持续地收集和监控与项目有关的网络安全信息建立信息监控和漏洞管理机制持续地保证产品的网络安全。新漏洞的发现、网络安全突发事件的发生、新攻击技术的出现等都有可能触发相应的网络安全工作。
本章节中描述了4项需要持续进行的网络安全活动
1. 网路安全监控
2. 网络安全事件评估
3. 漏洞分析
4. 漏洞管理
1. 网路安全监控
网络安全信息的收集
外部的信息政府研究机构盈利或非盈利组织供应商客户
内部信息售后field使用现场FFAField failure analysis 收集网络安全信息并进行分类以确定该网络安全信息是否成为一个或多个网络安全事件event。
1. 信息的来源是否可靠
2. 威胁是新的还是再发生
3. 威胁会导致风险的提高或降级
4. 有没有触发阈值影响车辆的范围损害影响的程度触发的话就会升级
没有风险的信息就会被筛选掉不需要关注
有风险的信息就是event事态当Event被利用确实发生了就是事件incident
2. 网络安全事件评估
评估网络安全事态event以确定一个功能项和/或组件的弱点weakness。
Weak是事态event的根本原因root cause 3. 漏洞分析
对弱点进行分析以确定漏洞弱点如若被利用就成为漏洞。
注释该分析可以包括 — 架构的分析 — 根据15.6规定的攻击路径分析和/或 — 根据15.7的攻击可行性评级
示例1攻击路径分析显示不存在攻击路径因此该弱点不被视为漏洞。 示例2攻击可行性评级对于利用该弱点来说非常低因此该弱点不被作为漏洞处理。
4. 漏洞管理
漏洞的管理应做到对每个漏洞 a) 对相应的网络安全风险进行评估并按照15.9章节的规定进行处理使之不存在不合理的风险或 b) 通过应用独立于 TARA 的可用补救措施消除该漏洞。
漏洞分析漏洞管理之后就会涉及到安全事件incident的响应客户投诉也会触发事件的响应13.3章中有描述 第九章-概念阶段
从第9章至第14章21434描述了车辆从概念设计到退役的全生命周期各阶段的网络安全要求。
第9章概念阶段Concept phase的主要工作是定义网络安全对象并通过TARA分析确定网络安全目标产生相应的网络安全概念。接下来将对这3个环节进行详细的描述。
1. 对象定义
应识别功能项的以下信息 a) 功能项边界 b) 功能和 c) 初步架构。
应描述功能项运行环境中关于网络安全的相关信息。
注释:
对运行环境及其与功能项的相互作用的描述可以识别和/或分析相关的威胁场景和攻击路径。 相关信息可以包括假设例如假设该功能项所依赖的每一个公钥基础设施证书机构都得到了适当的管理。
2. 网路安全目标
应在功能项定义的基础上进行分析其中包括 a) 根据15.3章节的规定进行资产识别 b) 按照15.4章节的规定进行威胁场景识别 c) 按照15.5章节的规定进行影响评级 d) 按照15.6章节的规定进行攻击路径分析 e) 根据15.7章节的规定对攻击的可行性进行评级以及 f) 按照15.8章节的规定确定风险值。 根据分析的结果应按照15.9的规定为每种威胁场景确定风险处理方案。
如果一个威胁场景的风险处理决定包括减少风险那么应规定一个或多个相应的网络安全目标。
如果对某一威胁场景的风险处理决定包括 a) 分享或转移风险或 b) 由于分析过程中使用的一个或多个假设而保留风险则应规定一个或多个相应的网络安全声明。
3. 网络安全概念
在描述技术和/或操作性网络安全控制及其相互作用以实现网络安全目标时应考虑到 a) 功能项的功能之间的依赖性和/或 b) 网络安全声明。
输入时Tara报告包括网络安全目标和申明 Verification report验证网络安全概念
一致性跟网络安全目标的一致性概念大于等于目标 Cybersecurtiy Goal, Concept, Specification的区别
1. Cybersecurity PropertiesC.I.A.
2. Cybersecurity Goals: 举例保护个人隐私数据的机密性
3. Cybersecurity Concept: 举例需要把个人数据进行加密
4. Cybersecurity Specification举例个人数据用AES128进行加密 第十章 - 产品开发
在上一章中通过对相关项的TARA分析已经得出了针对高风险项的网络安全要求网络安全概念在产品开发阶段应根据网络安全概念制定详细的网络安全技术规范并将需求逐层分解到下游的子系统、零部件层完成相应的架构设计和详细设计。在V模型右端进行集成和符合性测试以保证相关的组件、系统符合V模型左端对应的网络安全设计规范。
第十一章 - 网络安全确认
第11章节的题目是“Cybersecurity Validation, 可译为”网络安全确认“。这里的Validation需要与上一章节产品开发中的Verification进行一下区分。Verification我们通常理解为是否“do the things right“即验证开发是否满足设计阶段的规范和要求对象通常是零件或子系统。而本章节的”Validation“则是验证是否”do the right things“即所开发的产品是否满足网络安全的目标更直白的讲是验证车辆是否安全。在该阶段确认活动的对象是整车并且是符合量产状态的整车。
在车辆层面的验证活动对于考虑批量生产的配置的功能项应确认 a) 网络安全目标在威胁场景和相应风险方面的充分性。 b) 功能项的网络安全目标的实现。 c) 网络安全要求的有效性以及 d) 对运行环境的要求的有效性如果适用。
