北京信息安全服务人员资质培训材料之五信息安全工程（左晓栋）

信息平安工程

中国科学院研究生院信息平安国家重点实验室左晓栋xd_dcs@sohu2003年9月1信息系统平安工程〔ISSE〕信息系统平安生命周期与平安效劳生命周期SSE-CMM对信息平安工程的其它讨论2什么是信息平安工程信息平安在我国开展的短短几年间，从早期的平安就是杀毒防毒，到后来的平安就是安装防火墙，到现在的购置系列平安产品，直至开始重视平安体系的建设，人们对平安的理解正在一步一步地加深。但是应该注意到，这些理解依然存在着“头痛医头，脚痛医脚〞的片面性，没有将信息平安保障问题作为一个系统工程来考虑和对待。信息平安保障问题的解决既不能只依靠纯粹的技术，也不能靠简单的平安产品的堆砌，它要依赖于复杂的系统工程——信息平安工程。信息平安工程是采用工程的概念、原理、技术和方法，来研究、开发、实施与维护信息系统平安的过程，是将经过时间考验证明是正确的工程实施流程、管理技术和当前能够得到的最好的技术方法相结合的过程。3为何需要信息平安工程信息平安具有社会性信息平安具有全面性信息平安具有生命周期性信息平安具有动态性信息平安具有层次性信息平安具有相对性4通用系统工程〔SE〕过程5由SE到ISSE信息系统平安工程〔ISSE〕是美国军方根据系统工程〔SE〕过程的原理，面向信息平安开发的方法学，其与SE之间是根本的映射关系。美国军方在1994年2月发布了?信息系统平安工程v1.0?，并随后发布了一系列相关军标和指令。6SE与ISSE过程的对应7SE与ISSE过程的对应8SE与ISSE过程的对应9

DoD5000.2-R系统工程过程

10IEEEStd.1220-1998系统工程过程

