【文档说明】信息安全系统工程ISSE.pptx，共(74)页，900.859 KB，由精品优选上传

转载请保留链接：https://www.ichengzhen.cn/view-292339.html

以下为本文档部分文字说明：

一、概述◼1、什么是信息安全工程◼2、为什么需要信息安全工程◼3、信息安全工程的发展什么是信息安全工程◼信息安全保障问题的解决既不能只依靠纯粹的技术，也不能靠简单的安全产品的堆砌，它要依赖复杂的系统工程——信息安全工程。◼信息安全工程：◼是采用工程的概念、原理、技术和方法，来研究、

开发、实施与维护信息系统安全的过程，它是将经过时间考验证明是正确的工程实施流程、管理技术和当前能够得到的最好的技术方法相结合的过程。为什么需要信息安全工程◼信息安全的现状是比较脆弱的，在安全体制、安全管理等各个方面存在的问题十分严重而突出，且不容乐观；但也可以看到，从20世纪90年代中期到21世

纪初，无论是政府部门、企业，还是个人用户，安全意识明显增强◼在Internet发展的短短几年，人们对安全的理解，从早期的安全就是杀毒防毒，到后来的安全就是安装防火墙，到现在的购买系列安全产品，在一步一步地加深。◼但是应该注意到，这些理解依然存在着“

头痛医头，脚痛医脚”的片面性，没有将信息安全问题作为一个系统工程来考虑对待；◼由于信息安全保障问题的极端复杂性，因此在信息系统建设中必须遵循信息安全工程方法。信息安全的复杂性◼1）信息安全具有社会性◼信息安全问题具有前所未有的广泛性和综合性，由于可能影响到安全的因

素不断增多，即使是一个简单的信息系统，也往往因为人机交互而涉及到组织结构、人员、物理安全、培训等方面的要求；◼在面对每一个信息系统的安全保障问题时，都要考虑这个系统与非技术因素的交互，将其放在整个社会化的环境下考虑。◼2）信息安全具

有全面性◼信息安全问题需要全面考虑，系统安全程度取决于系统最薄弱的环节。信息安全的复杂性（续）◼3）信息安全具有过程性或生命周期性◼一个完整的安全过程至少应包括安全目标与原则的确定、风险分析、需求分析、安全策略研究、安全体系结构的研究、安全实施领域的确定、安全技术与产品的

测试与选型、安全工程的实施、安全工程的实施监理、安全工程的测试与运行、安全意识的教育与技术培训、安全稽核与检查、应急响应等，这一个过程是一个完整的信息安全工程的生命周期。◼经过安全稽核与检查后，又形成新一

轮的生命周期，是一个不断往复的不断上升的螺旋式安全模型。信息安全的复杂性（续）◼4）信息安全具有动态性◼信息技术在发展，黑客水平也在提高，安全策略、安全体系、安全技术也必须动态地调整，在最大程度上使安全系统能够跟上

实际情况的变化发挥效用，使整个安全系统处于不断更新、不断完善、不断进步的动态过程中。◼5）信息安全具有层次性◼信息系统的构成本身就是层次性的（主要有物理、网络、系统、应用和管理等层面），需要用多层次的安全技术、方

法与手段，分层次地化解安全风险。信息安全的复杂性（续）◼6）信息安全具有相对性◼安全是相对的，没有绝对的安全可言；◼首先，安全的动态性决定了所谓的安全只能是相对于过去的安全，相对未来而言，当前的安全很可能会表现为不安全；◼其次，安全不是目的，安全措施应该与保护的信息与网络系统的价值相称，因此，实施

信息安全工程要充分权衡风险威胁与防御措施的利弊与得失，在安全级别与投资代价之间取得一个企业能够接受的平衡点，人们追求的是在适度风险下的相对安全，而非绝对的安全。信息安全工程的发展◼早期的信息安全工程方法理论来自于系统工程(SE)过程方法。◼美国军方最早在系统工程理论基础之上开发了信息

