FISMA Compliance Handbook: Second Edition

1

FISMA Compliance Overview

Abstract

FISMA is the most important cyber security law affecting U.S. federal agencies and requires a security assessment for all systems that transmit or store government-owned data. FISMA terminology has evolved over the years, but the law has not changed by one word since the day it went into effect. FISMA involves creating various security documentation about the system, and templates streamline the process. Oversight and governance are provided by Inspector Generals. The Department of Homeland Security reports on FISMA metrics annually.

Keywords

Terminology; Paperwork; Inspector Generals; Oversight; Governance; Department of Homeland Security; Treasury Office of Inspector General; U.S. Department of Justice; U.S. Department of Agriculture; General Services Administration

The law cannot be enforced when everyone is an offender.

—Chinese Proverb

Topics in this chapter

• Terminology

• Processes and paperwork

• Templates streamline the process

• Oversight and governance

• Supporting government security regulations

Introduction

The Federal Information Security Management Act (FISMA) is the most important cyber security law affecting U.S. federal agencies. No other cyber security law creates as much oversight, audit, and scrutiny as FISMA—at least as far as federal departments and agencies are concerned.

FISMA, also known as Title III of the E-Government Act (Public Law 107-347), requires that all systems and applications that reside on U.S. government networks undergo a formal security assessment before being put into production. System authorization is the ultimate output of a FISMA compliance project, and a system or application cannot be authorized unless it meets specific security control requirements. However, keep in mind that no system can be completely secure—unless it is powered off and locked in a vault. Of course, then it is not very usable. Determining the security controls for the system is a balancing act between making the system usable and making the system secure. These two endeavors are often at odds with each other. In order to find the balance, security experts analyze the probability and impact of vulnerabilities being exploited (or not) and then make risk-based decisions based on the analysis. Clearly, the goal of FISMA is to force federal agencies to put into production secure systems and applications and then to analyze risk periodically, all for the purpose of making risk-based decisions.

Before FISMA came along, implementing security controls on U.S. government networks was optional. Some agencies did a good job and others didn’t. Today, implementing security controls, looking for vulnerabilities, and performing security assessments are no longer an option. All federal agencies and departments work on FISMA compliance projects for all of their systems as a routine part of their information security agenda.

New applications and systems require a security assessment and authorization before they can be put into production, and existing applications and systems require a new assessment and authorization every 3 years. Systems that have already been authorized to operate must be reassessed every 3 years.

An additional requirement of FISMA is that federal departments and agencies develop and implement an agency-wide Information Security Program. The agency Information Security Program should be described in a document known as an Information Security Program Plan. I’ll talk more about what goes into an Information Security Program Plan in Chapter 5.

Though U.S. federal departments and agencies have no choice but to comply with FISMA, private sector organizations can optionally take advantage of FISMA compliance methodologies to help mitigate risks on their own information systems and networks. About 90% of the nation’s critical infrastructure is on private networks that are not part of any U.S. federal department or agency. The nation’s critical infrastructure includes those information technology systems that run electrical systems, chemical systems, nuclear power plants, transportation systems, telecommunication systems, banking and financial systems, and agricultural, food and water supply systems—to name only a few. The FISMA compliance methodologies described in this book can be adopted and used by not just federal agencies but by the private sector as well. Though federal departments and agencies seem to get repeated criticisms belittling their security initiatives, it’s my experience and belief that the criticisms are somewhat exaggerated and that their security conscientiousness far exceeds that of private industry. Any enterprise organization can adopt the FISMA compliance methodologies explained in this book. A special license is not required, and no special tools are required to make use of the model—it is simply a way of doing things related to information security.

The FISMA compliance process culminates with a very comprehensive and standardized security assessment. Essentially, the security assessment is an audit. Having worked in both private industry and on government networks, my experience shows that contrary to what you read in the news, most private and public companies do not put nearly as much time, effort, and resources into implementing security controls as government agencies do. Except for security incidents involving personally identifiable information, there are few federal laws that require companies to disclose security incidents. The percentage of those security incidents that are disclosed is very small. Many organizations purposefully do not report incidents to avoid bad press.

To demonstrate FISMA compliance, descriptions of security control implementations, policies, procedures, and risks are explained formally in a collection of documents known as a Security Package. The Security Package includes details of a review and analysis of all the hardware and software components of the system, as well as the data center, or location where the system resides. In some cases, a system may span multiple geographic locations and may consists of numerous connections from one or multiple data centers to other data centers that are either part of the system or are owned by other entities. A system’s Security Package demonstrates that due-diligence in mitigating risks and maintaining appropriate security controls has occurred.

