FISMA Compliance Handbook

Second Edition

Laura P. Taylor

• Publisher: Syngress
• Year: 2013
• Print ISBN: 9780124058712
• eBook ISBN: 9780124059153
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

This comprehensive book instructs IT managers to adhere to federally mandated compliance requirements. FISMA Compliance Handbook Second Edition explains what the requirements are for FISMA compliance and why FISMA compliance is mandated by federal law. The evolution of Certification and Accreditation is discussed.This book walks the reader through the entire FISMA compliance process and includes guidance on how to manage a FISMA compliance project from start to finish. The book has chapters for all FISMA compliance deliverables and includes information on how to conduct a FISMA compliant security assessment.Various topics discussed in this book include the NIST Risk Management Framework, how to characterize the sensitivity level of your system, contingency plan, system security plan development, security awareness training, privacy impact assessments, security assessments and more. Readers will learn how to obtain an Authority to Operate for an information system and what actions to take in regards to vulnerabilities and audit findings.FISMA Compliance Handbook Second Edition, also includes all-new coverage of federal cloud computing compliance from author Laura Taylor, the federal government's technical lead for FedRAMP, the government program used to assess and authorize cloud products and services.- Includes new information on cloud computing compliance from Laura Taylor, the federal government's technical lead for FedRAMP- Includes coverage for both corporate and government IT managers- Learn how to prepare for, perform, and document FISMA compliance projects- This book is used by various colleges and universities in information security and MBA curriculums

Chapter 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 Securit...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• About the Author
• Foreword
• Chapter 1. FISMA Compliance Overview
• Chapter 2. FISMA Trickles into the Private Sector
• Chapter 3. FISMA Compliance Methodologies
• Chapter 4. Understanding the FISMA Compliance Process
• Chapter 5. Establishing a FISMA Compliance Program
• Chapter 6. Getting Started on Your FISMA Project
• Chapter 7. Preparing the Hardware and Software Inventory
• Chapter 8. Categorizing Data Sensitivity
• Chapter 9. Addressing Security Awareness and Training
• Chapter 10. Addressing Rules of Behavior
• Chapter 11. Developing an Incident Response Plan
• Chapter 12. Conducting a Privacy Impact Assessment
• Chapter 13. Preparing the Business Impact Analysis
• Chapter 14. Developing the Contingency Plan
• Chapter 15. Developing a Configuration Management Plan
• Chapter 16. Preparing the System Security Plan
• Chapter 17. Performing the Business Risk Assessment
• Chapter 18. Getting Ready for Security Testing
• Chapter 19. Submitting the Security Package
• Chapter 20. Independent Assessor Audit Guide
• Chapter 21. Developing the Security Assessment Report
• Chapter 22. Addressing FISMA Findings
• Chapter 23. FedRAMP: FISMA for the Cloud
• Appendix A. FISMA
• Appendix B. OMB Circular A-130 Appendix III
• Appendix C. FIPS 199
• Index