11ISSE的三大原那么原那么1：始终将问题空间和解决方案空间相别离。“问题〞是“我们期望系统做什么？〞，“解决方案〞是“系统怎样实现我们的期望？〞当我们关注解决方案时，很容易无视对问题的注意，这便会导致错误问题的解决和错误系统的建造。没有比解决一个错误的问题并建造一个错误的系统更低效的了。12ISSE的三大原那么原那么2：问题空间要根据客户的使命或业务需求来定义。用户经常同工程师讨论技术或对解决方案的想法，而不是告诉工程师问题在哪。系统工程师和信息系统平安工程师必须把客户的这些想法放到一边，开掘出客户的根本问题。如果客户的需求不是基于其使命或业务需求而提出的，那么最终系统可能难以满足客户的需求。这样会继续导致错误系统的建造。13ISSE的三大原那么原那么3：解决方案空间要由问题空间相驱动，并由系统工程师和信息系统平安工程师来定义。是系统工程师精通系统的解决方案，而不是客户。如果客户是解决方案的设计专家，那就没必要再去雇用系统工程师了。一个坚持介入设计工程的客户很可能会对解决方案带来限制，影响到系统工程师的灵活性，从而影响到系统的使命或业务支持目标，影响到用户需求的满足。14ISSE活动1：开掘信息保护需求任务-01.1分析机构的使命任务-01.2判断信息对任务的关系和重要性任务-01.3确定法律和法规的要求任务-01.4确定威胁的类别任务-01.5判断影响任务-01.6确定平安效劳任务-01.7记录信息保护需求任务-01.8记录平安管理的角色和责任任务-01.9标识设计约束任务-01.10评估信息保护的有效性子任务-01.10.1向客户提供/展示文档化的信息保护需求子任务-01.10.1得到客户对信息保护需求的认同任务-01.11支持系统的认证和认可〔C&A〕子任务-01.11.1标识指派的批准官员〔DAA〕/认可员子任务-01.11.2标识认证专家〔CA〕/认证员子任务-01.11.3确定可适用的C&A和采办过程子任务-01.11.4确保认可员和认证员对信息保护需求的认同15ISSE活动2：定义系统平安要求任务-02.1定义系统平安背景环境子任务-02.1.1定义系统边界及与SE的接口子任务-02.1.2记录目标系统和外部系统的平安分配子任务-02.1.3标识目标系统与外部系统之间的数据流以及与这些数据流有关的保护要求任务-02.2定义平安运行概念〔CONOPS〕任务-02.3制定系统平安要求基线子任务-02.3.1定义系统平安要求子任务-02.3.2定义系统平安操作模式子任务-02.3.3定义系统平安性能测度任务-02.4审查设计约束任务-02.5评估信息保护的有效性子任务-02.5.1向客户提供并展示平安背景环境、平安CONOPS及系统平安要求子任务-02.5.2得到客户对系统平安背景环境、CONOPS及保护要求的认同任务-02.6支持系统的认证和认可〔C&A〕子任务-02.6.1确保认可员和认证员对系统平安背景环境、CONOPS及保护要求的认同16ISSE活动3：设计系统平安体系结构任务-03.1实施功能分析和功能分配子任务-03.1.1分析待建系统的体系结构子任务-03.1.2在体系结构中分配平安效劳子任务-03.1.3选择平安机制的类型子任务-03.1.4提交平安体系结构设计，以供评估子任务-03.1.5修改平安体系结构子任务-03.1.6选择平安体系结构任务-03.2评估信息保护的有效性子任务-03.2.1确保所选择的平安机制能够提供所需的平安效劳子任务-03.2.2向客户解释平安体系结构如何满足平安要求子任务-03.2.3制定风险目标子任务-03.2.4得到客户对平安体系结构的认同任务-03.3支持系统的认证和认可〔C&A〕子任务-03.3.1准备并提交最终的体系结构文档，用于风险分析子任务-03.3.2与认可员和认证员一起协商风险分析的结果17ISSE活动4：开展详细的平安设计任务-04.1确保对平安体系结构的遵循任务-04.2实施均衡取舍〔trade-off〕研究任务-04.3定义系统平安设计要素子任务-04.3.1向系统平安设计要素中分配平安机制子任务-04.3.2确定备选的商业现货〔COTS〕/政府现货〔GOTS〕平安产品子任务-04.3.3确定需要定制的平安产品子任务-04.3.4检验设计要素和系统接口〔内部及外部〕子任务-03.3.5制定标准任务-04.4评估信息保护的有效性子任务-04.4.1对详细设计进行风险分析子任务-04.4.2确保所选择的平安设计能够提供所需的平安效劳子任务-04.4.3向客户解释平安设计如何满足平安要求子任务-04.4.4向客户解释并记录设计中存在的任何剩余风险子任务-04.4.5得到客户对详细平安设计的认同任务-04.5支持系统的认证和认可〔C&A〕子任务-04.5.1准备并提交详细设计文档，用于风险分析子任务-04.5.2与认可员和认证员一起协商风险分析的结果18ISSE活动5：实现系统平安任务-05.1支持对平安的实现和集成子任务-05.1.1参与平安实现的规划子任务-05.1.2检验平安工具和机制的互操作性子任务-05.1.3根据平安设计对实现进行验证子任务-05.1.4根据所选择的平安准那么，验证平安组件是否已经得到评估子任务-05.1.5参与系统组件的集成，确保其满足了系统平安标准，且未改变组件的标准子任务-05.1.6参与系统组件的配置，确保平安特性已经激活，且平安参数已得到正确设置，能够提供所需的平安效劳子任务-05.1.7确保系统和组件的配置已得到纪录，并实施了配置管理任务-05.2支持测试和评估子任务-05.2.1建立测试和评估战略〔包括示范、观察、分析和测试〕子任务-05.2.2评审可用的测试和评估证据〔例如来自于CCEP、NIAP、内部测试的数据〕子任务-05.2.3对测试和评估流程的开发提供支持子任务-05.2.4对测试和评估活动提供支持19ISSE活动5：实现系统平安任务-05.3评估信息保护的有效性子任务-05.3.1监督以确保平安设计的正确实现子任务-05.3.2实施并更新风险分析子任务-05.3.3定义风险及其可能对任务带来的影响，并通知客户和认可员及认证员任务-05.4支持系统的认证和认可〔C&A〕子任务-05.4.1确保所需的C&A文档能满足客户和认可员及认证员的要求子任务-05.4.2为C&A过程提供文档记录和分析任务-05.5支持平安培训20ISSE活动6：评估信息保护的有效性要在多项活动中评估信息保护的有效性：开掘信息保护需求、定义系统平安要求、定义系统平安体系结构、开展详细的平安设计以及实现系统平安。“评估信息保护的有效性〞中的各项任务和子任务已经列入上述的活动中。21ISSE活动7：评估信息保护的有效性任务-07.1估计工程范围任务-07.2确定资源及其可用性任务-07.3确定角色和责任任务-07.4估计工程本钱任务-07.5制定工程进度任务-07.6标识技术活动任务-07.7标识可交付项任务-07.8定义管理接口任务-07.9准备技术管理规划任务-07.10审查工程方案任务-07.11得到客户的认同22ISSE活动8：管理技术工作任务-08.1指导技术工作任务-08.2跟踪工程资源任务-08.3跟踪技术参数任务-08.4监督技术活动的进展任务-08.5确保可交付项的质量任务-08.6管理配置要素任务-08.7审查工程绩效任务-08.8报告工程状态23信息系统平安工程〔ISSE〕信息系统平安生命周期与平安效劳生命周期SSE-CMM对信息平安工程的其它讨论2425信息系统平安生命周期启动：在启动阶段，要清晰描述系统需求，并完整记录下系统的目标。本阶段的活动包括敏感性评估。开发/采办：在这个阶段会对系统进行设计、购置、规划、开发或其他的一些建造工作。这个阶段常常由系统开发周期或采办周期组成。该阶段的活动包括确定平安要求、将平安要求整合到标准中并采办系统。实现：在实现阶段，系统将得到测试、安装或者实施。该阶段的活动包括平安控制的安装/开启、平安测试和认可。运行/维护：在这个阶段，系统执行其职能。系统总是会因硬软件的增加或其他的事件而不断发生变更。该阶段的活动包括平安运行和管理、运行保证、审计和监控。废弃：IT系统生命周期的废弃阶段包括对信息、硬件和软件的处置。该阶段的活动包括移除、归档、丢弃或销毁信息并对介质进行去除。26NIST?IT平安工程原那么?27NIST?平安工程原那么?28NIST?平安工程原那么?29NIST?平安工程原那么?30NIST?平安工程原那么?31NIST?平安工程原那么?32NIST?平安工程原那么?33专家域与生命周期3435NIST?IT平安效劳指南?IT平安效劳生命周期：第1阶段：启动——组织应确定是否有必要考察IT平安效劳对组织的平安工程有效性的促进作用。第2阶段：评估——机构使用测度准那么对当前环境进行评估，并确定可行的解决方案。第3阶段：解决方案——决策者将开发业务案例，并从一组可行的选项集中指定适宜的效劳方案解决方案。第4阶段：实现——机构选用符合要求的效劳提供商，制定效劳协定并实现解决方案。第5阶段：运行——机构始终如一地对效劳提供商和机构绩效进行监视，保证运行的成功。第6阶段：结束——当效劳结束或废止时，机构要保证一种平稳的过渡。36启动阶段37评估阶段38解决方案阶段39实现阶段40运行阶段41结束阶段42信息系统平安工程〔ISSE〕信息系统平安生命周期与平安效劳生命周期SSE-CMM对信息平安工程的其它讨论43SSE-CMMSSE-CMM综述SSE-CMM的模型SSE-CMM的域维〔过程域与根本实施〕SSE-CMM的能力维〔公共特征与通用实施〕44SSE-CMM的全名为“系统平安工程-能力成熟度模型〞为什么要有SSE-CMM？质量保证概念在全世界兴起以软件工程CMM为代表的CMM思想占据主流地位SSE-CMM〔系统平安工程-能力成熟度模型〕SE-CMM〔系统工程-能力成熟度模型〕P-CMM〔人员能力成熟度模型〕TCMM〔可信能力成熟度模型〕CMMI〔CMM集成〕IA-CMM〔INFOSEC评估-能力成熟度模型〕45什么是SSE-CMM？SSE-CMM是系统平安工程能力成熟模型〔SystemsSecurityEngineeringCapabilityMaturityModel〕的缩写，它描述了一个组织的平安工程过程必须包含的本质特征，这些特征是完善的平安工程的保证。尽管SSE-CMM没有规定一个特定的过程和步骤，但是它聚集了工业界常见的实施方法。本模型是平安工程实施的标准度量准那么，它覆盖了：整个生命期，包括开发、运行、维护和终止；整个组织，包括其中的管理、组织和工程活动；与其它标准并行的相互作用，如系统、软件、硬件、人的因素、测试工程、系统管理、运行和维护等标准；与其它机构的相互作用，包括采办、系统管理、认证、认可和评估机构。在SSE-CMM模型描述中，提供了对所基于的原理、体系结构的全面描述；模型的高层综述；适当运用此模型的建议；包括在模型中的实施以及模型的属性描述。它还包括了开发该模型的需求。SSE-CMM评定方法局部描述了针对SSE-CMM来评价一个组织的平安工程能力的过程和工具。46SSE-CMM宗旨：信息平安建设中需要有一个清晰定义的、成熟的且可测量的要求。SSE-CMM目标：通过区分投标者的能力级别和相关的方案风险来选择合格的平安工程提供商；有利于工程组把投资集中在平安工程工具、培训、过程定义、管理实施和改进上；提供基于能力的保障，也就是说，用户可以基于对工程组平安工程实践和过程的成熟度而确保信心。47SSE-CMM的使用者平安效劳提供商平安对策开发人员产品开发商具体的工业行业48如何使用SSE-CMMSSE-CMM和使用模型的方法〔即评定方法〕所建议的应用方式如下：作为工程组织的工具，用于评价平安工程实施活动，并定义平安工程的改进。作为顾客用来评价一个供给商的平安工程能力的标准机制。作为平安工程评估机构〔如系统认证机构，产品评定机构等〕的工作根底，用于建立基于整体组织能力的信任度〔这个信任度可作为系统或产品的一个平安保证要素〕。如果这个模型及其评定方法的使用者能够完全理解模型的适用范围和它固有的局限性，那么这个评定技术可以适用于自我改进和选择供给商。49SSE-CMM的益处平安的趋势是从保护政府涉密数据转向涉及更广泛的领域，其中包括金融交易、契约合同、个人信息和因特网。因此用于维护和保护这些信息的产品、系统和效劳开始迅速开展。这些平安产品和系统进入市场一般有两种途径：通过长周期且昂贵的评估后进入市场或者不加评估就进入市场。对于前者，平安产品无法及时进入市场来满足用户平安需求，当进入到市场后，产品所具有平安功能就解决的威胁而言已经过时。对于后者，购置者和用户只能依赖于产品或系统开发者或操作者的平安说明，这造成市场上的平安工程效劳都将基于这种空洞的无法律依据的根底。这种情况要求组织以一个更成熟的方式来实施平安工程。特别地，在平安系统和平安产品生产和操作过程中要求以下特性：连续性-以前获得的知识将用于将来的工作重复性-保证工程可成功重复实施的方法有效性-可帮助开发者和评估者都更有效工作的方法保证-落实平安需求的信心50SSE-CMM工程的历史April93-December94 预研〔NSA〕January95 1st公共会议 工作组成立March951st工作组会议Summer/Fall96 SSE-CMM实验工程October96 SSE-CMMv1.0Spring97 评定方法v1.0Summer97 SSE-CMMv1.1 评定方法v1.114-17July97 2nd公共会议April1999SSE-CMMv2.0April1999评定方法v2.0March2002被ISO接受为ISO/IEC2182751SSE-CMM工程结构

