Hackers are growing smarter and more sophisticated in their attempts to avoid detection. With IT security and visibility efforts still largely focused higher in the stack at the application layer, bad actors are seeking to breach systems further down the stack at the firmware level.
Once inside the firmware, hackers can disable remote firmware updates, making it impossible to fix remotely and thus requiring the service of a technician with physical access to the hardware/firmware, often requiring a complete shutdown and an on-site visit that can be quite costly for large-scale deployments. This process means fixing zero-day hacks in firmware or hardware can be incredibly time-consuming, leaving the system in question vulnerable for longer than a software breach would. These factors have contributed to a rise in firmware attack frequency both from state-sponsored actors and from smaller and less well-resourced but still dangerous private groups.
The National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) shows that attacks on firmware have risen by 500% since 2018, and survey data from a new Microsoft report show 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. This is unsustainable: a report from Gartner predicted that “by 2022, 70% of organizations that do not have a firmware upgrade plan in place will be breached due to a firmware vulnerability.”
To secure firmware against ever more ambitious and creative attackers, a Root of Trust (RoT) is necessary as an entity against which to check every layer of the stack from hardware boot to firmware load, OS runtime, up until the running applications. 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 solution as an option. A hardware solution is therefore necessary, often involving storing crypto keys that tie directly to the device owner who provisioned the keys in the silicon of a machine rather than in its software in an isolated implementation.
Novel solutions take things a step further by offloading the RoT to a separate security processing unit (SPU) chip entirely to enable remote attestation for all motherboard components but also any peripheral device connected to the system.
The Open Compute Project advocates for the hardware RoT in the open standard version 1.0 of their RoT specification. This formal specification is important because in addition to protecting against firmware persistency attacks, it also helps firmware developers understand how to develop more secure firmware with fewer vulnerabilities (though these learnings can be difficult to implement). Standardization helps vendors create interoperable solutions as well.
The issue with establishing a RoT on a system’s hardware or on an isolated security processor is that, by design, they are very difficult to access or affect. This makes them more secure against bad actors but leaves them less flexible when new vulnerabilities are found, or new functions are required.
This is where field-programmable gate arrays (FPGAs) can enter the picture. An FPGA is a semiconductor device separate from the processor that is configurable after manufacturing, which allows programmers to adjust how components of their larger system are structured without sizable financial or temporal burdens that would otherwise be necessary.
All told, what CIOs, CISOs, and IT decision-makers need to realize is that their systems are very much vulnerable – especially at the firmware level. What is needed is a hardware root of trust that can be used to authenticate and authorize any alteration of any stack level, while remaining flexible enough to adapt to new vulnerabilities and enable security applications. Firmware attacks will only increase as hackers grow more ambitious – it’s long past time we all did something about it.