Back to Blog
A Q&A on Lessons Learned from SolarWinds

swqa blog

SolarWinds first made headlines in December 2020, but nearly six months later, more information about the attack continues to come to light. From the execution method to the implications for securing the software supply chain—we’ve learned many lessons already and we will continue to do so as we gather more data about the attack. 

As we know, it was a software supply chain attack that infiltrated SolarWinds’ Orion, IT management software. Like many other large software suppliers, SolarWinds pushes out regular updates of their software over the network. By using compromised Microsoft 365 accounts, the attackers were able to corrupt the build and release process. They inserted the malware known as SUNSPOT into the Orion software which created a backdoor in the subsequently signed and deployed update. 

The corrupted update was subsequently installed by nearly 18,000 of SolarWinds’ customers. From there, the malware performed reconnaissance, received commands, and offloaded information to attacker-controlled servers. In its aftermath, it has become abundantly clear that the true target of the attack was the U.S. government, compromising all five branches of the US military, the Departments of State, Treasury, and Homeland Security, as well as major businesses like Microsoft, Cisco, Intel, and NVIDIA.

In a recent webinar entitled “Lessons Learned from SolarWinds”, Dover Microsystems’ Founder and CEO, Jothy Rosenberg, and Cadence Design Systems’ Senior Group Director of Solutions Marketing, Frank Schirrmeister, highlighted how to limit the scope and damage of future software supply chain attacks by securing downstream endpoints. They were joined by a cybersecurity expert, Michael, with over 15 years experience in the Defense, Intel, and Law Enforcement Communities, as well as over 35 years supporting the National Security Community. The expert provided specific detail on how the SolarWinds attack was executed, why it happened, and the scope of its impact.

The webinar concluded with a Q&A session, where the presenters fielded questions from those attending the session live. Leslie Barthel, Dover’s Director of Marketing, moderated the Q&A portion, as follows:

 

Leslie Barthel: Mike, could you speculate on the types of endpoints that might have been, or potentially still are, compromised as a result of this attack?

Michael: The most obvious things are the endpoints from the government’s unclassified networks that have been moved outside of government facilities and into people’s homes—everything from cell phones and laptops to printers and routers. I would not be surprised if in the very near future you start seeing articles about how certain WiFi routers were connecting and attempting to manipulate data inside government networks. In addition, the sites where this malware ended up, have countless embedded systems, including those that control the electric grid or operate nuclear power plants. I shudder to think what they could do with access to these systems.

 

LB: Are there any counter-measures that could have stopped the initiation of the SolarWinds attack?

Jothy Rosenberg: Stopping an attacker’s ability to initiate this type of attack includes doing everything from social engineering to practicing state-of-the-art security hygiene. During the webinar, we touched on the fact that SolarWinds, the company, was sorely lacking in the latter due to its focus on cost cutting instead of security.

 

LB: You mentioned that you could not have prevented the attack, but could have mitigated it. Could you expand on that?

JR: We’re focused on embedded devices and not servers, which is what was attacked at SolarWinds—we would not have had a role there. But, in the “fullness of time” we will expand our footprint to include servers. Until we reach that point, CoreGuard and Cadence would play a role in mitigating the impact of attacks like SolarWinds, because we are able to secure the downstream endpoints that contribute to the spread of the malware.

 

LB: More specifically, how can you limit the scope and damage of future software supply attacks?

JR: We say this all the time, but when it comes to security you need a defense-in-depth approach. Cybersecurity technology like a CoreGuard-protected Tensilica processor running on  would stop an embedded system from doing anything it isn’t supposed to do, like sending private data out of the network unencrypted. In order to limit the scope and damage of future attacks, we need to secure the downstream endpoints that use third-party software. This prevents these systems from becoming the second or third-level targets of attacks like SolarWinds.

 

LB: In the hack, would the code that was injected by the bad guys be compiled into CoreGuard and hence be considered ‘good’?

