信息系统安全工程_信息安全工程(ISSE)_软件

后来，在信息系统安全工程方法的发展上，出现 了第二种思路：过程能力成熟度的方法，其基础 是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/IEC 21827，冠名为《信息技术—系统安全工 程—能力成熟度模型》。

上述描述通常称为产品或项目的功能体系结构。


2.2.4 开展详细设计

系统工程师应分析系统的设计约束和均衡取舍， 完成详细的系统设计，并考虑生命周期的支持。


系统工程师应将所有的系统要求跟踪至系统组件，直 至无一遗漏。 最终的详细设计结果应反映出组件和接口规范，为系 统实现时的采办工作提供充分的信息。
External System
System Interfaces
iatf_3_4b_3004b
Define System Requirements
iatf_3_4a_3004a
Design System Architecture
描述了“定义系统要求”与“设计系统体系结构”的区别。 前者将目标系统视为“黑盒”，后者则创建系统的内部结 构；

在Internet发展的短短几年，人们对安全的理解，从早期的安全就 是杀毒防毒，到后来的安全就是安装防火墙，到现在的购买系列 安全产品，在一步一步地加深。
但是应该注意到，这些理解依然存在着“头痛医头，脚痛医脚” 的片面性，没有将信息安全问题作为一个系统工程来考虑对待；


由于信息安全保障问题的极端复杂性，因此在信息系统建 设中必须遵循信息安全工程方法。
信息安全工程的发展


早期的信息安全工程方法理论来自于系统 工程(SE)过程方法。 美国军方最早在系统工程理论基础之上开 发了信息系统安全工程（ISSE），并于 1994年2月28日发表了《信息系统安全工程 手册v1.0》。 ISSE由系统工程过程发展而来，因而其风 格仍然沿袭了以时间维划定工程元素的方 法学，这也暴露出了一些不足：
信息安全的复杂性

1）信息安全具有社会性


信息安全问题具有前所未有的广泛性和综合性，由于 可能影响到安全的因素不断增多，即使是一个简单的 信息系统，也往往因为人机交互而涉及到组织结构、 人员、物理安全、培训等方面的要求； 在面对每一个信息系统的安全保障问题时，都要考虑 这个系统与非技术因素的交互，将其放在整个社会化 的环境下考虑。 信息安全问题需要全面考虑，系统安全程度取决于系 统最薄弱的环节。
信息安全的复杂性（续）

4）信息安全具有动态性

信息技术在发展，黑客水平也在提高，安全策略、安 全体系、安全技术也必须动态地调整，在最大程度上 使安全系统能够跟上实际情况的变化发挥效用，使整 个安全系统处于不断更新、不断完善、不断进步的动 态过程中。

5）信息安全具有层次性

信息系统的构成本身就是层次性的（主要有物理、网 络、系统、应用和管理等层面），需要用多层次的安 全技术、方法与手段，分层次地化解安全风险。
二、系统工程(SE)过程

1、系统工程过程概况 2、通用系统工程过程活动 3、系统工程过程的几个原则
2.1 系统工程过程概况
评估有效性
挖掘 需求 定义 系统
设计 系统 体系 结构
详细 设计 实施 系统
2.2 系统工程过程活动

通用SE过程由如下活动构成：




1、发掘需求； 2、定义系统要求； 3、设计系统体系结构； 4、开展详细设计； 5、实现系统； 6、评估有效性。

本阶段的工作必须在开发或购买能够满足详细设计规范 的组件这二者之间做出决定。 系统工程师必须权衡两种方式的利弊并进行深入研究。

建设


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

详细设计将产生更低层次的产品规范、具体的工 程与接口控制图、原型、具体的测试计划与流程 和具体的集成后勤支持计划(ILSP-Integrated Logistics Support Plan)。
2.2.5 实现系统

系统工程师将系统从规范变为现实，该阶段的主要 活动包括采办、集成、配置、测试、记录和培训。 采办
External System
NEEDS
System
External System External System
Solution Set
定义系统（续）

系统要求可分为功能要求和性能要求

功能要求描述系统需要完成的任务、动作和行为； 性能要求包括系统的质、量、适用范围、使用频度、响 应性、可靠性、可维护性、可用性等； 此外，内外接口要求与互操作性要求是系统成员之间或 系统与环境、其他系统之间的互作用概念的重要要求。
《信息系统安全工程》之
信息安全工程方法论ISSE
西南交通大学 信息科学与技术学院 李晓航
Last Modified: 2015.12
一、概述

1、什么是信息安全工程 2、为什么需要信息安全工程 3、信息安全工程的发展
什么是信息安全工程


信息安全保障问题的解决既不能只依靠纯 粹的技术，也不能靠简单的安全产品的堆 砌，它要依赖复杂的系统工程——信息安 全工程。 信息安全工程：
External System
Design Elements Components System elements
Internal Interfaces
Target System (all system functions)
System
External System
System Interfaces

2）信息安全具有全面性

信息安全的复杂性（续）

3）信息安全具有过程性或生命周期性


一个完整的安全过程至少应包括安全目标与原则的确 定、风险分析、需求分析、安全策略研究、安全体系 结构的研究、安全实施领域的确定、安全技术与产品 的测试与选型、安全工程的实施、安全工程的实施监 理、安全工程的测试与运行、安全意识的教育与技术 培训、安全稽核与检查、应急响应等，这一个过程是 一个完整的信息安全工程的生命周期。 经过安全稽核与检查后，又形成新一轮的生命周期， 是一个不断往复的不断上升的螺旋式安全模型。
信息安全工程的发展（续）


