Dover and Cadence: Lessons Learned from SolarWinds

I recently attended a webinar with presenters from Dover, Cadence, and a mystery guest who was just a silhouette with the name Michael. The title was Lessons Learned from SolarWinds: How to Limit the Scope and Damage of Software Supply Chain Attacks. I'm going to assume you already know at least something about the SolarWinds attack. If not, read my post The Biggest Security Breach Ever. Let me start by pointing out that the title of the webinar is a bit of a bait and switch. The lesson is that breaches like SolarWinds will occur, and will result in software on your network that has been compromised, and you need to defend yourself against this. And when I say "will occur", I actually mean has already occurred at other companies than SolarWinds, it just hasn't come to light yet.

SolarWinds

The single paragraph description of SolarWinds, who is an IT software provider, is that the company's build process got compromised and so malicious code ("sunspot") was built into their product and installed at about 18,000 of its 30,000 customers. That included a good proportion of US government organizations (which seem to have been the primary target) along with lots of big Fortune 500 companies. How bad is it? As security expert Bruce Schneier put it:

Recovering from this attack isn’t easy...the only way to ensure that your network isn’t compromised is to burn it to the ground and rebuild it.

The webinar was presented by Jothy Rosenberg, the founder and CEO of Dover, Frank Shirrmeister from Cadence, and mystery guest "Michael" with no last name or face, but with over 35 years in the national security community.

The webinar started with Jothy introducing Dover and Frank introducing Cadence. Dover is the first "oversight system company". As Jothy put it, "our software acts as a bodyguard". The company got started as a crash response to Stuxnet. Although the US government is presumed to have been involved in the creation of Stuxnet (to disable Iran's centrifuges for uranium purification), "the though of this being turned against them was terrifying". The software was incubated at Draper Laboratory and prepared for commercialization. Dover was spun out in 2017. Exactly what an "oversight system" is will become clearer during this post. I'm assuming you already know who Cadence is!

"Michael"

Michael gave a color commentary on how SolarWinds happened. The company hired a new CEO to raise its value. He did a great job (just look at its 10-Ks) but the cost associated with this was that anything that was not directly concerned with increasing revenue was cut back or eliminated...such as security. As Michael put it, "this occurs in government also". The exploit was designed to be undetectable. Michael said there were two big gifts to the attackers. First, Covid meant that everyone went to work from home and suddenly everyone had to diversify how they did their IT security—perimeter security was impossible since now it included every employee's house, their Wi-Fi routers, and their smart lightbulbs. The second was all the activity associated with the 2020 election.

Future threats come in three flavors. Front door (normal network access, defended at the perimeter with firewalls), back door (network access that shouldn't exist but might), and side door (where a third-party partner of software that you don't independently verify has access).

Not only will there be future SolarWinds-type attacks and they will leverage side doors. Physical connections to external networks to the good guys and software (SaaS) to lower cost. Nobody pays for a security problem immediately.

In the future, every device needs to be treated as if it is a potential point of entry. Including lights turned on and off by some sort of RF device. If that seems far-fetched, see my post What Keeps MGM's Head of Security Up at Night? Lightbulbs! In fact, it wasn't lightbulbs, it was aquaria. See A smart fish tank left a casino vulnerable to hackers.

Dover's CoreGuard

Dover operates alongside embedded processors, which is actually 98% of the world's processors. So its technology would not have prevented the SolarWinds breach (since its build process runs on regular x86 servers). But where Dover comes in is to stop a breach like SolarWinds getting into embedded devices. A pilot project has integrated Cadence's Tensilica Xtensa LX7 DSP with Dover's CoreGuard.

So how does CoreGuard work? It is a processor that runs alongside the "main" processor (the Tensilica processor in the demonstration). It is silicon IP, which makes it unassailable by network-based attacks since you can't just rewire the hardware. It runs at hardware speed, too.  CoreGuard has various micro-policies that it watches and enforces. The three that work out-of-the-box are buffer overflow, stack smashing, and code injection.

When the Tensilica processor runs, it reads the next instruction to be executed along with its data. This is sent over to CoreGuard that applies the micropolicies. If there is no violation, the instruction executes normally without any slowdown. If a violation is detected, it stops the execution before it can do any damage (such as writing to the outside world). CoreGuard responds so fast that if it detects an instruction is malicious, that instruction gets stopped before it executes. CoreGuard does not detect problems after they happen, but before.

Here's a little more detail. Part of the software environment is a function called malloc ("memory allocation") that the program calls to get an area on the heap for something (or an equivalent function). CoreGuard intercepts this and so knows when malloc has been called to create a new buffer. Unlike the main processor, CoreGuard keeps track of which memory locations are associated with the buffer, and also keeps track of the pointers to the buffer. Jothy talked of them being colored. If the color of the pointer is identical to that of the buffer, then the instruction is allowed. If not, then it is an attempt to write outside of the buffer and may be an attacker trying a buffer overflow exploit (writing off the end of the buffer...typically way off the end of the buffer so that it overwrites code and can take control).

Another example: Data is labeled as private (social security numbers, for example) or public. One micropolicy is that "private data may not leave the system unless it is encrypted". Another micropolicy is that data marked as private may not be written to areas marked as public. There is only one way to remove the private tag and that is encryption.

Hardware Demonstrator

The demonstrator integrated a Tensilica LX7 DSP with a CoreGuard processor. The Tensilica team made the signals that CoreGuard required available and so created the hardware platform on which they can run the demonstration. There is an FPGA evaluation board available to see the technology running. And, of course, you can run the whole design in the verification suite: Xcelium simulation, JasperGold formal, Palladium emulation, and Protium prototyping.

One question in the Q&A was whether the software needed to be re-architected and the answer was:

No, it runs unchanged. There is no need for special compilers. Things like confidentiality are handled by a configuration file. It is an easy lift to start using CoreGuard.

Another question was where these micropolicies were stored.

They are stored in DRAM in the same memory that the host is using. It cordons off a little for itself and controls access so that only CoreGuard can see that memory, it can't be seen by the host or the network.

Summary

• CoreGuard defends Tensilica DSPs (or any embedded processor) against common types of software vulnerabilities
• CoreGuard prevents exfiltration of confidential data or unauthorized modification
• CoreGuard provides unlimited compartmentalization and access control
• CoreGuard immunizes Tensilica DSPs against network-based cyberattacks (including zero days)
• Cadence/CoreGuard allows pre-silicon simulation of attacks, allowing a "shift left' methodology of verifying security early in the design cycle
• Cadence/CoreGuard enables negative testing to model unexpected scenarios

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.