3 Steps to a Security Plan

Assessing the security of a hardware design sometimes seems like a combination of the guy looking under a streetlight for his car keys, because that’s where the light is (We have this tool, let’s see what problems it can find) and a whack-a-mole response to the latest publicized vulnerabilities (Cache timing side channels? What do we have to mitigate that?). Well-intentioned, but at the end of it all, you’re left feeling that while you know what attacks you have defended against, you have no idea whether that represents the majority of likely attacks on your design, or the most important attacks, or just a small sampling of what could be possible.

The problem with most approaches to security analysis is that they’re bottom-up; you start with a list of possible attacks. But when you start with the details of an attack, you lose sight of the coverage that a comprehensive security plan should be giving you. You also lose sight of the relative importance and risks associated with an attack and the balance of investment you want to put into defenses. You want a basis to assess security overall and be able to tradeoff staff, investment, schedule and risk, to find the best tradeoffs you can.

The recent Mitre Common Weakness Enumeration should help, but that’s a list of weaknesses, not a methodology to identify the threats most relevant and mitigations most applicable to your specific design. A better starting point is to take inspiration from the Secure Development Lifecycle (SDL) approach developed by Microsoft, initially in 2004, to build security into applications and services from the ground up. Originally targeting the software development lifecycle, Tortuga Logic and other chip vendors have adapted this approach for hardware. I talked to Nicole Fern (a Senior Hardware Security Engineer at Tortuga Logic) to understand the approach and the unique aspects of hardware which must be considered. This covers 3 top-down considerations: an asset inventory, threat modeling and lifecycle analysis.

1.  Asset Inventory

At the root of any SDL is the concept of what assets might be attacked. What should you should consider? You might assume just an encryption key or two, maybe a subscriber ID, that should be about it, right? Wrong. The keys are important certainly, but hardware attacks are getting more sophisticated; internal state is also important. In cryptography, random numbers and state in crypto algorithms are potential assets. Configuration and control register states are assets, for example memory protection region registers, watchdog timers, even program counters. Weights for machine learning, access control settings for the bus fabric and bitstream for FPGA programming are all assets. Software for trusted execution, device drivers and first stage boot loader – all assets. And of course, user data can be an important asset.

The key is that this process starts through the lens of the assets specific to your design and end target use case.  Assets are information in the design that you must protect.

2. Threat modeling

Threat modeling is a top-down approach to how those assets might be attacked. This is a process of identifying what you must protect, what threats might be possible, what the consequences of a successful attack would be and what resources the attacker might have.  Threats cover what is ironically known as the CIA triad – confidentiality (the information should not be leaked), integrity (the information should not be modified) and availability (the system remains responsive even when under attack). Consequences depend ultimately on the application but here can be bounded to disclosure of sensitive data, privilege escalation, data tampering, spoofing and so on. Attacker capabilities you may consider are remote attacks or physical access to the device. Finally, you will want some assessment of the likelihood and cost of a successful attack, against which you will be able to weigh the cost of protecting that asset.

3. Lifecycle Analysis

Why is this a lifecycle analysis? Because where and how assets are created, and therefore also where and how they can be attacked, is a lifecycle question. Is it hardwired into the chip logic, or generated by software and if so at runtime, or is it baked into the firmware? Or is it coded into the device by the maker during provisioning, perhaps over-the-air?

Can the asset be changed? Is it stored in volatile or non-volatile memory? Is the value transferred during execution? When should it be zeroized or destroyed? Should it persist across reset cycles or across context switches to different privilege levels? Is it externally accessible, even through highly privileged paths, after manufacturing?

Implementing the Plan

Answering these questions in a comprehensive analysis will help you build a systematic SDL for hardware. Think of it like a top-level functional coverage plan. Based on the security requirements produced from threat modeling you can then start to build tests to check your actual coverage, and mitigation techniques per that plan.  Security is a game of risk v. spend.  A systematic security plan of course requires resources to implement but in the end is more efficient and effective at mitigating risk than ad-hoc approaches.  Of course, it would be nice if you could code your plan into executable threat models, from which you can then accumulate threat model coverage assessment during the course of your normal functional testing. For that you should talk to Tortuga Logic.