Terminology

Since the first edition of this book, FISMA terminology has changed somewhat. Originally, the process by which agencies complied with FISMA was known as Certification and Accreditation (C&A). Those terms were originally coined by someone at the National Security Agency and were gradually adopted by the Department of Defense, the National Institute of Standards and Technology (NIST), and all the civilian federal agencies. A Security Package was originally referred to as a C&A Package. In the first edition of this book, I said that the term Certification can be confusing because the system does not really get Certified by anyone for anything. I also said that a more apropos name might have been a Security Package. As luck would have it, in the newly revised version of NIST 800-37 (Revision 1) [1], the terms Certification and Accreditation were dropped and NIST changed the terminology of the suite of security documents from a C&A Package to a Security Package.

The original version of NIST 800-37 was titled Guide for the Certification and Accreditation of Federal Information Systems. Revision 1 of Special Publication 800-37 is titled Guide for Applying the Risk Management Framework to Federal Information Systems. However, old traditions die hard and government agencies are slow to change. Therefore, many federal departments and agencies still use the terms Certification and Accreditation or C&A when referring to their FISMA compliance process. If you’re going to be working on FISMA compliance, it will help you to understand the meaning of these original terms, even if they have fallen out of fashion. As of this writing, many federal agencies still use these terms, even though current standards have abandoned them.

The original version of NIST Special Publication 800-37 [2] defined Certification as:

A comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.

Experts among us don’t always agree on the definition of a particular term and government agencies are no different. In June 2006, the Committee on National Security Systems, Chaired by the Department of Defense, defined Certification in the National Information Assurance Glossary [3], as:

A comprehensive evaluation of the technical and nontechnical security safeguards of an IS to support the accreditation establishes the extent to which a particular design and implementation meets a set of specified security requirements.

The definitions are similar enough and if you’re going to be working in this industry, you’ll hear both terms sooner or later. From a legal standpoint, the term Certification means attesting to the truth about something. You may at some point in your life need to sign a document that says something like I certify that this, that, and the other thing are true. You could be held liable for any falsifications made if you certify something. The idea behind certifying a set of information security documents means that you’re attesting to the truth about the fact that they are accurate.

Accreditation refers to the positive evaluation made on the Certification and Accreditation Package by an evaluation team. The original version of NIST Special Publication 800-37 referred to accreditation as:

The official management decision given by a senior agency official to authorize operation of an information system and to explicitly accept the risk to agency operations (including mission functions, image, or reputation), agency assets, or individuals, based on the implementation of an agreed-upon set of security controls.

And the National Information Assurance Glossary referred to accreditation as a:

Formal declaration by a Designated Accrediting Authority (DAA) that an IS is approved to operation at an acceptable level of risk, based on the implementation of an approved set of technical, managerial, and procedural safeguards.

An accreditation is a statement about a decision. As far as FISMA goes, before a system is deemed FISMA compliant, a decision is made by an oversight team after reviewing a suite of documents containing information about the system and its risk exposure. The oversight team may be referred to by different names in different agencies. You should think of the oversight team as specialized information security auditors and these days, they are most commonly referred to as independent assessors. Since the most current version of NIST Special Publication 800-37 refers to these folks as independent assessors, that is the term that I will be using in this book.

Each agency has their own independent assessors to evaluate the various Security Packages within their own agency. The independent assessors review the system’s security controls, interview the system owner and team members, and create a Security Assessment Report that describes the vulnerabilities, threats, and risks. The AO then makes a risk-based decision on whether to issue an Authority to Operate (ATO).

Once a Security Package has been evaluated, the independent assessors then provide recommendations to the Authorizing Official (AO) based on their findings. The Senior Agency Information Security Officer (SAISO)¹ then makes a decision on whether to issue an Authority to Operate (ATO) for the system. A positive authorization indicates that a senior agency official has formally made the decision that the documented risks to the agency, assets, and individuals are acceptable. Senior agency officials employ large teams of information assurance oversight staff that go over the Security Packages with fine-toothed combs. Authorization does not come lightly and occurs only after each Security Package has undergone a scrupulous review. By authorizing an information system, the senior agency official agrees to take responsibility for the accuracy of the information in the Security Package and consents to be held accountable for any security incidents that may arise related to the system.

