2024道路车辆信息安全工程.docx

《2024道路车辆信息安全工程.docx》由会员分享，可在线阅读，更多相关《2024道路车辆信息安全工程.docx（67页珍藏版）》请在课桌文档上搜索。

1、道路车辆信息安全工程道路车辆信息安全工程1 范围本文件规定了道路车辆中电子电气（E/E）系统（包括其组件和接口）在概念、产品开发、生产、运行、维护和报废阶段的信息安全风险管理的工程要求。本文件定义了一个框架，其中包括信息安全过程要求以及沟通和管理信息安全风险的通用语言。本文件适用于在本文件发布后开发或修改的批量生产的道路车辆E/E系统，包括其组件和接口。本文件未规定与信息安全有关的具体技术或解决方案。2 规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

2、文件。GBZT34590.3-2022,道路车辆功能安全第三部分：概念阶段3 术语和定义下列术语和定义适用于本文件。3.1架构设计architecturaldesign可以识别组件、边界、接口和交互的表示方法。3.2资产asset具有价值或对价值做出贡献的对象。注：资产具有一个或多个信息安全属性，未达到要求时可能导致一个或多个危害场景。3.3攻击可行性attackfeasibiIity攻击路径的属性，描述成功执行相应攻击活动的难易度。3.4攻击路径attackpath为实现威胁场景的一组攻击活动。3.5攻击者attacker执行攻击路径的个人、团体或组织。3.6审核audit对过程进行检查，以

3、确定过程目标的实现程度。3.7组件component逻辑上和技术上可分离的组成部分。3.8客户customer接受服务或产品的个人或组织。3.9道路车辆信息安全cybersecurity使资产受到充分保护，免受道路车辆相关项、其功能及其电气或电子组件的威胁场景的危害。注：为简洁起见，本文件使用信息安全”一词代替道路车辆信息安全。3.10信息安全评估cybersecurityassessment信息安全状态的评价。3.11信息安全档案cybersecuritycase有证据支持的结构化论证，表明风险的合理性。3.12信息安全声明cybersecurityclaim关于风险的信息安全索赔声明。注：

4、信息安全声明可包括保留或分担风险的理由。3.13信息安全概念cybersecurityconcept相关项的信息安全需求和对操作环境的要求以及有关信息安全控制的相关信息。3.14信息安全控制cybersecuritycontrol改变风险的措施。3.15信息安全事态cybersecurityevent与相关项或组件有关的信息安全信息。3.16信息安全目标cybersecuritygoal与一个或多个威胁情景相关的概念级信息安全需求。3.17信息安全事件cybersecurityincident可能涉及漏洞利用的情况。3.18信息安全信息cybersecurityinformation与信息安全

5、有关的信息,其相关性尚未确定。3.19信息安全接口协议cybersecurityinterfaceagreement客户和供应商之间关于分布式信息安全活动的协议。3.20信息安全属性cybersecurityproperty值得保护的属性。注：属性包括保密性、完整性和/或可用性。3.21信息安全规范cybersecurityspecification信息安全需求和相应的架构设计。3.22危害场景damagescenario涉及车辆或车辆功能并影响道路使用者的不良后果。3.23分布式信息安全活动distributedcybersecurityactivities相关项或组件的信息安全活动，其责任

6、在客户和供应商之间分配。3.24影响impact对危害场景下的损害程度或物理伤害程度的估计。3.25相关项item在车辆层面实现一个功能的组件或组件集。注：如果一个系统在车辆层面实现了一个功能，它就可以成为一个相关项，否则就是一个组件。3.26操作环境OPeratiOnalenvironment在操作使用中考虑到相互作用的环境。注：相关项或组件的操作使用，包括在车辆功能，生产，和/或服务和修理中的使用。3.27独立于环境out-of-context未在特定相关项定义下的开发。示例：基于假设信息安全需求的处理单元可集成到不同的相关项中。3.28渗透测试penetrationtesting模拟实际