系统安全工程（ISSE），并于1994年2月28日发表了《信息系统安全工程手册v1.0》。◼ISSE由系统工程过程发展而来，因而其风格仍然沿袭了以时间维划定工程元素的方法学，这也暴露出了一些不足：信息安全工程的发展（续）◼1）很多安全要求应该贯彻在整个工程过程之中，尤其是

信息安全的保证要求，而ISSE对其缺乏有针对性的讨论；◼2）此外，信息安全的内容及其庞杂，一次完整的信息安全工程过程，往往会涉及到多个复杂的安全领域，而有些领域的时间过程性却不明显，以时间维为线索的描述方式不适合反映出这些内容。◼后来，在信息系统安全工程方法的发展上，出现了第二种思路：过程能

力成熟度的方法，其基础是CMM（能力成熟度模型）。信息安全工程的发展（续）◼CMM的1.0版在1991年8月由卡内基-梅隆大学软件工程研究所发布。◼同期，NSA也开始了对信息安全工程能力的研究，并选取了CMM的思想作为其方法学，正式启动了SSE-CMM—

《系统安全工程—能力成熟度模型》研究项目。◼1996年10月发布了SSE-CMM的1.0版本，继而在1997年春制定完成了SSE-CMM评定方法的1.0版本。◼1999年4月，形成了SSE-CMMv2.0和SSE-CMM评定方法v2.0。◼2002年3月，SSE-CMM得到

了ISO的采纳，成为ISO的标准—ISO/IEC21827，冠名为《信息技术—系统安全工程—能力成熟度模型》。二、系统工程(SE)过程◼1、系统工程过程概况◼2、通用系统工程过程活动◼3、系统工程过程的几个原则2.1系统工程过程概况挖掘需求定义系统设计系统体系结构详细设计实

施系统评估有效性2.2系统工程过程活动◼通用SE过程由如下活动构成：◼1、发掘需求；◼2、定义系统要求；◼3、设计系统体系结构；◼4、开展详细设计；◼5、实现系统；◼6、评估有效性。◼在上图中，箭头显示了信息在不同活动间的流向，但并不一定意味着各活动之间的顺序

或时间性。◼用户/用户代表并不是一个系统工程活动，之所以标注用户/用户代表的原因在于提醒我们，所有的活动中，必须不断地在系统工程师或信息系统安全工程师与用户之间进行交流和反馈。2.2.1发掘需求◼系统工程师帮助客

户理解并记录用来支持其业务(business)或任务(mission)的信息管理的需求(Needs)，信息需求说明可以在信息管理模型(IMM-informationmanagementmodel)中记录。◼发掘需求是SE过程的起点

，是针对用户需求以及用户环境中的相关策略、法规和标准的一系列判断。◼系统工程师要标识所有的用户及这些用户与系统的交互，标识他们所扮演的角色、承担的责任以及在系统生命周期各阶段中的授权。◼需求应该来自用户的视角，不应该对设计产生过度的约束，并且

要通过用户语言来进行文档化。发掘需求（续）◼业务(business)/任务(mission)描述◼SE或ISSE的全部工作都是为了使一个机构的本职业务/任务能够顺利实施；◼因此，在挖掘需求时，首要的一步就是确定任务/业务的需求，而不是工程或信息安

全需求；◼任务描述的重点之一是对任务环境进行描述。◼需要考虑的策略和政策◼在进行系统工程时必须考虑对机构具有约束力的政策、法规和标准；◼事实上，政策、法规问题是导致很多系统工程失败的主要原因之一。2.2.2定义系统◼在该阶段，系统工程师必须明确系统要完成的功能，包括该功能的实现应达到的程度以及

系统的外部接口。◼由需求到目标、目标到要求以及要求到功能的各个翻译环节均要采用工程语言。◼目标描述能够通过描述系统的预期运行效果而满足需求，系统工程师必须能将目标同此前提出的需求相联系，并且能够从理论上加以解释。◼系统工程师要

在该阶段考虑一套或多套能够满足由客户提出并记录在IMM中的系统需求的解决方案集。NEEDSSystemExternalSystemExternalSystemExternalSystemSolutionSetNEEDSSystemExternalSystemExternalSystemExtern

