信息安全系统工程ISSE

一、概述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中的系统需求的解决方案集。NEEDSSystemExternalSystemExternalSystemExternalSystemSolutionSetNEEDSSystemExternalSystemExternalSystemExternalSystemSolutionSetNEEDSSystemExternalSystemExternalSystemExternalSystemSolutionSet定义系统（续）系统要求可分为功能要求和性能要求功能要求描述系统需要完成的任务、动作和行为；性能要求包括系统的质、量、适用范围、使用频度、响应性、可靠性、可维护性、可用性等；此外，内外接口要求与互操作性要求是系统成员之间或系统与环境、其他系统之间的互作用概念的重要要求。当明确所有的要求后，系统工程师必须同其它系统负责人一起评估这些要求的正确性、完整性、一致性、互依赖性、冲突和可测试性。定义系统（续）在要求的分析过程中，系统工程师要审查可追踪性文档，确保发掘出的所有需求都已经分配到了目标或外部系统之中，确保目标系统的背景环境描述中包含了所有的外部接口和信息流。系统工程师还应确保概要性的CONOPS能覆盖所有的功能性和任务或业务需求，并且系统运行的内在风险也得到了提及。定义系统（续）功能（Functions）由要求决定，每个要求将产生一项或几项功能。功能分析的主要内容是分析功能之间或功能与环境之间的联系。有很多方法可以通过图表来描述功能的相关联系最简单的图表是文本功能列表，它通过习惯性的缩进、标号、字体来描述一系列功能的层次结构。功能列表将对功能进行命名，并且描述其定义、行为、何时被调用以及输入\输出。2.2.3设计系统体系结构系统工程师应该分析待建系统的体系结构，完成功能的分析和分配，同时分配系统的要求，并选择相关机制。系统工程师还应确定系统中的组件或要素，将功能分配给这些要素，并描述这些要素间的关系。在SE的“定义系统要求”活动中，系统要求是分配到整个信息系统中的，它只是指明了系统的功能，却没有定义系统的组件；而在“设计系统体系结构”活动中，SE小组将对功能进行分解，选择具体功能的执行组件，这是体系结构设计的核心内容。-DefineSystemRequirementsTargetSystem(allsystemfunctions)ExternalSystemSystemInterfacesExternalSystemiatf_3_4a_3004aTargetSystem(allsystemfunctions)ExternalSystemSystemInterfacesExternalSystemiatf_3_4a_3004aDesignSystemArchitectureExternalSystemInternalInterfacesSystemInterfacesSystemDesignElementsComponentsSystemelementsiatf_3_4b_3004bExternalSystemInternalInterfacesSystemInterfacesSystemSystemDesignElementsComponentsSystemelementsiatf_3_4b_3004b描述了“定义系统要求”与“设计系统体系结构”的区别。前者将目标系统视为“黑盒”，后者则创建系统的内部结构；设计系统体系结构（续）功能分析要将此前的要求分析阶段所确定的高层功能分解至低层功能，与高层功能相关的性能要求也要分解至低层。功能分析的结果是描述每个产品或项目的逻辑功能或性能。分析的对象包括待建系统的体系结构、功能和过程、接口（内部和外部）、元素（组件）、信息的流动情况、环境和用户/访问。上述描述通常称为产品或项目的功能体系结构。功能分析和分配使得可以对系统的功能目的及其实现方式形成更好的理解，并在一定程度上获知低层功能的优先级和冲突。它提供了对于优化物理解决方案来说重要的信息。2.2.4开展详细设计系统工程师应分析系统的设计约束和均衡取舍，完成详细的系统设计，并考虑生命周期的支持。系统工程师应将所有的系统要求跟踪至系统组件，直至无一遗漏。最终的详细设计结果应反映出组件和接口规范，为系统实现时的采办工作提供充分的信息。详细设计将产生更低层次的产品规范、具体的工程与接口控制图、原型、具体的测试计划与流程和具体的集成后勤支持计划(ILSP-IntegratedLogisticsSupportPlan)。2.2.5实现系统系统工程师将系统从规范变为现实，该阶段的主要活动包括采办、集成、配置、测试、记录和培训。采办本阶段的工作必须在开发或购买能够满足详细设计规范的组件这二者之间做出决定。系统工程师必须权衡两种方式的利弊并进行深入研究。