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

二、系统工程(SE)过程

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

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




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

后来，在信息系统安全工程方法的发展上，出现 了第二种思路：过程能力成熟度的方法，其基础 是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，冠名为《信息技术—系统安全工 程—能力成熟度模型》。
《信息系统安全工程》之
信息安全工程方法论ISSE
西南交通大学 信息科学与技术学院 李晓航
Last Modified: 2015.12
一、概述

1、什么是信息安全工程 2、为什么需要信息安全工程 3、信息安全工程的发展
什么是信息安全工程靠纯 粹的技术，也不能靠简单的安全产品的堆 砌，它要依赖复杂的系统工程——信息安 全工程。 信息安全工程：
定义系统（续）

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

功能分析的主要内容是分析功能之间或功能与环境之 间的联系。 最简单的图表是文本功能列表，它通过习惯性的缩进、 标号、字体来描述一系列功能的层次结构。 功能列表将对功能进行命名，并且描述其定义、行为、 何时被调用以及输入\输出。
External System
Design Elements Components System elements
Internal Interfaces
Target System (all system functions)
System
External System
System Interfaces
External System
NEEDS
System
External System External System
Solution Set
定义系统（续）

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

功能要求描述系统需要完成的任务、动作和行为； 性能要求包括系统的质、量、适用范围、使用频度、响 应性、可靠性、可维护性、可用性等； 此外，内外接口要求与互操作性要求是系统成员之间或 系统与环境、其他系统之间的互作用概念的重要要求。
信息安全的复杂性（续）

6）信息安全具有相对性


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

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


2.2.3 设计系统体系结构


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


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

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

系统工程师将系统从规范变为现实，该阶段的主要 活动包括采办、集成、配置、测试、记录和培训。 采办
信息安全工程的发展（续）


1）很多安全要求应该贯彻在整个工程过程之中，尤其 是信息安全的保证要求，而ISSE对其缺乏有针对性的 讨论； 2）此外，信息安全的内容及其庞杂，一次完整的信息 安全工程过程，往往会涉及到多个复杂的安全领域， 而有些领域的时间过程性却不明显，以时间维为线索 的描述方式不适合反映出这些内容。
External System
System Interfaces
iatf_3_4b_3004b
Define System Requirements
iatf_3_4a_3004a
Design System Architecture
描述了“定义系统要求”与“设计系统体系结构”的区别。 前者将目标系统视为“黑盒”，后者则创建系统的内部结 构；
信息安全工程的发展


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

2）信息安全具有全面性

信息安全的复杂性（续）

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


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

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


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

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


2.2.4 开展详细设计

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


系统工程师应将所有的系统要求跟踪至系统组件，直 至无一遗漏。 最终的详细设计结果应反映出组件和接口规范，为系 统实现时的采办工作提供充分的信息。

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

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

1）信息安全具有社会性


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

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

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

需要考虑的策略和政策

2.2.2 定义系统

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