alSystemSolutionSetNEEDSSystemExternalSystemExternalSystemExternalSystemSolutionSet定义系统（续）◼系统要求可分为功能要求和性能要求◼功能要求描述系统需要完成的任务、动作和行为；◼性能要求包括系统的质

、量、适用范围、使用频度、响应性、可靠性、可维护性、可用性等；◼此外，内外接口要求与互操作性要求是系统成员之间或系统与环境、其他系统之间的互作用概念的重要要求。◼当明确所有的要求后，系统工程师必须同其它系统负责人一起评估这些要求的正确性、完整性、一致性、互依赖性、冲突和可测试性。定义系统（

续）◼在要求的分析过程中，系统工程师要审查可追踪性文档，确保发掘出的所有需求都已经分配到了目标或外部系统之中，确保目标系统的背景环境描述中包含了所有的外部接口和信息流。◼系统工程师还应确保概要性的CON

OPS能覆盖所有的功能性和任务或业务需求，并且系统运行的内在风险也得到了提及。定义系统（续）◼功能（Functions）由要求决定，每个要求将产生一项或几项功能。◼功能分析的主要内容是分析功能之间或功能与环

境之间的联系。◼有很多方法可以通过图表来描述功能的相关联系◼最简单的图表是文本功能列表，它通过习惯性的缩进、标号、字体来描述一系列功能的层次结构。◼功能列表将对功能进行命名，并且描述其定义、行为、何时被调用以及输入\输出。2.2.3设计系统体系结构◼系统工程师应该分析待建系统

的体系结构，完成功能的分析和分配，同时分配系统的要求，并选择相关机制。◼系统工程师还应确定系统中的组件或要素，将功能分配给这些要素，并描述这些要素间的关系。◼在SE的“定义系统要求”活动中，系统要求是分配到整个信息系统中的，它只是指明了系统的功能，却没有定义系统的

组件；◼而在“设计系统体系结构”活动中，SE小组将对功能进行分解，选择具体功能的执行组件，这是体系结构设计的核心内容。-DefineSystemRequirementsTargetSystem(allsystemfunctions)E

xternalSystemSystemInterfacesExternalSystemiatf_3_4a_3004aTargetSystem(allsystemfunctions)ExternalSystemSystemInterf

acesExternalSystemiatf_3_4a_3004aDesignSystemArchitectureExternalSystemInternalInterfacesSystemInterfacesSystemDesignElementsComponen

tsSystemelementsiatf_3_4b_3004bExternalSystemInternalInterfacesSystemInterfacesSystemSystemDesignElementsComponentsSystemelementsiatf_3_4b_3004b描述了

“定义系统要求”与“设计系统体系结构”的区别。前者将目标系统视为“黑盒”，后者则创建系统的内部结构；设计系统体系结构（续）◼功能分析要将此前的要求分析阶段所确定的高层功能分解至低层功能，与高层功能相关的性能要求也要分解至低层。◼功能分析的结果是描述每个产品或项目的逻辑功

能或性能。◼分析的对象包括待建系统的体系结构、功能和过程、接口（内部和外部）、元素（组件）、信息的流动情况、环境和用户/访问。◼上述描述通常称为产品或项目的功能体系结构。◼功能分析和分配使得可以对系统的功能目的

及其实现方式形成更好的理解，并在一定程度上获知低层功能的优先级和冲突。◼它提供了对于优化物理解决方案来说重要的信息。2.2.4开展详细设计◼系统工程师应分析系统的设计约束和均衡取舍，完成详细的系统设计，并考虑生命周期的支持。◼系统工程师应将所有的系统要

求跟踪至系统组件，直至无一遗漏。◼最终的详细设计结果应反映出组件和接口规范，为系统实现时的采办工作提供充分的信息。◼详细设计将产生更低层次的产品规范、具体的工程与接口控制图、原型、具体的测试计划与流程和具体的集成后勤支持计划(IL

SP-IntegratedLogisticsSupportPlan)。2.2.5实现系统◼系统工程师将系统从规范变为现实，该阶段的主要活动包括采办、集成、配置、测试、记录和培训。◼采办◼本阶段的工作必须在开发或购买能够满足详细设计规范的组件这二者之间做出决定。◼系统工程师必

