FISMA basics: What federal agencies and contractors need to know

FISMA defininition: What does FISMA stand for?

FISMA, or the Federal Information Security Management Act, is a U.S. federal law passed in 2002 that seeks to establish guidelines and cybersecurity standards for government tech infrastructure, and in so doing protect government information and operations. The law was modified in 2014 to put more emphasis on continual monitoring with the passage of the similarly named Federal Information Security Modernization Act; generally, discussions of FISMA refer to the set of regulations established by both these laws.

Like most federal cybersecurity laws, FISMA constitutes a complex set of rules that are intended to be at least somewhat flexible. While the initial intention of the law was to establish standards that the IT departments for federal agencies would follow, the sprawling nature of the government and its tight interconnection with private contractors means that the FISMA umbrella covers many, many organizations—including, maybe, yours.

Who must comply with FISMA?

Originally, FISMA was designed to strengthen IT infrastructure operated and maintained by the U.S. federal government. To that end, as the consultancy Aronson puts it in its whitepaper on FISMA compliance, the law “requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor or other source.”

There are a few important things to note in this description. One is the emphasis on “information and information systems.” The rules are really about assessing the security of individual systems, rather than companies or agencies as a whole. And because in practice federal agencies interact with or rely on outside organizations to provide IT services, FISMA rules apply to those organizations as well. These might range from state government agencies helping administer joint state-federal programs like Medicaid to private companies providing the feds with software or services.

But because FISMA is primarily written to impose standards on federal agencies, it affects private companies differently than laws like HIPAA, which mandate direct penalties like hefty fines on companies that don’t live up to the rules. By contrast, under FISMA, a person designated an Authorizing Official (AO)—generally, a high-level manager with responsibility over infosec at a federal agency—is in charge of determining if an information system complies with FISMA’s standards, whether that system is run in-house by the agency or is operated by another public body or a private federal contractor. This sign-off is known as an Authority To Operate (ATO), and the AO assumes responsibility for the systems to which they grant ATOs. If there’s a breach or other security failure in a system to which an ATO has been granted, it’s the AO and their team who would take the fall for it—and as you can imagine, there are career consequences for serious breaches.

But if the affected system is supplied by a private contractor, that company can’t expect to emerge from the incident unscathed. As RSI Security explains on its blog, contractors who are discovered to have fallen short of FISMA’s requirements probably at the least will find the specific contract for that system cancelled; depending on the severity of the security shortfall, they might also be blackballed from other federal contracts, and company execs might even find themselves hauled before a Congressional hearing to explain themselves. 

FISMA vs. FedRAMP

Before we dig into the specifics of the security standards laid down by FISMA, let’s take a moment to discuss another, related bit of jargon important for federal IT security: FedRAMP. Since 2011, the federal government has been working to rationalize its sprawling, fragmented IT infrastructure by moving much of it to the cloud. FedRAMP (the Federal Risk and Authorization Management Program) is a program launched to help certify cloud providers as secure enough for federal use. Specifically, it aims to provide a framework for applying the FISMA rules, most of which were written before the cloud era got underway, to cloud service providers. So, you can think of FedRAMP as a way that FISMA is applied to one specific category of IT. All FedRAMP is about FISMA, but not all FISMA is about FedRAMP.

FISMA compliance requirements

Like most federal laws of this type, FISMA outlines somewhat broad principles and delegates the specific rulemaking to a federal agency—the National Institute of Standards and Technology (NIST), in this case. NIST has encapsulated the most important rules in SP 800-53, “Security and Privacy Controls for Information Systems and Organizations,” but other important documents include FIPS-199, “Standards for Security Categorization of Federal Information and Information Systems,” and SP 800-30, “Guide for Conducting Risk Assessment.”

There’s a lot of detail in these documents, far beyond the scope of this article. But to give you a sense of what you’re up against, we’ll take a closer look at these high-level requirements of the law:

• Keep an inventory of your information systems
• Categorize the risk level of your data and systems
• Maintain a system security plan
• Use security controls
• Conduct risk assessments
• Certification and accreditation
• Continually monitor your systems

Inventorying information systems Federal agencies must keep track of information systems that they control or operate, as well as the interdependencies between those systems and interdependencies. They also need to keep track of those systems outside agency control, including those within an agency’s encrypted cloud.

Categorizing risk: FISMA high, moderate, and low You’ll need to categorize all data and IT systems under the FISMA umbrella according to the risk that a breach or other security problem poses to the relevant agency—the risk categories are defined as high, moderate, or low. Low-risk systems generally contain public information that doesn’t require safeguarding. A moderate-risk system may contain sensitive info and will require more security. A high-impact system contains information whose loss or compromise would present a grave risk to the U.S. government. An agency’s encrypted cloud environment must be categorized as well. NIST SP 800-60, “Guide for Mapping Types of Information and Information Systems to Security Categories,” goes into more detail.

