GB T 20282-2006 信息安全技术.信息系统安全工程管理要求.pdf

《GB T 20282-2006 信息安全技术.信息系统安全工程管理要求.pdf》由会员分享，可在线阅读，更多相关《GB T 20282-2006 信息安全技术.信息系统安全工程管理要求.pdf（39页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.020 L 09 毒国中华人民共和国国家标准G/T 20282-2006 信息安全技术信息系统安全工程管理要求Information security technology-Information system security engineering management requirements 2006-05-31发布中华人民共和国国家质量监督检验检菇总局中国国家标准化管理委员会2006-12-01实施中华人民共和国国家标准信息安全技术信息系统安全工程管理要求GB/T 202822006 4峰中国标准出版社出版发行北京复兴门外三里河北街16号邮政编码:100045网址电话:

2、6852394668517548 中国标准出版社秦皇岛印刷厂印刷各地新华书店经销奇峰开本880X 1230 1/16 印张2.5字数71千字2006年9月第一版2006年9月第一次印刷* 书号:155066 1-27972 定价18.00元如有印装差错由本社发行中心调换版权专有侵权必究举报电话:(010)68533533GB/T 20282-2006 目次E1112222222222333334556667788990112233I 求uuu要u程程uu性过过境uuuuuu合u程程环-uu性符工工化持uuUUH-H要u求HH策统统演支HHHUHHHH.全示u质求要求求政H系系品程调制险H据势i

3、k求安文u系目u求资要务要要L求的的产工协求控u风川性论态输要认札风U用义体程系要成质服品理如要织织列统商要全响全胁弱证全全全全确要证置目引定程工关证集资方产监J证组组系系应施安影安戚脆保安安安安和施保配项.性和工述全本保统员三全程律保义进理理训供实理估估古估立调视共定证实量理理围范语全概安基格系人第安工法织定改管管培与程管评评评评建协监制指验目质管管言范规术安资组工01项tI1i。Lqu1iqi】qJA峙ARUno-9unJA吐RUEU唱1。LqJA吐RUEU句ioOQU1i141i9年J-A剧12344.Ah511旦旦旦旦66.6.队队667777777777778888G/T 20282

4、-2006 8.4 监视技术活动. . . 14 8. 5 计划技术活动.9 安全工程管理分等级要求.9.1 第一级:用户自主保护级9.2 第二级:系统审计保护级.17 9.3 第三级:安全标记保护级9.4 第四级:结构化保护级209.5 第五级:访问验证保护级9. 6 安全保护等级划分与安全工程要求对照表10 安全工程流程与安全工程要求n10.1 安全工程流程2310. 2 安全工程流程各阶段的安全工程要求.附录A(资料性附录)安全工程要求与安全保护等级、安全工程流程的对应关系27参考文献. 34 E GB/T 20282-2006 目。自本标准的附录A是资料性附录。本标准由信息安全标准化技

5、术委员会提出并归口。本标准起草单位:中国电子科技集团第三十研究所、上海三零卫士信息安全有限公司、上海标准化研究院。本标准主要起草人z张建军、魏忠、叶铭、陈长松、孔一童。阳山GB/T 20282-2006 信息安全技术信息系统安全工程管理要求1 范围本标准规定了信息系统安全工程(以下简称安全工程)的管理要求，是对信息系统安全工程中所涉及到的需求方、实施方与第三方工程实施J茹前苔方可3TJIf荆吗建立安全工程管理体系。本标准按照GB17859- 1999 要求。本标准适用于信息系统2 规范性引用文件GB/ T 20 269-GB/ T 20271一3 术语和定义3. 1 3.2 安全工程的生存周在

6、整个信息系统生程实施开发与制造、生产与3.3 安全工程指南security 由工程组做出的有关如何选择3.4 脆弱性vulnerability 能够被某种威胁利用的某个或某组资产的弱点。3.5 凤险risk 义、验证与确认、工某种威胁会利用一种资产或若干资产的脆弱性使这些资产损失或破坏的可能性。3.6 需求方owner 信息系统安全工程建设的拥有者或组织者。GB/T 20282-2006 3. 7 实施方developer 信息系统安全工程的建设与服务的提供方。3.8 第三方third party 独立于需求方、实施方，从事信息系统安全工程建设相关活动的中立组织或机构。3.9 项目projec