须权衡两种方式的利弊并进行深入研究。◼建设◼在本阶段，已开发的系统方法将被转化为一个稳定的、可生产的、性价比合理的系统设计实践，涉及到了所有产品级的软件、硬件和固件。◼该阶段在采办过程完成后进行，即系统的装配或建设。实现系统（

续）◼测试◼组件开发后，要接受测试和评估，以确保它们能够满足规范（单元测试）。测试过程和预期的测试结果在定义方案之后由工程师写出。◼成功的完成组件测试之后，各组件—硬件、软件、固件—要进行集成和正确的配置，并作为一个系统接受整体集成测试。◼集成测试

用于验证较高级的系统性能水平。◼集成测试可能导致要改变某些系统组件，这将立即反馈给系统设计，以供其做出判断。2.2.6评估有效性◼各项活动的结果都要接受评估，其中必须检测两个主要因素：◼1）系统是否达到了任务的需求？◼2）系

统是否能够依照机构所期望的方式操作？◼除此之外，还要注意可能影响评估结果的如下因素：◼1）互操作性；◼2）可用性；◼3）人员培训；◼4）人机接口；◼5）建设和维护成本。2.3系统工程过程的几个原则◼1、始终将问题空间和解决方案空间相分离。◼2、问题空间要根据

客户的任务或业务需求来定义。◼3、解决方案空间要由问题空间相驱动，并由系统工程师和信息系统安全工程师来定义。始终将问题空间和解决方案空间相分离◼“问题”是“我们期望系统做什么？”，表示“解决方案”这一概念的约束条件、风险、策略和一些界限（值）。◼“解决方案”是“

系统怎样实现我们的期望？”，代表了在开发系统以满足用户需求时所有已经结束的行为和创造出的产品。◼当我们关注解决方案时，很容易忽视对问题的注意，这便会导致错误问题的解决和错误系统的建造。问题空间要根据客户的

任务或业务需求来定义◼有些客户经常同工程师讨论技术或对解决方案的想法，而不是告诉工程师问题在哪◼系统工程师（或信息系统安全工程师）必须把客户的这些想法放到一边，发掘出客户的基本问题。◼如果客户的需求不是基于其任务或业务需求而提出的，则

最终系统可能难以满足客户的需求，这样会导致错误系统的建造。解决方案空间要由问题空间相驱动，并由系统工程师来定义◼是系统工程师精通系统的解决方案，而不是客户。◼如果客户是解决方案的设计专家，那就没必要再去雇用系统工程师了。◼一个

坚持介入设计工程的客户很可能会对解决方案带来限制，影响到系统工程师的灵活性，从而影响到系统的任务或业务支持目标，影响到用户需求的满足。三、信息系统安全工程(ISSE)过程◼1、ISSE概述◼2、ISSE过程ISSE概述◼ISSE—InformationSystemsSecurityEng

ineering。◼ISSE是发掘用户的信息保护需求并随后设计和实现信息系统的一门艺术和科学，在一定的经济成本和精心设计下，这些系统便能够安全地抵御其面对的各种攻击。◼ISSE过程是系统工程（SE）的一个组成部分，并应当对认证和认可（C&A）过程提

供支持。ISSE过程◼ISSE过程覆盖了6项活动，它们与通用的SE过程相对应：◼1、发掘信息保护需求（发掘需求）；◼2、定义系统安全要求（定义系统要求）；◼3、设计系统安全体系结构（设计系统体系结构）；◼4、开展详细的安全设计（开展详细设计）；◼5、实现系统安全（实

现系统）；◼6、评估信息保护的有效性（评估有效性）。1、发掘信息保护需求◼在这个过程中，ISSE将首先调查在信息方面的用户任务需求、相关政策、法规、标准以及威胁。◼然后，ISSE将标识信息系统的具体用户、他们与信息系统和信息的交互作用的实质以及他们在

