Developing effective hardware security requirements is one of the trickiest aspects of building trustworthy electronic products. Even highly skilled and experienced teams don’t always get it right.
Why?
First, it’s very difficult to anticipate every security risk – much less cover every possible scenario with a specific security requirement. Instead, hardware security requirements often focus disproportionately on known risks. While understanding and avoiding known risks is important, it’s usually unanticipated risks that blindside semiconductor manufacturers and their supply chain partners late in the design and development process – or worse – after product launch.
Another factor that makes security requirements challenging is the fact that security teams are often trying to secure a moving target. Today’s sophisticated system on chip (SoC) architectures and complex electronic products integrate many different types of hardware and software intellectual property for specialized purposes – often at different levels of the supply chain. So, in addition to ensuring requirements coverage is broad enough, you also need to make sure that you have verifiable security requirements as your product takes shape.
How Abstract Should Security Requirements Be?
How effective you are at overcoming the above challenges will likely come down to whether you develop security requirements that strike the right balance between abstraction and verifiability. Many security teams begin their requirements definition process by creating architectural security requirements for the product based on an applicable threat model. These requirements encompass the entire product and may not be differentiating between hardware and software. A set of high-level requirements plays a valuable role, since it can encompass low-hanging fruit like Common Weakness Enumerations (CWEs) while also providing some boundaries around the scope of security requirements efforts.
The problem is that the more abstract your architectural security requirements are, the less likely they are to cover the unique aspects of your design and implementation – and the less practical it is to verify them systematically.
That said, you can use these top-level requirements as a starting point and derive additional requirements that focus on more specific aspects of your product design and security objectives. Usually, it makes sense to start with an abstract format for these “child” requirements as well, avoiding the complexity of design source code while requirements are being defined and communicated. This provides a much clearer shared understanding – and handoff – between the security team and the design and verification teams.
Hardware Security Requirements: Four Essential Elements
When creating abstract requirements that extend your product design, you should start with the following ingredients:
● The security ASSET
● The SECURITY OBJECTIVE
● The PROTECTION and related BOUNDARY
Using these elements, you can create requirements that address the specific security objectives (e.g., confidentiality or integrity) you have for your product.
Here’s a simple example:
Decryption Key must not be readable in unprivileged mode by the system bus
This requirement is both easily understandable and something that can be assigned a clear pass or fail score during verification.
Turning a Security Requirement Into a Rule
Now let’s take this sample requirement and turn it into a rule that is still understandable by humans but also a bit more actionable by your design or verification team. To make this easier for users of our Radix technology, we’ve created rule templates for different types of security objectives. Since the objective “must not be readable in” falls under the general category of confidentiality, we can place the other three variables from our sample requirement above into our confidentiality rule template to create something like this:
This is still a human-readable rule, but this and other rules like it extend the threat model to cover unexpected behavior that may occur in a specific product design or implementation. Notice that the rule above is very broad. It is not aimed at predicting exactly what will happen. Instead, it is focused on catching any behaviors or information flows outside of this stated requirement.
Verifying Requirements Systematically
While the rule format above provides an excellent framework for defining security requirements and socializing them with stakeholders, users of our Radix product can also very easily instantiate these types of requirements with real register transfer level (RTL) design signals for your product. This makes it possible to verify security requirements systematically at all stages of design and development. We’ll cover this process in more detail in a future post.
But hopefully you can see how this framework can be used to create a collection of hardware security requirements that are:
- Broad enough to uncover unexpected risks early in the product life cycle
- Understandable by the cross-functional teams responsible for building secure products
- Systematically verifiable throughout the design and development processes
Interested in learning more about how you can create more comprehensive and verifiable security requirements? Schedule an introductory call with one of our product experts today.