7、f 项目是各种相关实施活动和资源的总和，这些实施活动和资源用于开发或维护信息系统安全工程。一个项目往往有相关的资金，成本账目和交付时间表。3.10 过程proc四S把输入转化为输出的一组相关活动。3. 11 过程管理process management 一系列用于预见、评价和控制过程执行的活动和体系结构。4 安全工程体系4. 1 概述在整个工程范围内确定了不同等级工程的具体要求构成了安全工程管理要求体系。通过这个体系从安全工程中分离出实施和保证的基本特征，建立信息系统安全分级保护要求与工程管理的关系。4.2 安全工程目标理解需求方的安全风险，根据己标识的安全风险建立合理的安全要求，将安全要求转

8、换成安全指南，这些安全指南指导项目实施的其他活动，在正确有效的安全机制下建立对信息安全的信心和保证;判断系统中和系统运行时残留的安全脆弱性，及其对运行的影响是否可容忍(即可接受的风险)，使安全工程成为一个可信的工程活动，能够满足相应等级信息系统设计的要求。4.3 基本关系安全工程由安全等级、保证与实施要求两个维度组成，不同等级要求的安全工程对应不同的保证与实施要求。其中保证是由资格保证要求和组织保证要求构成，实施是由工程实施要求和项目实施要求构成。资格保证要求表示信息安全工程中对应具备一定能力级别的实施方或与工程相关第三方资质的要求;组织保证要求表示信息安全工程过程要求中对需求方组织保证的要求

9、;工程实施要求表示信息安全工程中对安全实施过程的要求;项目实施要求表示信息安全工程中对项目实施过程的要求。5 资格保证要求5. 1 系统集成资质要求国家主管部门认可的系统集成资质。5.2 人员资质要求国家主管部门认可的安全服务人员资质。5. 3 第三方服务要求国家主管部门认可的服务单位资质。5.4 安全产晶要求信息安全产品应具有在国内生产、经营、销售的许可证，并符合相应的等级。5.5 工程监理要求5.5.1 应具备信息安全系统建设工程实施监理管理制度。GB/T 20282-2006 5.5.2 系统聘请专业监理公司，且监理公司具有国家主管部门认可监理资质证书。5.6 法律、法规、政策符合性要求

10、系统应符合国家相关的法律、法规和政策。6 组织保证要求6. 1 定义组织的系统工程过程6. 1. 1 基本要求应为系统工程定义一套标准有明确目标的过程，这套标准的过程可以通过裁剪应用于定义新工程项目的过程。6.1.2 制定过程目标6. 1.2. 1 从组织的应用目标出发为组织的系统工程过程制定目标。6.1.2.2 系统工程过程在业务环境中运行，为了使组织的标准实现制度化，该目标应得到明确的认可;这个过程的目标应考虑财力、质量、人力资源和对业务成功起重要作用的问题。6. 1.3 收集过程资产6. 1. 3. 1 收集和维护系统工程过程资产。6.1.3.2 在组织和项目层次中，由过程定义活动所产生

11、的信息都需要存储(在过程资产库中)，使得那些剪裁、过程设计活动中的资产能被使用人理解，并得到维护与保持。6.1.4 开发组织的系统工程过程6.1.4. 1 为组织开发一个充分定义的标准系统工程过程。6. 1. 4. 2 在开发组织的标准系统工程过程中，可能使用到过程资产库中的设备;在开发任务时，可能需要一些新的过程资产，应该将这些资产添加到过程资产库中;应该将组织的标准系统工程过程置于过程资产库中。6.1.5 定义剪裁指南定义剪裁组织的标准系统工程过程的指南，该指南在开发项目的定义过程中使用。6.2 改进组织的系统工程过程6.2.1 基本要求应实施测量和改进系统工程过程的连续活动，以标准系统工

12、程过程定义为基础，通过不断改进活动提高组织系统工程过程的效益和效率。6.2.2 评定过程6.2.2.1 评定组织中现有的执行过程以便了解它们的强项和弱项，了解组织现有的执行过程的强项和弱项是建立改进活动基线的关键。6.2.2.2 评定时应考虑过程执行的测量与课程学习过程;评定可以多种形式进行，评定方法的选择应与文化和组织需求相匹配。6.2.3 规划过程改进应基于对潜在改进所产生影响的分析，为组织制定过程改进计划，以达到过程的目标。6.2.4 改变标准过程改变组织的标准系统工程过程以便反映目标的改进。6.2.5 沟通过程改进适当地同现有项目和其他相关团体共同沟通过程的改进。6.3 管理系列产品演

