金融信息安全(10)-构建有安全保障的应用系统.pptVIP

构建有安全保障的应用系统 李改成 lgc@ss.pku.edu.cn 瀑布模型－由SE到ISSE Winston Royce 1970为美国空军开发的瀑布模型是一个经典模型。其思想是首先获得系统需求的简洁陈述，将其精化为规范，实施并测试系统组件，集成并测试系统，然后投入生产运营。 信息系统安全工程（ISSE）是美国军方根据系统工程（SE）过程的原理，面向信息安全开发的方法学，其与SE之间是基本的映射关系。 美国军方在1994年2月发布了《信息系统安全工程v1.0》，并随后发布了一系列相关军标和指令。 SE与ISSE过程的对应 SE与ISSE过程的对应 SE与ISSE过程的对应 安全需求 安全需求 （security requirement）是为保证组织业务战略的正常运作而在安全措施方面提出的要求，可以确保安全内建于信息系统中。 对特定安全需求的清晰理解可建立一个有效的系统。不了解需求是失败的根源，对应用领域的不了解释导致失败和冲突的需求的原因，并导致沟通的不畅。 应用系统的安全需求主要来自以下两个方面： 1　业务系统本身决定的安全需求（系统级），包括系统的服务可用性，抗否认性等 2　信息处理流程所决定的安全需求（数据级），包括信息机密性、完整性等。 特定系统的安全需求 安全需求导出 安全需求导出的困难 应使所有有关团体能就安全需求达成一致性意见。 安全需求的导出是一个复杂而困难的技术问题，并且夹杂着一些微妙的组织和个人政治斗争的因素。 另一个困难是，在现实中，什么地方需要进行保护经常是不明确的。 原则：安全需求的导出需要始终将问题空间和解决方案空间相分离。 “问题”解决“系统做什么？”，“解决方案”处理“系统如何做？ ”问题空间要根据客户的使命或业务需求来定义。 安全需求导出 定义系统安全要求信息时，系统安全的背景环境、概要性的系统安全以及基线安全要求均应得到确定。 分析业务系统及其包含的各种敏感信息，确定其安全需要，最后经过汇总得到整个系统的安全需求。 收集所有可影响系统安全性的外部影响。 可能的外部影响包括法律、法规、政策以及商业标准，他们均可能左右系统的环境。必须说明系统客户提出的安全需求，并从中理解其安全意义。 机构外的很多因素也会影响到机构的安全需求，如策略上的倾向性和政治重点的变化、技术发展、经济影响、全局性事件以及信息战。 安全需求导出 这些因素没有一个是静态的，因此需要监视并定期地评估这些变化可能造成的影响。 定义或确定出目标的逻辑或物理边界，以确保没有疏漏。 系统的环境包括该系统与其他机构或系统的接口。要标识出接口组件是位于安全边界的内侧还是外侧。运行的约束条件也要接受检查，以考察其对安全的影响。 头脑风暴法 在没有专家的情况下，使用头脑风暴。考虑所有可能的最坏的情况，使用多个专家记录，密码学、访问控制和内部审计的人从不同的角度看问题。有价值的创意包括策略目标的陈述、特定攻击的讨论和某种保护机制有效性的讨论。对一个新项目，一群不同背景的人考虑一天的效果要比一个专家考虑20天的效果好。 记录安全需求 记录并分发安全需求说明文件是一种合作解决问题的手段。 使用CC标准处理安全需求。 安全保护框架PP 为一类目标系统（TOE）定义的一组与实现无关的安全要求。 通常使用CC标准中定义好的需求组件或由这些组件构成的组件包。 每个PP都必须指定一个安全保证等级，这是按照该PP研制的安全产品的安全确信度所应该达到的程度。 安全标的ST 为某一特定的安全产品而定义的，与PP相比，代表了更低层次上的概念。 ST由以下几个部分组成：引言、TOE描述、TOE安全环境、安全目的、安全要求、TOE概要规范、PP引用声明、基本原理等。 满足性分析 ST包括确定的目标系统（TOE）的IT安全要求和它所提供的安全功能和保证措施，并证明这些安全功能和保证措施是满足其所述安全要求的。 满足性分析将系统面临的威胁映射到系统的安全需求和假设之上。为证明映射关系的正确性，需要考察安全需求和假设能以何种方式对抗某个安全威胁。 完整性安全威胁T1：没有被授权使用协调的人员能够冒充一个授权用户访问系统资源。 身份认证需求R1：只有当用户向系统提供了有效的、唯一的标识，并且系统通过使用口令的方式对这个标识进行了认证的情况下，用户才能和系统建立会话。 访问控制需求R2：只有系统成功完成了用户标识的识别和认证的情况下，用户和系统才能在建立的会话中进行交互。 假设A1：系统在安装时必须保证只有一部分合法的用户能从物理上接触到该系统。 假设A2：只有特殊授权的用户才能拆卸系统中存储用户标识和认证数据的磁盘。 假设A3：用户不能让其他人知道自己的口令。 假设A4：用户口令产生后，必须以安全的方法进行传送。 在这里， 安全需求和假设A1 可保证阻止非授权用户的