JR: No, CoreGuard protects the embedded devices or endpoints connected to the network. The malware embedded in SolarWinds’ Orion software update ended up on the victims’ networks, but once there it retrieved new malware and started probing the network for embedded devices. If those devices were protected by CoreGuard and the malware tried to do a buffer overflow, for example, CoreGuard would have stopped it.

 

LB: Is Dover’s CoreGuard solution in the same family as Arm’s Trustzone?

JR: Arm’s TrustZone is a compartmentalization solution which prevents applications in one compartment from interacting with or compromising applications in a separate compartment. However, it doesn’t actually make these applications any less vulnerable to attack. All software has bugs which means even applications in the “trusted” compartments can be compromised and TrustZone can only limit the scope of damage to the compartment in which the attack originates.

CoreGuard is specifically designed to prevent the exploitation of software vulnerabilities and stop entire classes of network-based attacks. CoreGuard can integrate with systems using TrustZone to protect each zone against the exploitation of software vulnerabilities. Alternatively, CoreGuard can independently provide compartmentalization with an unlimited number of compartments and fine-grained access control—unlike the only two or four compartments provided by Arm. 

 

LB: Do the applications need to be re-architected/re-factored to take advantage of CoreGuard?

JR: No, the base set of micropolicies work out of the box with no application changes. Other security, safety, and privacy micropolicies can be layered on top of the base set and use configuration files to tell CoreGuard the additional information it needs about the application.

 

LB: Are there compilers or other tools that help developers?

JR: Standard compilers (GCC & LLVM) provide all the information CoreGuard needs about the application. There is also no need for special tools or modifications to compilers.

 

LB: What is the response time of CoreGuard? Does CoreGuard react after or before the damage is done?

JR: CoreGuard examines each instruction as it is being executed by the host processor. Before the host completes that execution, CoreGuard determines if the instruction should be allowed, or if it’s malicious and thus should be stopped. If it’s allowed, the instruction proceeds as normal. But, if it’s malicious, CoreGuard issues a violation to the host and the instruction does not complete, thus stopping it before any damage is done.

 

LB: Regarding buffer security, why do you need to check the application at compile time? Is it a matter of compromised hardware? And if that’s the case, aren’t the traces compromised as well? Is the metadata there to check the traces?

JR: It's not a matter of compromised hardware. The way CoreGuard ensures memory safety, there is no static metadata gathered. Metadata is generated dynamically, because we need to slightly modify the buffer creation routine called malloc(). But for virtually every other micropolicy, CoreGuard needs static metadata that is generated by analyzing the application binary. Typically, we use the term “trace” to describe the information about the instruction being executed by the host. 

Frank Schirrmeister: Adding to that, this question may have been triggered by the pre-silicon analysis I discussed during the webinar. Since the question is also about compromised traces, we want to address things like CWEs. You need to have the tests with which you model different attack scenarios, and you try to have those done as early as possible, pre-silicon. You have to make sure you have the right traces there by ensuring those tests and scenarios are not tampered with and work pre-silicon but expose you to a vulnerability later.  

 

LB: Do the micropolicies also get put onto the ASIC or is it stored in non-volatile memory?

JR: CoreGuard is allocated a portion of memory of the same type and location on the SoC that the host uses. This is most likely DRAM. CoreGuard needs about 25% additional memory on top of what the host needs.

 

Limiting the damage of software supply chain attacks by securing endpoints

The reality is that software supply chain attacks will be a preferred method of cyberattack by state-backed organizations and private criminal groups alike. The nature of the software supply chain makes it an attractive target, and one that has the potential to wreak havoc on embedded systems and their end users.

In order to limit the scope and impact of these attacks, we need to secure the downstream embedded systems that will be using the potentially-compromised software. To learn more about how CoreGuard can provide this security, contact us today. 

Share This Post

More from Dover

PublishedJuly 21, 2021

In order to understand the many potential cyberattacks that threaten you and your organization, we turn to MITRE’s Common Weakness Enumeration (CWE) database as a key first step.

Security Safety Privacy Defense-in-Depth