13、化6.3. 1 基本要求应通过引进服务、设备和新技术实现产品更新与工程费用降低，获取工程进度和执行的最佳收益。6.3.2 定义产品演化6.3.2.1 定义要提供产品的类型。3 G/T 20282-2006 6.3.2.2 定义支持组织战略目标的系列产品。6.3.2.3 考虑组织的强项和弱项、竞争力、潜在的市场份额和可利用的技术。6.3.3 标识新生产技术6.3.3.1 标识新生产技术或加强基础设施建设，将有助于组织获取、开发和应用新生产技术来提高竞争优势。6.3.3.2 确定可能引入到系列产品的新生产技术，为确定新技术和基础设施改进而建立并能维护的原始资料和方法。6.3.4 适应开发过程6.3

14、. 4.2 适应组织的产品开发过挚;7fWJ6.3.5 确保关键组件的可用6.3.5. 1 确保关键组件都和管理与产品设t6.4 管理系统6. 4. 1 基本要应能够为态的变化对支6.4.2 维持6.4.2. 1维. ，.酌6.4.2.2 X才6.4.3 确定根据组织6.4.4.2 针对所需要求项选择一个解决6.4.5 剪裁系统工程剪裁系统工程支持环6.4.7 维护环境案;利用分析候选解决:;11工程支持环境中。，要支持组织的应用目标及工程需要;在系统工6.4.7. 1 维护系统工程支持环境以持续支持依赖该环境的项目。6.4.7.2 维护活动包括计算机系统管理、培训、热线支持、专家的作用、发展

15、或者扩充一个技术库等。6.4.8 监视系统工程支持环境6.4.8.1 监视系统工程支持环境以发现改进的机会。6.4.8.2 确定影响系统工程支持环境有用性的因素，包括任何新插入的技术;监视新技术和整个系统工程支持环境的接受情况。4 GB/T 20282-2006 6.5 培训6.5. 1 基本要求应建立一套完整的培训体系，能够为员工提供满足组织需求并适用于系统工程活动的、及时有效的知识与技能培训11。6.5.2 确定培训要求6.5.2.1 以项目的要求、组织的战略计划和现有的员工技能情况为指导，确定组织在技能与知识方面所需的改进。6.5.2.2 综合现有的程序、组织的战略计划和现有员工的技能等

16、各方面信息确定这些要求。6.5.6.2要6.5.7 评估6.5.7.1评6.5.7.2评结果，以便对6.5.8 维护6.5.9.2 维护知认6.6 与供应商协调6.6. 1 基本要求应能够根据工程的需飞品或服务。6.6.2 确定系统的组件或服务-确定应由其他外部组织提供的系统组件旦6.6.3 确定胜任的供应商或销售商6.6.3.1 标识在特定领域中具有专门技术的供应商。为系统工程提供满足要求的产6.6.3.2 供应商的能力包括胜任开发过程、制造过程、验证责任、及时交付、生存周期支持过程及远程有效通信能力，上述能力应符合本组织的各项要求。6.6.4 选择供应商或销售商6.6.4.1 依照7.1选

17、择供应商。6.6.4.2 以合乎逻辑和公平的方式选择供应商以满足产品的目标;提供最能弥补本组织能力的供应商特征，标识合格的候选者;通过要求项7.1的实施来选择出合适的供应商。5 GB/T 20282-2006 6.6.5 提出要求6.6.5.1 对供应商提出组织对系统组件或服务的要求、期望和效果指标。6.6.5.2 在合同签署时组织应将它的要求和期望清楚地指明并排出优先顺序，并且要指明对供应商方面的所有限制;组织要与供应商密切合作，使其充分了解产品达到的要求和自己要承担的责任，并达成相互理解。6.6.6 维持沟通6.6.6. 1 与供应商维持及时的双向沟通。6.6.6.2 组织与供应商要对期望

18、的和所需的沟通建立相互谅解。所建立的沟通的特点包括:双方公认的公开的没有任何限制的信息类型，受限的信息类型(如策略或合同关系)，所期望的信息请求与回应的及时性，用于沟通的工具和方法，安全、保密以及期望的分布情况。7 工程实施要求7. 1 管理安全控制7. 1. 1 基本要求应保证系统在运行状态下达到设计预期的安全特性，安全控制措施被配置且能正常使用。7. 1. 2 建立安全职责7. 1. 2.1 建立安全控制措施的职责和责任并通知到组织中的每一个人。7.1.2.2 本项目应该保证承担相应安全责任的人员是负责的，并获得相应的授权;应该保证采用的所有安全控制措施是明确的，并被广泛和一致地应用。7.