7、攻击的信息安全测试，用以识别破坏信息安全目标的方法。3.29风险risk信息安全风险，道路车辆信息安全不确定性的影响，可用攻击可行性和影响表示。3.30风险管理riSkmanagement指导和控制组织风险的协调活动。3.31道路使用者roaduser参与道路交通活动的人员。3.32裁剪tailor以与本文件描述不同的方式省略或执行某项活动。3.33威胁场景threatscenario为实现危害场景，一个或多个资产的信息安全属性遭到破坏的潜在原因。3.34分类triage分析以确定信息安全信息与某一相关项或组件的相关性。3.35触发器trigger用于分类的准则。3.36确认VaIidatio

8、n通过提供客观证据以证明相关项的信息安全目标是否充分并已实现。3.37验证verification通过提供客观证据确认是否满足特定要求。3 .38脆弱性或漏洞vulnerabiIity能被利用的弱点，可作为攻击路径的一部分。4 .39漏洞分析vulnerabiIityanalysis系统地识别和评估漏洞。5 .40弱点weakness可导致非预期行为的缺陷或特征。示例：如缺少需求或规范：架构或设计缺陷、包括安全协议的不正确设计：实现的弱点，包括硬件和软件的缺陷，安全协议的不正确的实现；操作过程或程序有缺陷，包括操作不当和用户培训不足：使用过时或弃用的功能，包括加密算法等06 缩略语CAL：信息

9、安全保障等级(CyberSeCUrilyAssuranceLevel)CVSS：常见漏洞评分系统(CommonVulnerabilityScoringSystem)E/E：电子电气(ElectricalandElectronic)ECU：电子控制单元(EleCtroniCeOntroIUnil)OBD:车教诊断(On-BoardDiagnostic)OEM：原始设备制造商(OriginalEquipmcntManufacturcr)PM：许可(PermiSSion)RC：建议(ReCOmmendation)RQ：要求(ReqUirement)WP：工作成果(WorkPrOdUCl)RASIC：

10、责任、批准、支持、知情、咨询(ReSPonSibIe,Accountable,Supporting,Infbrmed,Consulted)TARA：威胁分析和风险评估(ThrCatAnaIySiSandRiSkASSeSSment)7 整体考虑一个相关项包括车辆中实现整车级别特定功能(如制动)的所有电子设备和软件(即其组件)。一个相关项或一个组件与各自的运行环境相互作用。本文件仅适用于批量生产的道路车辆(即不是原型车)与信息安全相关的相关项和组件，包括售后件和服务件。车辆的外部系统(如后端服务器)出于信息安全的目的可以考虑，但不在本文件的范围内。本文件从单个相关项的角度来描述信息安全工程。本文

11、件没有规定如何进行道路车辆E/E架构中相关项功能的适当分配。对于车辆整体而言，可以考虑构建车辆E/E架构或其信息安全相关的相关项和组件的信息安全档案集。如果本文件中描述的信息安全活动是在相关项和组件上进行的，那么将会解决不合理的车辆信息安全风险。如图1所示，本文件中描述的组织整体信息安全风险管理适用于全生命周期。图1整体信息安全风险管理信息安全风险管理适用于整个供应链，以支持信息安全工程。汽车供应链表现出多样化的合作模式。并非所有的信息安全活动都适用于与某个特定项目相关的所有组织。信息安全活动可以根据具体情况的需要进行裁剪。某一特定相关项或部件的开发伙伴应就工作分工达成一致，以便执行适用的信息

12、安全活动。图2显示了一个相关项、功能、组件和相关术语之间的关系。第16章描述了信息安全风险评估的模块化方法，这些方法会在其他章节所述的信息安全风险活动中被引用。在信息安全工程背景下的分析活动，可识别和探索具有恶意意图的抽象敌对行为者的潜在行为，以及车辆E/E系统的信息安全损害后可能产生的危害。信息安全工程和其他学科的专业知识之间的协调可以支持深入分析并减轻具体的信息安全风险。信息安全监测、补救和事件响应活动作为概念和产品开发活动的补充，可以作为一种被动的方法，确认环境中不断变化的条件（如新的攻击技术），持续地识别和管理道路车辆E/E系统的弱点和漏洞。纵深防御的方法可用于减轻信息安全风险。纵深防

