安全需求分析的一般课题

3.3.2　安全需求分析的一般课题

这一节考察在安全目标、需求和要求的分析和定义中所涉及的一般性课题。

1.安全规则和政策解释

首次信息系统安全需求分析活动，应当包括全面审查和考虑一切适用的、与有关安全标准或目标体系结构相符合的规则和政策性指令。在这一个步骤里，需要对由国家、国际机构、地方和企业发布的保护涉密的和敏感的非涉密信息的强制性和指导性的法律体、规则、机构政策与指南等进行分析和解释。政府通过国家主管部门的指令、国家标准和行业标准以及由政府授权的代理机构的规划和指导，提供保证信息系统的综合安全指南。为业务域定义的安全目标，以及为系统获取项目所开发的具体项目的需求和要求，必须保证系统所提交的强制性需求是足够的，并保证遵守适当的指南和方法论，这些强制性规定的解释同用户和指定审批机构（DAA）自己的参考和解释框架（包括DAA许可的任何机构）是一致的。从安全规则和政策评审中提取出的某些需求和表达的客户的操作运行安全需求是难于区别的。然而，在其他情况下，政策条款却可以给某些特定系统强加系统安全需求，因为这些特定系统不能按逻辑立即从其运行业务需求中产生出系统安全需求，这些政策性需求将是系统开发或运行的设计限制。

在根据较高层次政策和规则提取系统安全需求时，应当把这种关系保留下来作为工程决策数据库和需求验证可跟踪模板（RVTM）的一部分。

信息安全工程过程并不要求产生系统特有的“策略”或指令，而是把这些指令视为对业务环境和用户机构更合适的较高层次的管理功能。由于业务环境包含许多各不相同但可能相互连接的系统，所以管理意义上的策略最好是采用一致性的一次性（而不是分离式的）系统配置模式，以避免冲突、相互依赖性和混乱。如上所述，任何定义的业务域策略都要按符合系统工程工作项目的目标和设计限制来运行。

然而，有关安全的接口控制/设计规范（有时叫做“策略”）以及系统安全运行程序、限制和控制，都应当作为系统产品和过程方案通过整个开发周期的信息安全工程活动过程产生出来。除了要仔细研究接口对正在获得的或改进的系统的影响之外，还应分析对与之连接的外部系统的影响。建立外部接口，往往要求每一个适用的外部系统与负责的系统管理人员和/或配置控制委员会充分协调，他们应当认真地审查新接口对系统功能、性能、运行和支持模式，以及安全风险可能产生的不利影响。

2.安全威胁评估

安全威胁被定义为：敌对方经过深思熟虑，利用那些可能对信息或系统造成损害的条件、（行为或事件的）能力、意图和方法。必须全面仔细地考虑在系统开发和系统运行期间，以及在实际或预计时间范围内可能发生的外部人员和内部人员蓄意的安全威胁。有时，也可以认为威胁包含授权用户不经意所犯下的错误、纯粹误操作或偶尔的误用，但这些因素具有偶然性和可控性的特征。

信息安全工程小组应当同用户一道工作，以帮助它们在“系统威胁评估报告”（System Threat Assessment Report，STAR）内准确全面地描述有关对信息系统安全的威胁。STAR报告描述了规划的未来运行威胁环境、系统特有的威胁、可能影响项目决策的实际威胁，以及项目管理人员在评估针对威胁的程序时所得到的交互式分析成果。威胁评估必须提前进行，使其在系统“初始运行能力”（Initial Operational Capability，IOC）的开始阶段及延伸到其预期运行寿命结束的时间范围内都有意义。STAR报告应当包含针对用户信息和信息系统的安全威胁，以及其他各种类型的威胁（例如：源自敌方的物理威胁或者军事破坏）。

应当针对特定业务和系统环境以及预期的运行时间框架，严密地裁剪信息系统安全的威胁信息。信息系统安全威胁信息应当包括已得到论证的威胁和可支持的设定的威胁。威胁信息的形成涉及潜在敌对方的手段、时机和动机。信息系统安全威胁信息应当以某种形式和在某个分类级别上提供给客户，以使用户和信息安全工程小组之间能够进行联系和相互理解。威胁信息将用来在系统运行需求文件，以及获取和工程管理计划中驱动相应的需求。

开发期间的相关威胁以及针对这些威胁要采取的安全对策，常常需要包括在“项目保护计划”中。“项目保护计划”涉及在试验中心、区域内、试验室、承包商设备以及部署现场中与程序相关联的活动，并按需求为获取程序提供全方位的保护措施。“项目保护计划”在“概念阶段”制定，并且应在后继的阶段加以更新。

3.任务（业务）安全目标