Maintaining a system security plan All agencies must develop and maintain a plan that defines how that agency will implement security controls; this plan is officially called a System Security Plan, or SSP. The SSP must be updated regularly and include a Plan of Action and Milestones (POA&M). Basically, the purpose is to ensure that agencies are always staying proactive about their security.

“The system security plan reflects how the organization is actually implementing the controls.  This is important because control assessments are based on the system security plan and what is actually in place.  A plan of action and milestone is the gap analysis, and provides a roadmap to organizations to get where they should be,” says Chad Boutin, science writer for NIST.

Using security controls In FISMA-speak, controls or security controls are specific countermeasures that can protect the confidentiality, integrity, and availability of an information system. Among other things, NIST SP 800-53 includes an extensive catalog of suggested security controls for FISMA compliance and so much more—the latest revision of SP 800-53 “now also include[s] privacy controls, which is a major update from previous revisions,” says Boutin. That doesn’t mean you have to implement all of those controls to achieve compliance; rather, you should implement those that are relevant to your organization and systems. The controls you do select should be documented in your SSP.

Conducting risk assessments Agencies are expected to conduct a risk assessment whenever they make changes to their systems. This process can help determine if additional controls are necessary to provide extra protection. NIST SP 800-30 provides specific guidance for conducting risk assessments. 

For more guidance on conducting risk assessments, you should refer to the NIST Risk Management Framework (RMF)—NIST Special Publication (SP) 800-37 Revision 2. “The RMF provides a flexible, holistic, and repeatable 7-step process to manage security and privacy risk and links to a suite of NIST standards and guidelines to support implementation of risk management programs to meet the requirements of the Federal Information Security Modernization Act (FISMA),” says Boutin.

FISMA certification and accreditation Certification and accreditation is a term no longer used by NIST; it was eliminated in 2010 with the release of NIST SP 800-37, Revision 1. “Certification and accreditation had connotations of a one and done process and compliance mindset, the complete opposite of what our guidelines intend to provide!” says Boutin. “The term has been replaced with Assessment and Authorization (A&A) to reference the two corresponding steps of the NIST RMF.  Assessment (corresponds with RMF Assess Step) determines if the controls are in place, operating as intended, and producing the desired results.  Authorization (corresponds with RMF Authorize Step) is when a senior official makes a risk-based decision to authorize a system to operate.”

The complete process is defined in NIST SP 800-37, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy.”

One thing that’s important to keep in mind is that, as with any undertaking of this complexity, the final assessment will be somewhat subjective. Though all the NIST documents we’ve been linking to here to try to quantify matters, in practice the final sign-off decision on a system is made by the Authorizing Officer, a human being. An AO at one agency might grant an ATO to a system, while another agency’s AO might make a different decision about the same system.

Conducting continuing monitoring Like any security process, getting FISMA certified isn’t a one-and-done deal. Agencies must monitor systems to detect abnormalities, and perform security impact analyses, ongoing assessments of security controls, and status reporting. That in turn means that contractors have to continuously keep track of their own systems so that they can show the agencies they work with that they’re keeping in line with FISMA’s requirements.

FISMA audit

There are a number of processes that might be referred to as a “FISMA audit.” Government agencies must have their FISMA compliance ascertained by the Office of the Inspector General, usually via an audit conducted by a third party; for instance, in 2019 the Department of Energy was audited by the consultancy KPMG. Contractors may also be required to participate in such audits or may have their own audit requirements built into their contract with their agency customers.

Contractors wishing to be proactive may themselves pay a third-party company to conduct an audit on their FISMA compliance; KirkpatrickPrice, a consultancy that specializes in such services, has an FAQ outlining what that entails. Any such audit will generally be conducted using the all-important SP 800-53 as a framework. 

FISMA compliance checklist

That’s a lot of information to process, and it’s really only the tip of the iceberg: there’s a reason so many specialist companies exist to guide you through the FISMA compliance maze.

Indeed, Boutin warns that “[t]here is no such thing as a ‘FISMA Compliance checklist,’ so be wary of those who are selling it.’ 

But if you’re looking for a quick-and-dirty checklist on how you should be thinking about a big picture approach to compliance, you could do worse than these three tips from the Digital Guardian blog:

• Classify information as it is created: This will allow you to prioritize security controls and policies to apply the highest level of protection to your most sensitive information.
• Automatically encrypt sensitive data: This should be a given! Ideally, you would use a tool that can encrypt sensitive data based on its classification level or when it is put at risk.
• Maintain written evidence of FISMA compliance: Everything in dealing with the federal government needs to be meticulously documented. Stay on top of FISMA audits by maintaining detailed records of the steps you’ve taken.

Boutin notes that NISTs guidance was developed to:

• Help organizations understand the security and privacy risk to their systems and organization
• Select the appropriate controls to manage risk to an acceptable level
• Determine if the controls are implemented and effective
• Ensure that there is senior-level oversight and accountability
• Put a process in place to continuously monitor the controls and risk posture, and
• Provide a common lexicon to communicate about information security and privacy risk management.

That is your ultimate checklist.