1）很多安全要求应该贯彻在整个工程过程之中，尤其 是信息安全的保证要求，而ISSE对其缺乏有针对性的 讨论； 2）此外，信息安全的内容及其庞杂，一次完整的信息 安全工程过程，往往会涉及到多个复杂的安全领域， 而有些领域的时间过程性却不明显，以时间维为线索 的描述方式不适合反映出这些内容。


当明确所有的要求后，系统工程师必须同其它系统 负责人一起评估这些要求的正确性、完整性、一致 性、互依赖性、冲突和可测试性。
定义系统（续）


在要求的分析过程中，系统工程师要审查 可追踪性文档，确保发掘出的所有需求都 已经分配到了目标或外部系统之中，确保 目标系统的背景环境描述中包含了所有的 外部接口和信息流。 系统工程师还应确保概要性的CONOPS能 覆盖所有的功能性和任务或业务需求，并 且系统运行的内在风险也得到了提及。
设计系统体系结构（续）

功能分析要将此前的要求分析阶段所确定的高层功能分 解至低层功能，与高层功能相关的性能要求也要分解至 低层。


功能分析的结果是描述每个产品或项目的逻辑功能或性能。 分析的对象包括待建系统的体系结构、功能和过程、接口（内 部和外部）、元素（组件）、信息的流动情况、环境和用户/访 问。 功能分析和分配使得可以对系统的功能目的及其实现方式形成 更好的理解，并在一定程度上获知低层功能的优先级和冲突。 它提供了对于优化物理解决方案来说重要的信息。
定义系统（续）

功能（Functions）由要求决定，每个要求将产生 一项或几项功能。

功能分析的主要内容是分析功能之间或功能与环境之 间的联系。 最简单的图表是文本功能列表，它通过习惯性的缩进、 标号、字体来描述一系列功能的层次结构。 功能列表将对功能进行命名，并且描述其定义、行为、 何时被调用以及输入\输出。
信息安全的复杂性（续）

ຫໍສະໝຸດ Baidu
6）信息安全具有相对性


安全是相对的，没有绝对的安全可言； 首先，安全的动态性决定了所谓的安全只能是相对于 过去的安全，相对未来而言，当前的安全很可能会表 现为不安全； 其次，安全不是目的，安全措施应该与保护的信息与 网络系统的价值相称，因此，实施信息安全工程要充 分权衡风险威胁与防御措施的利弊与得失，在安全级 别与投资代价之间取得一个企业能够接受的平衡点， 人们追求的是在适度风险下的相对安全，而非绝对的 安全。

在上图中，箭头显示了信息在不同活动间的流向，但并不 一定意味着各活动之间的顺序或时间性。 用户/用户代表并不是一个系统工程活动，之所以标注用 户/用户代表的原因在于提醒我们，所有的活动中，必须 不断地在系统工程师或信息系统安全工程师与用户之间进 行交流和反馈。
2.2.1 发掘需求

系统工程师帮助客户理解并记录用来支持其业务 (business)或任务(mission)的信息管理的需求(Needs)，信 息需求说明可以在信息管理模型(IMM- information management model )中记录。 发掘需求是SE过程的起点，是针对用户需求以及用户环 境中的相关策略、法规和标准的一系列判断。 系统工程师要标识所有的用户及这些用户与系统的交互， 标识他们所扮演的角色、承担的责任以及在系统生命周期 各阶段中的授权。 需求应该来自用户的视角，不应该对设计产生过度的约束， 并且要通过用户语言来进行文档化。

是采用工程的概念、原理、技术和方法，来研 究、开发、实施与维护信息系统安全的过程， 它是将经过时间考验证明是正确的工程实施流 程、管理技术和当前能够得到的最好的技术方 法相结合的过程。
为什么需要信息安全工程

信息安全的现状是比较脆弱的，在安全体制、安全管理等 各个方面存在的问题十分严重而突出，且不容乐观；但也 可以看到，从20世纪90年代中期到21世纪初，无论是政 府部门、企业，还是个人用户，安全意识明显增强

需要考虑的策略和政策

2.2.2 定义系统

在该阶段，系统工程师必须明确系统要完成的功 能，包括该功能的实现应达到的程度以及系统的 外部接口。

由需求到目标、目标到要求以及要求到功能的各个翻 译环节均要采用工程语言。


目标描述能够通过描述系统的预期运行效果而满 足需求，系统工程师必须能将目标同此前提出的 需求相联系，并且能够从理论上加以解释。 系统工程师要在该阶段考虑一套或多套能够满足 由客户提出并记录在IMM中的系统需求的解决方 案集。



发掘需求（续）

业务(business) /任务(mission)描述

SE或ISSE的全部工作都是为了使一个机构的本职业务/ 任务能够顺利实施； 因此，在挖掘需求时，首要的一步就是确定任务/业务 的需求，而不是工程或信息安全需求； 任务描述的重点之一是对任务环境进行描述。 在进行系统工程时必须考虑对机构具有约束力的政策、 法规和标准； 事实上，政策、法规问题是导致很多系统工程失败的 主要原因之一。

有很多方法可以通过图表来描述功能的相关联系


2.2.3 设计系统体系结构


系统工程师应该分析待建系统的体系结构，完成 功能的分析和分配，同时分配系统的要求，并选 择相关机制。 系统工程师还应确定系统中的组件或要素，将功 能分配给这些要素，并描述这些要素间的关系。


在SE的“定义系统要求”活动中，系统要求是分配到 整个信息系统中的，它只是指明了系统的功能，却没 有定义系统的组件； 而在“设计系统体系结构”活动中，SE小组将对功能 进行分解，选择具体功能的执行组件，这是体系结构 设计的核心内容。