In order to make sense of the many threats plaguing embedded systems today, we turn to MITRE’s Common Weakness Enumeration (CWE) database. This database serves as a tool to help categorize the tens of thousands of common vulnerabilities and exposures (CVEs), which are the individual vulnerabilities that lead to exploits and eventual attacks. 

In a recent webinar, “Securing Embedded Systems: Analyzing CWE Threats & Delivering Hardware-Based Defense-in-Depth,” Dover’s Founder & CEO, Jothy Rosenberg, was joined by Tortuga Logic’s Co-founder & CTO, Jason Oberg, to discuss recent changes to the CWE database, including the addition of hardware CWEs in February 2020.  During this webinar, Jothy also reviewed an analytical framework that can be used to better understand threats most relevant to different embedded systems and to identify the mitigating defense mechanisms available to address.

In addition to analyzing the top software and hardware CWEs, Jothy and Jason answered questions from webinar attendees. Leslie Barthel, Dover’s Director of Marketing, moderated the Q&A portion, as follows:

Leslie Barthel: What were the biggest changes to MITRE’s database over the last year?

Jothy Rosenberg: We’ve identified four major changes to the database since 2020. First, there was significant growth in software CWEs, with over 24,000 new CVEs added across 50 new CWE categories. MITRE also released the ATT&CK framework this past year, which looks at cyber threats from a tactical viewpoint. The biggest change was the addition of hardware CWEs. With prominent hardware-based attacks like Spectre and Meltdown, the addition of hardware vulnerabilities became imperative.

The annual ranking of Top 25 Software CWEs was also just released a few weeks ago, where we saw some big changes like cross-site scripting (CWE-79) getting knocked out of the top spot for CWE-787, or stack-based buffer overflow.

Leslie: How can you use the information from the database to identify the right defense mechanism to address it?

Jothy: That’s where the analytical framework comes in. The framework not only maps out all of the CVEs and their severity across all CWEs, it also identifies the exact type of defense mechanism you need to address those threats. You can use this framework to measure exactly how effective each of those defense mechanisms are at protecting against the relevant vulnerabilities.  

Leslie: What level of protection does CoreGuard offer? What about RADIX?

Jothy: When it comes to software CWEs, CoreGuard protects against 93% of them. 

Jason Oberg: At Tortuga Logic, we focus on preventing the exploitation of hardware CWEs. Right now, we’re looking at 80% protection of hardware CWEs with Tortuga’s RADIX solution.  

Leslie: The trace bus between the Core and CoreGuard is an interesting point of attack. How do you protect that channel? 

Jothy: Because CoreGuard is IP that is installed on the same silicon as the processor it protects, that channel is entirely inside the SoC and not visible or mutable by outside mechanisms,  especially not by network-based attacks. The only potential attack vectors on that bus are physical attacks. As part of your defense-in-depth strategy, you should ensure systems are deployed with existing physical attack prevention strategies such as tamper resistance and shielding to mitigate these attacks.

Leslie: Is anyone working on addressing the deficits of Von Neumann architecture?

Jothy: For those that don’t follow, in 1945 Von Neumann created the architecture that almost all processors use today. This architecture is nice and simple and has just one memory. All instructions and data are in this memory. The processor is given an instruction and it executes. This has been great for Moore’s Law, but it’s been terrible for cybersecurity. With Von Neumann architecture, there is no way for the processor to know if an instruction is legitimate, or a malicious instruction. It’s going to take a while for us to change something as fundamental as the Von Neumann architecture. So, in the meantime, you’re going to need an oversight system, like CoreGuard, to protect the processor and prevent any malicious instructions from executing.

Leslie: TrustHub has been working on making formal property assertions available for common use cases; is Tortuga working on something similar for security properties vs. CWE/CVE?

Jason: The short answer is yes. We have a guide on our website that takes CWEs and provides RADIX rule templates, so that’s definitely something we’re interested in and some of our solutions are on TrustHub, as well as in collaboration with the University of Florida teams that have been pioneering that research. 

Leslie: Since both RADIX and CoreGuard require security rules to function; who writes or creates those rules?

Jason: Security is very much a cross-organizational problem. There are three steps that I see in building any security program, starting with security requirements to security verification to security sign-off. Ultimately, the security requirements are owned by a central security team like product security or security architecture. They won’t have the design knowledge to write a natural language type of security requirements, so they will take those requirements and bring them to the verification and design team to write those RADIX rules. Then the verification teams will execute them. We’re doing a lot of work to build more products with that holistic aggregation of information so the security teams can get that feedback more consistently. 

Jothy: We’ve designed a language to make writing micropolicies as easy as possible. Initially, Dover writes the micropolicies because they apply to a broad set of CWEs, but over time people are going to write micropolicies that are unique to their device or application. Eventually, we’ll  train people how to write their own custom micropolicies. These will be written by people close to the application, like software designers that are either looking at the same specifications or looking at the application source code itself.

Leslie: Are CoreGuard’s micropolicies updatable?

