安全需求定义

对于功能要求和设计约束的的描述，应当：
易于理解 无歧义 综合、全面考虑 完整
简洁
定义需求阶段的有效性评估

“有效性评估”渗透在ISSE过程的每个阶段，用来 评价该阶段的工作是否做的合格了 本阶段的有效性评估将执行以下任务：
确保被选中的解决方案完全符合了支持用户业务的
（信息保护）需要 协调系统（安全）边界，避免与其它系统发生冲突

功能要求 设计约束
系统概念>>安全需求>>功能要求

描述系统应该能做哪些工作（功能）
在安全方面，描述系统提供的安全功能以及性
能指标

不涉及具体的实现架构和操作流程
将信息系统视为黑盒
架构的设计是下一个工程阶段的事情
系统概念>>安全需求>>功能要求

对于功能要求的描述，应该明确下列指标：
对于目标系统，解决方案中定义了它的系 统概念（System Concept），包括：
系统环境（System
Context） 初步的操作概念（Preliminary CONOPS） 系统需求，在安全方面表现为系统安全需求
目标系统的“系统概念”
External System
Target System (all system functions)
系统安全需求（System
Security
Requirements）
系统概念>>系统环境

定义系统(数据、应用、网络)的边界
对于系统安全环境来说，就是系统安全边界

如，需要认证用户才能访问的区域的边界

定义与外部系统的接口
对于系统安全环境来说，就是系统安全方面的
对外接口

如访问CA服务器的地址、端口、通信协议
信息安全工程
安全需求的定义
知识回顾
信息安全工程的功能：6个 信息安全工程小组 LCIE和决策数据库 一般系统需求定义的过程：4个

本讲内容与学习目标

区别系统安全需求 vs. 信息保护需要
System
Security Requirements vs. Information Protection Needs
外部系统：已有的系统，例如已运营的PKI系统
外部系统
外部源自文库统是已存在的，与本次系统
工程要设计的目标系统并存 解决方案中定义了目标系统与外部 系统的接口
这是目标系统环境的一部分
接口的定义主要由外部系统决定
接口示例：访问外部数据库系统的IP
地址、端口、认证协议、通信协议。
目标系统

定义系统安全需求

对应于系统工程的“定义系统需求” 本阶段，系统工程师将提出一个或多个能够满足 用户需要（Needs）的解决方案
Sets” 解决方案是针对整个信息系统而言的，其中包括了为 满足用户的信息保护需要而制定的方案 系统安全工程师要协助系统工程师制定解决方案，在 安全方面协助
解决方案集：“Solution
定义需求阶段的有效性评估（续）
将系统（安全）概念通报给用户，取得他们的
合作
系统（安全）概念——系统（安全）环境，（安全） 操作概念和系统（安全）需求 概念是由系统（安全）工程师确定的，用户不会参 与定义概念的工作，而只是对概念发表认可或不认 可的意见

确保项目风险可以被用户接受
这里的项目风险，与信息系统面临的风险不同，指 的是用户允许实施本次系统工程项目，从而面临的 风险。 例如一旦项目失败（无产品或产品不合格），或者 工期拖延，会给用户带来经济上和业务上的损失

在用户的参与下，最终将有一个解决方案 被选定
选定的解决方案，应该能够满足各个方面的用
户需要，包括信息保护需要

要由用户和系统工程师（系统安全工程师）合作选 定解决方案
目标系统与外部系统

解决方案中可以把用户需要（包括信息保 护需要）分配给目标系统
目标系统：本次系统工程要建设的系统

解决方案中也可以把用户需要分配给外部 系统
系统概念>>安全需求>>设计约束

与外部系统接口的约束
前面已经说到：目标系统与外部系统的接口主
要由外部系统决定 例如与外部数据库的接口，需要主动连接相应 IP和端口，并按照规定格式收发信息
系统概念>>安全需求>>设计约束

对系统设计灵活性的限制
（物理、人文）环境的限制

例如服务器机房空间大小的限制，使得服务器的 数量不能太多 例如车载系统，系统结构要考虑防震