工程领导关键评审专家轮廓/测度/保障工作组指导组模型维护工作组评定方法工作组生命周期支持工作组发起/规划/采纳工作组界内评审专家52工程的参与方〔45家机构〕ArcaSystems,Inc.BDMInternationalInc.Booz-AllenandHamilton,Inc.CommunicationsSecurityEstablishment(Canadian)ComputerSciencesCorporationDataSystemsAnalysts,Inc.DefenseInformationSystemsAgencyE-SystemsElectronicWarfareAssociates-Canada,Ltd.FuentezSystemsConceptsG-JConsultingGRCInternational,Inc.HarrisCorp.HughesAircraftInstituteforComputer&InformationSciencesInstituteforDefenseAnalysesInternalRevenueServiceITTAerospaceJOTASystemSecurityConsultantsInc.LockheedMartinMerdanGroup,Inc.MITRECorporationMitretekSystemsMotorolaNationalCenterforSupercomputingApplicationsNationalInstituteforStandardsandTechnologyNationalSecurityAgencyNavalResearchLaboratoryNavyCommand,Control,OperationsSupportCenter;Research,Development,Testing,andEvaluationDivision(NRaD)NorthropGrummanNRaDOfficeoftheSecretaryofDefenseOracleCorporationpragmaSystemsCorp.SanAntonioAirLogisticsCenterScienceApplicationsInternationalCorp.SPARTA,Inc.StanfordTelecomSystemsResearch&ApplicationsCorp.TaxModernizationInstituteTheSachsGroupstOmegaEngineeringTrustedInformationSystemsTRWUnisysGovernmentSystems53SSE-CMM对平安工程的理解平安工程是一门正在开展的学科。当前尚不存在一个精确的、业界一致认可的平安工程定义。然而，对平安工程概括性的描述还是可能的。平安工程的一些目标是：获取对企业的平安风险的理解。根据已识别的平安风险建立一组平衡的平安要求。将平安要求转换成平安指南，这些平安指南将集成到工程实施的其它方面之中，并集成到对系统配置或运行的定义中。在正确有效的平安机制下建立信心和保证。判断系统中和系统运行时残留的平安脆弱性对运行的影响是否可容忍〔即可接受的风险〕。将所有工程科目和专业活动集成为一个对系统平安可信性的共同理解。54SSE-CMM对平安工程的生命周期的理解前期概念概念开掘和定义示范和验证工程实施、开发和制造生产和部署运行和支持废置55平安工程与其它工程学科的关系平安工程还要涉及：企业工程系统工程软件工程人力因素工程通信工程硬件工程测试工程系统管理56平安工程与其它平安学科的关系SSE-CMM的制定者认识到，平安工程必须与其它传统的平安学科相结合，包括：运行平安：运行环境的平安以及对平安运行态势的维护；信息平安：涉及到信息及其在操作和处理中的平安维护；网络平安：涉及到网络硬件、软件和协议的保护，包括网络上通信信息的平安；物理平安：侧重于建筑物和物理场所的保护；人员平安：与人有关，还涉及到人员的可信度及他们对平安问题的意识；管理平安：涉及到平安的管理因素和管理系统的平安；通信平安：与平安域之间的信息通信有关，尤其是信息在传输介质上流动时的保护；辐射平安：涉及到所有机器设备产生的不期望的电磁信号，这些电磁信号可能会将信息传输到平安域外部；计算机平安：尤其涉及到各种类型的平安计算设备。57SSE-CMMSSE-CMM综述SSE-CMM的模型和方法学SSE-CMM的域维〔过程域与根本实施〕SSE-CMM的能力维〔公共特征与通用实施〕58平安工程过程的三个组成局部59SSE-CMM将平安工程划分为三个根本的过程区域：风险，工程，保证。它们可以独立地加以考虑，但这决不意味它们之间有截然不同的区分。在最简单的级别上，风险过程识别出所开发的产品或系统的危险性并对这些危险性进行优先级排序。针对危险性所面临的问题，平安工程过程要与其它工程一起来确定和实施解决方案。最后，由平安保证过程来建立对解决方案的信任并向顾客转达这种平安信任。60风险过程61平安措施的实施可以减轻风险。平安措施可针对威胁、脆弱性、影响和风险自身。但无论如何，并不能消除所有威胁或铲除某个具体威胁。这主要是因为风险消除的代价和相关的不确定性。因此，必须接受残留的风险。在存在很高的不确定性的情况下，由于风险的不精确的本质，因此是否接受风险是需要慎重对待的大问题。SSE-CMM过程域包括威胁、脆弱性、影响和相关风险进行分析的活动保证。62工程过程63平安工程与其它科目一样，它是一个包括概念、设计、实现、测试、部署、运行、维护、退出的完整过程。在这个过程中，平安工程的实施必须紧密地与其它的系统工程队伍相合作。SSE-CMM强调平安工程师是一个大的工程队伍中的一局部，需要与其它科目工程师的活动相互协调。这会有助于保证平安成为一个大的工程过程中一个整体局部，而不是一个分开的独立活动。在生命周期的后面阶段，平安工程师将根据意识到风险来适当地配置系统，以确保新的风险不会造成系统运行的不平安状态。64保证过程65保证是指平安需要得到满足的信任程度。它是平安工程非常重要的产品。存在着有许多的保证形式。SSE-CMM的信任程度来自于平安工程过程可重复性的结果质量。这种信任的根底是成熟组织比不成熟组织更可能产生出重复的结果。不同保证形式之间的详细关系目前是正在研究的课题。平安保证并不能添加任何额外的对平安相关风险的抗拒能力，但它能为减少预期平安风险控制的执行提供信心。平安保证也可看作是平安措施按照要求运行的信心。这种信心来自于正确性和有效性。正确性保证了平安措施按设计实现了需求。有效性那么保证了提供的平安措施可充分地满足顾客的平安需要。66SSE-CMM体系结构SSE-CMM体系结构的设计是可在整个平安工程范围内决定平安工程组织的成熟性。这个体系结构的目标是清晰地从管理和制度化特征中别离出平安工程的根本特征。为了保证这种别离，这个模型是两维的，分别称为“域〞和“能力〞。重要的是，SSE-CMM并不意味着在一个组织中任何工程组或角色必须执行这个模型中所描述的任何过程，也不要求使用最新的和最好的平安工程技术和方法论。然而，这个模型要求是一个组织机构要有一个适当过程，这个过程应包括这个模型中所描述的根本平安实施。组织机构可以以任何方式随意创立符合他们业务目标的过程以及组织结构。SSE-CMM也并不意味着执行通用实施的专门要求。一个组织机构一般可随意以他们所选择的方式和次序来方案、跟踪、定义、控制和改进他们的过程。然而，由于一些较高级别的通用实施依赖于较低级别的通用实施，因此组织机构应在试图到达较高级别之前，应首先实现较低级别通用实施。67根本模型域维仅仅由定义平安工程的所有实施构成。这些实施称为“根本实施〞——BP。能力维代表了假设干可表现管理和制度化能力的实施。这些实施被称作“通用实施〞——GP，可在广泛的域中应用。通用实施表现了一个根本实施中应当完成的活动。通过设置这两个相互依赖的维，SSE-CMM在各个能力级别上覆盖了整个平安活动范围。68根本实施与通用实施的关系69将根本实施和通用实施综合考虑使得可以检查一个机构实施一个特定活动的能力。上图中，感兴趣的人士可能会问：“你的机构有足够的资源来查找系统的平安脆弱性吗？〞如果答复“是〞，那么对方显然获知了机构在这方面的能力。在二维图的所有交叉点上的问题都得到答复后，我们就得到了对一个机构的平安工程能力的总体认识。70SSE-CMMSSE-CMM综述SSE-CMM的模型SSE-CMM的域维〔过程域与根本实施〕SSE-CMM的能力维〔公共特征与通用实施〕71根本实施SSE-CMM包含了60个根本实施，这60个根本实施被归为了11类，它们涵盖了所有主要的平安工程域。这些根本实施来自于广泛的材料、实践和专家知识。一个根本实施：应用于整个企业生命期和其它BP互相不覆盖代表平安业界“最好的实施〞不简单地反映新型技术可在商务环境下以多种方法使用不指定特定的方法或工具72过程域60个根本实施被归为的11类，称为过程域。有许多方式将平安工程范畴划分为过程域。一种可能的做法是将真实世界模型化，创立匹配平安工程效劳的过程域。其它的方法可以是概念域的方法，这些概念域形成了根底的平安工程建设模块。SSE-CMM在确定11个过程域的过程中，综合了比较优秀的几种方法。每一个过程域包括一组表示一个成功执行过程域的目标。每一个过程域也包括一组集成的“根本实施〞或简称为“BP〞。根本实施定义了取得过程域目标的必要步骤。73过程域过程域：聚集了一个域中的相关活动与有价值的平安工程效劳相关可在整个组织生命周期中应用能在多个组织和多类产品范围内实现能作为一个独立的过程加以改进能够被感兴趣的组织加以改进包括了所有需要满足过程域目标的BP7411个过程域PA01管理平安控制PA02评估影响PA03评估平安风险PA04评估威胁PA05评估脆弱性PA06建立平安论据PA07协调平安性PA08监视平安态势PA09提供平安输入PA10确定平安需求PA11验证与确认平安75其它过程域PA12确保质量PA13管理配置PA14管理工程风险PA15监视和控制技术工作PA16规划技术工作PA17定义机构的系统工程过程PA18改善机构的系统工程过程PA19管理产品线开展PA20管理系统工程支持环境PA21提供不断开展的技能和知识PA22与提供商相协调SSE-CMM还包括其余11个与工程和机构活动相关的过程域。它们来自于SE-CMM〔系统工程——能力成熟模型〕。这些过程域不是与平安直接相关的，但是它们也会对平安造成影响。76过程域与根本实施的关系过程域03基本实施01.02过程域02基本实施01.01安全机构安全项目安全工程过程域01域维77PA01——管理平安控制BP01.01建立平安职责平安的某些问题能够在常规的管理结构中得到管理。然而，还有一些平安问题那么需要更专业化的管理。本管理过程将确保平安责任人员的行为能够得到追踪〔即可追究性〕，并授予平安责任人相应的行动权力。同时也应确保所采用的任何平安控制均是明确的，并能一致性地应用。此外，还应确保所采纳的平安管理结构不但要通知到管理结构内的所有人，也应通知到整个机构。BP01.02管理平安配置所有设备的平安配置均需要管理。之所以有本根本实施，是因为意识到了系统平安要在很大程度上依赖于大量的相关组件〔硬件、软件和程序〕，而常规的配置管理实施并不能解决这些相关组件间的依赖性——这些依赖性恰是平安系统之所需。

