在抽象和可验证性之间取得适当的平衡。
开发有效的硬件安全需求是构建值得信赖的电子产品最棘手的方面之一。即使是技术娴熟、经验丰富的团队也并不总是正确的。
为什么?
首先，预测每一种安全风险是非常困难的——更不用说涵盖每一种具有特定安全需求的可能场景了。相反，硬件安全需求往往不成比例地集中在已知风险上。虽然理解和避免已知风险很重要，但在设计和开发过程的后期，或者更糟的是，在产品发布之后，半导体制造商及其供应链合作伙伴往往会遇到意想不到的风险。
使安全需求具有挑战性的另一个因素是安全团队经常试图保护一个移动的目标。当今复杂的片上系统(SoC)架构和复杂的电子产品集成了许多不同类型的硬件和软件知识产权，用于专门用途——通常在供应链的不同级别。因此，除了确保需求覆盖足够广泛之外，您还需要确保在产品成型时具有可验证的安全需求。
您如何有效地克服上述挑战可能取决于您开发的安全需求是否在抽象和可验证性之间取得了正确的平衡。许多安全团队通过基于可应用的威胁模型为产品创建体系结构安全需求来开始他们的需求定义过程。这些需求包含了整个产品，可能无法区分硬件和软件。一组高级需求扮演着一个有价值的角色，因为它可以包含像常见弱点列举同时还围绕安全需求的工作范围提供了一些边界。
问题在于，您的体系结构安全需求越抽象，它们就越不可能涵盖您的设计和实现的独特方面——系统地验证它们就越不实际。
也就是说，您可以使用这些顶级需求作为起点，并派生出关注产品设计和安全目标更具体方面的额外需求。通常，从这些“子”需求的抽象格式开始也是有意义的，避免了在定义和交流需求时设计源代码的复杂性。这在安全团队与设计和验证团队之间提供了更清晰的共享理解和传递。
在创建扩展产品设计的抽象需求时，您应该从以下要素开始:
使用这些元素，您可以创建满足产品特定安全目标(例如，机密性或完整性)的需求。
这里有一个简单的例子:
在非特权模式下，系统总线不能读取解密密钥
这个要求很容易理解，并且在验证过程中可以为它分配一个明确的及格或不及格分数。
现在，让我们以这个示例需求为例，将其转换为人类仍然可以理解的规则，而且对您的设计或验证团队来说更具有可操作性。为了方便我们的用户基数技术，我们为不同类型的安全目标创建了规则模板。既然目标是"一定不能读进去吗属于保密性的一般类别，我们可以将上面示例需求中的其他三个变量放入我们的保密规则模板中，以创建如下内容:
这仍然是一个人类可读的规则，但是这个规则和其他类似的规则扩展了威胁模型，以涵盖在特定产品设计或实现中可能发生的意外行为。注意，上面的规则非常广泛。它的目的不是准确预测将会发生什么。相反，它的重点是捕捉这个规定的需求之外的任何行为或信息流。
上面的规则格式提供了一个很好的框架来定义安全需求，并将它们与利益相关者联系起来，我们的Radix产品的用户也可以很容易地为您的产品实例化这些类型的需求，使用真实寄存器传输级别(RTL)设计信号。这使得在设计和开发的所有阶段系统地验证安全需求成为可能。我们将在以后的文章中更详细地介绍这个过程。
但是希望你能看到如何使用这个框架来创建一个硬件安全需求的集合:
|
|
|
|
|
|
|
|
留下回复