本标准规定了计算机信息系统安全工程(以下简称信息安全工程)管理的要求，是对信息安全工程中所涉及到的甲方、乙方与第三方实施安全工程的指导性文件，各方可以此为依据建立安全项目的安全工程管理体系。本标准按照GBl7859—1999划分的五个安全保护等级，规定了对不同安全保护等级的计算机信息系统进行工程实施采用不同安全要求。本标准按照GBl7859—1999的五个安全保护等级的要求，适用于有关信息安全的计算机信息系统开发与集成工程管理，对于提供安全服务和安全工程组织的机构也可参照使用。本标准适用于安全系统的机构和开发商的工程管理，集成商、安全服务的提供商和安全工程的组织商也可参照使用。 GA/T 483-2004 计算机信息系统安全等级保护工程管理要求 GA/T483-2004 标准下载解压密码：www.bzxz.net
本标准规定了计算机信息系统安全工程(以下简称信息安全工程)管理的要求，是对信息安全工程中所涉及到的甲方、乙方与第三方实施安全工程的指导性文件，各方可以此为依据建立安全项目的安全工程管理体系。本标准按照GBl7859—1999划分的五个安全保护等级，规定了对不同安全保护等级的计算机信息系统进行工程实施采用不同安全要求。本标准按照GBl7859—1999的五个安全保护等级的要求，适用于有关信息安全的计算机信息系统开发与集成工程管理，对于提供安全服务和安全工程组织的机构也可参照使用。本标准适用于安全系统的机构和开发商的工程管理，集成商、安全服务的提供商和安全工程的组织商也可参照使用。