13、御方法利用多层信息安全控制来提高车辆的信息安全。如果攻击能够穿透或绕过一个层，另一个层可以帮助遏制攻击并保持对资产的保护。8 组织的信息安全管理8.1 总则为了实现信息安全工程，组织应建立并维护包括信息安全意识管理、能力管理和持续改进在内的信息安全治理和信息安全文化。这涉及到制定组织层面的规则和过程，并依据本文件中的目标进行独立审核。为了支持信息安全工程，组织还应为信息安全建立管理体系，包括工具的管理和质量管理体系的应用。8.2 目标本章的目标是：a）定义信息安全方针和组织层面的信息安全规则和过程：b）分配执行信息安全活动所需的职责和相应的权限；c）支持信息安全的实施，包括资源的提供和信息安全

14、过程与其他相关过程之间相互作用的管理；d）管理信息安全风险；e）建立并维护信息安全文化，包括能力管理、意识管理和持续改进；f）支持并管理信息安全信息的共享；g）建立并维护支撑信息安全维护的管理体系；h）提供证据证明使用的工具不会对信息安全产生不利的影响；i）执行组织层面的信息安全审核。8.3 输入无。6. 3.1先决条件无。7. 3.2更多支持信息可以考虑以下信息：-符合质量管理标准的证据。例如：IATF16949与其他标准的联合,如：ISO9001,AutomotiveSPICE,ISO/IEC330XX系列标准，ISO/IEC/IEEE15288和ISO/IEC/IEEE12207o6.4

15、要求和建议6.4.1信息安全治理RQ-05-01组织应定义信息安全方针，包含：a）对道路车辆信息安全风险的确认；b）最高管理层对相应信息安全风险进行管理的承诺。注1：信息安全方针可以与组织目标及其他方针相关联。注2：在考虑内部和外部环境的情况下，信息安全方针可以包括一项声明，说明对组织的产品或服务组合的一般威胁场兔的风险处理。RQ-05-02组织应建立并维护组织层面的规则和过程，以满足以下要求：a)能够实施本文件的要求；b)支持相应活动的执行。示例1：如过程定义、技术规则、指南、方法和模板。注3：信息安全风险管理能包括活动的付出-收益的考虑。注4：这些规则和过程覆盖概念、产品开发、生产、运营、

16、维护和报废，包括TARA的方法、信息共享、信息安全监测、信息安全事件响应和触发。注5：有关漏洞披露的规则和过程，例如信息共享的一部分，可以依据ISO29147定义。注6：图3概述了总体的信息安全方针(见RQ-05-(H)与具体组织的信息安全规则和过程(见RQ-05-02)、职成(见RQ-05-03)和资源(见RQ-0504)之间的关系。图3信息安全治理RQ-05-03组织应分配实现与维护信息安全的职责，并给予相应的组织权力。注7：这既关系到项目层面的活动也关系到组织层面的活动。RQ-05-04组织应提供解决信息安全问题所需的资源。注8：资源包括负责信息安全风险管理、开发、事件管理的人员。示例2

17、：熟练的人员和合适的工具来完成信息安全活动。RQ-05-05组织应识别与信息安全有关或相互作用的专业领域，并在这些专业领域之间建立和维护沟通的渠道，以满足以下要求：a)确定是否要将信息安全融入到现有过程中，以及如何融合；b)协调相关信息的交换。注9：协调各学科之间共享过程，以及策略和工具的使用。注10：学科包含信息技术安全、功能安全和隐私保护。示例3：跨学科的交换：- 威胁场景和危害信息：- 信息安全目标和功能安全目标的冲突或对抗；- 信息安全要求与功能安全要求的冲突或对抗。6.4.2信息安全文化RQ-05-06组织应培养并维护强大的信息安全文化。注1：示例见附录B。RQ-05-07组织应确保

18、被分配了信息安全角色和职责的人员具有履行这些角色和职责的能力和意识。注2：能力、意识和培训项目考虑以下范围：- 与信息安全相关的组织规则和过程，包括信息安全风险管理：- 与信息安全学科相关的信息安全规则和过程，例如功能安全和隐私保护：- 领域知识；- 系统工程：- 信息安全有关的方法、工具、指南：- 已知的攻击手段和信息安全控制。RQ-05-08组织应建立并维护持续改进过程。示例：持续改进过程包括：- 从以前的经验中学习，包括通过信息安全监测和内外部信息安全相关信息观察而收集的信息安全信息；- 从领域中类似的应用产品的信息安全信息中学习：- 在后续的信息安全活动中进行改进；- 将信息安全经验教