19、 1. 3 管理安全配置7. 1. 3. 1 所有设备的安全配置都需要管理。7. 1. 3. 2 管理系统安全控制措施的配置。7.1.4 管理安全意识、培训和教育大纲7. 1. 4.1 组织和管理对所有员工进行安全意识的培训和教育。7.1.4.2 管理所有的需求方和管理员的安全意识、培训和教育大纲。7. 1. 5 管理安全服务及控制机制7. 1.5. 1 安全服务及控制机制的一般管理类似于其他服务及机制的管理，包括保护它们避免损伤、偶然事故和人为故障，并根据法律和政策要求进行整理并归挡。7. 1.5.2 对安全服务及控制机制进行定期的维护和管理。7.2 评估影响7.2.1 基本要求应标识对该系

20、统有关系的影响，并对发生影响的可能性进行评估。7.2.2 对影晌进行优先级排列对在系统中起关键作用的运行、业务或任务的能力进行标识、分析和按优先级排列。7.2.3 标识系统资产7.2.3. 1 对支持系统的安全目标或关键性能力(运行，业务或任务功能)进行标识。7.2.3.2 对必需的系统资源和数据进行标识;通过对给定环境中提供这种支持的每项资产的意义进行评估，来对每项资产进行定义。7.2.3.3 对支持系统的关键性运行能力或安全目标的系统资产进行标识和特征化。7.2.4 选择影晌的度量应预先确定适合的度量用于评估影响。7.2.5 标识度量关系标识所选影响的评估度量与度量转换因子之间的关系。6

21、GB/T 20282-2006 7.2.6 标识和特征化影晌利用多重度量或统一度量的方法对意外事件的意外影响进行标识和特征化。7.2.7 监视影响监视影响中的变化，本条与7.8.3中的通用性监视活动紧密相连。7.3 评估安全凤险7.3. 1 基本要求应对在特定环境中运行该系统相关的安全风险进行标识与评价，并按照一定的方法对风险问题进行优先级排序。7.3.2 选择凤险分析方法7.3.2.1 本要求项包括定义用于标识给定环境中的系统安全风险的方法，该方法是对安全风险进行分析、评估和比较;应该包括一个对风险进行分类和分级的方案，其依据是威胁、运行功能、已建立的系统脆弱性、潜在损失、安全需求等相关问题

22、。7.3.2.2 选择用于分析、评估和比较给定环境中系统安全风险所依据的方法、技术和准则。7.3.3 标识安全风险7.3.3.1 标识该风险，认识这些威胁和脆弱性的利害关系，进而标识出威胁和脆弱性造成的影响F这些风险在选择系统保护措施中应予以考虑。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.5.4中已被标识的威胁、脆弱性及其特征和影响不确定性的累积。本要求项与7.6密

23、切相关，因为证据能用于追踪修改，从而在某种输入下降低不确定性。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.

24、2 监视安全风险频度变化和风险特征的变化。7.4 评估威胁7.4. 1 基本要求应标识安全威胁及其性质和特征，对系统安全的威胁进行标识和特征化;应定期地对威胁进行监视，以保证由本要求项所产生的安全理解始终得到维持。7.4.2 标识自然威胁标识由自然原因引起的相应威胁。7.4.3 标识人为威胁标识由人为偶然原因引起的威胁与故意行为引起的威胁。7 GB/T 20282-2006 7.4.4 标识威胁的测量尺度7.4.4. 1 对可能在特定位置中出现的预料事件，应根据具体情况建立最大和最小测量单位范围。7.4.4.2 标识特定环境中相应的测量尺度和适用范围。7.4.5 评估威胁影晌的效果7.4.5.

25、1 确定对系统进行成功攻击的黑客潜在的能力。7.4.5.2 评估由人为原因引起的威胁影响的动因和结果。7.4.6 评估威胁的可能性对威胁事件如何发生的可能性进行评估，评估出现威胁事件的可能性。7.4.7 监视威胁及其特征7.4.7. 1 有规律地对现有威胁及其特征进俨I紧密相连。7.5 评估脆弱性7.5.1 基本要求应标识和特征化系统脆弱性的评估，并获得对7.5.2.1 所有分析应法论应包括预期结果;f析7.5.2.2 选择对一7.5.3 标识脆弱性7.5.2中研究过以记录、标识。7.5.4 收集脆弱性收集与脆弱性相杂的7.5.5 综合系统脆弱分析哪些脆弱性豆定脆弱性和特定脆弱性7.5.6 监

