在可信计算架构中分解系统安全性以防止网络攻击

可信计算系统中的高级安全需求可从多个来源向下传播到系统，如提案请求(RFP)或提供系统设计指导的参考文档。处理安全需求的最佳方法是遵循一种框架，根据必要安全级别来确定设计过程。

该框架不仅将具体说明如何实现必要的安全性，还将引导设计者完成整个思维过程。例如，位于马里兰州米德堡的国家安全系统委员会(CNSS)就设计者应考虑的系统保密性、完整性和可用性控制提供了指导。

类似地，CNSS提供了一种将授权功能或消息完整性设计为系统安全性的途径。尽管美国军事系统的一些安全指导文件是保密的，但也有类似文件告诉系统安全设计者在完成架构和设计过程时需要考虑什么。

在建立高级需求框架后，客户和集成商必须就如何最好地满足这些需求达成一致。这就要考虑系统背景及其运行用例，以及查看系统运行位置与方式的“风险分析”。

例如，武装警卫是否一直会在场，或者系统能否在无人看管的情况下运行数周或数年？风险分析将评估这些不同用例如何处理不同类型的网络攻击带来的风险。

风险分析的第一步是创建一个高级逻辑系统描述来进行对数据和流进行建模；当系统架构仍定义为在安全需求和实现之间进行最佳的模式化权衡时，就应该这样做。

尽早让系统安全工程师积极参与以优化设计权衡，这很重要。一旦设置了物理实现，缓解安全漏洞的机会就会减少，这使得任何所需的修改都更加困难和昂贵。更糟糕的是，如果系统设计人员不及早处理安全问题，他们可能要被迫接受系统中的一些漏洞。

接下来，系统安全架构师必须确定系统安全的两个关键方面：确定要保护的内容，以及必须防范的威胁。这些内容可能涉及特定算法、数据、接口和功能。与此同时，预期的威胁可能涉及防止潜在攻击者查看或修改某些算法——尤其在系统或软件开发人员需要共享这些算法的情况下。

一些系统要求保护实际数据——特别是在无人机通信情报或侦察图像等实现中，以防止远程黑客攻击。安全团队还必须留意与其系统通信的其他应用程序及其分类级别。

系统设计人员还必须在识别潜在威胁时考虑计划的系统可用性。缓解可能导致系统崩溃的DOS攻击非常重要。

接着，设计人员应该确定预期的系统攻击类型，如远程攻击、本地攻击或内部威胁。潜在攻击者是典型的黑客、资源丰富的有组织犯罪分子还是民族国家？

为了防止内部威胁，确保系统软件中没有开发后门路由非常重要。同样，系统设计人员必须保护硬件免受恶意组件的侵害，如果有人发送关键字段，这些组件可能会出现故障。此外，必须对整个硬件供应链进行测试和验证。

远程攻击可包括尝试访问无人机视频源。攻击者可能会访问系统数据以修改其操作或拒绝可用性，尤其是连接到互联网的情况下。本地攻击可以像恶意行为者插入USB密钥来捕获数据一样，简单而危险。

系统安全工程师可将名义物理系统架构映射到逻辑系统架构，以识别潜在的物理攻击途径。系统逻辑图定义了系统的用途及其需要执行的功能。

下一步是将该信息分解为实际的物理架构，以识别这些功能所在的电路板，知道这些电路板是如何相互通信的。设计人员需要定义背板、网络接口以及数据如何在整个系统中流动。这使得系统安全工程师能够将系统操作映射到潜在的攻击向量，并为每个预期的攻击向量提出补救措施。

当系统设计者完成所有这些工作后，他们就可以开始与客户合作，对系统的物理架构进行更改。他们可能必须删除单板计算机上的某些连接，将加密器添加到数据路径以增强安全性，或添加加密硬盘驱动器来存储数据。（因此）设计人员可能希望应用其他逻辑约束来提供补救。通过这种方式，他们可以改变系统运行方式的安全性方面，而不用改变物理架构。（即）执行软件来验证系统当前的功能。

设计人员应该权衡每种预期攻击类型的修复成本，因为要确定采用哪种技术。然而，查明补救措施是否造成了新的系统漏洞也很重要——有没有新的补救措施需要应用？

设计者必须权衡不同攻击向量的风险与修复成本；这将对补救过程的最佳性产生影响。一种经济有效的补救措施可以防止多种攻击，但很难证明使用非常昂贵的补救措施来抵御一个攻击向量是合理的。

风险分析可能揭示一种可能性不大的潜在攻击类型，或者几乎没有系统访问机会的潜在攻击。在这种情况下，系统安全工程师可能决定不防范这种攻击，或者用一种低成本、低效率的方法来缓解这种攻击。低风险潜在攻击向量是可以接受的。设计人员可能会将额外补救措施应用至流程和过程，例如在部署后定期检查系统，确保其仍处于良好状态。

在理想的世界中，参与开发系统的所有团体都在一起工作；可惜，这并不总是可行的。不同的组可以在不同时间使用；合同可以开始和终止；在定义物理架构之前，工程师可能无法解决安全问题，迫使他们在现有架构的基础上对安全性进行分层。

政府客户可能要求系统设计者接受所有已识别的风险。网络安全、防篡改和系统认证的要求之间可能会有冲突。出于这些原因，在最终确定架构之前，让系统安全工程师尽早参与进来是至关重要的。就像早些时候，安全团队应该让供应商参与进来，这样其成员就可了解可用的解决方案，以及他们可以采取哪些步骤来实现其安全和性能目标。