19、训传达给适当的人员：- 根据RQ-05-02检查组织规则和过程的充分性。注3：持续改进适用于本文件中的所有信息安全活动。6.4.3信息共享RQ-05-09组织应界定在哪些情况下，要求、允许或者被禁止组织内部和外部共享信息安全相关的信息。注：共享信息的情况可以基于：-共享的信息类型；-共享的审批过程：-信息的编辑要求：- 源头归属的规则：- 为特定方提供的通讯类型；- 漏洞披露程序（见5.4.1的注5）- 面向接收方的处理高度敏感信息的要求RC-05T0组织应根据RQ-05-09的规定，将共享数据的信息安全管理与其他各方保持一致。示例：公共、内部、机密和第三方机密的安全分类级别的一致。6.4.4

20、管理体系RQ-05-11组织应按国际标准或者同等标准建立和维护一个质量管理体系来支撑信息安全工程，包含：示例1：IATF16949与ISO9001相结合。a）变更管理；注1：信息安变更管理的范围处管理相关项及其组件的变更，以便继续满足适用的信息安全目标和要求。例如，根据生产控制计划评审生产过程的变更，以防止此类变更引入新的漏洞。b）文档管理；注2：一项工作成果可以被合并或映射到不同的文档库。C）配置管理；d）需求管理。RQ-05-12用于维护该领域内产品信息安全的配置信息应保持可用，直至产品的网络安全支持结束，以便能采取补救措施。注3：归档构建环境有助于确保配置信息的后续使用。例2：物料清单、

21、软件配置。RC-05-13应建立生产过程的信息安全管理体系，以便支持12章的活动。例3：IEC624432-lo6. 4.5工具管理RQ-05-14应管理能够影响相关项或组件信息安全的工具。示例1：用于概念或产品开发的工具，如：基于模型的开发工具、静态检查工具、验证工具。示例2：用于生产的工具，如FlaSh写入、EOL测试工具。示例3：用于售后维修的工具，如OBD工具或者重新编程工具。注：这类管理可以通过以下方式确立：- 用户手册及勘误表的使用；- 对非预期的使用和操作进行防护；- 对工具使用者进行访问控制；- 对工具进行认证。RC-05-15支持信息安全事件补救措施的合适环境应该是可复现的，

22、直至产品的信息安全支持结束。例4：用于复现和管理漏洞的测试、软件构建和开发环境。例5：用于构建产品软件的工具链和编译器。6. 4.6信息安全管理RC-05-16工作成果应按照信息安全管理体系进行管理。例：可以将工作成果存储在文件服务器上，以防止未经授权的变更或删除。7. 4.7信息安全审核RQ-05-17应独立进行信息安全审核以判断组织的过程是否达到了本文件的目标。注1：信息安全审核可以纳入质量管理体系标准的审核中，或者与之相结合。例如，IATFI6949与ISO9001相结合。注2：独立性可以基于，例如，GB/T34590系列标准。注3：执行审核的人员可以来自组织内部或者外部。注4：为了确保

23、组织的过程始终适用于信息安全，审核可以周期性执行。注5：图7展示了组织的信息安全审核和其他信息安全活动间的关系。8. 5工作成果WP-05-01信息安全方针、规则和过程，依据6.4.1至643的要求。WP-05-02能力管理和意识管理的证据，依据RQ-05-07的要求；持续改进的证据，依据RQ-05-08的要求。WP-05-03组织管理体系的证据，依据6.4.4和6.4.6的要求。WP-05-04工具管理的证据，依据645的要求。WP-05-05组织层面的信息安全审核报告，依据647的要求。7项目相关的信息安全管理7.1 总则本章描述了有关特定项目的信息安全开发活动的管理要求。项目相关的信息安

