7 信息安全工程.pptVIP

2002-11-24 信息安全工程 石 鉴 shih@nankai.edu.cn 南开大学国际商学院 信息系统安全工程（ISSE） 信息系统安全生命周期与安全服务生命周期 SSE-CMM 对信息安全工程的其它讨论 什么是信息安全工程 信息安全在我国发展的短短几年间，从早期的安全就是杀毒防毒，到后来的安全就是安装防火墙，到现在的购买系列安全产品，直至开始重视安全体系的建设，人们对安全的理解正在一步一步地加深。但是应该注意到，这些理解依然存在着“头痛医头，脚痛医脚”的片面性，没有将信息安全保障问题作为一个系统工程来考虑和对待。 信息安全保障问题的解决既不能只依靠纯粹的技术，也不能靠简单的安全产品的堆砌，它要依赖于复杂的系统工程——信息安全工程。信息安全工程是采用工程的概念、原理、技术和方法，来研究、开发、实施与维护信息系统安全的过程，是将经过时间考验证明是正确的工程实施流程、管理技术和当前能够得到的最好的技术方法相结合的过程。 为何需要信息安全工程 信息安全具有社会性 信息安全具有全面性 信息安全具有生命周期性 信息安全具有动态性 信息安全具有层次性 信息安全具有相对性 通用系统工程（SE）过程 由SE到ISSE 信息系统安全工程（ISSE）是美国军方根据系统工程（SE）过程的原理，面向信息安全开发的方法学，其与SE之间是基本的映射关系。 美国军方在1994年2月发布了《信息系统安全工程v1.0》，并随后发布了一系列相关军标和指令。 SE与ISSE过程的对应 SE与ISSE过程的对应 SE与ISSE过程的对应 DoD 5000.2-R系统工程过程 IEEE Std. 1220-1998系统工程过程 ISSE的三大原则 原则1：始终将问题空间和解决方案空间相分离。 “问题”是“我们期望系统做什么？”，“解决方案”是“系统怎样实现我们的期望？”当我们关注解决方案时，很容易忽视对问题的注意，这便会导致错误问题的解决和错误系统的建造。没有比解决一个错误的问题并建造一个错误的系统更低效的了。 ISSE的三大原则 原则2：问题空间要根据客户的使命或业务需求来定义。 用户经常同工程师讨论技术或对解决方案的想法，而不是告诉工程师问题在哪。系统工程师和信息系统安全工程师必须把客户的这些想法放到一边，发掘出客户的基本问题。如果客户的需求不是基于其使命或业务需求而提出的，则最终系统可能难以满足客户的需求。这样会继续导致错误系统的建造。 ISSE的三大原则 原则3：解决方案空间要由问题空间相驱动，并由系统工程师和信息系统安全工程师来定义。 是系统工程师精通系统的解决方案，而不是客户。如果客户是解决方案的设计专家，那就没必要再去雇用系统工程师了。一个坚持介入设计工程的客户很可能会对解决方案带来限制，影响到系统工程师的灵活性，从而影响到系统的使命或业务支持目标，影响到用户需求的满足。 ISSE活动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 支持系统的认证和认可（CA） 子任务-01.11.1 标识指派的批准官员（DAA）/认可员 子任务-01.11.2 标识认证专家（CA）/认证员 子任务-01.11.3 确定可适用的CA和采办过程 子任务-01.11.4 确保认可员和认证员对信息保护需求的认同 ISSE活动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