Tackling the toughest FISMA requirement: Firmware integrity

Firmware is under attack, yet few organizations have matured beyond a state of foundational security to address more advanced security controls such as firmware integrity. Given the potential impacts of compromised firmware, agency personnel must determine how and when to tackle one of the most difficult security controls, the National Institute of Standards and Technology's SP 800-53 SI-7: Software, Firmware and Information Integrity, referred to as SI-7.

All security controls considered equal?

The Federal Information Security Management Act provides guidance as to which security controls and subcontrols must be addressed for information systems categorized as being of “Low,” “Moderate” or “High” potential impact.  However, within those categorizations, all NIST 800-53 security controls are considered equal, meaning that an agency “Moderate” system must prioritize and comply with all of the indicated subcontrols, from the most basic to more-advanced controls such as SI-7.  That’s not so easy to do, given the varying agency maturity levels across government. After agencies progress beyond implementation of basic foundational controls -- such as log management, configuration management and vulnerability management -- they are then positioned to tackle some of the more advanced controls.

With so many agencies still considered to be at a low-tier maturity level, firmware integrity is not often addressed as a priority. So, does a lack of security maturity justify a lack of firmware priority? Well, no, because it is a FISMA requirement and, perhaps more importantly, because the risks of firmware compromise have gotten much greater since the inclusion of SI-7 in the original release of FISMA.

The evolution of firmware compromise

According to Tripwire’s David Henderson, the term “firmware” has evolved significantly over the years. Once considered the underlying layer of a system architecture that was not easily accessed or altered, firmware is now “accessible by anyone with a device that can communicate on or over a network,” he wrote in his blog.

[Today]…Firmware can be found in many places such as startup and timing devices in home appliances, light bulbs, home thermostats, our automobiles, our computers and embedded or installed components such as storage systems. What about the network routers, switches, firewalls and intrusion detection systems at the office, not to mention the Internet of Things? Yes and yes. Our phones, mp3 players, tablets and a host of other devices also contain firmware.

According to NIST security expert Andrew Regenscheid, firmware protection has become an increasingly important issue over the past 10 years. Regenscheid started leading NIST’s firmware protection guidance efforts in 2010, he and co-authored NIST’s first firmware guidance, NIST SP 800-147: BIOS Protection Guidelines, among others. He said federal agencies were among the first to recognize the need to build firmware protections into the purchasing process, after research into early attacks indicated a potential for compromise at the firmware level. In an effort to help ensure a higher degree of security in products purchased by the government, “SP 800-147 was intended to identify technical guidelines for how PC manufacturers could protect the BIOS,” Regenscheid said.

Potential impact

SP 800-147 raised the bar for firmware in PCs.  However, given the increasing complexity of firmware and its privileged position in PC architectures, the potential security impacts have become significant. In critical infrastructure environments, the physical safety of U.S. citizens is of top concern. Next on the list would be a firmware attack's resulting loss of productivity, such as the $10B cost of downtime to organizations hit by notPetya. Of equal significance is the potential of sensitive data loss via undetected hardware security flaws such as Spectre and Meltdown,  which were mitigated with firmware updates.

With the potential loss of safety, productivity and sensitive data due to the rise in firmware vulnerabilities, more standards organizations are “getting tough” on ensuring firmware protections. Agency personnel should expect the same evolution from the government regulatory community as well.

Where to start?

Regenscheid advises agencies "to look at the risks that are most relevant by their systems. You have to then look at where firmware security falls on that list which will dictate what priority you give it.” He gives the example that many components in PCs, such as video or network cards, have updatable firmware and are also at risk for attacks. This would be an area to elevate in priority and to regularly update. NIST released new guidelines in May 2018, SP 800-193: Platform Firmware Resiliency Guidelines, to address firmware-related threats to these components.

After ensuring regular firmware updates, agencies can look at monitoring firmware for unscheduled changes. They should start by asking the following:

• Is firmware being monitored today? If so, how?
• Does the current integrity management solution support firmware monitoring? If not, can this feature be added? 
• What level of effort will be required to implement a broader monitoring solution?

Agencies would be wise to start thinking about firmware as another layer in the stack that must be managed and secured. From a solutions perspective, vendors have taken a number of different approaches -- from building firmware monitoring point solutions to incorporating firmware integrity management as one component of the overall integrity software tool suite. Ideally, the solution will detect potential firmware attacks, monitor firmware for unscheduled changes and be capable of recovering the firmware to its original state.