24、全管理包括职责分配和信息安全活动的计划。本文件以通用方式定义要求，以便可以将其应用于各种相关项和组件。另外，可以基于原理在信息安全计划中进行裁剪。可以使用裁剪的示例包括：- 复用；- 独立于环境的组件；- 使用现成组件；- 更新。无论后关项、组件或其操作环境是否发生变更，相关项和组件的复用是可以应用的开发策略。但是，变更可能会引入原始相关项或组件尚未考虑的漏洞。此外，已知攻击可能发生了变化，例如：攻击技术的发展；新出现的漏洞，例如从信息安全监测或信息安全事件评估中得知的漏洞；自初始开发以来资产的变化。如果原始相关项或组件是根据本文件开发的，则可基于现有的工作成果复用该相关项或组件。如果相关项或

25、组件最初不是根据本文件开发的，则可以基于现有文件复用，并说明理由。一个组件可以独立于环境开发，例如基于假设的环境。在与客户接触或达成商业协议之前，组织可以为不同的应用和不同的客户开发通用组件。供应商可以对环境和预期用途进行假设。基于此，供应商可以得出独立于环境的开发需求。例如，独立于环境开发微控制器。现成的组件是指不为特定客户开发的组件，可以在不变更其设计或实施的情况下使用。例如，第三方软件库、开源软件组件。现成的组件不被认为是按照本文件要求开发的。按照本文件，现成的组件和独立于环境开发的组件可以被集成到一个相关项或组件中（见图4）。集成可包含与7.4.4中复用分析类似的活动，如果为了解决无效

26、的假设而进行变更，则适用于变更管理。可对准备集成的组件或以集成为目标的组件或相关项进行变更。图4现成和独立于环境的组件的集成信息安全档案是信息安全评估和后开发阶段发布的输入。注：后开发阶段通常包括生产、运维、报废阶段。信息安全评估可独立判断一个相关项或组件的信息安全，是决策后开发阶段发布的输入。7.2 目标本章的目标是：a）分配项目的信息安全活动职责；b）规划信息安全活动，包括定义裁剪的信息安全活动；c）创建一个信息安全档案；d）执行信息安全评估，如果适用；e）从信息安全的角度决定是否发布相关项或组件以用于后开发阶段。7.3 输入7. 3.1先决条件无。9. 3.2更多支持信息可以考虑以下信息

27、：-组织的信息安全审核报告WP-05-03;项目计划。7.4要求和建议1.1.1 4.1信息安全职责及其分配RQ-06-01与项目信息安全活动有关的职责应根据RQ-05-03进行沟通和分配。注：信息安全活动的责任可以转移，前提毡要进行交流并移交相关信息。1.1.2 4.2信息安全计划RQ-06-02为了决定相关项或组件的信息安全活动，应分析相关项或组件以确定:a）该模块或组件是否与信息安全相关；注1：附录D提供了可用于评估信息安全相关性的方法和标准。注2：如果确定该相关项或组件与信息安全无关，则没有相关的信息安全活动，因此不会启动信息安全计划。b）如果该相关项或组件与信息安全有关，该相关项或部

28、件是新开发还是复用；c）是否按照743进行裁剪。RQ-06-03信息安全计划应包括：a）扇动的目标；b）对其他活动或信息的依赖；C）负责执行活动的人员；d）执行活动所需的资源；e）开始节点或终止节点以及预期持续时间；f）工作成果的标识。RQ-06-04应根据RQ-05-03和RQ-05-04分配开发和维护信息安全计划以及根据信息安全计划跟踪信息安全活动进度的职责。RQ-06-05信息安全计划应：a）在开发项目计划中提及；b）包括在项目计划中，以使信息安全活动具有可区分性。注3：信息安全计划可以在配置管理下包含与其他计划（如项目计划）的交叉引用（见RQ-0609）.RQ-06-06信息安全计划应

29、根据第9、1011和15章的相关要求，指定与概念阶段和产品开发阶段所需要的信息安全活动。RQ-06-07当进行的活动确定要发生更改或细化时，应更新信息安全计划。注4：信息安全计划可以在开发过程中逐步完善。例如，信息安全计划可以根据信息安全活动的结果进行更新，如TARA（见第16章）。PM-06-08对于根据本文件16.8的分析确定的风险值为1的威胁场景，可以省略与10.5、11和12章的符合性。注5：威胁情况可能会对信息安全产生影响，如果产生影响，则对相应的风险进行处理。注6：可以根据信息安全档案中定义的基本原理来论证对此类风险的处理是否充分，基本原理可以基于质量管理标准的符合性，如IATFI