信息保护生命周期各阶段的角色、责任和权力。◼在此过程中，重要的一步是应用“最小权限”规则，用户只能接触为完成其工作所必不可少的过程和信息。◼信息保护需求应该来自于用户的视角，并且不能对系统的设计和实施造成过度的限制。任务信息威胁分析政策信息保护策略系统需求系统保护需求任务、安全威胁和政策对信息

保护需求的影响2、定义系统安全要求◼信息系统安全工程师要将信息保护需求分配到系统中◼系统安全的背景环境、概要性的系统安全CONOPS以及基线安全要求均应得到确定。◼在确定系统的安全背景环境时，需要定义系统的边界以及对SE的接口，并要将安全功

能分配到目标系统和外部系统中，标识出目标系统和外部系统之间的数据流以及这些数据流的保护需求◼IMM中的信息管理需求以及IPP中的信息保护需求均要在目标系统和外部系统中进行分配，在外部系统中的功能分配必须得到系统所有者的同意。定义系统安全要求（续）◼

信息系统安全工程师要确保所选择的解决方案集能够满足任务或业务的安全需求，系统边界已经得到协调，并确保安全风险可以达到可接受的级别。◼信息系统安全工程师将向客户提交安全背景环境、安全CONOPS以及系统安全要

求，并得到客户的认同。3、设计系统安全体系结构◼信息系统安全工程师要与系统工程师合作，一起分析待建系统的体系结构，完成功能的分析和分配，同时分配安全服务，并选择安全机制。◼信息系统安全工程师还应确定安全系统的

组件或要素，将安全功能分配给这些要素，并描述这些要素间的关系◼在本项活动中，信息系统安全工程师要与系统工程师合作，确保安全要求能正确地流向体系结构，且体系结构不会对安全造成削弱。设计系统安全体系结构（续

）◼信息系统安全工程师要负责向目标系统和外部系统分配安全要求，并确保外部系统可以支持这些安全要求。◼信息系统安全工程师还要在此项活动中确定高层安全机制（例如加密和数字签名），这样，安全机制间的依赖性，例如密钥管理和加密，才能得到讨论和分配。

◼信息系统安全工程师还要将安全机制与安全服务的强度相匹配，落实设计中的约束因素，分析并记录下发现的不足，实施互依赖分析，确定安全机制的可行性，并评估这些安全机制中存在的任何残余风险。4、开展详细的安全设计◼信息系统安全工程师

应分析设计约束和均衡取舍，完成详细的系统和安全设计，并考虑生命周期的支持。◼信息系统安全工程师应将所有的系统安全要求跟踪至系统组件，直至无一遗漏。◼最终的详细安全设计结果应反映出组件和接口规范，为系统实现时的采办工作提供充分的信息。开展详细的安全设计（续）◼在本活动中

，信息系统安全工程师将确保对安全体系结构的遵循，实施均衡取舍研究，并定义系统安全的设计要素，包括：◼1）向系统安全设计要素中分配安全机制；◼2）确定备选的商业现货（COTS）/政府现货（GOTS）安全产品；◼3）确定需要定制的安全产品；◼4）检验

设计要素和系统接口（内部及外部）；◼5）制定规范（例如CC的保护轮廓）。5、实现系统安全◼“实现系统安全”的目标是采办、集成、配置、测试、记录和培训，它使系统从设计转入运行。◼该项活动的结束标志是最终系统有效性评估行为，给出系统满足要求和任务需求的证据。实现系统安全（续）◼在该阶段，信息系统

安全工程师将：◼1）提供对认证和认可（C&A）过程的输入；◼2）验证系统的确能够防御此前的威胁评估中确定的威胁；◼3）跟踪或参与信息保护保障机制在系统实现和测试活动中的运用；◼4）审查系统的生命周期计划、运行流程以及运转培训材料，并向这些文档提供输入；◼5）实施正式的信息保护评估