GA/T483—2004
GB17859--1999《计算机信息系统安全保护等级划分准则》是我国计算机信息系统信息安全等级管理的重要标准，已于1999年9月13日发布。为促进计算机信息系统安全等级管理工作正常有序地开展，特制定一系列相关的标准，包括：计算机信息系统安全等级保护技术要求系列标准；一计算机信息系统安全等级保护评估准则系列标准；一计算机信息系统安全等级保护工程管理要求；计算机信息系统安全等级保护管理要求。本标准为以上相关系列标准之一。本标准的附录A中列出了等级要求对照表。本标准的附录A是资料性附录。
本标准由公安部公共信息网络安全监察局提出。本标准由公安部信息系统安全标准化技术委员会归口。本标准起草单位：公安部公共信息网络安全监察局、中国电子科技集团第三十研究所、上海三零卫士信息安全有限公司。
本标准主要起草人：张建军、魏忠、叶铭、陈克军、卿昊、吴晓星。Ⅲ
GA/T483—2004
本标准所指的信息系统安全等级保护工程是指按照GB17859--1999及其相关配套标准对计算机信息系统安全等级管理的要求，对信息网络系统、信息应用系统和信息资源开发等项目的新建、扩建和升级。
本标准不仅是计算机信息系统安全等级保护工程实施的指南，而且也是实施计算机信息系统安全等级保护工程、建立工程实施保证体系的依据，同时也是国家相应主管部门进行计算机信息系统安全工程等级评审的依据。本标准可作为甲方、乙方、第三方进行安全保护工程建设时的参考，也可作为制定与安全保护工程质量相关的法令、法规、标准的依据和参考。IV
１范围
计算机信息系统安全等级保护
工程管理要求
GA/T 483---2004
本标准规定了计算机信息系统安全工程（以下简称信息安全工程）管理的要求，是对信息安全工程中所涉及到的甲方、乙方与第三方实施安全工程的指导性文件，各方可以此为依据建立安全项目的安全工程管理体系。
本标准按照GB17859一1999划分的五个安全保护等级，规定了对不同安全保护等级的计算机信息系统进行工程实施采用不同安全要求。本标准按照GB17859—1999的五个安全保护等级的要求，适用于有关信息安全的计算机信息系统开发与集成工程管理，对于提供安全服务和安全工程组织的机构也可参照使用。本标准适用于安全系统的机构和开发商的工程管理，集成商、安全服务的提供商和安全工程的组织商也可参照使用。
2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB17859—1999计算机信息系统安全保护等级划分准则GA/T390--2002计算机信息系统安全等级保护通用技术要求GA/T391—2002计算机信息系统安全等级保护管理要求3术语和定义
下列术语和定义适用于本标准。3.1
information security
信息安全
信息的保密性、完整性和可用性。3.2
甲方owner
信息系统安全工程的投资者（或拥有人），代表信息系统安全工程建设的需求方。3.3
乙方developer
承担信息系统安全工程建设的实体，通过自身的努力，建设信息系统安全工程，满足信息系统建设者的安全需求。
第三方third party
独立于甲、乙两方的组织或机构。3.5
安全工程
security engineering
GA/T483-—2004
为了确保信息系统的保密性、完整性、可用性等目标而进行的系统工程活动。3.6
bh security engineering related activity安全工程相关的活动
与安全工程相关的其他工程活动，其中包括：企业工程、系统工程、软件工程、人力工程、通信工程、硬件工程、测试工程和系统管理。3.7
安全工程的生命期
月 security engineering lifecycle在整个信息系统生命期中执行的安全工程活动包括：概念形成、概念开发和定义、验证与确认、工程实施开发与制造、生产与部署、运行与支持和终止。3.8
组织organization
按一定宗旨和系统建立起来的集体。3.9
项目project
项目是各种相关实施活动和资源的总和，这些实施活动和资源用于开发或维护信息安全工程。个项目往往有相关的资金，成本账目和交付时间表。3.10
过程process
将一个或多个输人进行一系列结构化处理，并将处理结果转化为对用户有价值的相互关联或相互作用的活动。
脆弱性vulnerability
系统中存在的弱点，安全漏洞，或实施缺陷等非设计意图的部分，可被威胁利用对系统进行攻击。3.12
过程能力processcapability
评估组织遵循工程过程能力的量化指标。3.13
过程成熟度process maturity
表明一个特定过程被清晰定义、管理、测量、控制的程度和有效性。3.14
过程管理
process management
一系列用于预见、评价和控制过程执行的活动和体系结构。3.15
安全工程指南　security engineering guide由工程组做出的有关如何选择工程体系结构、设计与实现的决定。3.16
关键资源keyresource
对项目成功与否有决定性影响的重要资源。4安全工程体系
4.1概述
计算机信息系统安全工程等级保护要求体系结构可在整个安全工程范围内决定安全工程的要求等级。本标准使用这个体系结构的目标是清晰地从管理和制度化特征中分离出安全工程的基本特征，建2
立安全工程的等级管理模型。
4.2安全工程目标
GA/T483—2004
理解用户的安全风险，根据已识别的安全风险建立合理的安全要求，将安全要求转换成安全指南，这些安全指南指导项目实施的其他活动，在正确有效的安全机制下建立对信息安全的信心和保证；判断系统中和系统运行时残留的安全脆弱性，及其对运行的影响是否可容忍（即可接受的风险），使安全工程成为一个可信的工程活动，能够满足相应等级信息系统设计的要求。4.3基本模型bzxz.net
由安全等级、保障与实施组成的二维模型（如图1所示），其中保障是由资格保障要求和组织保障要求构成，实施是由工程实施要求和项目实施要求构成。资格保障要求表示一定能力级别所应具备的乙方或与工程相关第三方的资质要求；组织保障要求表示信息安全工程过程要求中对甲方组织保障的要求；工程实施要求表示对信息安全工程中安全过程的要求；项目实施要求表示信息安全工程的项目实施过程要求。
安全等级
第五级
第四级
第三级
第二级
第一级，
保障与实施
5资格保障要求
5.1系统集成资质要求
组织保障
图1安全工程等级保护模型
5.1.1国家主管部门认可一级集成资质。5.1.2国家主管部门认可二级集成资质。5.1.3国家主管部门认可三级集成资质。5.1.4国家主管部门认可四级集成资质。5.2人员资质要求
公安部认可服务人员资质。
5.3第三方服务要求
5.3.1公安部认可一级服务单位资质。5.3.2公安部认可二级服务单位资质。5.3.3公安部认可三级服务单位资质。5.3.4公安部认可四级服务单位资质。5.3.5公安部认可五级服务单位资质。资格保障
GA/T 483—2004
5.4安全产品要求
5.4.1信息安全产品应具有在国内生产、经营、销售的许可证。5.4.2操作系统符合保护等级操作系统同级要求。5.5工程监理要求
5.5.1应具备信息安全系统建设工程实施监理管理制度。5.5.2系统聘请专业监理公司，且监理公司具有国家主管部门认可监理资质证书。5.6密码管理要求
5.6.1符合国家密码主管部门的要求。5.6.2使用的密码产品为国家主管部门批准的密码产品。5.6.3密码产品来源为国家主管部门批准的定点销售单位产品。5.6.4使用的密码产品研制来源于国家主管部门批准的密码研制单位。5.7其他要求
系统符合公共安全的相关法律、法规，按照相关主管部门的技术管理规定手段对非法信息和恶意代码进行有效控制，按照有关规定对设备进行控制使之不被作为非法攻击源或跳板。6组织保障要求
6.1定义组织的系统工程过程
6.1.1制定过程目标
6.1.1.1从组织的应用目标出发为组织的系统工程过程制定目标。6.1.1.2系统工程过程在商务环境中运行，为了使组织的标准实现制度化，该目标应得到明确的认可；这个过程的目标应考虑财力、质量、人力资源和对业务成功起重要作用的问题。6.1.2收集过程资产
6.1.2.1收集和维护系统工程过程资产。6.1.2.2在组织和项目层次中，由过程定义活动所产生的信息都需要存储（在过程资产库中），使得那些剪裁、过程设计活动中的资产能被使用人理解，并得到维护与保持。6.1.3开发组织的系统工程过程
6.1.3.1为组织开发一个充分定义的标准系统工程过程。6.1.3.2在开发组织的标准系统工程过程中，可能使用到过程资产库中的设备；在开发任务时，可能需要一些新的过程资产，应该将这些资产添加到过程资产库中；应该将组织的标准系统工程过程置于过程资产库中。
6.1.4定义剪裁指南
定义剪裁组织的标准系统工程过程的指南，该指南在开发项目的定义过程中使用。6.2改进组织的系统工程过程
6.2.1概要
本要求项包括在组织中用以测量和改进系统工程过程执行的连续活动，利用组织过程资产的初始收集和组织的标准系统工程过程的定义，通过不断改进组织使用的系统工程过程的有效性和效率以获得更大的竞争优势。
6.2.2评定过程
6.2.2.1评定组织中现有的执行过程以便了解它们的强项和弱项，了解组织现有的执行过程的强项和弱项是建立改进活动基线的关键。6.2.2.2评定时应考虑过程执行的测量与课程学习过程；评定可以多种形式进行，评定方法的选择应与文化和组织需求相匹配。
6.2.3规划过程改进
GA/T 483—2004
应基于对潜在改进所产生影响的分析，为组织制订过程改进计划，以达到过程的目标。6.2.4改变标准过程
改变组织的标准系统工程过程以便反映目标的改进6.2.5沟通过程改进
适当地同现有项目和其他有相关团体共同沟通过程的改进。6.3管理系列产品进化
6.3.1概要
应通过引进服务、设备和新技术以达到产品更新、减少工程费用的目的，达到工程进度和执行的最佳收益，与产品系列一同向其最终目标进化发展。6.3.2定义产品进化
6.3.2.1定义要提供产品的类型。6.3.2.2定义支持组织战略目标的系列产品。6.3.2.3考虑组织的强项和弱项、竞争力、潜在的市场份额和可利用的技术。6.3.3标识新生产技术
6.3.3.1标识新生产技术或加强基础设施建设，将有助于组织获取、开发和应用新生产技术来提高竞争优势。
6.3.3.2确定可能引人到系列产品的新生产技术，为确定新技术和基础设施改进而建立并能维护的原始资料和方法。
6.3.4适应开发过程
6.3.4.1在产品开发周期中采取必要的变动以支持新产品的开发。6.3.4.2适应组织的产品开发过程，熟悉并利用准备在将来使用的组件。6.3.5确保关键组件的可用性
6.3.5.1确保关键组件都可利用，并可以支持有计划的产品改进。6.3.5.2组织应决定产品系列的关键组件及其可用性的计划。6.3.6插入产品技术
6.3.6.1将新的技术插人到产品开发、市场营销和制造过程中。6.3.6.2管理将新技术引入到系列产品的工作（包括现有产品系列组件的改进、新组件的引进）；标识和管理与产品设计变化有关的风险。6.4管理系统工程支持环境
6.4.1概要
本要求项列出了在项目层面和组织层面都属于系统工程支持环境的事项。支持环境的元素由系统工程活动的所有环境组成，包括：计算机资源、网络带宽、分析方法、组织结构策略和程序、机器的购买、化学处理设施、环境强调设施、系统工程仿真工具、软件开发工具、专有的系统工程工具、工作空间等。6.4.2维持技术认识
6.4.2.1维持对支持实现组织目标的那些技术的认识。6.4.2.2对工艺现状或实施现状应该插人新的技术，组织应具有对新技术的充分认识。6.4.3确定支持需求
根据组织的需要确定组织的系统工程支持环境的需求。6.4.4获得系统工程支持环境
6.4.4.1获得个系统工程支持环境，该环境要满足在确定支持需求中通过利用分析候选解决要求项的实施而建立的要求。
6.4.4.2针对所需的系统工程支持环境，确定其评价标准和潜在的候选解决方案；利用分析候选解决要求项选择一个解决方案；得到并实现所选的系统工程支持环境。5
GA/T 483—2004
6.4.5剪裁系统工程支持环境
剪裁系统工程支持环境，以满足单个项目的要求。6.4.6插入新技术
6.4.6.1根据组织的应用目标和项目需要将新技术插人到系统工程支持环境中。6.4.6.2组织的系统工程支持环境应用新技术更新，并要支持组织的应用目标及工程需要；在系统工程支持环境中，应提供使用新技术的培训。6.4.7维护环境
6.4.7.1维护系统工程支持环境以持续支持依赖该环境的项目。6.4.7.2维护活动包括计算机系统管理、培训、热线支持、专家的作用、发展或者扩充一个技术库等。6.4.8监视系统工程支持环境
6.4.8.1监视系统工程支持环境以发现改进的机会。6.4.8.2确定影响系统工程支持环境有用性的因素，包括任何新插入的技术；监视新技术和整个系统工程支持环境的接受情况。
6.5培训
6.5.1确定培训要求
6.5.1.1以项目的要求、组织的战略计划和现有的员工技能情况为指导，确定组织在技能与知识方面所需的改进。
6.5.1.2综合现有的程序、组织的战略计划和现有员工的技能等各方面信息确定这些要求。6.5.2选择知识或技能的获取模式6.5.2.1评价和选择通过培训或其他资源获取知识或技能的适当模式。6.5.2.2应确保所选择的方法是最佳的，以使得所需技能和知识对项目及时有效。6.5.3确保技能和知识的可用性
确保技能和知识对系统工程活动是适用的。6.5.4准备培训材料
6.5.4.1根据确定的培训要求准备培训材料。6.5.4.2为每一个由组织内部人员建成的班编制培训材料，或为每一个已存在的班准备培训材料。6.5.5培训人员
6.5.5.1培训教员要具备执行赋予他们的角色的技能与知识。6.5.5.2要根据培训计划和编制的材料进行人员培训。6.5.6评估培训的有效性
6.5.6.1评估培训的有效性以满足所确定的培训要求，6.5.6.2评估有效性的方法应与培训计划编制和培训材料的拟定同时列出；应及时获取有效性评估的结果，以便对培训做出相应调整6.5.7维护培训记录
6.5.7.1维护培训与取得经验的记录。6.5.7.2维护记录以追踪每个人员接受培训的情况，以及受训后的技能和能力。6.5.8维护培训材料
6.5.8.1维护知识库中的培训材料。6.5.8.2维护知识库中的课件材料以供员工今后访问，并且在课程材料变动时可供跟踪。6.6与供应商协调
6.6.1确定系统的组件或服务
确定应由其他外部组织提供的系统组件或服务。6.6.2确定胜任的供应商或销售商6
6.6.2.1标识在特定领域中具有专门技术的供应商。GA/T 483-2004
6.6.2.2供应商的能力包括胜任开发过程、制造过程、验证责任、及时交付、生命期支持过程，以及远程有效通信能力，上述能力应符合本组织的各项要求6.6.3选择供应商或销售商
6.6.3.1依照要求项（7.1)选择供应商。6.6.3.2以合乎逻辑和公平的方式选择供应商以满足产品的目标；提供最能弥补本组织能力的供应商特征，识别合格的候选者；利用要求项（7.1)的实施来选择出合适的供应商。6.6.4提供期望
6.6.4.1对供应商提出组织对系统组件或服务的要求、期望和效果指标。6.6.4.2在合同签署时组织应将它的要求和期望清楚地指明并排出优先顺序，并且要指明对供应商方面的所有限制；组织要与供应商密切合作，使其充分了解产品达到的要求和自已要承担的责任，并达成相互理解。
6.6.5维持沟通
6.6.5.1与供应商维持及时的双向沟通。6.6.5.2组织与供应商要对期望的和所需的沟通建立相互谅解。所建立的沟通的特点包括：双方公认的公开的没有任何限制的信息类型，受限的信息类型（如策略或合同关系），所期望的信息请求与回应的及时性，用于沟通的工具和方法，安全，保密以及期望的分布情况。7工程实施要求
7.1管理安全控制
7.1.1概要
应保证系统在运行状态下达到设计预期的安全特性，安全控制措施被配置且能正常使用。7.1.2建立安全职责
7.1.2.1建立安全控制措施的职责和责任并通知到组织中的每一个人。7.1.2.2本项目应该保证承担相应安全责任的人员是负责的，并获得相应的授权；应该保证采用的所有安全控制措施是明确的，并被广泛和一致地应用。7.1.3管理安全措施的配置
7.1.3.1所有设备的安全配置都需要管理。7.1.3.2管理系统安全控制措施的配置。管理安全意识、培训和教育大纲7. 1.4
组织和管理对所有员工进行安全意识的培训和教育。7. 1. 4. 1
7.1.4.2管理所有的用户和管理员的安全意识、培训和教育大纲。管理安全服务及控制机制
安全服务及控制机制的一般管理类似于其他服务及机制的管理，包括保护它们避免损伤、偶7. 1.5. 1
然事故和人为故障，并根据法律和政策要求进行整理并归档。7.1.5.2对安全服务及控制机制进行定期的维护和管理。7.2评估影响
7.2.1概要
应识别对该系统有关系的影响，并对发生影响的可能性进行评估。7.2.2对影响进行优先级排列
对在系统中起关键作用的运行、商务或任务的能力进行识别、分析和按优先级排列。7.2.3识别系统资产
7.2.3.1对支持系统的安全目标或关键性能力（运行、商务或任务功能）进行识别。7
GA/T 483—2004
7.2.3.2对必需的系统资源和数据进行识别；通过对给定环境中提供这种支持的每项资产的意义进行评估，来对每项资产进行定义。7.2.3.3对支持系统的关键性运行能力或安全目标的系统资产进行识别和特征化。7.2.4选择影响的度量
应预先确定适合的度量用于评估影响。7.2.5标识度量关系
标识所选影响的评估度量与度量转换因子之间的关系。7.2.6识别和特征化影响
利用多重度量或统一度量的方法对意外事件的意外影响进行识别和特征化。7.2.7监视影响
监视影响中的变化，本条与7.8.3中的通用性监视活动紧密相连。7.3评估安全风险
7.3.1概要
通过对在一给定环境中运行该系统相关的安全风险的理解，并按照给定的方法论对风险问题进行优先级排序。
7.3.2选择风险分析方法
7.3.2.1本要求项包括定义用于识别给定环境中的系统安全风险的方法，该方法是对安全风险进行分析、评估和比较；应该包括个对风险进行分类和分级的方案，其依据是威胁、运行功能、已建立的系统脆弱性、潜在损失、安全需求等相关问题。7.3.2.2选择用于分析、评估和比较给定环境中系统安全风险所依据的方法、技术和准则。7.3.3识别风险
7.3.3.1识别该风险，认识这些威胁和脆弱性的利害关系，进而识别出威胁和脆弱性造成的影响；这些风险在选择系统保护措施中应予以考虑。7.3.3.2识别威胁/脆弱性/影响三组合（风险）。7.3.4评估风险
7.3.4.1识别每个风险出现的可能性。7.3.4.2评估与每个风险有关的风险。7.3.5评估总体不确定性
7.3.5.1每种风险都有与之相关的不确定性；总体风险不确定性是在7.4.6中已被标识的威胁、脆弱性和影响及其特征不确定性的积累、7.4.6、7.5.4以及7.3.6。本要求项与7.6密切相关，因为证据能用于追踪修改，从而在某种输人下降低不确定性。7.3.5.2评估与该风险有关的总体不确定性。7.3.6风险优先级排列
7.3.6.1已经被识别的风险应以组织优先权、风险出现的可能性与这些因素相关的不确定性和可用财力为依据进行排序；风险可以被减轻、避免、转移或接受，也可以使用这些措施的组合。“减轻”这一措施能够对付威胁、脆弱性、影响或风险本身；安全措施的选择要适当考虑到7.10“指定安全要求”中的要求，商务优先级和整个系统体系结构。7.3.6.2按优先级对风险进行排列。7.3.7监视风险及其特征
7.3.7.1定期地检查新的风险，本条与7.8.3“监视威胁、脆弱性、影响、风险和环境方面的变化”中一般性监视活动紧密相联。
7. 3.7.2监视风险频率变化和风险特征的变化。7.4评估威胁
7.4.1概要
GA/T 483—2004
应识别安全威胁及其性质和特征，对系统安全的威胁进行标识和特征化；应定期地对威胁进行监视，以保证由本要求项所产生的安全理解始终得到维持。7.4.2识别自然威胁
识别由自然原因引起的相应威胁。7.4.3识别人为威胁
识别由人为偶然原因引起的威胁与故意行为引起的威胁。7.4.4识别威胁的测量尺度
7.4.4.1对可能在特定位置中出现的预料中事件，应根据真体情况建立最大和最小测量单位范围。7.4.4.2识别特定环境中适当的测量尺度和适用范围。7.4.5评估威胁影响的效果
7.4.5.1确定对系统进行成功攻击的黑客潜在的能力。7.4.5.2评估由人为原因引起的威胁影响的动因和结果。7.4.6评估威胁的可能性
对威胁事件如何发生的可能性进行评估，评估出现威胁事件的可能性。7.4.7监视威胁及其特征
7.4.7.1有规律地对现有威胁及其特征进行监视，并检查新的威胁；本条与7.8.3的一般化监视活动紧密相连。
7.4.7.2监视威胁频谱中不断的变化以及相应特征的变化。7.5评估脆弱性
7.5.1概要
应识别和特征化系统的安全脆弱性。本要求项包括分析系统资产、定义特殊的脆弱性以及提供对整个系统脆弱性的评估，并获得对一确定环境中系统安全脆弱性的理解。7.5.2选择脆弱性分析方法
7.5.2.1所有分析应在预先安排和指定时间内，在一个已知的并记录有配置的框架内进行；分析的方法论应包括预期结果；分析的特定目标应陈述清楚。7.5.2.2选择对一确定环境中系统安全脆弱性进行识别和特征化的方法、技术和标准。7.5.3识别脆弱性
7.5.2中研究过的脆弱性分析方法论应延伸到对脆弱性的证实；所有发现的系统安全脆弱性应予以记录、识别。
7.5.4收集脆弱性数据
收集与脆弱性相关的数据。
7.5.5综合系统脆弱性
分析哪些脆弱性或脆弱性的组合会对系统道成问题，所有分析应识别出该脆弱性的特征；评估由特定脆弱性和特定脆弱性组合所产生的系统脆弱性与总体脆弱性。7.5.6监视脆弱性及其特征
7.5.6.1本项要求与7.8.3的变化的一般性监视活动紧密相连。7.5.6.2监视脆弱性及其特征的连续变化。7.6建立保证论据
7.6.1概要
本项目包括对与需求有关的保证进行识别和定义，包括证据的产生和分析的活动，包括支持保证需求所需的附加证据、文档清单和过程以及那些能清晰地向用户提供已满足其安全需求的证据本项目要求建立保证证据有关的活动记录，包括管理、标识、计划、封装和提交安全保证证据。GA/T 483—2004
7.6.2识别保证目标
7.6.2.1识别安全保证目标。
7.6.2.2系统安全保证目标应规定强制性系统安全策略的机密性等级：目标的充分性由开发者、集成者、用户和签名授权者确定。
7.6.2.3新的和修改过的安全保证目标的标识应与所有内部和外部工程组织等安全相关性团体保持协调一致。
7.6.2.4对安全保证目标进行修改的内容需及时解释其中变化。7.6.2.5安全保证目标应清晰地沟通。7.6.3定义保证策略
7.6.3.1规划并确保正确地实现强制性安全目标；通过实现安全保证策略所产生的证据应（向系统签名授权者）提供一个可接受的机密性等级，此等级安全的测量足以管理安全风险。通过开发并颁布安全保证策略，获得对保证的相关活动进行有效管理；工程早期应对需求相关的保证进行的识别和定义产生必要的支持证据；通过不断外部协调，对保证用户需求的满意程度进行理解和监视，确保高质量组合保证要求。
7.6.3.2为所有保证目标定义一个安全保证策略。7.6.4控制保证证据
安全保证证据通过与所有工程实施要求项相互配合，在安全保证策略内识别出的不同层面抽象的证据的方法进行收集；证据应受到控制。7.6.5分析证据
对安全保证证据进行分析，保证工程产品相对于基线系统是完善和正确的。7.6.6提供保证论据
7.6.6.1开发出一个完整的证明与安全目标一致的安全保证论据，并提供给用户；保证论据是由多层抽象中获得的保证证据的组合所支持的一系列声明性保证目标；应对提交证据中的缺陷和安全保证目标中的缺陷进行复查。
7.6.6.2提供证明用户安全需求得到满足的安全保证性论据。7.7协调安全
7.7.1概要
保证所有部门都有一种参与安全工程的意识，协调并保持所涉及到安全组织、其他工程组织和外部组织之间的关系；多种机制用于在这些部门之间协调和沟通安全工程的决定和建议，包括备忘录、文档、电子邮件、会议和工作组。
项目组的所有成员应具有参与安全工程工作的意识，有关安全的决策和建议是相互沟通和协调一致的结果。
专业的安全工程师应该是所有主要设计队伍和工作组、开发和运行机构；在做出关键设计决定后的工程生命期早期应建立起安全工程与其他工程队伍间的联系。7.7.2定义协调目标
定义和建立与其他组织之间的联系和义务关系；这些关系应被全体参与部门所接受。7.7.3识别协调机制
识别安全工程的协调机制，明确协调机制实现的方法。7.7.4促进协调
7.7.4.1确保不同优先级的不同组织间进行沟通有可能发生的一些冲突和争端以合适的、富有成果的方式得到解决。
7.7.4.2促进安全工程的协调。
7.7.5协调安全决定和建议
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。