FISMA provides federal agencies significant leeway when determining the security controls required for compliance. Each agency is responsible for determining the appropriate controls based on their particular risk profile. And while some agencies may dismiss firmware security, that would be a big mistake. Adversaries have noticed that firmware and hardware constitute a serious blind spot for most organizations, and while firmware may have once been the domain of nation-state attackers, it is now easier than ever to develop firmware-based attacks that bypass security and cause serious (even permanent) damage. However, advances in firmware security mean that agencies no longer need specialized talent or manual analysis to protect their firmware. Let’s look at how FISMA requirements relate to firmware security and what organizations should consider when determining what controls are required.
First and foremost, it’s critical to note that firmware clearly falls well within scope for FISMA compliance. The regulation’s far-reaching requirements are spelled out in two NIST documents. SP 800-37 lays out a Risk Management Framework (RMF), and SP 800-53 addresses Security and Privacy Controls. Both NIST documents identify firmware as a critical part of a security program. In fact, they consistently include firmware along with hardware and software when describing the components of technology and devices to be protected. The question isn’t whether to include firmware in a security program, but which firmware to include.
Understanding the threat and scope
In the first phase of the RMF (“Prepare”), organizations are called to define their high-level risk strategy based on their unique mission, tolerance for risk, types of threats such as cyber-attacks, and other factors. Given their high-risk level, firmware security threats should be considered as part of these efforts. This requires an understanding of the scope and severity of firmware security threats.
Firmware is the foundational code of a device. System firmware such as BIOS or UEFI runs before the operating system. Threats at this level can subvert security controls and assumptions made by the operating system or applications.
Firmware is also present in virtually every piece of hardware in a computer system, from the storage drives to the network adaptors. Attackers have plenty of opportunity to eavesdrop on data stored on a system or transmitted over its network connections, or to disable the device altogether—all at the firmware level. To further exacerbate the problem, firmware threats subvert traditional security controls and survive common incident response processes. For example, attackers can persist in the firmware even if the operating system is reinstalled to a known-good version. All of this adds up to a high potential impact on a system’s confidentiality, integrity, and availability.
Choosing security controls for firmware
Once federal agencies identify the systems to be protected, they must implement the proper security controls, as enumerated in NIST SP 800-53. The following families of security and privacy controls identified in the document may naturally apply to firmware security:
· SI – System and Information Integrity
· SA-Systems and Services Acquisition
· CM-Configuration Management
· AC-Access Control
· RA-Risk Assessment
· IR-Incident Response
· MA-Maintenance
Many of the controls specifically call out firmware security. For example, Configuration Management states the importance of only using updates that are cryptographically signed. As examples, the document identifies “firmware version updates, patches, service packs, device drivers, and basic input output system (BIOS) updates.”
Control SI-7 also addresses firmware, along with software and information integrity. The Control specifically addresses the need to ensure the integrity of the system boot process as well as the integrity of the boot firmware.
Section MA-3 of SP 800-53 also demands that organizations consider firmware security. This time, in respect to the tools administrators use to service a system. According to the document:
“Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, intentionally or unintentionally, into a facility and subsequently into systems.”
Conclusion
Firmware is explicitly within the scope of FISMA. More importantly, because of ongoing efforts across the industry, the cost of including firmware protections into a security program is now lower than ever. With open source and commercial tools available, organizations can now deploy firmware security at scale in the supply chain, in operations, and in incident response. Armed with an understanding of the severity and scope of the threat organizations can determine the proper controls required to comply with FISMA and—perhaps more importantly—strengthen their firmware security in a noticable, practical way.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.