30、6949与ISO9001相结合，并结合其他措施，例如：一信息安全意识保证：一质量人员的信息安全培训：一组织的质量管理体系中规定的信息安全具体措施。RQ-06-09信息安全计划中确定的工作成果应在后开发阶段发布之前和发布时进行更新并保持准确性。RQ-06-10对于分布式信息安全活动，客户和供应商均应根据第16章为其各自的信息安全活动和接口定义信息安全计划。RQ-06-11信息安全计划应按照6.4.4的规定，接收配置管理和文件管理。RQ-06-12按照6.4.6的规定，信息安全计划中确定的工作成果，应接受配置管理、变更管理、需求管理和文件管理。1.1.3 裁剪PM-06-13信息安全活动可以被裁剪

31、。RQ-06-14如果信息安全活动被裁剪了，应提供并审查基本原理，用来证明可以通过裁剪充分实现本文件的相关目标。注：因供应链中的另一实体执行而未执行的活动不被视为裁剪，被视为分布式信息安全活动。然而，信息安全活动的分布可以导致联合裁剪。1.1.4 复用RQ-06-15如果一个相关项或组件完成开发，应开展复用分析：a）计划进行变更；b）计划在另一个操作环境中复用；示例1：由于在新的操作环境中安装了现有的相关项或组件，或者由于与之交互的其他相关项或组件的升级而使环境发生了变更（见图5）,A可作为复用分析的结果而改变。车辆A车辆B相关项或组件A相关项或组件B组件XJ组件Xa图5复用分析示例c）计划在

32、不变更的情况下复用，并且有关模块或组件的信息也有相应的变化，示例2已知攻击和漏洞的变化，或威胁场景的变化。注1：在确定是否复用时.，需考虑现有的工作成果：注2：变更可以包括设计变更和/或实施变更：-设计变更可以来自需求变更，例如，功能或性能增强。-软件修正或使用新的生产或维护工具（例如，基于模型的开发），可能会导致实施变更。注3：配置数据或校准数据的变更，如果影响现有相关项或组件的功能行为和资产或信息安全属性，则视为发生变更。RQ-06-16相关项或组件的复用分析应：a）识别相关项或组件的变更和操作环境的变更；b）分析变更后的信息安全影响，包括对信息安全声明和先前假设的有效性的影响；示例3：对

33、信息安全需求、设计和实施、操作环境、假设和操作模式的有效性、维护、对已知攻击的敏感性和已知漏洞或资产的暴露的影响。c）识别受影响或缺少的工作成果；示例4：TARA考虑新的或变更的资产、威胁场景或风险值。d）在信息安全计划中指定符合本文件所需的信息安全活动。注4：可能产生裁剪。RQ-06-17组件的复用分析应评估：a）该组件能够满足其要集成的相关项或组件所分配的信息安全要求；b）现有文档是否足以支持该组件集成到一个相关项或另一个组件中。1.1.5 独立于环境的组件RQ-06-18应在相应的工作成果中记录独立于环境开发的组件对预期用途和环境的假设，包括外部接口。RQ-06-19对于独立于环境的组件

34、的开发，信息安全需求应基于RQ-06-18的假设。RQ-06-20对于独立于环境开发的组件的集成，应验证RQ-06-18的信息安全声明和假设。1.1.6 现成组件RQ-06-21当集成现成组件时，应收集和分析与信息安全相关的文件，以确定：a）满足分配的信息安全需求；b）适合于预期用途的特定应用环境；C）现有的证明文件是否足以支持信息安全活动。RQ-06-22如果现有的证明文件不足以支持现成组件的集成，那么应识别并执行符合本文件的信息安全活动。示例：有关漏洞的文件不充分。注：这可能意味着裁剪。1.1.1 4.7信息安全档案RQ-06-23应创建一个信息安全档案，为相关项或组件的信息安全提供论据，