，为最终的系统有效性评估作出准备；◼6）参与对所有系统事项作出的多学科检查。实现系统安全（续）◼选择需要在解决方案中集成的具体安全产品是本阶段的工作任务之一。◼这些产品可通过购买、租用、借贷等多种选择来获得，影响选择的因素包括组件成

本、可用性、形式以及适宜性。◼其它的因素包括系统组件的依赖性效果、组件的最低性能可能对系统性能的影响以及组件或替代品在将来的可用性。◼不能购买的组件必须自制。◼所有的接口均需要测试，系统和设计工程师将撰写测试流程，并通过集成测试将验证子系统或系统的性能◼在集成和测试时，重要的一项

工作是记录下安装、操作、维护和支持的流程。6、评估信息保护的有效性◼评估信息保护的有效性活动跨越了整个SE/ISSE过程，下表摘要描述了ISSE各项活动中的有效性评估任务。ISSE活动评估信息保护的有效性任务发掘

信息保护需求Ø纵览整个过程。Ø概述信息模型。Ø描述任务或业务的信息攻击威胁。Ø针对信息威胁建立安全服务，确定安全服务对客户的相对重要性。Ø得到客户对本阶段活动结论的认同，作为判断系统安全有效性的基础。定义系统安全要求Ø确保所选择的解决方案集满足了任务或业务的安全需求。Ø协调系

统边界。Ø向客户提供并展示安全背景环境、安全CONOPS以及系统安全要求，并获得客户的认同。Ø确保预期的安全风险能被客户接受。设计系统安全体系结构Ø开展正式的风险分析，确保所选择的安全机制能够提供所需的安全服务，并向

客户解释安全体系结构如何满足安全要求。开展详细的安全设计Ø执行互依赖分析，比较安全机制的强度，审查所选择的安全服务和机制是否能够对抗信息威胁。Ø一旦完成设计，风险评估的结果，尤其是风险减缓需求和残余风险，将得到记录

，并获得客户的认同。实现系统安全Ø实施并更新风险分析。Ø制定风险减缓战略。Ø标识风险可能对任务带来的影响，并通知客户和认可员及认证员。四、风险分析◼1、资产保护◼2、风险管理1、资产保护◼任何有效的风险分析始于需要保护的资产和资源的鉴别。1.1资产的类型◼1）物理资源：物理资源是具有物

理形态的资产◼包括工作站、服务器、终端、网络设备、外围设备等，基本上，凡是具有物理形态的计算资源都是物理资源。◼2）知识资源：和物理资源相比，知识资源更难鉴别，因为它只以电子的形式存在◼知识资源可以是任何信息的形式，并且在组织的事务处理中起一定的作用。◼

它包括软件、财务信息、数据库记录以及计划图表等。例如，公司通过电子邮件交换信息，这些电子报文的存储应看成知识资产。资产的类型（续）◼3）时间资源：时间也是一个重要的资源，甚至是一个组织最有价值的资源◼当评估时间

损失对一个组织的影响时，应考虑由于时间损失引起的全部后果。◼4）信誉（感觉）资源◼在2000年2月，大部分网络公司诸如Yahoo、Amazon、eBay和Buy.com等在受到拒绝服务攻击以后，他们的股票价狂跌。虽然这是暂时的，但足以说明消费者和股票持有者对他们的可信度确

实存在影响，且可测量。1.2潜在的攻击源◼潜在的网络攻击可来自任何能访问网络的源，这些源之间有很大差异，它依赖于一个组织的规模以及提供的网络访问的类型。◼当作风险分析时，要能识别所有的攻击源◼这些攻击源包括内部

系统、来自办公室的访问、通过广域网联到经营伙伴的访问、通过Internet的访问，以及通过modem池的访问等。1.3资产的有效保护◼资产一旦受到威胁和破坏，就会带来两类损失◼1）即时的损失，如由于系统被破坏，员工无法使用，因而降低了劳动生产率。◼2）长期的恢复所需花费，也就是从

