Get Outta Here: Securing Computing Systems by Storing Security Elsewhere

This article is part of the TechXchange: Cybersecurity

What you’ll learn:

• Why hackers historically have had an architectural advantage against software- and firmware-based security defenses.
• How this edge has translated into increased attacks on firmware levels.
• What enterprises and CSPs can do to protect themselves.

Cybersecurity has long been a game of cat and mouse between organizations looking to secure their networks, devices, and data with increasingly more sophisticated security solutions. Meanwhile, hackers look to poke and exploit whatever holes may exist in those defenses. The architecture of this conflict has disproportionately benefited hackers, as through trial and error they have been able to map a target’s defenses until the point where they identify a way in.

The location of where security solutions are stored plays a pivotal role here, as hackers’ perpetual probing only serves its purpose if a target’s defenses are visible, or worse, accessible. Storing unprotected encryption keys, credentials, and sensitive data anywhere reachable is equally unadvisable.

Don’t Store Your Security Solutions in These Spots

Cybersecurity defenses have typically been stored at the software, or application, layer. This exposes defenses to visibility and manipulation by any hacker who gains access to that layer, which is what happened in the recent Huawei Cloud attack. This cloud service provider (CSP) was hit with malware that used a software script to simply disable the security agent in charge of scans and reset user credentials.

Moving security solutions down to the firmware isn’t necessarily much safer, as hackers have shown great resourcefulness and little trouble in breaching this layer, too. The National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) shows that attacks on firmware have risen by 500% since 2018. Furthermore, survey data from a new Microsoft report shows that 83% of enterprise IT decision-makers have had their systems hit with a firmware attack in the last two years, but that only 29% of the average security budget is dedicated to protecting the firmware level.

Intel recently discovered the danger of under-securing this level themselves, as significant vulnerabilities were exposed in the BIOS firmware of various Intel processors. Intel advised that users apply available BIOS updates to patch the holes, but most motherboard vendors don’t release BIOS updates all that frequently, since it’s something of a legacy solution (replaced in many applications by UEFI firmware).

Become Isolated

Corruption of security defenses stored in software or firmware is the path followed by many ransomware attacks, but they can only do so if the system’s security is stored in or checked against somewhere they have already breached. With software and firmware layers subject to increasingly common intrusion, a hardware solution is necessary—one that features an isolated implementation of a dedicated security processor that can’t be accessed from the CPU.

Storing security defenses in an isolated processor creates an architectural advantage for security applications that prevents attackers from disabling or evading defenses. Unlike processor-based systems that are susceptible to trial-and-error attacks, where hackers try various techniques to glean information about a system’s defenses, isolated security chips provide very little visibility to would-be intruders.

Turn to TPMs

Trusted Platform Modules (TPMs) are a good step in this direction. TPMs sit separate from a computing system’s processor. They function as a sort of black box that attackers will struggle to access or even see into, and are assigned to hold valuable assets like keys as well as sensitive data while owning only low-level operations.

However, TPMs alone aren’t secure or flexible enough. Emerging solutions instead offload security, assets, and trust anchors to a more specialized and more dynamic security processing unit (SPU) chip. Under this approach, attackers are unable to access (and thus corrupt) security systems, data, and most importantly, the system’s root of trust (RoT). This means the integrity of its attestations from boot through runtime is preserved.

Isolated SPUs also are more convenient to manage. UEFI firmware authentication introduces logistical issues that can lock a CPU to a particular platform, which limits the ability to upgrade or change a CPU on the motherboard.

All told, what CIOs, CISOs, and IT decision-makers need to realize is that their systems are very much vulnerable, especially at the software and firmware levels. Storing security systems, let alone a RoT, at these levels is folly. Therefore, what’s needed is a hardware solution that can be used to store security beyond the hacker’s reach while also hosting a RoT that can authenticate and authorize any alteration of any stack level. In addition, it must be flexible enough to adapt to new vulnerabilities and enable security applications.

Read more articles in the TechXchange: Cybersecurity