信息安全工程系统设计支持活动

3.4.2　信息安全工程系统设计支持活动

在开发功能和物理体系结构期间，信息安全工程小组通过提供安全分析和建议来支持客户。这种开发在系统的整个生命期内设计到若干阶段和事件，并且通常是反复进行的过程。信息安全工程要识别“怎样”反映用客户语言表达出的系统需求。在使设计支持项目增值的任何技术阶段或问题领域，信息安全工程小组都应考虑使用仿真、建模或快速原型法迅速开发技术。

对许多设计类型的分析，将系统和CI安全需求看做与各类安全服务相关联是有益的，然后再把这些服务映射为类属的安全机制。这样做，对另外一些项目可能有帮助也可能没有帮助，例如，有些项目要求集中开发新的应用中独有的软件或硬件，而为它们选择的“可重用性”标准的安全协议和机制就很少会用到。当信息安全工程小组期待实现安全服务时，可以考虑将目标安全体系结构（Goal Security Architecture，GSA）的原理作为对系统体系结构的安全解决方案配置的指南。下面是GSA中可用的项目主题：

①GSA安全需求——策略、需求，导出的需求。

②安全角度和概念。

③端系统和中继系统。

④安全管理关系和概念。

⑤传输系统主题。

⑥安全学说——提供安全服务的安全机制学说。

⑦商业现货（COTS）考虑。

信息安全工程小组将根据正在结合使用的解决方案所存在的安全风险，加上以前的经验和教训，对体系结构进行研究。信息安全工程小组活动的重点是识别正在开发的体系结构的脆弱性，并建议对抗措施和可选择方案。系统可用不同的保护措施（即机制的类型和特殊的实现方法，不管是“制造”还是“购买”）来满足安全需求。如果两个或更多个系统需要相互作用，那么必须建立接口协议和规则以允许其相互作用。当个别的系统具有不同的安全策略、安全需求和在本地社区受到运行限制时，或者当新的连接可能引起某些附加安全风险或与现有系统或基础设施有冲突时，特别需要建立接口协议和规则。在那些情况下，需要一些折中分析和协商以支持相互作用。

在系统开发之后再添加没有预先规划的保护措施或对抗措施时，实现起来一般非常昂贵和困难，而且可能并不是最有效的方法。这是因为，这些改变一般不能很理想地结合到系统中（除非通过一个计划中的递增策略）。不过，人们很难超前掌握和预料所有恰当的需求，或者在快速改变的信息系统和信息技术领域很难瞄准恰当的技术。通常，比较适当的方法是建立一个强健的基础体系结构，在此基础上开发已计划的和动态出现的修改需求。早期的原型法或仿真可能就是有用的了。

用文档化形式定义安全设计，是说明其满足需求等合理性的理由，因为这些理由不总是明明白白的，或是理所当然的。

尽管在安全IV&V和风险评估的前前后后，应该进行各自独立的分析，但是对系统设计小组，包括信息安全工程的参与者来说，系统地阐述系统安全状态的合理性是很重要的。这些信息可以伴随着系统设计文档以书面分析的形式出现或出现在适当的设计评审中。

1.关键技术的识别

在任何给定时间点对安全需求的理解中，信息安全工程小组应当考虑是否有必要开发或使用任何新技术以满足那些需求。对于任何关键的和使“最有希望”的系统概念增值的信息系统安全新技术，信息安全工程小组都必须进行调查，以确保能有把握地将它们集成到系统设计中。该活动可包括原型法的应用、测试，以及早期的运行评估，以降低安全风险等级和与使用新出现的信息系统安全技术有关的预期风险。

信息安全工程小组在系统开发周期的早期考虑这些问题时，可能仅仅注意到需要什么技术。但是，事先识别出需要开发的基本关键技术却是十分重要的，以便在系统生命期的设计、实现直到后续的生产和/或P³I/修改阶段需要它们之前，预先将这些技术建立起来。如果满足特殊安全需求所需的技术还没得到，那么就要确认有足够的时间来完成技术研究或其他工作项目，而不与客户要求的进度发生冲突。信息安全工程小组也要保证，由于采用新技术而产生的利益要大于由于依赖它而增加的计划和技术风险。典型情况是，对新技术或未检验的产品的依赖将对整个计划引入额外的技术、费用和进度的风险。进一步说，必须仔细地和经常地监控这些新技术或产品。信息安全工程小组应该确保在将新技术包括在系统计划之前，客户完全了解其带来的所有风险和潜在的利益；信息安全工程还应该事先准备好后备产品或过程解决方案，以处理由于未曾预料的延迟或技术问题而带来的新技术不能使用的偶然事故。

使用新技术需求的一个例子是新的密码算法。算法的研究开发以及在系统内实现之前的安全性评估都需要时间和资金，这就会影响成本和进度。另一个例子是需要满足系统安全需求的一个完整的终端项目，这就会影响成本和与其他子系统的关系。这与密码算法的例子不同，密码算法或许仅仅是一个配置项目（CI）的一部分。

2.设计的约束

信息安全工程小组要明确对影响和限制所需安全服务实现的系统设计的约束。许多因素都可决定对系统如何满足其安全需求进行约束或对系统设计过程进行约束。系统运行的环境，它的运行模式（专用的、系统高层的、系统分级的等），其业务功能的敏感性和临界点，每一个都可能是影响设计决策的约束。接口和互操作性问题也可能产生对设计的约束，例如，为了符合一个特殊的标准轮廓或特殊环境的安全政策，援引一个特殊的个别的标准需求，或排除某些解决方案选项以适应与外国政府或国际机构的互操作（或者已知需求或未来有特殊定义的可能性）的需求。

某些支持性的需求也可能约束系统设计和运行的安全状况。这些需求当然包括但不限于后勤支持需求、可移植性需求、生存性需求；个人和培训的限制，命令、控制、通信和情报接口需求；标准化和互操作需求等。

随着设计活动的开发，信息安全工程小组也要注意因设计的选择引申出来的需求。例如，选择高度机密保护的解决方案可能要求保护数据抗篡改的附加需求。这些需求将被反馈给需求定义函数，并在决策数据库与可追踪性体系中被准确定位。

3.非技术的安全设计措施

正被获取的系统及其设计规划，将在整个系统工程周期内通过运行、支持、培训和其他系统工程功能的并发应用中被开发。信息安全工程小组将为正在进行的活动作出贡献，并从中进行学习，以改善任何系统安全解决方案的适用性和有效性。

信息安全工程小组应该从技术的和非技术两方面满足安全需求。例如，为某一特殊信息提供机密性需求，可用诸如加密技术解决方案来满足，也可使用非技术的（如隐藏或其他的物理手段）的解决方案。其他的非技术解决方案将包括过程控制，如适当的操作程序、人事的和运行的安全控制、隐瞒采购和用户身份，以及可信软件开发方法论（TSDM）的非技术要素等。