Jothy: Yes, our micropolicies are updatable. Because our micropolicies are designed to protect against entire classes of attacks, you won’t need to update a micropolicy every time a new exploit is discovered. That said, if a micropolicy needs to be updated for any reason, or if you want to add a new micropolicy after CoreGuard is already installed, it’s pushed out in a similar way to any firmware update.

Leslie: When the micropolicy is violated, what happens next? 

Jothy: You can think of CoreGuard as a real-time attack detector. It’s able to detect a cyberattack precisely down to the line in the source code where the bug is being exploited. When an attack is detected, CoreGuard will package up the necessary data about what happened and communicate that to the host through a non-maskable interrupt. The host will then send that data to the application. 

Responses to a cyberattack can vary based on the system CoreGuard is protecting. Options include everything from restarting the application to asking for user input to scrambling memory. In a more sophisticated or potentially dangerous environment what a lot of people choose to do is run an alternate application. This application doesn’t listen to the network and essentially runs in a ‘safe-mode.’ For example, let’s say you have a package delivery drone that is being attacked and the attack is attempting to redirect those packages. When CoreGuard recognizes the drone is being attacked and issues a violation, an alternate application will run and pull out of encrypted store a GPS location of a safe place to fly to. It does all of this without listening to the network so it’s not susceptible to further attacks.

Leslie: In the case of an exception, how does CoreGuard prevent the elevation of privilege during exception handling?

Jothy: In this case, you’re trusting the operating system. Once CoreGuard has detected an attack and notified the host, the OS is now in charge.In this case, we can trust that no other corruption or attack that could result in privilege escalation has occurred, otherwise CoreGuard would have caught it.

Leslie: How do RADIX security rules integrate into simulation and emulation environments?

Jason: We have a methodology for creating RADIX rules that address hardware CWEs, and then loading them into RADIX.  Then we generate what we call a security monitor. This is essentially a Verilog RTL and then that gets included into your existing simulation/emulation environment. You don’t have to modify your design and you don’t have to change your environment. You can take those RADIX rules and execute them in your existing design environment.

Leslie: What is the performance and area impact of CoreGuard? 

Jothy: We’ve worked very hard on our performance and area numbers. If you’re measuring by number of gates, some CoreGuard configurations can be as low as 100K gates. If you’re measuring by the physical area—let’s say a 22nm node—CoreGuard is around one tenth of a square mm. When it comes to performance impact, CoreGuard adds less than a half of a percent of performance degradation and in many cases it’s actually zero.

Leslie: Is CoreGuard an IP intended for ASIC/FPGA? Is it specific to certain processor types?

Jothy: CoreGuard works with both ASIC and FPGAs. As far as specific processor types,  CoreGuard is ISA-agnostic and is compatible with all RISC architectures, including RISC-V, Arm, Tensilica, and others. The CoreGuard technology can also be applied to CISC and DSP processors—it’s really broadly applicable.

Leslie: Can CoreGuard be used to monitor proper operation of non-processor logic, such as FPGA logic?

Jothy: It probably could be, but not straight out of the box. Essentially, the CoreGuard hardware looks at an instruction and has to decode it, at least partially. Whatever the mechanism is, as long as it can be translated into an instruction and CoreGuard is able to look up that instruction against the micropolicies, from then on it’s fairly straightforward.

Leslie: During the presentation you highlighted both hardware and software bugs. How do you ensure that your solutions don’t contain them? 

Jason: We use good code quality, and exercise good engineering practices. We’re not instrumenting anything in the design and we don’t modify the customer’s design. We’re more of an analysis tool in some respects. We’re not inserting something into the design so if there was a bug in our software it wouldn’t impact the shipped product.

Jothy: On our side the hardware portion of CoreGuard is getting instructions sent to it, it’s not actually in connection with any of the host memory. When we talk about metadata in words of memory, we’re talking about ‘shadow memory’ or memory that’s cordoned off from the host and therefore the network and protected by the CoreGuard hardware. The one place where there could be a bug in CoreGuard’s system is a micropolicy. So we’ve made sure that all micropolicies are quite small. We always test things very thoroughly, using formal methods to prove micropolicies are correct. One of the great things about CoreGuard is that even if a micropolicy has a bug, it’s very updatable and easy to fix. We can cosign and encrypt a micropolicy to the site where it’s handled by an administrator and installed to fix any problems that might occur.

Securing Embedded Systems Requires Defense-in-Depth

The unfortunate reality is that cyberattacks are not going away anytime soon. They’re only going to become more dangerous, costly, and pervasive as time goes on. The software-based defense mechanisms we’ve relied on for decades are simply not enough to keep up with the sophisticated cyberattacks we’ve already witnessed and those to come. In order to achieve a truly secure embedded system, an insubvertible, hardware-based defense mechanism is necessary. 

Providing hardware-based defense-in-depth is possible through security solutions like Dover’s CoreGuard oversight system and Tortuga Logic’s RADIX technology. Together, these solutions prevent the exploitation of both hardware and software CWEs, including zero-day threats. To learn more about how you can achieve this level of security in your embedded systems, contact us today.