26、视脆弱性及其7.5.6. 1 本项要求与7.8.7.5.6.2 监视脆弱性及其币7.6 建立保证论据7.6. 1 基本要求应对需求相关的保证证据进行标l的附加证据、文档清单和过程以及那些能渝地血雷求方提盐门本条与7.7.2的一般化监视活动脆弱性应予本项目要求建立保证证据有关的活动记录，包括管理、标识、计划、封装和提交安全保证证据。7.6.2 标识保证目标7.6.2. 1 标识安全保证目标。7.6.2.2 系统安全保证目标应规定强制性系统安全策略的保密性等级;目标的充分性由开发者、集成者、需求方和签名授权者确定。7.6.2.3 新的和修改过的安全保证目标的标识应与所有内部和外部工程组织等安全相关

27、性团体保持协调一致。7.6.2.4 对安全保证目标进行修改的内容需及时解释其中变化。7.6.2.5 安全保证目标应清晰地沟通。7.6.3 定义保证策略GB/T 20282-2006 7.6. 3. 1 规划并确保正确地实现强制性安全目标;通过实现安全保证策略所产生的证据应(向系统签名授权者)提供一个可接受的保密性等级，此等级安全的测量足以管理安全风险。通过开发并颁布安全保证策略，获得对保证的相关活动进行有效管理;工程早期应对需求相关的保证进行的标识和定义产生必要的支持证据;通过不断外部协调，对保证需求方需求的满意程度进行理解和监视，确保高质量组合保证要求。7. 6.3.2 为所有保证目标定义一

28、个安全保证策略。7.6.4 控制保证证据安全保证证据通过与所有工程实施要证据的方法进行收集;证据应受到控-。7.7. 4 促进协调7.7. 4. 1 确保不同优先1方式得到解决。7. 7.4.2 促进安全工程的巴7.7.5 协调安全确定和建议在各种安全工程组织、其他、.、出的机制去协调有关安全的确定和矗7.8 监视安全态势7.8. 1 基本要求应标识并报告所有的安全违规行为;监视外部和内部环境中可能影响系统安全的所有因素;探测和跟踪内部和外部与安全有关的事件。根据策略制定响应突发事件的措施;根据安全目标标识并处理运行安全态势的变化。7. 8.2 分析事件记录检测安全相关性信息的历史和事件记录，

29、通过多条记录中的事件相关元素，标识出安全事件;分析事件记录，以确定事件的原因、预测可能发生的事件。7. 8.3 监视变化监视威胁、脆弱性、影响、风险和环境方面的变化，查找可能影响当前安全状态有效性的任何变化;GB/T 20282-2006 监视所有因素的变化并分析这些变化以评估它们对安全有效性的意义。7.8.4 标识安全突发事件7.8.4. 1 确定是否发生了一个有关安全的突发事件，标识出事件详细情况并且在必要时提出报告;有关安全的突发事件可利用历史事件的数据、系统配置数据、完整性工具和其他系统信息诊断。7.8.4.2 标识与安全相关的突发事件。7.8.5 监视安全防护措施7.8.5. 1 检

30、测安全防护措施的执行情况，标识出安全防护措施执行中的变化。7.8.5.2 监视安全防护措施的性能和有效性。7.8.6 检查安全态势检查系统安全态势以标识出必要的更正，评审实施安全的理由并根据其他的规则检查需要安全的地方。7.8.7 管理安全突发事件晌应应急计划要求标识出系统失效的最长时间、系统正常工作的基本元素;开发一个可恢复策略和计划，测试并维护该计划。7.8.8 保护安全监视的记录数据保证与安全监视有关的设备得到相应的保护，监视活动包括封存和归档相关的日志、审计报告和相关分析结果。7.9 提供安全输入7.9.1 基本要求应为系统的规划者、设计者、实施者或需求方提供他们所需的安全信息，信息应

31、包括安全体系结构、设计或实施选择以及安全指南;开发、分析并提供安全输入并与基于7.10中定义的安全需求中的适当组织机构成员协调一致;要求所有具有安全意义的系统问题都应受到检查并按照安全目标的要求予以解决;所有项目组成员都要理解安全问题，解决方法应反映出所提供的安全输入。本要求项适用于标定开发(设计者和实现者)和运行(用户和管理员)的安全输入。7.9.2 理解安全输入要求7.9.2. 1 安全输入包括任何种类的、应被其他项目所考虑的、与安全相关的指南、设计、文档或思想;输入可以为多种形式包括文档、备忘录、电子邮件、培训和咨询。7.9.2.2 安全输入要求可基于7.10中确定的需求。7.9.2.3