78PA01——管理平安控制BP01.03管理平安意识、培训和教育工程所有员工的平安意识培养、培训和教育都应得到管理，其管理方式与其他意识培养、培训和教育工程的管理方式相同。BP01.04管理平安效劳及控制机制平安效劳及机制的常规管理类似于对其他效劳及机制的管理，其中包括防止破坏、偶然事故和人为故障，并与法律和政策要求相一致。79PA02——评估影响

BP02.01对功能进行优先级排序用来对运行、业务或任务功能进行标识、分析和优先级排列，还应考虑到业务战略可能受到的影响。这些行为将会影响和缓解一个机构可能遭受的影响，也会继而对其他过程域中的风险评估工作产生影响。当考察系统可能面临的影响时，这也是极为重要的因素。本根本实施与PA10“确定平安需求〞有关。BP02.02标识系统资产本根本实施将标识出系统中为支持系统平安目标或关键功能〔运行功能、业务功能或任务功能〕所必需的资源和数据。本根本实施可以通过评估各类资产在给定环境中〔对平安目标或关键功能提供支持〕的重要性来定义出各类资产。80PA02——评估影响BP02.03选择影响的度量准那么有很多度量准那么可于衡量事件的影响。在评估之前，应预先确定采用何种度量准那么来评估具体系统面临的影响。BP02.04确定不同度量准那么之间的关系某些影响可能需要使用不同的度量准那么进行评估。因此必须确定不同度量准那么之间的关系，以确保在整个影响评估中使用一致性的方法对所有的影响进行评估。在某些情况下，还需要将各种度量准那么组合起来，以产生唯一确实定性结果。这就需要建立起相应方法，以便组合这些度量准那么。当使用定量的度量准那么时，还需要建立起转换规那么，确立转换因子，在不同的定量方法之间对数值进行转换。81PA02——评估影响BP02.05标识和描述影响本根本实施要利用BP02.01和BP02.02中确定的资产和功能信息来确定平安事件的可能影响。对每一个资产来说，这种影响可能包括资产的破坏、泄露、阻断或丧失。功能的影响可能还要包括拦截、延迟、弱化。一旦创立了相对完整的影响列表，便可以利用BP02.03和BP02.04中确定的度量准那么或度量准那么的组合来描述影响。其中可能还要参考机构的保险情况、财政年鉴等其他资源。在评估中，要考察其中的不确定性，并与影响相联系。BP02.06监视影响任何位置和状态下的影响都是动态变化的。新的影响可以变得互为关联。因此重要的一项工作就是监视现有影响并有规律地检查可能的新影响。本根本实施与BP08.02中的通用性监视活动紧密相连。82PA03——评估平安风险BP03.01选择风险分析方法本根本实施中要定义用于标识一给定环境中系统平安风险的方法，以对平安风险进行分析、评估和比较。它还应该包括一个对风险进行分类和分级的方案，该方案将依赖于威胁、系统的运行功能、已获知的系统脆弱性、潜在损失、平安需求或其他相关事项。BP03.02标识暴露标识暴露的目的在于认识这些威胁和脆弱性的利害关系，进而标识威胁和脆弱性造成的影响。这些暴露是选择系统保护措施时必须予以考虑的。83PA03——评估平安风险BP03.03评估暴露的风险标识出一个暴露出现的可能性。BP03.04评估总体的不确定性每种风险都有与之相关的不确定性。总体风险不确定性是在BP04.05“评估威胁的可能性〞、BP05.03“收集脆弱性数据〞、BP02.05“标识和描述影响〞中标识的不确定性的积累。本根本实施与PA06“建立保证论据〞联系紧密，因为保证能用于改变——很多时候是降低——不确定性。84PA03——评估平安风险BP03.05排列风险优先级已经标识的风险应该基于机构的优先安排、风险出现的可能性、与这些因素相关的不确定性以及可用的财力而进行排序。风险可以被减轻、躲避、转嫁或接受，也可以使用这些措施的组合。“减轻〞这一措施能够对付威胁、脆弱性、影响或风险本身。平安措施的选择要适当考虑到PA10“确定平安需求〞中的客户要求、业务的优先级以及整体系统的体系结构。BP03.06监视风险及其特征任何位置和状态下的风险都是动态的。新的风险可能会出现，而已有的风险也可能会发生变化。因此，监视现有风险及其特征、定期检查新风险是十分重要的。本根本实施与“监视威胁、脆弱性、影响、风险和环境变化〞中的普适性监视活动密切相关。85PA04——评估威胁

