安全需求定义概述

3.3.3　安全需求定义概述

1.同安全有关的运行需求分析

用文档确认一个系统初始的安全能力需求极其重要，这样有助于负责系统开发的人了解必须完成的作业。业务和运行需求是对用户需求的说明，并且必须用来指导项目办事机构和工程小组进行后续开发工作。信息安全工程应当尝试帮助用户在适当的时候生成安全能力需求和运行需求说明，但应当善于理解用户用他们自己的名词术语和优先权所表达的需求愿望。最重要的问题是，所有涉及的人或机构（例如：用户、获取机构、C&A代表、信息安全工程小组）要意识到这些都是用户自己的需求，而非项目办事机构或工程人员的需求。所陈述的安全能力需求集，应当包含针对系统的最高级别的安全需求。它们应当是从相关安全目标和指令、特定业务问题，以及把业务资源置于风险之下的安全威胁分析的最高级别的信息中推导出来的。安全能力需求将影响到在未来系统内如何管理、保护和分发信息，影响到信息如何同其他系统接口。安全能力需求应当以与实现无关的方式，以不含专业化信息系统安全术语的方式，在适当的高等级抽象层上予以表述。

为了对来自广泛业务能力需求中与安全相关的系统运行需求进行更为充分的定义，信息安全工程小组应当对业务能力需求，国家的、本地的和商业企业的适用安全政策，业务目标/安全目标以及业务威胁进行评审。利用对业务的了解，信息安全工程小组应当注意识别在其运行环境内对系统的安全威胁。信息安全工程小组要利用为“系统威胁评估报告（STAR）”所准备的威胁信息以及其他资源（例如信息系统安全威胁专家把威胁运用到系统上时的信息），确定安全能力或防御这些威胁所必需的对抗措施。

一般说来，支持信息安全工程小组分析所必需的信息可在各种系统文件内找到，只是各具不同的详细程度、精确度、用户支持度以及作为获取进程的成熟度而已。对于MNS，信息安全工程小组希望这些信息和对这些信息的任何分析信息，是稍微口语化并且被高度抽象的。在“概念和需求阶段”，开发工作将转入需求的进一步分解、文件编制，并以运行需求说明形式中的需求为最终需求基线和系统需求规范。随着需求的成熟和修改，提高精确度、详细度和分析的密度，规范的形式以及配置控制的维护将变得十分清楚。在确定系统的安全需求时，对可用信息的评审和分析，对政策和规则进行评审的结果，都是十分有价值的。

为了给一个系统概念定义恰当的运行安全需求，对信息安全工程小组同样重要的是理解其他适用的（非安全）能力目标，以及为满足总体能力需求而制定的获取范围（成本、进度、风险、组队方式）。为了取得成功，所有这些都必须处于平衡状态。在开始正式的工程需求分析之前，安全能力需求必须转换为一组运行功能需求和性能需求与约束。

2.信息安全工程需求活动

在帮助客户确定安全能力需求之后，信息安全工程小组作为总体系统工程小组的一部分继续进行更加正式的需求分析。信息安全工程小组的需求分析活动应该从评审和更新先前的分析（业务、威胁等）开始，提炼出业务和环境定义，从而支持对每一项功能建立起安全需求。信息安全工程还应当理解在其他功能领域所进行的分析，比如那些与运行和支持工程功能相关的领域，以及由其他专家（例如安全工程师、软件工程师和业务应用专家等）所进行的分析。

随着安全需求从顶层需求向更精确的具体需求转化，必须对它们作出最充分的定义，以使系统概念和体系结构的可选择方案能够得到开发，并能在集成的并发工作过程内进行比较。由于对可选择概念已进行了研究，所以将在恰当的时候完成对每个不同概念的需求分析。从安全目标、国家政策和整个设计过程的其他输入中反复地导出系统、后继的配置项目（CI）和组件安全需求的过程，参见图3-6。

信息安全工程必须协同客户分析安全需求，从而确定这些需求是否确实是有效的需求。除了仔细研究各个需求说明外，还必须仔细地研究整个安全需求的完整性、不一致性和相互依赖性。有效的需求说明，即是对有关系统功能、性能需求的或者设计限制的简单的、非歧义的和可验证的陈述。安全需求还必须说明使需求有效的条件。除了必须确定限制外，安全需求的陈述不需说明如何实现系统产品和过程方案。正确的需求陈述对系统的验证和证实是极其重要的，它们提供了判断系统的简明而精确的尺度。安全需求是设计、实现、验证和证实的基础。对任何需要提请审批的、对安全需求和其他相互关联需求的修改，都应当仔细地研究这些修改可能对设计系统安全风险的影响。

图3-6　安全需求的开发

向系统中的各种设备提供密钥的需求，即是一例经过推导所得到的安全需求：这一需求的存在是隐含的，直到为支持特定系统安全需求提供机密性服务而作出选取加密方法的决策时，这一需求才明显地被提出来。这个决策改变了系统的前后环境关系，产生了一个新的界面，一个新的数据敏感度类型（即密钥）和相关需求（例如密钥管理）。

随着系统体系结构的改进，必须不断地评审和提炼安全需求，借以确保继续有效地以安全需求的规范形式提交系统的安全需求，推动系统设计。随着系统安全需求的提炼和形式化过程的不断进行，以及系统设计的雏形出现，各个配置项目（CI）的详细安全需求也从形式化的系统级需求和规范中被提炼出来。

3.安全性能和保障需求

信息安全工程小组还必须识别同安全功能性需求目标相关联的性能需求，这通常应当采用若干种需求表达形式：

（1）功能/性能需求（Functional/Performance Rrequirements Pairs）

对与功能性安全需求相连的性能需求，可以在条件允许情况下直接写出，或者参照初步设计过程中的与已定义安全保证类相关联的开发条款来确定。例如，合约规范中的一个需求可陈述为：

“除了指定的监督小组内的特许用户之外，系统将阻止其他人改动职员的工资记录；这一能力需求将在不低于中等保证的级别上提供。”

“除了两个或多个指定的特权维护人员可以修改之外，并且要求他们在请求改动之前，每一位都要及时正确完成必要的鉴别程序，否则系统将阻止其他人员非法改动核反应堆的安全警戒线。这个能力需求将在不低于超高（SUPER-HIGH）保证级别上提供。”

（2）设计需求

随着系统功能被分解，在安全保证规划中形成的负面事件清单也被分解。信息安全工程审视每个子功能的潜在错误特性，并把这些负面事件映射到先前确定的安全保证级别上。当分解完成时，便可以对每个最低层子功能分配设计需求所需的信任级别。软件设计需求的一个示例是：

“AUDIT2.1安全审计子功能软件将被实现为IAW安全保证级别PRETTY-GOOD，正如在‘TRUS-ME软件开发计划’中所定义的。”

一个与需求规范相关的活动就是从安全角度进行的“可测试”，并对适当验证这些需求规范进行识别——不仅包括所选择的手段，也包括所需验证的严密程度和强度。