32、 设计者、开发者和需求方应一起确保相应部门对安全输入有一个共同的理解。7.9.3 确定安全约束和考虑因素确定做出有科学依据的工程决策所需的所有安全约束和考虑因素。安全工程组进行分析以确定在需求、设计、实现、配置和文档方面的任何安全限制和考虑;约束可在系统生存周期内的所有时间进行标识，可在许多不同的抽象层上进行标识。7.9.4 标识安全选项标识出与安全相关的工程问题的解决办法选项;解决办法可以多种形式提供。7.9.5 分析工程选项的安全性7.9.5.1 分析和区分工程选项的优先级;确定安全约束与考虑因素(见7.9. 3)，根据标识的安全约束和考虑因素，设计组可以评估每个工程选项并提出对工程组的建

33、议;安全工程组应考虑其他工程组的工程指南。7.9.5.2 这些工程选项不受所标识的安全选项的限制(见7.9.的，还应包括来自其他项目的选项。7.9.5.3 利用安全约束和考虑因素来分析和区分工程选项的优先级。7.9.6 提供安全工程指南制定出与安全相关的指南，并将它提供给工程组。10 GB/T 20282-2006 7.9.7 提供运行安全指南7.9.7. 1 制定出与安全相关的指南并提供给系统用户和管理员;运行安全指南的制定应在生存周期内提早开始。7.9.7.2 运行安全指南包含用户和管理员在以安全模式进行安装、配置、运行和终止系统时应做的内容。7.10 指定安全要求7. 10. 1 基本要

34、求应明确地为系统标识出与安全相关的要求;指定安全要求涉及到系统安全定义的基本原则，遵循有关安全的所有法律、策略和组织需求;定义与安全相关的要求集合成系统安全的基线。所有部门，包括用户之间应达成对安全要求的共识;应定义整个信息系统中所有安全方面的活动，通过在整个项目中收集、提炼、使用和更新(见7.9)这一要求项所获得和产生的信息，提出安全要求。7.10.2 获得对安全要求的理解通过收集所有用于全面理解需求方安全要求所需的信息，获得对安全要求的理解。7.10.3 标识可用的法律、策略和约束为给定系统确定法律、策略、标准、外部影响和约束;收集所有对系统安全产生影响的外部影响;标识出支配系统目标环境的

35、法律、规则、策略和业务标准;应进行全局和局部间优先级的决策;系统需求方提出的系统安全需求应被标识并说明安全意义。7.10.4 标识系统安全关联性7.10.4.1 标识出系统间的关系是如何影响安全的，任务的处理和运行概要应作为安全因素加以评估;标识出系统遭受到的或可能遭受到的威胁，评估性能和功能需求对安全可能产生的影响。7.10.4.2 定义系统的安全边界;组织的许多外部因素也影响组织安全要求的变化程度，监视和定期地评估策略上的倾向性和策略重点的改变、技术开发、经济影响、全局性事件以及信息战等变化带来的潜在影响。7.10.4.3 标识系统的用途以确定其安全的关联性。7.10.5 获取系统运行的安

36、全思想7. 10.5.1 应明确总体的、面向安全的指导思想，包括任务、职责信息流、资产、资源、人员保护以及物理保护的指导思想。7.10.5.2 明确系统运行的面向安全的总体指导思想。7.10.6 获取安全的高层目标确定在运行环境中对系统安全性是足够的安全目标;获取高层安全目标就是定义系统的安全性。7.10.7 定义安全相关需求7. 10.7. 1 定义与系统安全相关的需求，应保证需求的完备性和一致性，为系统安全的评价提供基础。7.10.7.2 定义一套一致性需求，该需求定义了在系统中将实现的保护。7.10.8 达成安全协议应在系统的安全需求中将所有的适用部分与特定安全之间达成协议;对于未被标识

37、的特殊用户而不是一个通用用户组的情况下，特定安全要满足目标设置;特定的安全应该完整地、一致地反映出对策略、法律和用户需求的管理;应标识并修改所发现的问题，直到达成满足需求方要求的协议。7.11 验证和确认安全性7.1 1. 1 基本要求应确保解决安全问题的办法已经被验证与证实。通过观察、示范、分析和测试，依照安全需求、体系结构和设计确认解决办法;依照需求方的运行安全需求证实解决办法;解决办法应满足需求方安全需求与运行安全要求。7. 11.2 确定验证和确认的目标确定验证和确认的目标;确定验证和确认的解决办法。11 GB/T 20282-2006 7. 11.3 定义验证和确认方法7.11.3.

38、1 应定义验证和确认每种解决方案的方法和严格等级;7. 11. 3. 2 严密等级应表明验证和确认的审查到底应有多严格;该要求项要受到7.6中保证策略输出的影响。7. 11.4 执行验证7.11.4.1 应通过显示解决办法实现与上一抽象层相关的要求，包括确定的保证需求正是作为7.6的结果所标识的保证需要;所用的方法在7.11.3中有标识;个人需求和整个系统都要受到检测。7.1 1. 4.2 验证解决办法实现了与上一抽象层相关的要求。7. 11.5 执行证实7. 11. 5. 1 通过显示能满足与法的证实。8. 1. 1 基本应通过来量修正监测、本要求品测量还有助于解8.1.3.2 根据工作P8

39、. 1. 4 测量过程质量对项目所使用的系统工8. 1.5 分析质量测量8. 1. 5. 1 分析质量测量以对质量改运言8. 1. 5. 2 绘制因果图。8. 1. 6 参与质量活动在确定和报告质量问题时，有关员工应参与其中。8. 1. 7 发起改进质量的活动应发起以质量问题或质量改进问题为主题的有关活动。8. 1.8 检测修正行为要求8. 1.8. 1 建立一种或一套机制来检测过程或产品中修正行为的要求。8.1.8.2 故障报告。、改进活动，以及质GB/T 20282-2006 8.2 管理配置8. 2.1 基本要求应维持系统中已确定的配置单元的数据和状况，并对系统及其配置单元的变化进行分析

40、和控制;管理系统配置包括为开发者和需求方提供准确的当前配置数据和状况;该要求项对置于配置管理之下的所有工作产品都是适用的。对一个系统(项目)而标识的配置单元级别的确定应当考虑7.6的保证目标所详细要求的级别。管理配置提供了7.6的证据;选择的配置管理CCM)系统自身管理也应当通过7.1来管理。配置管理功能应允许在生存周期的任一点上通过系统要求的层次来对配置进行眼踪，从而支持可追溯性;可追溯性作为要求项8.2中咛，他曲，咽再如蛙画t8. 2.2 建立配置管理方法8. 2. 2. 1 应有配置管理苟8.2. 2. 2 应将要求项8. 2: 3 确定配置8.2. 3. 1 确定构8. 2. 4 维护