BP04.01标识自然威胁由自然原因引起的威胁包括地震、海啸和台风。然而，并非所有的自然威胁都会在所有地方发生。例如，在大陆中心就不可能会出现台风。因此，重要的是标识出在一具体地方到底会存在哪一种自然威胁。BP04.02标识人为威胁人为原因引起的威胁与自然威胁不一样，它根本上有两种类型：偶然原因引起的威胁和成心行为引起的威胁。在某些环境中，因为不涉及到人为威胁，可以在经过分析后取消对人为威胁的考察。86PA04——评估威胁BP04.03标识威胁的测量单元大量的自然和人为威胁都有其与之相关的测量单元。关于地震的Richter测量标度便是一例。大多数情况下，测量单元的全部尺度并不适用于一次具体的评估。因此，对可能在一个机构中出现的事件，可根据具体情况建立最大和最小的测量单元。BP04.04评估威胁主体的能力本过程域将确定可能对系统发动成功攻击的敌人的主观能力和客观能力。主观能力指的是攻击者所掌握的攻击知识〔例如他们经过的训练和拥有的技能〕；客观能力那么是指一个有能力的敌人实际发动攻击的可能性〔例如他们拥有的资源〕。87PA04——评估威胁BP04.05评估威胁的可能性本根本实施将对威胁事件发生的可能性进行评估。在评估中需要考虑多种因素，从自然事件的概率到人员的有意或无意行为的概率等均要去评估。并不是说这些所有因素都要去计算或测量，但这其中应该有一个一致的度量准那么。BP04.06监视威胁及其特征任何位置和状态下的威胁都是动态的。新的威胁可能会出现，而已有的威胁也可能会发生变化。因此，监视现有威胁及其特征、定期检查新威胁是十分重要的。本根本实施与BP08.02“监视变化〞中的普适性监视活动密切相关。88PA05——评估脆弱性

BP05.01选择脆弱性分析方法本根本实施包括定义系统的脆弱性分析方法，以对平安脆弱性进行标识和描述。其中还要包括脆弱性的分类和优先级排序方案，以威胁及其可能性、系统的运行功能、平安需求或其他感兴趣的内容为根底来完成脆弱性的分类和排序。还要标识出这些分析方法的深度和广度，以使平安工程师和客户判断出待分析的目标系统及分析的全面性。脆弱性分析应该在预定的专门时间内展开，并在一个框架和清晰记录的配置内完成。脆弱性分析方法中应包括预期结果，脆弱性分析的具体目标也应陈述清楚。BP05.02标识脆弱性系统的平安和非平安局部均有可能存在脆弱性。很多时候，对平安功能起到支撑作用或与平安机制相协调的很多非平安机制中常被发现具有可被利用的脆弱性。BP05.01中的主动攻击方法可以用来验证这些脆弱性。所发现的所有系统脆弱性应得到记录。89PA05——评估脆弱性BP05.03收集脆弱性数据脆弱性是自身的属性。本根本实施旨在收集与这些属性相关的数据。在某种情况下，脆弱性的测量单元可能与BP04.03“标识威胁的测量单元〞中威胁的测量单元相类似。脆弱性被利用的难易程度、脆弱性存在的可能性等数据也应得到标识和收集。BP05.04综合系统的脆弱性本根本实施将分析那些脆弱性或脆弱性的组合给系统带来的问题。分析中还应确定出该脆弱性的属性特征，例如脆弱性被利用以及被成功攻击的概率。还应提出脆弱性的综合分析建议。BP05.05监视脆弱性及其特征任何位置和状态的脆弱性状况都是动态的。新的脆弱性会从中产生，而现有脆弱性的特征也可能会发生变化。因此，要有规律地监视现有的脆弱性及其特征，并检查新的脆弱性，该项工作非常重要。本BP与BP08.02中的监视活动密切相关。90PA06——建立保证论据

