《《安全需求定义》PPT幻灯片》由会员分享，可在线阅读，更多相关《《安全需求定义》PPT幻灯片（29页珍藏版）》请在金锄头文库上搜索。
1、1,信息安全工程,安全需求的定义,2,知识回顾,信息安全工程的功能：6个 信息安全工程小组 LCIE和决策数据库 一般系统需求定义的过程：4个,3,本讲内容与学习目标,区别系统安全需求 vs. 信息保护需要 System Security Requirements vs. Information Protection Needs 了解“解决方案（Solution Set）”的内容 了解系统（安全）需求的内容,4,安全需求 vs. 保护需要,信息保护需要（Information Protection Needs）：从用户角度对信息系统安全的理解 信息保护策略（IPP） 系统安全需求：由信息系统安
2、全工程师确定的，信息保护需要在系统功能和性能上的体现,5,定义系统安全需求,对应于系统工程的“定义系统需求” 本阶段，系统工程师将提出一个或多个能够满足用户需要（Needs）的解决方案 解决方案集：“Solution Sets” 解决方案是针对整个信息系统而言的，其中包括了为满足用户的信息保护需要而制定的方案 系统安全工程师要协助系统工程师制定解决方案，在安全方面协助,6,解决方案（Solution Sets）,解决方案将用户需要映射到外部系统（已有）或者目标系统（待设计）,7,解决方案（Solution Sets）,在用户的参与下，最终将有一个解决方案被选定 选定的解决方案，应该能够满足各个
3、方面的用户需要，包括信息保护需要 要由用户和系统工程师（系统安全工程师）合作选定解决方案,8,目标系统与外部系统,解决方案中可以把用户需要（包括信息保护需要）分配给目标系统 目标系统：本次系统工程要建设的系统 解决方案中也可以把用户需要分配给外部系统 外部系统：已有的系统，例如已运营的PKI系统,9,外部系统,外部系统是已存在的，与本次系统工程要设计的目标系统并存 解决方案中定义了目标系统与外部系统的接口 这是目标系统环境的一部分 接口的定义主要由外部系统决定 接口示例：访问外部数据库系统的IP地址、端口、认证协议、通信协议。,10,目标系统,对于目标系统，解决方案中定义了它的系统概念（Sys
4、tem Concept），包括： 系统环境（System Context） 初步的操作概念（Preliminary CONOPS） 系统需求，在安全方面表现为系统安全需求,11,目标系统的“系统概念”,系统概念是对目标系统的黑盒定义，并不涉及目标系统内部的架构（那是下一个工程阶段的事情）,12,目标系统的系统概念的内容,系统环境（System Context） 系统安全环境（System Security Context） 初步操作概念（Preliminary CONOPS） 系统需求（System Requirements） 系统安全需求（System Security Requiremen
5、ts）,13,系统概念系统环境,定义系统(数据、应用、网络)的边界 对于系统安全环境来说，就是系统安全边界 如，需要认证用户才能访问的区域的边界 定义与外部系统的接口 对于系统安全环境来说，就是系统安全方面的对外接口 如访问CA服务器的地址、端口、通信协议,14,系统概念系统环境（续）,将信息保护需要分配给目标系统或外部系统 IMM文档中的信息管理过程 IPP中的信息保护需要 分配给外部系统时，要争得外部系统拥有者的同意,15,系统概念系统环境（续）,识别目标系统和外部系统间的信息流 与外界系统之间的信息流动过程 例如访问外部系统的认证过程 在安全方面，要考虑与这些信息流相关的保护需要，并由此
6、确定怎样对信息流进行控制 例如认证过程中数据加密，随机数的使用等,16,系统概念初步操作概念,从用户的角度，描述系统应该具有什么样的功能，以便支持用户的业务。 初步的操作概念中，不定义Step by Step的操作步骤 在安全方面，初步操作概念中将从用户角度，描述系统应该具备什么样的信息保护功能 例如用户认为： 系统应该能够防止重放攻击 系统应确保信息不被无授权者获得 系统应对所有外发的数据提供数据起源认证,17,系统概念初步操作概念（续）,操作概念中还定义了用户业务需要（信息保护需要）对外部系统的依赖关系，以及外部系统能够提供的（安全）服务 例如，用户认证，依赖外部PKI系统（这意味着本系统
7、不实现PKI的功能） 系统（安全）环境和操作概念要由系统工程师（系统安全工程师）、用户、外部系统的拥有者共同协商确定，不能是某一家说了算,18,系统概念系统（安全）需求,“系统需求”描述的是系统应该做成什么样子（What the system is to accomplish） 对系统需求分析，应该搞清楚目标系统的： 功能要求 设计约束,19,系统概念安全需求功能要求,描述系统应该能做哪些工作（功能） 在安全方面，描述系统提供的安全功能以及性能指标 不涉及具体的实现架构和操作流程 将信息系统视为黑盒 架构的设计是下一个工程阶段的事情,20,系统概念安全需求功能要求,对于功能要求的描述，应该明确
8、下列指标： 对于此项功能的量的要求（多少个） 对于此项功能的质的要求（做的多好） 在安全方面，体现在安全功能的强度 此项功能的时间要求（何时有效，持续多久） 此项功能的覆盖范围 此项功能的可用性（能够多频繁的被使用）,21,功能要求示例,用户认证功能 量的要求：支持1万用户 质的要求：穷举攻击在计算上不可行 时间要求： 系统运行中的任何时刻，认证功能都有效； 单次认证时间不超过100毫秒（这个指标需要综合考虑网络速度和认证服务器处理速度） 覆盖范围：所有用户 可用性：最大10个并发认证线程,22,系统概念安全需求设计约束,设计约束是与目标系统的设计相关的，会影响到全部或部分的系统设计活动 与外
9、部系统接口的约束 限制系统设计灵活性的约束,23,系统概念安全需求设计约束,与外部系统接口的约束 前面已经说到：目标系统与外部系统的接口主要由外部系统决定 例如与外部数据库的接口，需要主动连接相应IP和端口，并按照规定格式收发信息,24,系统概念安全需求设计约束,对系统设计灵活性的限制 （物理、人文）环境的限制 例如服务器机房空间大小的限制，使得服务器的数量不能太多 抵御内外部威胁的限制 例如车载系统，系统结构要考虑防震 合同、用户和法律法规的限制 例如合同上的资金不够购买高档服务器 例如企业规定了员工的隐私权，所以不能监控员工邮件的内容,25,系统概念安全需求设计约束,在系统需求分析中，应当
10、确定并文档化所有设计约束 这是下一阶段进行系统架构设计时，要遵循的设计基线,26,系统概念安全需求,对于功能要求和设计约束的的描述，应当： 易于理解 无歧义 综合、全面考虑 完整 简洁,27,定义需求阶段的有效性评估,“有效性评估”渗透在ISSE过程的每个阶段，用来评价该阶段的工作是否做的合格了 本阶段的有效性评估将执行以下任务： 确保被选中的解决方案完全符合了支持用户业务的（信息保护）需要 协调系统（安全）边界，避免与其它系统发生冲突,28,定义需求阶段的有效性评估（续）,将系统（安全）概念通报给用户，取得他们的合作 系统（安全）概念系统（安全）环境，（安全）操作概念和系统（安全）需求 概念是由系统（安全）工程师确定的，用户不会参与定义概念的工作，而只是对概念发表认可或不认可的意见 确保项目风险可以被用户接受 这里的项目风险，与信息系统面临的风险不同，指的是用户允许实施本次系统工程项目，从而面临的风险。 例如一旦项目失败（无产品或产品不合格），或者工期拖延，会给用户带来经济上和业务上的损失,29,定义需求总结,定义系统安全需求是ISSE的第二阶段 将得到的用户需要（信息保护需要），分配给目标系统或外部系统 定义目标系统的系统概念 系统（安全）环境 初步的操作概念（CONOPS） 系统（安全）需求 功能要求 设计约束,
