FISMA Compliance: Security Standards & Guidelines Overview

What is FISMA?

FISMA stands for Federal Information Security Management Act, and was originally released in December 2002 and established the importance of information security principles and practices within the Federal Government, noting that information security was “critical to the economic and national security interests of the United States.” The emphasis of the FISMA was to establish a “risk-based policy for cost-effective security.”

With the passage of FISMA, each Federal agency was then responsible for developing and implementing an information security program for the information systems under its control to include any information systems that were managed by contractors on behalf of the agency. The goals of FISMA were to reduce information security risk and expenditures for the Federal agencies, specifically they were to implement “adequate security, or security commensurate with risk.”

FISMA Overview: Guidelines to Help Understand FISMA

With the passage of FISMA in 2002, its implementation was divided into two phases. Phase I (2003-2012) established guidelines and security standards for use across the Federal government. These guidelines and standards were part of the FISMA Implementation Project that started in January 2003. The specific documents and guidelines initially developed as part of Phase I of FISMA implementation include the following (as depicted with the latest revision):

• Federal Information Processing Standard (FIPS) Publication 199: Standards for Security Categorization of Federal Information and Information Systems (Feb. 2004)
• FIPS Pub 200: Minimum Security Requirements for Federal Information and Information Systems (March 2006)
• Special Publication (SP) 800-53: Security and Privacy Controls for Federal Information Systems and Organizations (Rev 4, April 2013, updated Jan. 2015). Note: Rev 5 is currently in Draft as of Feb 2016.
• SP 800-59: Guideline for Identifying an Information System as a National Security System (Aug. 2003)
• SP 800-60: There are two volumes that make up SP 800-60. Volume 1 (Rev 1, Aug. 2008) is the Guide for Mapping Types of Information Systems to Security Categories and Volume II (Rev 1, Aug. 2008) is the Appendices to Volume I.

Additional Phase I documents were developed to supplement the original list. As of May 2016, the following additional documents have been included:

• SP 800-18: Guide for Developing Security Plans for Federal Information Systems (Rev 1, Feb. 2006)
• SP 800-30: Guide for Conducting Risk Assessments (Rev 1, Sept. 2012)
• SP 800-37: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach (Rev 1, updated June 5, 2014)
• SP 800-39: Managing Information Security Risk: Organization, Mission, and Information System View (March 2011)
• SP 800-53A: Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans (Rev 4, Dec. 2014, updated as of Dec. 18, 2014)
• SP 800-137: Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations (Sept. 2011)
• SP 800-160: (DRAFT) Systems Security Engineering Guideline: An Integrated Approach to Building Trustworthy Resilient Systems (Sept. 2016)

As you can see, there are a large number of documents that have been produced to assist with the implementation of security within Federal information systems and to align with FISMA standards. The above list, though, is not all inclusive. There are many more ranging from application whitelisting (SP 800-167) to Networks of ‘Things’ (SP800-183).

The initial set of documents were key as they assisted the Federal agencies with understanding the information processed by their information systems and the associated security impact levels (low, medium, and high) against confidentiality, integrity, and availability. The resulting categorization of the system guides the applicable FISMA security controls as outlined in the SP 800-53 security control catalog.

Another important document released as part of Phase I of the FISMA Implementation was SP 800-59. This document defined the method for identifying a National Security System and gave the authority to develop information security policies, guidelines, and standards for National Security Systems (NSS) to the Department of Defense (DoD) and the Director, Central Intelligence (DCI) (specifically for systems processing intelligence information). All other Federal Systems were under the authority of the Secretary of Commerce.

How Does FISMA Apply to the Department of Defense (DoD) and the Intelligence Community?

With the authority for National Security Systems with the DoD and DCI, DoD and Intelligence Community specific information security guidelines, processes, and standards were developed. As a result, the DoD Instruction 8500.2, Information Assurance (IA) Implementation and the Director of Central Intelligence (DCID) 6/3 Protecting Sensitive Compartmented Information within Information Systems documents were developed.

With the move toward ICD 503 in the Intelligence Community, DCID 6/3 was rescinded and replaced by standards, policies and guidelines established by the National Institute of Standards and Technology (NIST) or the Committee on National Security Systems (CNSS).

In the DoD community, the DoD Risk Management Framework (RMF) has replaced the Defense Information Assurance Certification and Accreditation Program (DIACAP) and aligned its RMF processes with the NIST RMF process. The DoD RMF also incorporates the NIST security controls as defined in SP 800-53.

How Does the Risk Management Framework Fit Into FISMA?

Today, many, if not all DoD and Intelligence Community organizations have moved to NIST 800-53 as their security controls catalog and have customized their Risk Management Framework based on the framework defined in SP 800-37. The primary framework steps outlined in SP 800-37 are identified below.

• Categorize Information System
• Select Security Controls
• Implement Security Controls
• Assess Security Controls
• Authorize Information Systems
• Monitor Security State

