首页
关于我们
公司简介
专业团队
合作案例
产品详情
最新资讯
公司动态
知识分享
产品中心
ASPICE
ISO26262
ISO21434
敏捷SPICE
资质培训
工具链
培训课程
联系我们
人才招聘
用心服务·专业技术·合作发展 13524704775
NEWS

最新资讯

当前位置:首页 - 最新资讯 - 知识分享

ASPICE for Cybersecurity VDA Guideline解读(04)SEC.2.网络安全实施

发表时间:2022-08-25 作者:亚远景科技 返回列表

本系列文章是亚远景科技结合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 网络安全风险管理。

SEC.1.Cybersecurity Requirements Elicitation网络安全需求获取


还没有看过的朋友可以点击上方链接前往阅读。


本篇要讲解的过程是:

SEC.2.Cybersecurity Implementation

网络安全实施



网络安全实施总览

网络安全实施过程的目的是将网络安全需求分配给系统和软件的要素,并确保它们得到实施。


网络安全实施过程需要使用到初始的架构设计,根据网络安全的目标和需求,对相应的架构元素及其接口进行设计改进。CS SPICE PAM中没有使用任何特定的术语来表示与网络安全相关的单独架构。


网络安全是产品的一个属性,所以系统和软件架构应反映相应的网络安全需求,以实现这个属性。这可以通过在架构中的增加组件元素或对元素之间的接口设计进行调整来实现相应的网络安全需求。这一点可以同比SYS.2与SWE.2的架构设计的BP2的要求,网络安全需求同样需要被分配给架构中的一个或多个元素。


网络安全控制(Cybersecurity controls)是指用于实现网络安全目标和网络安全需求的具体实现机制。这些控制机制是多元的,可能是复杂的软件算法、硬件解决方案,甚至是运维手册中的相关警告,主要取决于如何去实现安全目标与需求,其最终目的应该是能够适当的减轻安全目标或需求所对应的威胁场景的风险大小。


网络安全控制机制的选择通常会对系统、软件、机械和硬件架构产生影响,如果需要更改相关架构中的某些元素,则这些元素的详细设计将相应的随之更改,其中,软件单元的开发以及可追溯性和一致性的建立都与SWE.3类似。


最后,网络安全活动是持续迭代的,如果在实施过程中发现的新的漏洞,需要传达给那些正在执行风险评估的人,以协调对相应威胁场景的风险等级。


评级建议

架构设计是对产品或产品组件的最高级别设计描述,其具有不同的抽象视图,如部署图、时序图等等,这能反映不同涉众对架构的关注点,这些视图是项目团队之间沟通、讨论、审查、分析、评估、规划、变更请求分析、影响分析、维护等所需的架构信息的来源。

 

在架构设计环节中,并没有通用的定义去规定哪些视图是必需的,对于视图数量也没有相应的规定。在行业中,也存在些一些方法论给出了架构视图的建议,最终这些视图都会集成到架构设计文档中,在其中会有文本解释对各个视图进行解释与说明。当前容易实施的肯定是依赖于SYS.3和SWE.2的要求,架构视图至少包括静态视图以定义相应的架构与组件,并包括动态行为视图以描述产品或产品组件的交互行为,详见SYS.3和SWE.2。


(1)网络安全控制Cybersecurity controls  

通常,网络安全控制是技术性或其他解决方案,以避免、检测、抵消或减少网络安全风险。这些措施的例子有:

  • 具备鲁棒性的软件设计Robust software design

  • 特定硬件Specific hardware

  • 硬件与软件之间的隔离Isolation between hardware and software

  • 常见的先进解决方案Common state-of-the-art solutions

  • 加密Encryption

建议和规则:

[SEC.2.RL.1]If documentation for cybersecurity controls does not contain an explanation on how the related risk is mitigated, the indicator BP3 must not be rated higher than P. 

解读:如果有关网络安全控制的文件中没有包含关于如何减轻相关风险的解释,则指标BP3的评级不得高于P。


在实施中,网络安全控制的机制会落地到具体的设计与实现过程中,包含对应网络安全需求在架构层面设计实现,甚至到详细设计层面,独立的安全相关模块,对应的防护,监控和异常处理动态行为等信息都是相应的网络安全控制机制。


相关内容:

  • BP3:Select cybersecurity controls选择网络安全控制

  • Output WP17-52:Cybersecurity controls 网络安全控制

(2)分析架构设计Analyze architectural design  

在对架构的分析过程中,分析的工作主要集中在检测新的漏洞。这些脆弱性漏洞都需记录下来导入到风险评估,以确定新的或更新对应的风险决策。


建议和规则:

[SEC.2.RL.2]If detected vulnerabilities are not documented, the indicator BP5 shall be downrated.

解读:如果检测到的漏洞没有记录,则应下调指标BP5。


[SEC.2.RL.3]If no vulnerabilities are found and the analysis is documented, the indicator BP5 must not be downrated. 

解读:如果没有发现漏洞并记录了分析,则不得下调指标BP5。


TARA和架构设计也是迭代的过程,往往初始的TARA需要初始的架构作为输入,分析出来的风险及其应对手段可能会调整对应的架构设计,更新后的架构同样需要进行TARA的二次分析以评估更新后的风险大小,此迭代活动可能会被往复触发,如架构的变更,新漏洞的发现,网络安全事件等

 

相关内容:

  • BP5:Analyze architectural design 分析建筑设计

  • Output WP15-50:Vulnerability analysis report漏洞分析报告


评级一致性

下图显示了SEC.2 各BP之间的关系:

这些关系被用作在以下子章节中定义的评级规则和建议的基础。

[SEC.2.RC.1]If SEC.1.BP1 is downrated, this should be in line with the rating of PA1.1.

解读:如果SEC.1.BP1被下调,则应与PA1.1的评级一致。


[SEC.2.RC.2]If SEC.2.BP6 is downrated, this should be in line with the rating of BP7.

解读:如果SEC.2.BP6被下调,这应该与BP7的评级相一致。


评级还应考虑可追溯性和一致性、总结和沟通以及策略和计划的一般方面。请参考VDA ASPICE GUIDELINE(第一版)了解更多信息。


关于亚远景科技

上海亚远景信息科技有限公司是国内汽车行业咨询及评估领军机构之一,深耕于汽车ASPICE、ISO26262功能安全、ISO21434网络安全领域,拥有10年以上的行业经验,专精于咨询、评估及培训服务,广受全球车厂及供应商赞誉,客户好评率行业领先。坚持以“探索、研发、融合”引领创新发展,秉持“用心服务、专业技术、合作发展”的理念,不断以新技术新模式为客户提供更有效更敏捷的服务。




咨询