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 under ..
Support the originator by clicking the read the rest link below.
