安全的生命期支持的开发方法

3.6.1　安全的生命期支持的开发方法

信息安全工程小组和LCIE将和客户一起作业，为系统整个生命期定义一个可理解的安全方案；在多个系统配置的情况下，对个别站点或站点类可能要开发特定方案。由于某些系统的安全需求可采用非技术的过程而不是技术产品解决方案，在获取和开发期间以及稍后的运行阶段要与负责系统安全的各种机构建立密切关系。这些机构可能有助于场地勘测、物理和管理安全分析及对策分析。

在这一活动中产生的信息，将被并入到相应的系统文件中。与预先激活的安全支持有关的信息安全工程的作用，可能需要并入到系统工程管理计划、项目保护计划和/或合同采购文件中。在系统部署开始之后，安全支持的文档多半是系统集成后勤支持计划的一部分，或者是安全管理计划的一部分。这些安全生命期支持问题对C&A团队来说很有意义，并且可能并行出现在系统C&A计划中。

信息安全工程应准备就系统开发和生产期间所适用的安全支持问题和方法，向客户提出建议。例如安全许可证等级，在开发者/集成者、操作者和系统维护者之间通常是可变的。开发者/集成者的人事和设备的许可证需求可在SOW中，而操作者和维护者的这种需求则可能在系统理论原则和后勤支持计划中。

隐藏系统开发者或拥有者身份的“隐蔽采购”行为，适合于某些子系统或组件。另一个例子是，安全方案中可能包括需要保护敏感信息以免泄露的若干步骤，也可能是需要监控系统生产和分配过程的各方面来保证合适的安全需求得到满足。

生命期的安全方案至少要涉及下列领域：监控系统安全、系统安全评估、配置管理、培训、后勤和维护、次要和主要的系统修改以及报废处置。早在开发期间就应该开始这些活动的规划，使系统在整个生命期内可以考虑这些领域的完整集成。主要修改通常将引起正式的再度请求系统工程和采集过程提出广泛的和价格昂贵的修改方案，并在重新设计现有系统还是代替现有系统之间进行利益平衡。

信息安全工程小组和LCIE将和客户与C&A小组共同作业，准备系统生命期的安全支持计划。信息安全工程小组应确保提供系统生命期支持的客户解决途径，使系统的安全风险不致恶化，并考虑提高安全性来对付敌对势力的能力或系统脆弱性的增加。C&A小组在系统启动之后，要注意确定重新认证重新认可的策略：合适的阈值，由谁判定（通常是DAA），以及在系统启动后这些策略怎样实现。信息安全工程小组考虑的领域包括：

①在开发、测试和运行使用期间，有必要对系统进行监控，以持续地与安全需求保持一致，而不增加可接受范围之外的安全风险。

②保证针对系统的培训要包括安全特性和限制，以使可能导致安全风险增加的类似操作和维护错误受到控制并可接受。

③对那些与可用规则和规章相一致的、与安全有关的组件的处理指令进行跟踪，而不增加安全风险。

④保证配置管理过程是适当的，以避免出现未经适当批准和引起安全风险上升的修改事件。

⑤定义必要的安全性应急计划，该计划与运行的应急计划相匹配，例如战时或敌对状态下的应急计划，此时可能需要接受更大（更小）的安全风险。

⑥对系统进行安全评估，找出系统中的薄弱环节，并妥善处理这些薄弱环节。

⑦保证后勤和维护支持系统中与安全有关的组成单元的需求，而不引起安全风险的增加。

生命期支持的安全方面包括，可控制的（或可信的）分配和“隐蔽采购”技术。其主要意图是避免在系统整个生命期期间非授权地了解或访问系统，并重视保证硬件、软件和数据（包括密码、密钥材料）的持续完整性。

在开发过程早期，就要开始计划并随着系统的开发变得更详细。最初的方案在ASR之前的先期概念和概念阶段就要作准备，这样，它就可以作为用于确定在系统开发中所使用的可选择系统概念信息的一部分。这种方案在系统设计阶段完成并且在SFR结束。也可要求在整个初始和详细设计以及后续阶段中追加更新的和/或附加的信息。这种信息将被放置在合适的系统文档中，通常是支持文件或系统理论原理文档。在系统开发期间，通过信息安全工程小组的支持来确定解决途径。

生命期对安全支持的主要目的，是确保系统的保护手段在运行和支持阶段依然适合其安全目标。任何引起不可接受安全风险的已知缺陷必须被明确提出来，并采取或大或小的修改措施弥补这些不足或缺陷。除了经常性地反复进行安全风险评估外，如果存在安全违规，或者安全检查或审计中揭示出安全缺陷，或现行的授权到期，都可以引发修改措施。

在对某些系统、中间环境或者更广泛的环境改变中，可能影响系统安全状态和安全解决方案实用性的，包括：

①由于业务驱动或保护政策驱动改变信息的安全临界值和/或敏感性，这种改变会引起安全需求或要求的对抗措施的改变。

②威胁的改变（即威胁动机的改变，或潜在的攻击者新的威胁能力的改变），可使系统的安全风险增加或减少。

③业务应用上的改变。这种改变要求不同的安全运行模式。

④发现新的安全攻击手段。

⑤安全缺陷、系统的完整性缺陷或异常事件或突发事件。

⑥安全审计、检查和外部评审的结果。

⑦系统、子系统或组件配置的改变或更新（例如，使用新的操作系统版本、数据管理应用程序的修改、安装新的商用软件包、硬件的升级或拔除、新的安全产品、对可能违反其安全假设的“可信”组件的接口特性的改变）。

⑧对CI的删除或降级。

⑨对系统过程对抗性措施（即人类接口需求或整个安全解决方案的其他原理/程序组件）的删除或降级。

⑩与任何新的外部接口的连接。

运行环境的改变（例如：重新部署其他设备，改变提供保护的基础设施和环境，改变外部操作程序）。

能改善安全态势或降低运行费用的新对抗技术的可用性。

系统安全可信期满。