定义需求总结
定义系统安全需求是ISSE的第二阶段 将得到的用户需要（信息保护需要）， 分配给目标系统或外部系统 定义目标系统的系统概念

系统（安全）环境
初步的操作概念（CONOPS）
系统（安全）需求
功能要求 设计约束

External System
System Interfaces
系统概念是对目标系 统的黑盒定义，并不 涉及目标系统内部的 架构（那是下一个工 程阶段的事情）
目标系统的系统概念的内容


系统环境（System Context）
系统安全环境（System
Security Context）
初步操作概念（Preliminary CONOPS） 系统需求（System Requirements）
例如用户认为： 系统应该能够防止重放攻击 系统应确保信息不被无授权者获得 系统应对所有外发的数据提供数据起源认证
系统概念>>初步操作概念（续）

操作概念中还定义了用户业务需要（信息 保护需要）对外部系统的依赖关系，以及 外部系统能够提供的（安全）服务
例如，用户认证，依赖外部PKI系统（这意味着
系统概念>>系统环境（续）

将信息保护需要分配给目标系统或外部系 统
IMM文档中的信息管理过程 IPP中的信息保护需要 分配给外部系统时，要争得外部系统拥有者的
同意
系统概念>>系统环境（续）

识别目标系统和外部系统间的信息流
与外界系统之间的信息流动过程

例如访问外部系统的认证过程
对于此项功能的量的要求（多少个） 对于此项功能的质的要求（做的多好）

在安全方面，体现在安全功能的强度
此项功能的时间要求（何时有效，持续多久） 此项功能的覆盖范围 此项功能的可用性（能够多频繁的被使用）
功能要求示例

用户认证功能
量的要求：支持1万用户 质的要求：穷举攻击在计算上不可行 时间要求：
解决方案（Solution Sets）
External System Target System System
NEEDS NEEDS
解决方案将用 户需要映射到 外部系统（已 有）或者目标 系统（待设计）
External System External System Solution Set
解决方案（Solution Sets）
在安全方面，要考虑与这些信息流相关的保护
需要，并由此确定怎样对信息流进行控制

例如认证过程中数据加密，随机数的使用等
系统概念>>初步操作概念

从用户的角度，描述系统应该具有什么样的功能， 以便支持用户的业务。 初步的操作概念中，不定义Step by Step的操作 步骤 在安全方面，初步操作概念中将从用户角度，描 述系统应该具备什么样的信息保护功能
抵御内外部威胁的限制

合同、用户和法律法规的限制
例如合同上的资金不够购买高档服务器 例如企业规定了员工的隐私权，所以不能监控员 工邮件的内容

系统概念>>安全需求>>设计约束

在系统需求分析中，应当确定并文档化所 有设计约束
这是下一阶段进行系统架构设计时，要遵循的
设计基线
系统概念>>安全需求
了解“解决方案（Solution Set）”的内容 了解系统（安全）需求的内容

安全需求 vs. 保护需要

信息保护需要（Information Protection Needs）： 从用户角度对信息系统安全的理解
信息保护策略（IPP）

系统安全需求：由信息系统安全工程师确定的， 信息保护需要在系统功能和性能上的体现
本系统不实现PKI的功能）

系统（安全）环境和操作概念要由系统工 程师（系统安全工程师）、用户、外部系 统的拥有者共同协商确定，不能是某一家 说了算
系统概念>>系统（安全）需求
“系统需求”描述的是系统应该做成什么样 子（What the system is to accomplish） 对系统需求分析，应该搞清楚目标系统的：
系统运行中的任何时刻，认证功能都有效； 单次认证时间不超过100毫秒（这个指标需要综合考 虑网络速度和认证服务器处理速度）

覆盖范围：所有用户 可用性：最大10个并发认证线程
系统概念>>安全需求>>设计约束

设计约束是与目标系统的设计相关的，会 影响到全部或部分的系统设计活动
与外部系统接口的约束 限制系统设计灵活性的约束