Hackers are growing smarter and more sophisticated in their choice of target and attack strategy.

As typical targets can simply backup their data to cut off potential ransomware leverage, some hackers have shifted focus to entities who store sensitive client data, which hackers can then threaten to leak. In an example from the spring of 2021, cloud service provider Swiss Cloud was hit by a ransomware attack that disrupted service for more than 6,500 customers.

These sorts of attacks aren’t remarkably common, but they do have the potential for exceedingly high ransoms, as CSPs and other web hosting providers feel immense pressure from clients when their services or stored data are unavailable. As a result, many victims simply end up paying the ransoms in order to get operations back up more swiftly, though of course this only adds evidence to hackers’ beliefs that these providers make for easy and effective targets.

In response, most CSPs deploy a bevy of security software to prevent and detect threats, though these are mainly operating on the application level at the top of the stack. These efforts are insufficient, as the recent Huawei Cloud attack illustrates. This CSP was hit with malware that used a software script to simply disable the security agent in charge of scans and reset user credentials. The attack was also spreading “Abcbot,” a new botnet with “worm-like propagation features,” according to Qihoo 360’s Netlab team.

Other hackers have realised another way to dodge detection from software and OS security is to enter the system beneath the application layer at the firmware level. As a result, firmware hacks have spiked: The National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) shows that attacks on firmware have risen by 500% since 2018. Once inside, they can then seize data or infect other devices operating on the same network.

This is the path many ransomware attacks follow, but they can only do so if the system’s Root of Trust (RoT) is stored somewhere they can find, i.e. in the firmware or software, under the same OS restrictions they already compromised.

The RoT is necessary as an entity against which to check every layer of the system from hardware boot to firmware load. Such RoT entity is a fundamental element to ensuring a Secure Boot, an umbrella term for a complete set of features that are responsible to securing and attesting a modern OS boot process from power-on to actual user login.

This chain of trust requires the absolute integrity of the RoT but the only way for a computing component to be trustworthy in this way is for it to be immutable, a condition that eliminates any sort of software or firmware solution as an option.

A hardware solution is therefore necessitated, one which features an isolated implementation of a dedicated security processor that creates a trust anchor that cannot be accessed from the CPU. Generating keys and encrypted data in the hardware prevents hackers from accessing them via software, and storing security defences in an isolated processor creates an architectural advantage for security applications that prevents attackers from disabling or evading defences.

Unlike processor-based systems that are susceptible to trial-and-error attacks where hackers try various techniques in order to glean information about a system’s defences, isolated security chips provide very little visibility to would-be intruders.

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

However, TPMs alone are not secure enough and flexible enough to operate as RoT. Novel solutions offload the RoT to a more specialised and more dynamic security processing unit (SPU) chip to enable remote attestation for all motherboard components and any peripheral device connected to the system, both at boot and continuously through runtime.

The Open Compute Project, which hosted its annual summit on November 9-10 in San Jose, CA, advocates for a hardware RoT in the open standard version 1.0 of their RoT specification, something industry movers and shakers believe is pivotal for enterprise data centre security as well as for hyperscalers. Until now, hyperscalers have had to build their own custom solutions for firmware protection but with the standardisation of RoTs, we can now expect this technology to be available for all data centres.

As OCP-compliant RoTs will even prevent attacks involving physical Flash component replacement, they are becoming a necessity for cloud providers wishing to adhere to recent  supply chain regulations (President Biden signed Executive Order 14028, “Improving the Nation’s Cybersecurity”). Eventually It may even become a necessity for consumer PCs and IoT eventually.

All told, what data centres need to realise is that their systems are very much vulnerable – especially at the firmware level. Attacks targeting this level are escalating in severity and sophistication so what is needed is a hardware root of trust which can be used to authenticate and authorise access for any system level, whether hardware, firmware, or software.

This root of trust must also be flexible enough to adapt to new vulnerabilities and enable security applications to do their job. In other words, data centres have to keep their systems safe by offloading security to a separate chip.