为业务或商业领域定义的安全目标代表安全定义的最高等级。这些安全目标最好以绝对术语（即没有那种通常与系统特定需求说明紧密联系的相关性能或“保证”准则），进行广泛陈述。虽然随着时间阶段的推移，安全目标并非完全静止不动，但却应当以一种大范围、长时期使用的观点提出安全目标——从而可以作为许多不同系统的安全风险分析及产品和过程规划的稳定平台。这些系统可能出现在有效时间跨度内的特定业务或工作环境中。一般说来，安全目标最好是由系统用户陈述，但信息安全工程小组应当理解安全目标的细节，并且在用户需要时提供帮助。如果用户没有陈述出安全目标时，信息安全工程小组应当能够通过回溯追踪需求的层次结构，抽取出与指定获取建议最为相关的绝大部分（安全）目标，以发现客户的基本安全理由和最终安全目标。

安全目标可以适用于业务的多方面或某个部分。一个具体安全目标的理由说明，应当对那些得到安全目标支持的业务进行文档化描述。同样，当业务功能被分配到业务环境内的单个系统时，安全目标可以不同程度地适用于使用中，或在任一特定时间点获取线上该系统的多个（或只有一个独立）的子系统，甚至该系统本身。依据给定的系统获取项目的前后情况，某些安全目标可以分配给尚未计划的未来工作项目；分配给整个过程解决方案；分配给接口需求和限制，这些需求和限制与正获取系统将要工作的环境中的基础设施或其他系统相关；或分配给更间接的环境假设条件。作为今后系统能力需求和要求定义的一部分，对表述的安全目标和基本理由陈述应该建立有效的可跟踪性。

安全目标如图3-5所示，它显示了在开发安全目标和基本理由说明过程中业务信息、通用性威胁指南和综合安全指南之间的关系，并图解说明其基本理论，包含基于安全目标进行推理阐述和解释的信息（图中所示跨系统的业务安全目标的前后文中的许多原则，也可按迭代方式应用于以后的、更为具体的系统的需求分析）。理由说明应当提供对需要某些安全保护的理解，并抓住安全目标与如下各项之间的关系：受到安全目标支持的业务目标，激发安全目标与业务相关的威胁，不实现安全目标的后果，以及驱动或支持适用于安全目标的综合安全指南。

在以后的体系结构开发、系统设计、系统实现和安全风险管理活动期间，可以参考上述这些理由说明和关系，指导有关的安全性分析。

4.安全服务分类

安全服务应当考虑与业务需求和威胁密切相关，其中威胁是在系统阐述安全目标和安全需求过程中的根据。对安全服务是进行单独考虑还是进行综合考虑，取决于业务需求、威胁和安全的综合指南。以下提供了可作参考的安全服务，这些安全服务的意义和配置使用应在适当时候参考信息安全工程小组或客户小组机构所习惯或指定的有关标准。

图3-5　安全目标

机密性（Confidentiality）：提供对未授权泄露的保护服务。

访问控制（Access Control）：为防止未经授权使用资源提供保护（例如：使用通信资源，读出、写入或删除信息资源和操作运行中的资源等）。

完整性（Integrity）：对抗主动威胁，确保信息准确而且无任何变化地被传送。

数据完整性（Data Integrity）：提供对不经意地篡改或销毁数据、恶意地销毁或篡改数据的保护。

系统完整性（System Integrity）：保护信息系统资源不受篡改或误用的危害。

鉴别（Authentication）：对用户、用户设备和其他实体进行有效性验证和真实性证实，或对被存储或被传输信息的完整性提供保证。

可用性（Availability）：保证信息能按用户所需的地点、时间和形式被提供。

不可抵赖性（Non-Repudiation）：向信息接收方提供源发证明以防止发送方否认发送过信息或其内容，同时也可向信息发送方提供递交证明以防止接收方否认收到过信息或其内容。

安全管理（Security Management）：这项服务关注对业务的安全方面进行支持和控制所需的操作。

5.信息流向及功能和价值

了解系统及其所处理信息的安全临界状态也是非常重要的。应该重视由于系统资源或系统所处理信息的丧失、泄露或被修改而对业务、人的生命和开销（金钱和时间）所产生的影响。为了定义恰当的安全目标，能力需求，以及有效地表达用户所需安全的系统需求，必须识别和分析由系统处理或存储信息的功能、流向和价值。系统使用信息的途径（功能）、信息如何通过和进/出系统元素（流向）、信息对于系统运行和业务在一般情况下的机密（敏感）性和重要性（价值），所有这些在反复开发系统安全需求中都是极其重要的因素。在近期未对业务信息的安全分类进行仔细研究的地方，或者未明确对业务信息的安全进行分类，或者分类过分详细，或者分类过分粗糙，这时的信息安全工程小组宁可使用用户目前的分类等级评估来支持客户和终端用户，而不要从头开始，对其他类似的重要性、敏感性分类评估也照此办理。