Much of the terminology that federal agencies use in their FISMA compliance programs comes from the Office of Management and Budget (OMB) Circular A-130, Appendix III (listed in Appendix B). The OMB was created in 1970 and essentially replaced the Bureau of Budget and is part of the Executive Office of the President of the United States. Aside from assisting the president with the budget, the OMB’s mission is also to create and oversee information and regulatory policies. The fact that the OMB plays a significant regulatory role in FISMA compliance shows just how important information security has become to our national infrastructure. It also means that FISMA compliance initiatives will have a budget and are clearly a priority to the Executive Office of the President of the United States—and that’s a good thing.

Processes and paperwork

Federal agencies typically use a standardized process for FISMA compliance. Each agency decides what their standardized security process consists of and documents it. The different U.S. federal departments and agencies develop their own unique standardized process based on standards and guidance from one of the following organizations:

• the National Institute of Standards (NIST)

• the National Security Agency (NSA)

• the Committee on National Security Systems (CNSS)

• the Department of Defense (DoD).

Federal agencies create multiple documents related to the security of the system to serve as evidence of compliance. This book will help you learn how to develop the various documents and artifacts required for FISMA compliance. The amount of security documentation that you will find in one Security Package is extensive, and these tomes of documents needed to prove compliance with FISMA have received much criticism from some industry experts. Unfortunately, today, showing evidence of compliance on paper is really the only way that compliance can be verified.

While some aspects of compliance can be automated, today there are no solutions available to fully automate the continuous monitoring of an entire system. The futuristic goal of automated compliance aside, many security experts fail to realize the value that the Security Package offers aside from compliance. Most large complex engineering feats require that the details of the design and operations are written down and there are many reasons for doing so. First, complex systems need to be managed and it’s hard to know what you’re managing if you don’t have reference documents that spell out the details. No one would ever expect anyone to be able to manage all of the intricacies of the Hoover Dam without all of the requisite operation documents. Boeing would never deliver an F-15E Strike Eagle to the U.S. Air Force without any reference documents on how to perform maintenance. How would you feel if our nuclear power plants were being operated without any manuals? Even if a Chief Information Security Officer (CISO) is briefed on how a system and network is architected, it is not possible for any CISO to simply hear all the details once and then remember them.

We write things down when there is too much information to remember. In the 1800s, a German psychologist, Herman Ebbinghaus, performed some important studies on the limitations of human memory. In the 1870s, Ebbinghaus researched the retention of learning and developed a curve of forgetting. He proved empirically that only one-third of an audience remembers a delivered message after 1 hour. After 2 days, the retention goes down to 28%. If any of us tried to memorize all of the intricacies of an enterprise information system, we would fail miserably. For that reason, the thousands of details about how enterprise information systems are built and configured need to be written down. People who manage complex systems perform better when they have reference documents. Trying to manage complex enterprise systems and networks without reference documents is a roadmap to failure. People involved in FISMA compliance projects should understand that developing the suite of documents that are required for the Security Package is not just a compliance exercise. The Security Package documents should be considered living documents and that CISOs (also referred to as SAISOs) count on using these documents to help manage the security of the system it describes.

Templates streamline the process

To create some order out of the paper work challenge, most agencies now have templates that they use for all the different types of documents that go into the Security Package. Templates ensure that all the different types of documents that go into the Security Packages have the same look and feel. Using templates is a way of standardizing the documentation to create recurring best practices to enable efficiencies. A good template helps to ensure that all key information is included in the document. Well-written templates also assist oversight teams in finding the information that they are looking for because they will know exactly in which section of the document to expect it.

The amount of information that is required in any one Security Package is so great that if each Security Package had a different format, it would be nearly impossible for assessors to evaluate the package. When independent assessors evaluate a Security Package, they want to know where to look to find key information and they don’t want to have to hunt for it. I have seen Security Packages receive negative findings not because the right information wasn’t in the Security Package, but because the right information was not where it was supposed to be.

In spite of the criticisms of the voluminous documentation required for FISMA, it would be a mistake to get rid of it all.

FISMA oversight and governance

A goal for any agency is to make sure that all Security Packages are properly evaluated and that all production systems have ATOs. Each agency is audited annually by an Inspector General (IG) and most agencies have a dedicated Office of Inspector General (OIG). Inspectors come on site annually and review agency Information Security Programs and the various systems that come under the purview of the program. They look to see if all systems have ATOs, and they also look to see if vulnerabilities that were previously reported are being mitigated. You can go to any agency Web site and find out various information about the Office of Inspector General by putting OIG into the search box on the agency home page. Here are some agency OIG sites that you can browse