35、并有工作成果加以支持。注1：证据可以隐含的（例如，如果从已编译的工作成果集中可以看出该证据，则可以省略这部分证据）。注2：在分布式开发中，相关项的信息安全档案可以是客户和供应商的信息安全档案的组合，其中引用各方产生的工作成果的证据。相关项的整体论据由各方的论据共同支持。注3：信息安全档案需考虑后开发的信息安全需求WP-10-02。7.4.8 信息安全评估RQ-06-24应采用基于风险的基本原理决定是否对相关项或组件进行信息安全评估。注1：基本原理可基于：TARA分析结果；待开发相关项或组件的复杂性；组织规则和过程所规定的标准；注2：如果不进行信息安全评估，可将基本原理记录在信息安全档案中。RQ

36、-06-25RQ-06-24的基本原理应独立评审。注3：独立方案可基于GB/T34590系列标准。RQ-06-26信息安全评估应判断相关项或组件的信息安全。注4：现有证据由信息安全活动的记录结果提供，如工作成果（见附录A）o注5：图6说明了组织信息安全审核、项目级信息安全评估和其他信息安全活动之间的关系。网络安全评估报告: 基于现有证据以及 提供理由的网络安 全独立评估组织级别|网络安金计|用电空全话动网络安全计划定义开展哪些活动执行砥安全计划定义的网络安全活动网各安全论据III隆各安全计划l7足头安全计划要求的工作产（S7解各安全案例网络安全评估：一检测理各安全计划定义的过程执行一独立茅P夬

37、相关项或部件本文件的目标已经充分达到，且提供的论据有说服力图6与其他信息安全活动有关的信息安全评估注6：信息安全评估可以逐步进行，以尽早解决已发现的问题。注7：信息安全评估可以重复或补充；例如，由于变更，之前的信息安全评估提供了否定建议或发现了漏洞。RQ-06-27应根据RQ-06-01,任命负责计划和独立进行信息安全评估的人员。注8：独立方案可基于GBZT34590系列标准。例：来自于组织内不同团队或部门的人员，如质量保证部门，来自独立组织的人员。RQ-06-28进行信息安全评估的人员应：a）有权获得相关信息和工具：b）获得执行信息安全活动的人员的合作。PM-06-29可基于对是否达到本文件

38、目标的判断进行信息安全评估。RQ-06-30信息安全评估的范围应包括：a信息安全计划和信息安全计划要求的所有工作成果；b）对信息安全风险的处理；c项目实施的信息安全控制和信息安全活动的适当性和有效性；注9：合理性和有效性可以通过使用先前为验证目的而进行的评审来判断。d）证明已达到本文件目标的基本原理（如果提供）；注10：考虑到PM-06-13,工作成果的创建负责人可以提供一个基本原理，解释为什么要实现本文件的相应目标以促进信息安全评估。注11：符合所有相应要求是实现本文件目的的充分基本原理。RQ-06-31信息安全评估报告应包括接受，带条件接受或拒绝该相关项或组件的信息安全建议。注12：评估报

39、告也可以包括持续改进建议。RQ-06-32如果提出了根据PM-06-31的带条件接受建议，则信息安全评估报告应包括接受条件。7.4.9 后开发的发布RQ-06-3司下列工作成果应在后开发阶段的发布之前可用： 信息安全档案WP-06-02； 如果适用，信息安全评估报告WP-06-03； 后开发阶段的信息安全需求WP-10-02。RQ-06-34相关项或组件在后开发的发布应满足以下条件：a）信息安全档案提供了充分的证据证明信息安全；b）通过信息安全评估确认信息安全档案，如果适用；b）后开发阶段的信息安全需求被接受。7. 5工作成果WP-06-01根据741至746的要求制定的信息安全计划。WP-0

40、6-02根据7.4.7的要求制定的信息安全档案。WP-06-03根据748的要求得出的信息安全评估报告（如适用）。WP-06-04根据749的要求得出的用于后开发阶段的发布报告。8分布式信息安全活动8. 1总则如果相关项或组件信息安全活动的责任是分布式的，本条适用。本章描述了分布式信息安全活动的管理，并且适用于以下情况：a）在分布式信息安全活动中开发的相关项和组件；b）客户供应商间的交互；c）客户-供应商接口协议适用的所有阶段。内部供应商和外部供应商可以采用同样的方式进行管理。示例：一个1级供应商是某C）EM开发过程中的供应商，在另一个组件供应的合同关系中它是某2级供应商的客户。这在图7中进行