BP06.01标识保证目标由客户确立的保证目标显示了用户对系统平安性的信任程度。系统平安保证目标规定了系统平安策略所能提供的平安可信程度。该目标的充分性要由开发商、集成商、客户和签字机关共同论证。对新增的平安保证目标或已有目标的修改均须得到确认，该工作要在工程机构的内外部平安相关人员间得到协调〔例如客户、系统平安认证机构、签字机关、用户等〕。为反映新的变化，应不断更新平安保证目标。需要对平安保证目标作出修改的情况包括客户、系统平安认证机构、签字机关、用户等对可接受的风险程度的改变。平安保证目标必须得到交流，以使其清晰且没有异议。如有必要，应参加适宜的解释。91PA06——建立保证论据BP06.02定义保证战略平安保证战略的目标是规划并确保平安目标能够正确地实现。平安保证战略在实施中产生的证据应能〔向系统的签字机关〕提供一个可接受的信心级，使其确信系统的平安措施足以管理平安风险。通过制定并实施平安保证战略，便可实现对保证活动的有效管理。对保证需求的尽早标识和定义对于产生必要的支撑性证据来说是必要的。应通过不断的外部协调来理解和观察客户对保证需求的满意程度，这有助于确保得到高质量的保证需求包。BP06.03控制保证证据平安保证证据要根据平安保证战略中的定义，通过与所有的平安工程过程域相互配合，在不同抽象水平上标识出保证证据。这些证据要受到控制，以确保他们对当前的工作结果来说具有合时性，对于平安保证目标来说具有关联性。92PA06——建立保证论据BP06.04分析证据之所以对保证证据进行分析，是为了保证所收集的证据能够满足平安目标，从而可以满足客户的平安需求。对保证证据的分析可说明系统平安工程及平安验证过程是否充分且足够，以判断出平安机制和平安特性是否已经令人满意地得到了实现。此外，对保证证据的分析还可确保工程实施的结果相对于基线系统来说是完善和正确的。如果保证证据显得不充分或不够，这就有必要对支持平安目标的系统、平安工作结果和过程进行修订。BP06.05提供保证论据本根本实施将开发出一个全面的平安保证论据，以说明对平安保证目标的遵循性，并将保证论据提供给客户。保证论据是一系列已声明的保证目标的集合，这些保证目标要依靠不同抽象度的保证证据所支持。保证论据要经过审查，以查找其中的保证证据的缺乏，查看其是否能够满足平安保证目标。93PA07——协调平安BP07.01定义协调目标很多团体都要有参与平安工程活动的意识，并确实能参与到平安工程活动中来。要通过检查结构、信息及工程需求来决定同这些团体的信息共享目标。要建立与其他团体之间的联系和承诺。成功的联系可有很多形式，但必须被所有的相关团体所知晓。BP07.02标识协调机制有很多方法可以与所有的工程组共享平安工程的决策和建议。本活动确定了在工程中协调平安的不同方法。在同一个工程上工作着多个平安部门并非异常。在这些情况下，所有的工作组都应该为一个得到共同理解的目标而工作。接口标识、平安机制选择、培训及开发等工作均需要按这种方式进行，以确保每个平安组件能够在运行系统中如愿工作。此外，所有的工程组必须理解平安工程工作及平安工程活动，以便使平安能完好地集成到系统中去。客户也必须知晓平安相关的事情和活动，以确保平安需求能够得到恰当的标识和考虑。94PA07——协调平安BP07.03促进协调成功的关系需要有良好的促进手段。在重要性不同的多个机构间进行交流时有可能会发生一些冲突。本根本实施确保这些争端能够以建设性的适当方式加以解决。BP07.04协调平安决策和建议本根本实施的目的是为了在各平安工程师、其他工程组、外部实体及其他可能的团体间交流平安决策和建议。95PA08——监视平安态势BP08.01分析事件记录检查历史记录和事件记录〔各种日志〕，以获得平安相关信息。应该对多个记录中的感兴趣事件及其与其他事件的关联因子进行标识。这之后，多个事件记录就可以融合为一个事件记录。BP08.02监视变化查找有可能对当前平安态势的有效性造成影响的任何变化，不管是正面还是负面影响。任何系统中实施的平安应该与威胁、脆弱性、影响和风险相关联，因为他们与系统的内外部环境有关。这些因素没有一个是静态的，他们中的任何变化均将影响到系统平安的有效性与适宜性。所有的变化必须得到监视，并对这些变化进行分析，以评估他们对平安有效性的影响。96PA08——监视平安态势BP08.03标识平安事件本过程域将判断是否发生了平安事件，说明事件的详细情况，并在必要时做出报告。平安事件可利用历史事件数据、系统配置数据、完整性工具和其他系统信息来检测。由于某些事件要经过一个较长周期的时间后才出现，因此该分析很可能要涉及到对系统长时间状态的比较。BP08.04监视平安措施检查平安措施的性能，以标识出平安措施的性能变化。BP08.05检查平安态势由于威胁环境、运行要求或系统配置等方面会出现变化，一个系统的平安态势可能会发生改变。本根本实施在于审查在系统中实施平安的理由，并审查对其他工程领域或方面提出的平安需求。97PA08——监视平安态势BP08.06管理平安事件响应在很多情况中，系统的连续可用性是非常关键的。由于很多事件不能预防，因此对这些破坏的响应能力便至关重要。应急方案中要求标识出允许系统失效的最长时间；标识出系统中的重要功能组件；标识并制定恢复战略和方案；测试并维护该方案。在某些情况中，应急措施可能包括对事件的响应或与攻击者〔例如病毒、黑客等〕的主动交锋。BP08.07保护平安监视的结果如果监视活动的结果不可靠，那么监视活动就没有任何意义。本根本实施包括对相关日志、审计报告和有关分析结果进行封存和归档。98PA09——提供平安输入BP09.01理解平安输入需求平安工程要与其他领域相协调，以判断出这些领域所需的平安输入的类型。平安输入包括平安相关的任何指南、设计、文档或思想。输入可以有多种形式，包括文档、备忘录、电子邮件、培训和咨询。这些输入要基于PA10“确定平安需求〞中的平安需求。例如，软件工程师就有可能需要一套平安规那么来支持其工作。某些平安输入可能与环境的关联性更强。BP09.02确定平安约束和平安考虑本根本实施的目的在于为工程选择确定出所有的平安约束和平安考虑。平安工程组将负责完成该类分析，从而为需求、设计、实现、配置和文档等确定出所有的平安约束和平安考虑。平安约束可在系统生命周期内的所有时间得到确定，并可在很多不同的抽象层上标识。需要注意的是，这些平安约束或是肯定语气〔总是如此〕或是否认语气〔绝对禁止如此〕。99PA09——提供平安输入BP09.03标识平安备选方案本根本实施的目的在于标识出平安相关工程问题的备选解决方案。这一过程要反复进行，将平安相关需求转化为具体的实现。这些解决方法可以以多种形式提供，例如体系结构、模型或原型。本根本实施涉及到对平安相关需要的分解、分析和重组，直到标识出有效的备选方案。BP09.04分析工程备选方案的平安性本根本实施的目的在于分析并排列工程备选方案的优先级。使用BP09.02中确定的平安约束和平安考虑，平安工程师便可以评估每一个备选方案，并向工程组提交建议。此外，平安工程师还应考虑其他工程组的工程指南。这些工程备选方案并不限于BP09.03中标识的平安备选方案，还包括来自其他领域的备选方案。100PA09——提供平安输入BP09.05提供平安工程指南本根本实施的目的在于制定平安相关指南，并将其提供给工程组。平安工程指南可被工程组用来对体系结构、设计和实现做出决策。BP09.06提供运行平安指南本根本实施的目的在于开发出平安相关指南并将其提供给系统用户和管理员。这些运行指南告诉了用户和管理员如何才能以平安的方式安装、配置、运行和终止系统。为确保到达该目的，运行平安指南的开发应尽早开始。101PA10——确定平安需求BP10.01获得对客户平安需求的理解本根本实施的目的在于收集所有有助于全面理解客户平安需求的信息。平安风险对客户的重要性程度将会影响到这些需求。系统的预期运行环境也会影响到客户的平安需求。BP10.02标识有关的法律、政策和约束本根本实施的目的在于收集所有可影响系统平安性的外部影响。可能的外部影响包括法律、法规、政策以及商业标准，他们均可能左右系统的环境。全局和局部政策的优先权应该得到确定。必须说明系统客户提出的平安需求，并从中理解其平安意义。102PA10——确定平安需求BP10.03标识系统平安背景本根本实施的目的在于说明系统的背景是如何影响平安的。它涉及了对系统用途〔例如，情报、金融、医疗〕的理解。系统的任务处理过程以及运行概要均要在平安考虑下加以评估。在本根本实施中，应该对系统面临的〔或可能面临的〕威胁进行深入理解。此外，还要评估性能和功能需求可能对平安产生的影响。运行的约束条件也要接受检查，以考察其对平安的影响。为了定义出系统的平安边界，系统的环境可能还要包括该系统与其他机构或系统的接口。要标识出接口组件是位于平安边界的内侧还是外侧。机构外的很多因素也会影响到机构的平安需求。这些因素包括策略上的倾向性和政治重点的变化、技术开展、经济影响、全局性事件以及信息战。这些因素没有一个是静态的，因此需要监视并定期地评估这些变化可能造成的影响。103PA10——确定平安需求BP10.04形成对系统运行的平安认识本根本实施的目的在于形成一个高层的、面向平安认识，包括角色、职责、信息流、资产、资源、人员保护以及物理保护。其中还要考虑在平安要求的约束下，机构如何运作。对系统的这些观察一般应该在运行平安概念中提出来，且应包括对系统体系结构、流程和环境的高层面的平安认识。在本阶段，与系统开发环境有关的要求也要观察和认识。BP10.05形成平安的高层目标本根本实施的目的在于，标识出为了向运行环境中的系统提供足够的平安而需满足的平安目标。PA06“建立保证论据〞中确定的系统保证目标也会对平安目标产生影响。104PA10——确定平安需求BP10.06定义平安相关需求本根本实施的目的在于定义出系统的平安相关需求。本实施应确保每个需求与相关的政策、法律、标准、平安需求以及系统的约束条件相一致。他们应能完全地产生出系统的平安需求，包括那些需要通过非技术手段提供的平安需求。通常有必要定义或确定出目标的逻辑或物理边界，以确保没有疏漏。这些需求应该映射或关联到系统目标中去。平安相关需求应清楚、简洁地陈述，且不能彼此之间发生矛盾。只要可能，平安就应努力将其对系统功能和性能的影响降至最小。平安相关需求将为目标环境中的系统平安性提供一个评价的根底。BP10.07达成对平安的一致性认识本根本实施的目的是使所有有关团体能就平安需求达成一致性意见。当讨论的是普遍性用户〔而非具体用户〕时，平安需求应该满足平安目标集。具体化的平安应能完备地、一致地反映出有关的政策、法律和用户需求。在一致性意见未达成之前，所有相关问题均应得到标识，必要时可以返工。105PA11——验证与确认平安BP11.01标识验证与确认对象本根本实施的目的在于分别标识出待验证与确认的对象。验证行为可证明解决方案已得到了正确的实施，而确认行为那么证明了解决方法是有效的。它也涉及与整个生命周期内所有工程组的协调。BP11.02定义验证与确认方法本根本实施的目的在于定义验证与确认的方法和严格程度。验证与确认方法的标识过程涉及到了选择哪一种方法去对工程中的各项需求实施验证与确认。严格程度可说明验证与确认的力度和粒度，这将受到“建立保证论据〞中的保证战略的影响。例如，某些工程只对需求的符合性进行简单的检查，而某些工程那么可能需要更严格的检查。验证与确认方法中还应包括维护可跟踪性的手段，跟踪的内容很多，从客户的运行平安需求到解决方案平安需要，以至到验证与确认的结果。106PA11——验证与确认平安BP11.03实施验证本根本实施的目的在于验证解决方案是否实现了上一抽象层中的相关要求，包括PA06“建立保证论据〞中所标识的保证需求，从而验证解决方案是否正确。有很多验证需求的方法，包括测试、分析、观察和演示。所用的方法应在BP11.02中标识。每个局部需求以及整个系统的需求都要受到验证。BP11.04实施确认本根本实施的目的在于验证解决方案是否能最终满足客户的运行平安需求。有很多方法可以用来完成该项工作，包括在一个运行环境或有代表性的测试环境中去测试解决方案。本根本实施所使用的方法应在BP11.02中被标识。BP11.05提供验证与确认的结果本根本实施的目的在于为其他工程组收集验证与确认的结果。验证与确认的结果应以某种易于理解和使用的方式所提供。所有结果均应被跟踪，以确保需求、解决方案、测试结果的可跟踪性。107过程域描述格式PA01——过程域名概述——对该过程域的概括介绍目标——实施该过程域期望到达的目标根本实施列表——说明每一个根本过程的序号和名称过程域注解——对该过程域的其它说明——根本实施名描述性名字——对该根本实施的一句描述描述——对该根本实施的概括工作成果例如——列出了所有可能的输出 注解——关于该根本实施的任何其它的注解BP.01.02……108过程域举例PA05评估脆弱性概述评估平安脆弱性的目的在于标识和描述系统的平安脆弱性。本过程域包括分析系统资产、定义具体的脆弱性以及对整个系统的脆弱性进行评估。与平安风险和脆弱性评估相关的术语在不同的场合中使用起来是不同的。就本模型的用途而言，“脆弱性〞指的是可被利用来完成不期望行为的系统的某些特征、平安弱点、漏洞或易被威胁所攻击的系统实施的缺陷。这些脆弱性与任何特定的威胁或攻击并不相干。本过程域中的活动可在系统生命周期内的任何时间进行，以支持在环境系统的开发、维护和运行决策。目标获得对一给定环境中系统平安脆弱性的理解。109过程域举例〔续〕过程域注解本过程域涉及到的分析和实施通常是“书面研究〞，而通过主动式工具和技术来查找系统脆弱性那么是另一种补充方法，但它不能代替其他的脆弱性分析技术。这些主动式技术可看作是一种特殊的脆弱性分析形式。当对系统进行升级后，为了验证升级后系统的平安性，主动式脆弱性分析技术便十分有用；或者当两个系统合并时，主动式也有助于发现系统中的脆弱性。在某些情况下，为了确认系统的平安状况并进一步发现和了解系统的平安脆弱性，往往也需要主动性分析技术。主动性分析技术有时称之为渗透性测试，在测试中，平安工程师将尝试是否能够绕过系统的平安机制。平安工程师一般要在常规用户的约束条件下展开渗透性攻击，但他们可以使用全部的设计和实施文档。这种渗透性测试也不能无止境地进行下去，它必然要受到时间和本钱的制约。本过程域产生的威胁信息可以与PA04中得到的威胁信息、PA02中得到的影响信息一起协作，为PA03提供输入。虽然这些涉及威胁、脆弱性和影响信息的收集活动是分散在不同的过程域之中的，但他们之间的互依赖性很强。他们的目的是为风险管理寻求充分的信息，以指导平安措施的实施。因此，在一定程度上，脆弱性评估过程要得到威胁和影响评估的指导。由于脆弱性可能会变化，因此必须定期地对其进行监视，以确保本过程域中获得的对脆弱性的理解始终正确。110过程域举例〔续〕根本实施清单BP05.01选择在一给定环境中对系统脆弱性进行标识和描述的方法、技术和标准。BP05.02标识系统平安脆弱性。BP05.03收集与脆弱性属性有关的数据。BP05.04评估系统脆弱性，并将特定脆弱性以及各种特定脆弱性的组合进行综合。BP05.05监视脆弱性及其特征的变化。111过程域举例〔续〕BP05.01选择脆弱性分析方法选择在一给定环境中对系统脆弱性进行标识和描述的方法、技术和标准。描述本根本实施包括定义系统的脆弱性分析方法，以对平安脆弱性进行标识和描述。其中还要包括脆弱性的分类和优先级排序方案，根据威胁及其可能性、系统的运行功能、平安需求或以其他感兴趣的内容为根底来完成脆弱性的分类和排序。还要标识出这些分析方法的深度和广度，以使平安工程师和客户判断出待分析的目标系统及分析的全面性。脆弱性分析应该在预定的专门时间内展开，并在一个框架和清晰记录的配置内完成。脆弱性分析方法中应包括预期结果，脆弱性分析的具体目标也应陈述清楚。112过程域举例〔续〕工作结果例如脆弱性分析方法——标识发现并讨论系统平安脆弱性的方法，包括分析、报告和跟踪过程。脆弱性分析格式——描述脆弱性分析结果的格式，以保证分析方法的标准化。攻击方法学及其原理——包括实施攻击测试的目标和方法。攻击过程——实施攻击测试的详细步骤。攻击方案——包括资源、时间进度和攻击方法描述。渗透研究——为标识或未知的脆弱性而采取的攻击方法和实施概要。攻击概要——描述将要实施的具体攻击。113过程域举例〔续〕注解脆弱性分析方法可以是现有的、经裁剪的或者专门针对特定的系统运行和环境而制定的。本根本实施通常会以PA03“评估平安风险〞中的风险分析方法为根底，或对其提供补充。需要注意的是，如果在实施脆弱性分析时要缩小工作范围，或者已经采纳了一套适当的假设，那么可以不去了解威胁、能力及资产价值。用于脆弱性分析的方法可以是定量或定性的。通常，脆弱性分析中要能够反映出对可能性的认识。主动性攻击结果可以以书面报告形式提交，但攻击本身还应该通过实践来实施。至少存在两种根本的脆弱性方法。这两种方法分别为基于分析的方法和基于测试的方法。基于测试的方法对于标识现有的脆弱性以及测试集中包含的威胁来说，是很好的方法。而基于分析的方法，那么对于标识新的脆弱性以及那些并不立即暴露但会随其他平安问题而显现的脆弱性来说是最好的方法。中选择脆弱性分析方法时，还应考虑的其他选项包括基于定量或定性的方法。应该考虑在分析或测量方法中控制的完整性问题。114SSE-CMMSSE-CMM综述SSE-CMM的模型SSE-CMM的域维〔过程域与根本实施〕SSE-CMM的能力维〔公共特征与通用实施〕115通用实施与公共特征通用实施〔GP〕是应用在所有过程中的行为。它们针对的是一个过程的管理、测量和制度化。一般来说，它们应用在对一个机构的过程执行能力的评定之中。通用操作被归为了假设干类逻辑域，成为“公共特征〞。SSE-CMM的能力级别共分为5级，5级的要求那么由这些公共特征所组成。与根本实施不同，通用实施的顺序根据成熟度排列。在通用实施维中，越向上，表示成熟级别越高。每一个公共特征由一个或多个通用实施所组成。116通用实施与公共特征的关系公共特征通用实施通用实施公共特征持续改进计划和跟踪非正式执行初始充分定义定量控制能力维117通用实施、公共特征、能力级别的关系