攻击或失效到恢复正常需要的花费，例如，受到拒绝服务攻击，在一定期间内资源无法访问带来的损失。◼为了有效保护资产，应尽可能降低资产受危害的潜在代价；另一方面，由于采取一些安全措施，也要付出安全的操作代价◼信息安全最终是一个折中的方案，需要对危害和

降低危害的代价进行权衡。资产的有效保护（续）◼在评估时要考虑网络的现有环境，以及近期和远期网络发展变化的趋势◼选用先进的安全体系结构和系统安全平台可减少安全操作代价，获得良好的安全强度。◼要获得安全强度和安全代价的折中，需要考虑以

下因素：◼1）用户的方便程度，不应由于增加安全强度给用户带来很多麻烦。◼2）管理的复杂性，对增加安全强度的网络系统要易于配置、管理。◼3）对现有系统的影响，包括增加的性能开销以及对原有环境的改变等。◼4）对不同平台的支持，网络安全系统应能适应不同平台的异构环境的使用。安全强度和安全代价

的折中为了有效保护资产，需要性能良好的安全系统结构和安全系统平台，能以小的安全代价换取高的安全强度。2、风险管理◼从本质上讲，安全就是风险管理◼一个组织者如果不了解其信息资产的安全风险，很多资源就会被错误地使用。◼风险管理提供信息资产评估的基础◼通过风险识别，可以知道一些特殊类型的资

产价值以及包含这些信息的系统的价值。2.1风险的概念◼风险是构成安全基础的基本观念，指丢失需要保护的资产的可能性◼如果没有风险，就不需要安全了。◼风险＝威胁＋漏洞◼风险是威胁和漏洞的综合结果。◼没有漏

洞的威胁没有风险，没有威胁的漏洞也没有风险。漏洞和威胁的关系漏洞◼漏洞是攻击的可能途径◼漏洞有可能存在于计算机系统和网络中，它允许打开系统，使技术攻击得逞；◼漏洞也有可能存在于管理过程中，它使系统环境对攻击开放。◼漏洞的多少是由需要

打开系统的技术熟练水平和困难程度来确定的，还要考虑系统暴露的后果◼如果漏洞易于暴露，并且一旦受到攻击，攻击者可以完全控制系统，则称高值漏洞或高脆弱性。◼如果攻击者需要对设备和人员投入很多资源，漏洞才能暴露，并且受到攻击后，也只能获取一般信息，而非敏感信息，则称低值漏洞或低脆弱性。威胁◼威胁是一

个可能破坏信息系统环境安全的动作或事件。◼威胁包含以下3个组成部分：◼1）目标：威胁的目标通常是针对安全属性或安全服务，包括机密性、完整性、可用性、可审性等。这些目标是在威胁背后的真正理由或动机。◼2）代理（攻击主体），有3个特性◼访问：代理必须有访问所需要系统、网络、设施或信息的能力。◼知识

：代理必须具有目标的知识，有用的知识包括用户ID、口令、文件位置、物理访问过程、员工的名字、访问电话号码、网络地址、安全程序等。◼动机：一个代理对目标发出威胁，需要有动机，通常动机是考虑代理攻击目标的关键特性。威胁（续）◼根据代理的3个特性，应该考虑的代理可能

是各种各样的，包括员工、和组织有关的外部员工、黑客、商业对手、恐怖分子、罪犯、客户、访问者以及自然灾害等。◼3）事件（攻击行为）：事件是代理采取的行为，从而导致对组织的伤害◼例如，一个黑客改变一个组织的Web页面来伤害它。另外要

考虑的是假如代理得到访问会产生什么样的伤害。◼常见的事件如下：对信息、系统、场地滥用授权访问；恶意地改变信息；偶然地改变信息；对信息、系统、场地非授权访问；被动地窃听通信；等等。风险级别◼风险可划分成低、中、高３个级别：◼1）低级别

风险是漏洞使组织的风险达到一定水平，然而不一定发生。如有可能应将这些漏洞去除，但应权衡去除漏洞的代价和能减少的风险损失。◼2）中级别风险是漏洞使组织的信息系统或场地的风险（机密性、完整性、可用性、可审性）达到相当

