Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

10/3/2019
10:00 AM
John Loucaides
John Loucaides
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

How FISMA Requirements Relate to Firmware Security

Federal guidelines can help all organizations pragmatically and meaningfully improve their firmware security.

Adversaries recently have noticed that firmware and hardware constitute a serious blind spot for most organizations. While firmware may have once been the domain of nation-state attackers, it's now easier than ever for criminals to develop firmware-based attacks that bypass security and cause serious (even permanent) damage. While advances in firmware security mean that organizations no longer need specialized talent or manual analysis to protect their firmware, a risk remains.

Enter the Federal Information Security Management Act, or FISMA. While FISMA applies mainly to government agencies and companies doing business with the government, it is based on NIST standards that provide guidance on best practices for all organizations. It's guidance on firmware is worth the attention of both government and nongovernmental security and risk management teams. (Editor's note: Eclypsium is one of several vendors that market firmware protection products.)

First and foremost, 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 RiskManagementFramework (RMF) Overview ("Prepare"), organizations are called to define their high-level risk strategy based on their unique mission, tolerance for risk, types of threats such as cyberattacks, 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 these 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 adapters. 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 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

A Call to Arms
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 that are "potential vehicles for transporting malicious code, intentionally or unintentionally, into a facility and subsequently into systems."

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 firmware threat, organizations can determine the proper controls required to comply with FISMA and — perhaps more importantly — strengthen their firmware security in a noticeable, practical way.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "How the City of Angels Is Tackling Cyber Devilry."

John is VP R&D at Eclypsium, the industry's leading enterprise firmware protection platform. John has extensive history in hardware and firmware threats from experience at Intel and the United States government. At Intel he served as the Director of Advanced Threat Research, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 4/7/2020
The Coronavirus & Cybersecurity: 3 Areas of Exploitation
Robert R. Ackerman Jr., Founder & Managing Director, Allegis Capital,  4/7/2020
'Unkillable' Android Malware App Continues to Infect Devices Worldwide
Jai Vijayan, Contributing Writer,  4/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-1633
PUBLISHED: 2020-04-09
Due to a new NDP proxy feature for EVPN leaf nodes introduced in Junos OS 17.4, crafted NDPv6 packets could transit a Junos device configured as a Broadband Network Gateway (BNG) and reach the EVPN leaf node, causing a stale MAC address entry. This could cause legitimate traffic to be discarded, le...
CVE-2020-8834
PUBLISHED: 2020-04-09
KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc__tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to...
CVE-2020-11668
PUBLISHED: 2020-04-09
In the Linux kernel before 5.6.1, drivers/media/usb/gspca/xirlink_cit.c (aka the Xirlink camera USB driver) mishandles invalid descriptors, aka CID-a246b4d54770.
CVE-2020-8961
PUBLISHED: 2020-04-09
An issue was discovered in Avira Free-Antivirus before 15.0.2004.1825. The Self-Protection feature does not prohibit a write operation from an external process. Thus, code injection can be used to turn off this feature. After that, one can construct an event that will modify a file at a specific loc...
CVE-2020-7922
PUBLISHED: 2020-04-09
X.509 certificates generated by the MongoDB Enterprise Kubernetes Operator may allow an attacker with access to the Kubernetes cluster improper access to MongoDB instances. Customers who do not use X.509 authentication, and those who do not use the Operator to generate their X.509 certificates are u...