Sometimes you just need to stop, stretch, and pick up the can.
Earlier this month we did an analysis of the President’s Executive Order on Improving the Nation’s Cybersecurity (You Can’t Unsee the Rabbit: Perspectives on the 2021 Cybersecuirty Executive Order). In it, we highlighted two key points:
- in the context in which the EO defines “critical software”– along with the need to track, assure, and protect it – nearly all firmware is critical software.
- enterprise firmware security is critical in the creation, execution, and operation of the “Zero Trust architectures” the executive order calls for.
Last week, NIST kicked the firmware can down the road. They released a first attempt at clarifying the executive order through a white paper called Definition of Critical Software Under Executive Order (EO) 14028.
Click below to watch our webinar “The Cybersecurity EO, Firmware, and Kicking the Can”
While the document gets so much right, it gets one important thing horribly wrong. The paper defined EO-critical software as any software that has, or is dependent on, components:
- designed to run with elevated privilege or manage privileges
- with direct or privileged access to networking or computing resources
- designed to control access to data or operational technology
- that perform a function critical to trust, or
- that operate outside of normal trust boundaries with privileged access
Firmware checks all these boxes.
- Running with elevated privilege? Check. Firmware most often runs beyond the scope of user privileges and with root-level access. It is essentially and in most cases “always running privileged”.
- Direct or privileged access to network or compute? Check. Very little beyond firmware has more direct access to compute resources – see our blog post on high speed DMA attacks that enable a potential attacker to read and write memory off a victim system directly, bypassing the main CPU and OS.
- Designed to control operational tech? Check. Firmware is all about controlling operational technology of every kind, from PLCs and SCADA devices to network devices and virtual machines.
- Performing a function critical to trust? Check: it’s hard to see functions more critical to trust than, for instance, bootloaders, BIOS and UEFI instructions.
- Operating outside normal trust boundaries? Check. Guiding the transition between “normal trust boundaries” is often firmware’s job, as it provides hardware with instructions on how to act and who to serve as it comes online.
Nothing in that criteria list does not apply to securing and controlling virtually all firmware.
But NIST kicked the proverbial can when they recommended “that the initial EO implementation phase focus on standalone, on-premises software that has security-critical functions or poses similar significant potential for harm if compromised.” And that “subsequent phases may address other categories of software such as:
- software that controls access to data;
- cloud-based and hybrid software;
- software development tools such as code repository systems, development tools, testing software, integration software, packaging software, and deployment software;
- software components in boot-level firmware; or
- software components in operational technology (OT).” (Emphasis added.)
One form of code–firmware–that‘s essential to how each device in every type of environment operates has been moved to a possible “subsequent phase.”
Boiling the Ocean
We understand exactly why NIST makes this statement about “subsequent phases.Truisms and folk advice abound regarding the success or failure of large projects.We say “Start with the End in mind.” We encourage people to ”Take bite-sized chunks.” And of course we say, “You can’t boil the ocean.”
But what if boiling this particular ocean–the firmware security ocean–is exactly what we need to do?
Atlantic Magazine had a great article a while ago called It’s Time to Retire the Phrase: “Don’t Boil the Ocean”. It showed how every problem falls into two categories:
- Mechanistic (or “complicated”) problems that are 100% solvable by someone with the right expertise or technical skill, or
- Interconnected, dynamically changing, non-deterministic (or “complex”) problems whose solutions can only be guessed at and shown to work in retrospect through trial-and-error.
The argument put forward by authors David Benjamin and David Komlos is that limiting complex, interconnected problems by “not boiling the ocean” will backfire. It’s critical to boil the ocean because on large projects you: A) can’t limit your focus to only a few critical areas; B) can’t make progress on parts in isolation; C) can’t pick a scope in advance and shut down anyone who strays from scope.
Firmware security is a critical part of a massive and interconnected cybersecurity problem. It is dynamically changing and non-deterministic. Aligning this “complex” problem with the three “can’t “ points above we see that boiling the ocean is exactly what we need to do.
Yes, it will be harder that way. Largely because firmware is hard to grasp, hard to establish provenance for, and has vulnerabilities that are hard to mitigate. But it will be far more successful.
Go Where the Fire Is
Half the Eclypsium team is in Oregon, where wildfire season is just beginning. Every spring crews, trucks, helicopters, and tankers come out of storage and begin moving to the mountains and forests where the fires are likely to catch.
One of the places where the cybersecurity fire seems to be flaring up is in firmware.
Two articulate CISA staffers made that point at the RSA Conference this year. Boyden Rohner, the Associate Director Vulnerability Management, and Thomas Ruoff, the Methodology Branch Chief for Vulnerability Management, put on an impressive session on vulnerabilities “below the OS”, in firmware and microcode.
Titled “DHS CISA Strategy to Fix Vulnerabilities Below the OS Among Worst Offenders”, the team made made a strong 3-point case for why agencies needed to focus on firmware now:
- “BAD NEWS: There are no ways to apply Vulnerability Mitigations below the OS.”
- “MORE BAD NEWS: Most criminal and advanced threat actors exploit Vulnerabilities Below the OS that affect UEFI.”
- “EVEN MORE BAD NEWS: In general, existing memory protections (NX) are not enforced due to vendor non-compliance.”
The two CISA professionals encouraged agency CISOs and security chiefs to start adding firmware to their Software Bill of Materials (SBOMs) immediately because “The place we find the majority of exploits (most, not all) are in UEFI code.”
“The place we find the majority of exploits (most, not all) is in UEFI code”
Beyond this on-point RSA session we find other supporting data points in the world at large:
- VPN attacks–largely enabled by firmware compromises–are up nearly 2000% (https://www.helpnetsecurity.com/2021/06/15/vpn-attacks-up/)
- Microsoft Signal, in a narrow survey, reported that 80% of enterprises have experienced at least one firmware exploit in the last two years.
- According to the NVD, there has been significant growth in firmware vulnerabilities in 2016-2019
Apart from any of the arguments above, the NIST white paper on interpreting the Executive Order includes this note in the FAQ section:
- Can embedded software or firmware be EO-critical?
Yes. If embedded software or firmware performs functions that are defined as EO-critical, then it is EO-critical
EO-critical software should include firmware, even if it is complex or hard to do. We need to go where the fire is, and one the places starting to burn is in firmware.
We Can Do This Now
Without dismissing the notion that this is all complex, difficult work, there are tools to help Federal cybersecurity teams and their CISOs:
- IDENTIFY their devices and supporting firmware throughout our far-flung networks, building detailed profiles and establishing dynamic inventories
- VERIFY the state of their firmware to a known-good baseline, using the world’s largest firmware database
- FORTIFY their firmware through updates or configuration changes if needed
Eclypsium is well-suited to help agencies build SBOMs that are inclusive of firmware–today. Call us for a demo of one.
As an industry we need to stop kicking the firmware can down Security Road.