41、维护工供在系统生8.2. 5. 1 X. 新系统的基=配置数据，为审计跟踪提批准新的配置，应更变化对工作产品、项即技术插销均取得成功;这个要求项要持续整个工程生存周期。与8.品vd慨和，即项面包括系统工程活动和全部技术项目活动。项目风险指与项目成功完成有关的风险，与费用和进度有关的一系列问题。工程实施要求项列出安全风险活动，这些活动是用来确定是否可容忍残余安全脆弱性对运行的影响。应当考虑到7.7，以确保安全问题都已列出。8.3. 2 制定项目凤险管理方法8. 3.2. 1 为项目风险管理活动制定出一个计划，对于整个项目生存周期来说，该计划是标识、评估、降低和监视安全风险的基础。8. 3. 2.

42、 2 本要求实施的目的是制定一个有效的计划以指导项目的风险管理活动;计划元素应当包括风险管理队伍成员的标识及其责任;应有用于标识和降低风险的常规风险管理活动、方法和工具列表以及风险降低活动的跟踪和控制方法;计划也应当为风险管理结果的评估提供帮助。13 GB/T 20282-2006 8.3.3 标识项目凤险8.3.3. 1 通过检查项目目标(并考虑到选择和限制)确定可能出现哪些差错并以这两种方法来标识项目的风险。8.3.3.2 有条理地审查项目目标、项目计划(包括活动或事件依赖性)以及系统需求，确定可能的困难区以及在这些区中会出现哪些差错;上述活动在要求项8.5中制定;建立关键的发展依赖性和提

43、供跟踪和修正行为将在要求项8.4中完成。8.3.4 评估项目风险评估项目风险，确定风险发生的可能性与可能造成的后果。8.3.5 评审项目凤险评估8.3.5. 1 获得项目风险评估的正式认可。8.3.5.2 评审项目风险评估的充分性，以确定是否需要修改或取消基于风险的承诺。8.3.6 执行项目凤险降低活动8.3.6.1 实施项目风险降低活动。8.3.6.2 可列出风险降低活动减少风险发生的可能性或减少风险发生时所造成损失程度的列表;对需要特别关注的风险，可以同时实施几种降低风险的活动。8.3.7 跟踪项目凤险降低活动8.3.7. 1 监视项目安全风险降低活动以确保得到预期结果。8.3.7.2 定