Phase II of the FISMA Implementation Project (2007-2012) focused on establishing a common understanding in the application of NIST documentation supporting the Risk Management Framework (RMF). To do this, multiple initiatives were implemented which produced additional reference materials “intended to promote common approaches for assessing the extent to which the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirement for the systems, including information technology products and services used in security control implementation.” This phase included initiatives aimed at training, support tools (e.g. the National Vulnerability Database (NVD) and the Security Content Automation Protocol (SCAP), product and services assurance, ISO harmonization (specifically identifying common relationships and mappings to the ISO/IEC 27000 series) and organizational assessment capabilities.

What is the Role of Federal Agencies With Regard to FISMA?

Another large focus of the FISMA was to specifically detail responsibilities under the Act between the Federal agencies, NIST, and the Office of Management and Budget (OMB). Under the FISMA, the following responsibilities were defined:

• Federal Agencies: Develop and implement an integrated risk-based information security program. As part of this effort, Federal agencies were responsible for identifying all of their information systems, categorizing their information systems, defining and implementing applicable controls, testing the controls and continuously monitoring their implementation to ensure the controls are operating effectively and align with FISMA standards.
• NIST: Develop the security guidelines and standards for implementation across all Federal agencies. These include guidelines and standards for categorization of information systems, comprehensive definition of security controls and risk management methodologies, among others.
• OMB: Define and implement methods for oversight (e.g. define a standardized process for reporting FISMA compliance). Report to Congress on the status of FISMA compliance across the Federal government.

In December 2014, FISMA was amended to “(1) reestablish the oversight authority of the Director of the Office of Management and Budget (OMB) with respect to agency information security policies and practices, and (2) set forth authority for the Secretary of Homeland Security (DHS) to administer the implementation of such policies and practices for information systems.” Other notable requirements of the amended FISMA include the following:

• The annual report to Congress must include an assessment of agency compliance with the OMB data breach notification procedures
• Automated tools are provided to assist in the agency information security programs (to support risk assessment, testing, detecting, and reporting incidents, etc.)
• OMB is directed to develop guidance on what constitutes a major incident
• Agencies must report to unauthorized acquisition or access to Congress within 30 days. Agencies must also notify all affected individuals.

What is FISMA Compliance?

So, what does it mean to be FISMA compliant? Is there a FISMA certification that organizations can get to demonstrate that they are FISMA compliant? In short, the answer is no. So how does an organization determine whether they are FISMA compliant? Both government agencies and commercial entities supporting a government contract to process, store, or transmit government data must demonstrate compliance with FISMA.

In short, they must categorize their system and identify the controls that need to be implemented. Then they must demonstrate that they’ve implemented the controls identified in NIST 800-53 and developed the associated supporting policies, processes, and procedures to support the secure operation of the system. The assessment of the security controls should be conducted by an independent assessor with a background and experience with the NIST 800-53 controls, the assessment processes, and the ability to document compliance with the controls.

Based on the outcome of the assessment of the controls, an Authorizing Official (AO) will determine if the risk is acceptable to allow the system to operate in “production,” or to process, store, and transmit “live” government data. An AO is “a senior (federal) official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation” (SP 800-37, Rev 1). The AO determines whether the system sufficiently protects the confidentiality, integrity, and availability of the system and therefore accepts the risk and responsibility for the security of the system. If the risk is sufficiently low, then the AO will grant an ATO which is an Authority to Operate. Receiving an ATO essentially demonstrates FISMA compliance. The process doesn’t stop with the receipt of an ATO. Each year the program must demonstrate through continuous monitoring that the security controls are still in place and operating effectively.

If a commercial entity supports multiple government agencies, then they may have to get multiple ATOs as each government agency may have slightly different requirements, standards, and risk appetites. FISMA compliance and granting an ATO is very much an individual agency determination and lacks reciprocity between the government agency AOs.

FISMA traditionally applies to non-cloud systems supporting a single agency. For systems that are cloud based and support a single government agency or multiple agencies, a FedRAMP Authorization must be obtained. You can read more about FedRAMP here.

Summary

As part of their responsibilities under FISMA, NIST has done an outstanding job with developing comprehensive information security standards and guidelines. In addition to the above mentioned documents, there are many more covering various other aspects of an information security program. While developed for the Federal government, NIST documentation can be leveraged to enhance any commercial information security program as well.

As mentioned previously, the assessment of NIST 800-53 security controls and supporting documentation, policies, and procedures should be conducted by an independent assessor with a background and experience with the NIST 800-53 controls, the assessment processes, and the ability to document compliance with the controls.

Get a FISMA Audit

Linford & Co personnel have over 20 years of combined experience leading successful FISMA compliant security engineering efforts for highly complex programs supporting the acquisition, processing, and reporting of satellite data for the Department of Defense and Intelligence agencies.

Please contact us if you’d like to know more about FISMA compliance or get a FISMA audit for your organization.