的水平，并且已有发生事件的现实可能性。应采取措施去除漏洞。◼3）高级别风险是漏洞对组织的信息、系统或场地的机密性、完整性、可用性和可审性已构成现实危害，必须立即采取措施去除漏洞。2.2风险识别◼对一个组织而言，识别风险除了要识别漏洞和威胁外，还应考虑已有的对策和预防措

施2.2.1识别漏洞◼识别漏洞时，从确定对该组织的所有入口开始，也就是寻找该组织内的系统和信息的所有访问点◼这些入口包括Internet的连接、远程访问点、与其他组织的连接、设备的物理访问以及用户访问点等。◼对每个访问点识别可访问的信息

和系统，然后识别如何通过入口访问这些信息和系统，应该包括操作系统和应用程序中所有已知的漏洞。2.2.2识别现实的威胁◼一个目标威胁是对一个已知的目标具有已知的代理、已知的动机、已知的访问和执行已知的事件的组合。◼例如，有一个不满意的员工（代理）希望得到正在该组织进行的最新设

计的知识（动机），该员工能访问组织的信息系统（访问），并知道信息存放的位置（知识）。该员工正窥测新设计的机密并且企图获得所需文件。◼识别所有的目标威胁是非常费时和困难的◼可以变更一种方法，即假设存在一个威胁的通用水平，这个威胁可能包括任何

具有访问组织信息或系统的可能性的人。◼假如假设一个通用的威胁，就能检查组织内允许这些访问发生可能产生的漏洞。2.2.3检查对策和预防措施◼在分析评估攻击的可能途径时，必须同时检查如果漏洞真正存在，相应环境采取的对策和预防措施。◼这些预防措施包括防火墙、防病毒软件、访问控制、双因子身份鉴别系统、仿生

网络安全程序、用于访问设备的卡读出器、文件访问控制、对员工进行安全培训等。◼对于组织内的每个访问点都应有相应的预防措施。◼例如，该组织有一个Internet连接，这就提供了访问该组织内部系统的可能性。可以采用防火墙来保护这个访问点，设置和检查防火墙的规则，可以很好地识别来自外部对内部

系统访问的企图。这样外部攻击者不能用访问点的某些漏洞，因为防火墙阻止访问这些漏洞和系统。2.2.4识别风险◼一旦对漏洞、威胁、预防措施进行了识别，就可确定该组织的风险。◼首先确定每个访问点的可能威胁或通用

威胁，并检查通过每个访问点的可能的目标（机密性、完整性、可用性、可审性）。◼基于它的危险程度给每个风险分成高、中、低等级。◼必须指出，对于相同的漏洞，可能得出基于访问点的不同级别的风险。2.3风险测量◼风险测量必须识别出在受到攻击后该组织需要付出的代价。◼认

识到风险使该组织付出的代价也是确定如何管理风险的决定因素◼风险永远不可能完全去除，风险必须管理。◼代价是多方面的，包括资金、时间、资源、信誉以及丢失生意等。代价◼1、资金◼资金是最显而易见的风险代价，包括损失的生产能力、设备或金钱的被窃、调研的费用、

修理或替换系统的费用、专家费用、员工加班时间等。◼2、时间◼时间的代价很难量化。但时间损失必须计入风险测量中。代价（续）◼3.资源◼资源可以是人、系统、通信线路、应用程序或访问。资源代价指如攻击得逞，

需要多少资源来恢复正常。◼4、信誉◼一个组织的信誉损失是十分关键的损失，然而这类损失的代价也难以测量。◼信誉就是诚信、可信。一个组织在公众心目中的可信度是十分重要的。小结◼1、系统工程概述◼2、系统工程(

SE)过程◼3、信息系统安全工程(ISSE)过程◼4、风险分析◼主要参考书◼《信息安全工程导论》，沈昌祥编著◼《网络安全》，胡道元、闵京华编著◼《信息保障技术框架》（IATF）3.1版计算环境安全安全体系规

划实例边界安全网络基础设施安全安全基础设施