CommonFeaturesCommonFeaturesGenericPracticesGenericPractices通用实施以实施或制度化为手段来提高工程过程的实施能力通用实施的集合，每一集合中的公共特征面向的是同一类过程的管理和制度化问题若干个（第一级是一个）公共特征的组合，显示了安全工程过程的实施能力级别公共特征能力级别118能力维的原那么119SSE-CMM的5个能力级别及其包含的公共特征

120121第一级：非正式执行该级将关注一个机构或工程是否执行了包含根本实施过程的平安工程。该级别的特点可以描述为“你必须首先做它，然后才能管理它〞。在本级别，过程域中的根本实施通常已得到了执行。但这些根本实施的执行可能未经过严格的方案和跟踪，而是基于个人的知识和努力。各过程域的工作结果可用来确认根本实施已经执行。在机构中以个人为单元区分出某根本实施应被执行，并对执行的需求及时间达成普遍意见。本级的工作结果是可标识的。122第二级：方案和跟踪该级将关注工程层面的定义、规划和执行问题。该级别的特点可描述为“在定义机构层面的过程之前，先要理解工程的相关事项〞。在本级别上，根本实施的执行要经过规划并被跟踪。执行时要依据具体的流程，并应得到验证。工作结果要符合特定的标准和需求。执行情况还要经过测量，以使机构能够基于这些执行而管理其活动。它与非正式执行级的主要区别是过程的实施要经过规划和管理。123第三级：充分定义该级将关注于在机构层面上从既定过程中实施已融合了各个专业领域知识的裁剪结果。该级别的特点可描述为“用工程中学到的最好的东西来创立机构层面的过程〞。在本级别，根本实施应按照充分定义的过程来执行，执行过程中将使用已获批准的、经裁剪的标准。本级与第2级“方案和跟踪级〞的主要区别在于本级将利用机构范围内的标准化过程来规划和管理平安工程过程。124第四级：量化控制该级将关注于测量，它是与机构的业务目标紧密联系在一起的。这个级别的特点可以描述为“只有你知道它是什么，你才能测量它〞以及“当你测量正确的对象时，基于测量的管理才有意义〞。对过程执行情况的详细测量将在本级中进行收集和分析。这将形成对过程能力的量化理解，使机构有能力去预测过程的执行。本级中，过程执行的管理是客观的，工作结果的质量是量化的。本级与充分定义级的主要区别在于所定义的过程是可量化理解和控制的。125第五级：连续改进该级将从此前各级的所有管理活动中获得最大的收益，并强调机构的文化，以保持所取得的成果。该级别的特点可以描述为“一个持续改进的文化需要以良好的管理措施、既定过程和可测量的目标为根底〞。在本级别，有关工程过程效果和效率的量化执行目标已经基于机构的业务目标而建立。过程的执行以及试验性的新概念和新技术产生了量化反响，从而使基于这些目标的连续的过程改进得到了实现。本级与量化控制级的主要区别在于，在本级中，基于对这些过程变化效果的量化理解，工程中既定过程和标准过程将得到不断的改进和提高。126请参照公安部GA/T391-2002?计算机信息系统平安等级保护管理要求?中的级别第一级〔用户自主保护级〕实施根本的管理第二级〔系统审计保护级〕实施操作规程管理第三级〔平安标记保护级〕实施标记制度化管理第四级〔结构化保护级〕实施标准化管理第五级〔访问验证保护级〕实施平安文化管理127能力级别的描述格式能力级别1——能力级别名概述——对该级别能力的概括介绍公共特征列表——说明每一个公共特征的序号和名称公共特征1.1——公共特征名