44、期检查已经有效实施的降低项目风险活动，测量结果并确定该活动是否成功。8.4 监视技术活动8.4. 1 基本要求应为实际进步和风险提供充分的可见性;可见性是在执行计划发生严重偏差时及时促进修正的行为。监视技术活动将根据项目估计、承诺和计划的文档来指导、跟踪和评审项目的完成情况、结果和风险;一个计划的文档是用来作为跟踪活动和风险，交流情况和修改方案的基础。类似于要求项8.4，此要求项适用于项目技术性行为以及系统工程活动。在开发和系统运行时，需要考虑到7.8和7.1。需要考虑到要求项7.7以确保安全问题都已经列出。8.4.2 指导技术活动8.4.2.1 根据技术性管理计划指导技术性活动。8.4.2.

45、2 贯彻落实在计划技术活动要求项中创建的技术管理计划;这一实施涉及到项目中所有工程活动的技术指导。8.4.3 跟踪项目资源8.4.3. 1 根据技术性管理计划跟踪资源的实际利用情况。8.4.3.2 提供在项目中资源使用的当前信息，在需要时及时调整活动和计划。8.4.4 跟踪技术参数8.4.4.1 根据已建立的技术性参数跟踪执行。8.4.4.2 通过测量在技术管理计划中建立的技术性参数来跟踪项目和它的产品的实际执行;将测量结果与技术管理方案中建立的阔值进行比较，将问题通知给管理人员。8.4.5 评审项目执行8.4.5. 1 根据技术性管理计划执行评审。8.4.5.2 应定期对项目和其产品的执行情

46、况进行评审，当超出正常技术参数的阔值时也要进行评审;评审技术执行的测量分析结果和技术执行的其他指标，批准修正行动计划。14 8.4.6 分析项目问题8.4.6. 1 分析跟踪和评审技术性参数的结果，确定修正行动。8.4.6.2 及时标识、分析和跟踪项目问题控制项目的执行。8.4.7 采取修正行动8.4.7. 1 当实际结果偏离计划时或技术参数预示着将有问题时，应采取修正行动。GB/T 20282-2006 8.4.7.2 当修正行动批准后，通过再分配资源，改变方法和步骤或加强对原计划的支持来执行修正行动;当需要改变技术管理计划时，采用8.5以修改该计划。8.5 计划技术活动8.5. 1 基本要

47、求应建立计划，这些计划能为在系统开发、制造、使用和配置过程中涉及到的技术性工作的进度、费用、控制、眼踪与商议的性质和范围提供基础;应将系统工程行为集成到整个项目的综合性技术计划中。计划技术活动涉及对所要执行工作量的估算，从有相关的部门或人员中获得必要的承诺，并对要进行的工作计划进行定义。特别是在执行8.4.6和8.4. 7时应考虑到7.7。计划应从对要进行的工作范围的理解开始，然后定义项目的限制和约束、风险和目标;计划过程应包括估算工作产品的规格，估算所需资源，制定时间安排表，考虑风险和协商承诺等步骤。8.5.2 标识关键资源标识对项目技术上的成功起关键作用的资源。8.5.3 估计项目范围8.

48、5.3. 1 对影响项目的规模和技术可行性的因素进行估计。8.5.3.2 应通过将系统分解成与其他项目相似的组成单元的办法来对项目范围和规模进行估计;对规模的估计可以调整为如复杂性差异或其他参数等因素。8.5.3.3 历史原始资料可为初始规模估计提供最有用的信息。8.5.4 估算项目费用针对项目实施要求的所有技术资源建立费用估算。8.5.5 确定工程过程8.5.5.1 确定项目使用的技术过程。8.5.5.2 在最高层的技术过程应遵循基于工程特征、组织特征和组织的标准过程的生存周期模型。8.5.6 确定技术活动8.5.6.1 为项目的整个生存周期确定技术活动。8.5.6.2 参照组织的历史经验，从可适用的标准与业界最佳实践中选择项目和系统工程活动。8.5.7 定义项目界面定义支持与需求方和供应商进行有效交互作用的特定过程。8.5.8 开发项目进度表8.5.8.1 为项目的整个生存周