41、了说明。图7供应链中客户/供应商关系的用例8.2 目标本章的目标是定义客户和供应商在信息安全活动中的交互、依赖和职责。8.3 输入无。8.4 要求和建议8.5 4.1供应商的能力RQ-07-01应按本文评价潜在供应商在开发（如果适用）以及后开发活动方面的能力。注1：该评价可用来支持供应商的选择，可以依据本文要求的能力，也可以依据其他国家或国际的信息安全工程标准的实施情况进行评价。RC-07-02供应商应提供信息安全能力记录，来支持客户对供应商能力的评价。注2：信息安全能力记录包含：- 组织关于信息安全能力的证据（例如：在开发、后开发、治理、质量和传统信息安全等方面的信息安全最佳实践）；- 开展

42、可持续的信息安全活动（见第9章）和信息安全事件响应（见第14章）的证据；- 以往信息安全评估报告的总结。8.4.2询价RQ-07-0司客户向潜在供应商发出的报价请求应包含：a）符合本文件的正式要求；b）7.4,3中对供应商履行信息安全职责的预期；c）与供应商报价的相关项或组件有关的信息安全目标或信息安全需求集。例：关于消息认证的信息安全需求。8.4.3职责的协调RQ-07-04客户和供应商应在信息安全接口协议中规定分布式信息安全活动，包含：a）任命信息安全相关的的客户和供应商的联络人；b）识别需要由客户和供应商各自实施的信息安全活动；例1：客户执行整车层面的信息安全确认。例2：后开发阶段的信息

43、安全活动的分布。例3：供应商、客户或者第三方可以就供应商开发的组件或工作成果进行信息安全评估。C）如果适用，按照643共同对信息安全活动进行裁剪；d）应共享信息和工作成果；注1：共享的信息可以包含：- 分发、评审和发生信息安全问题时的反馈机制；- 信息共享策略；- 漏洞和其他信息安全相关发现的信息交换流程，例如，关于风险；- 接口相关的过程、方法和工具，用来确保客户和供应商对接的兼容性，例如对于数据的恰当处理和对传输数据的通讯网络的安全防护；- 角色的定义；- 沟通和记录相关项或组件变更的方法，包含TARA潜在重复使用；- 需求管理工具的统一；- 信息安全评估的结果。e）分布式信息安全活动的里

44、程碑；f）相关项或组件的信息安全支持终止的定义。RC-07-05信息安全接口协议应在客户和供应商开始分布式活动前共同商定。RQ-07-06如果根据RQ-08-07识别的漏洞需要管理，则客户和供应商应对采取的行动及行动的职责达成共识。RQ-07-07如果需求不清楚、不可行、或与其他信息安全需求或相关领域的需求相冲突，则客户和供应商应互相通知对方，以便做出适当的决定并采取行动。RC-07-08在职责分配矩阵中规定职责。注2：可以使用RASIC表，参见附录Co8. 5工作成果WP-07-018.4.3的要求产生的信息安全接口协议。9持续的信息安全活动9. 1总则持续的信息安全活动可以在全生命周期的每

45、一个阶段进行，也可以在项目之外进行。信息安全监测收集信息安全情报并根据已定义的触发器进行分类。信息安全事态评估帮助确定信息安全事件是否展现了相关项和组件的脆弱性。漏洞分析检查弱点，并评估该弱点是否可被用于发动攻击。漏洞管理跟踪并监督相关项和组件中的漏洞处理，直至信息安全支持结束。10. 目的本章节的目的包括：a）监控信息安全情报从而识别信息安全事态；b）评估信息安全事态从而识别弱点；c）识别来自脆弱性的漏洞；d）管理已识别的漏洞。9.3信息安全监测9.3.1 输入9. 3,1.1先决条件应提供以下信息：在WP-05-01中用于开发触发器的规则和过程。10. 3.1.2附加支持资料可以考虑以下信息：-相关项定义WP-09-01；- 信息安全声明WP-09-04；- 信息安全规范WP-IO-Ol;- 威胁场景WP15-0司；- 过去的漏洞分析结果WP-08-05；- 现场收集的信息；示例：漏洞扫描报告、修复信息、顾客使用信息。- .3.2要求和建议RQ-08-01应选择信息安