What is FISMA?

FISMA is a federal law that requires the implementation of specific sets of security controls for information systems that process, transmit, or store federal data. This mandate covers government agencies, such as NIH, NASA, the CDC, the EPA, and many more. FISMA compliance also trickles down to the contracting agents or grantees that work on behalf of these government entities. As a major research institution, UAB is awarded such contracts or grants and, as a result, its researchers can fall under the FISMA umbrella. Because it is a federal law, FISMA compliance is mandatory and, when called upon to do so, UAB researchers must meet the minimum security controls prescribed by FISMA if the federal contract or grant specifies that the researcher must meet those FISMA requirements.

How do I know whether FISMA applies to my research?

When evaluating a new research effort or preparing to renew an ongoing effort, start by discovering whether FISMA-specific language is included in the terms of the federal contract or grant. Such FISMA-specific language often appears in the special contract requirements or security requirements sections of those documents. Look for references such as the following:

  • IT Security Plan or System Security Plan (IT-SP or SSP)
  • IT Risk Assessment (IT-RA or RA)
  • FIPS 199 and FIPS 200 Standards
  • NIST Special Publications (SP) 800-26, 800-30, 800-37, and/or 800-53
  • Federal Information Security Management Act (FISMA)

If you find references to one or more of these topics, your research project might require FISMA compliance, but it’s not a guarantee that compliance is mandatory. Some government agencies write overly broad contracts/grants that include FISMA language even though it is not applicable to the contractor/grantee. For example, FISMA compliance is required if federal data is being stored, processed, and/or transmitted by a contractor/grantee. If your research project does not store, process and/or transmit federally owned data, you likely will not be required to meet FISMA information security requirements even if your contract/grant includes FISMA-specific language.

If you discover FISMA requirements in your contract or grant, the best course of action to determine whether compliance applies to your research project is to reach out to your primary contact at the sponsoring government agency tied to the contact or grant. Ask him/her for clarification regarding how the FISMA language should be interpreted. If FISMA compliance is required, you can contact UAB’s Enterprise Information Security Office (EISO) at 975-0842 or DSO-RiskMgt@uab.edu and request additional guidance in meeting FISMA’s information security requirements.

If FISMA doesn’t apply, are there any information security requirements?

Yes. Even if FISMA is not required, your research project must still follow all UAB policies, standards, and rules related to information security and the protection of UAB-owned resources and data. If your research project involves identifiable patient data, you also would have to abide by the security and privacy mandates derived from the Health Insurance Portability and Accountability Act (HIPAA). Finally, some government agencies include information security requirements that are specific to them and have nothing to do with FISMA. The National Institute of Health (NIH), for example, often requires that contractors and their staff complete annual security awareness training provided by NIH. Government agencies also might require specific levels of encryption for restricted data. Such stipulations would appear in the contract or grant. Therefore, even if the sponsoring government agency informs you that your project is not required to be FISMA compliant, there will be other information security requirements that must be met.

This is all technical stuff, right?

When one thinks of “information systems” or “information security,” it is easy to focus solely on technology. However, that is just one component of the FISMA equation. A significant portion of the controls is implemented outside of the technical realm. Such controls apply standards that govern how processes and procedures related to the researcher’s mission can be conducted in a more secure, compliant manner. Other non-technical controls govern how physical information system assets are protected, such as servers being housed in a locked room with backup power supplies attached to them. FISMA compliance is more than just securing laptops, servers, and networks.

How difficult is this going to be?

Creating a FISMA-compliant environment is not as bad as some people make it out to be. There will be learning curves to tackle during the process. A culture change often is required to adapt to a new way of doing business. In fact, the culture change might be the biggest hurdle the organization faces. Also, there is a large amount of documentation that needs to be created and maintained. However, there are resources that can be used to help a PI navigate the road to FISMA compliance. The FISMA Compliance Handbook for UAB Researchers and Support Staff, for example, is one such resource.

Can UAB IT help me with this?

Creating a FISMA-compliant information system and environment without outside aid is possible, but the required resources and time are likely cost-prohibitive for most research teams. However, there are solutions that can be developed by leveraging UAB resources and/or third-party service providers.

For example, UAB’s Risk Management and IT Compliance security engineers can provide insight and guidance through every step of the FISMA process. These engineers also can examine proposed strategies or help develop roadmaps aimed at creating a FISMA-compliant environment for a research project.

Common strategies that are adopted by some organizations are:

  • The Solo approach: The organization itself creates all of the documentation, designs and builds the controls and the information system, and conducts the continuous monitoring activities itself.
  • The Hybrid approach: The organization itself creates all of the documentation, designs and builds the controls and the information system that are specific to its mission. The organization then secures a third-party to host the information system and provide additional controls. (For example, an organization designs and builds a research application and then has a FISMA-compliant third-party cloud provider securely host the application. In this scenario, the research department develops controls specifically for the application and inherits FISMA-compliant controls implemented by the cloud provider). Any third-party cloud provider must be approved in advance by UAB’s Vice President of Information Technology.

UAB IT has SSP templates that were developed by the EISO and were used to aid researchers in meeting their FISMA requirements. These templates can be used as a model and likely will speed up the process of developing an SSP. However, there are two pitfalls that must be avoided:

  • Even though using SSP templates might speed up the creation of a new project’s SSP, the development of the plan for a new project will take a significant amount of time. There are no shortcuts to be taken.
  • There might be a temptation to simply copy and paste numerous elements from an example SSP into the SSP being written for a new project. This is a recipe for failure because the SSP must reflect the reality of how a specific information system is designed and controlled. An auditor assessing the information system will quickly realize when an SSP does not match reality, which might jeopardize whether a project is approved by the sponsoring government agency. This could kill the research mission.

UAB’s Risk Management and IT Compliance team can provide assistance during this trek. For more information about FISMA compliance strategies and solutions, please contact UAB’s Risk Management and IT Compliance team at 975-0842 or DSO-RiskMgt@uab.edu.

FIPS and NIST documents

The table below provides links to the relevant FIPS and NIST PDF documents that are cited in UAB’s FISMA compliance handbook or are helpful in developing FISMA artifacts. Access to all NIST-related documents can be found at the following links:

DOCUMENT TITLE LINK
FIPS 199 Standards for Security Categorization of Federal Information and Information Systems Link to NIST FIPS 199 Guidance
FIPS 200 Minimum Security Requirements for Federal Information and Information Systems Link to NIST FIPS 200 Guidance
NIST SP 800-30 Guide for Conducting Risk Assessments Link to NIST SP 800-30 Guidance
NIST SP 800-34 Contingency Planning Guide for Federal Information Systems Link to NIST SP 800-34 Guidance
NIST SP 800-37 Guide for Applying the Risk Management Framework to Federal Information Systems Link to NIST SP 800-37 Guidance
NIST SP 800-50 Building an Information Technology Security Awareness and Training Program Link to NIST SP 800-50 Guidance
NIST SP 800-53, Rev. 4 Security and Privacy Controls for Federal Information Systems and Organizations Link to NIST SP 800-53 rev.4 Guidance
NIST SP 800-64, Rev. 2 Security Considerations in the System Development Life Cycle Link to NIST SP 800-64 Guidance
NIST SP 800-128 Guide for Security-Focused Configuration Management of Information Systems Link to NIST SP 800-128 Guidance
NIST SP 800-137 Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations Link to NIST SP 800-137 Guidance

UAB information security policies and standards

A number of UAB information security policies, standards, and rules can be used to help meet and address requirements tied to FISMA compliance and its related security controls. These documents can be found on the UAB Information Security Policies and Guidance page. Policies, standards, and rules that can be applied to FISMA-related compliance include, but are not limited to, the following:

  • UAB Data Protection and Security Policy
  • Acceptable Use Policy
  • Data Access Policy
  • Data Classification Rule
  • Data Protection Rule
  • UAB Password/Passphrase Standard
  • Portable Computing Device Security –Laptop Standard
  • UAB Computing Device Rule
  • Vulnerability Management Rule

Checklist of FISMA deliverables

The checklists below enumerate the various documents that must be created

DOCUMENTS TO BE SUBMITTED TO THE AUTHORIZING OFFICIAL
System Security Plan Security Assessment Report Plan of Action and Milestones

PRIMARY STANDARDS AND PROCEDURES DOCUMENTS
Access Control Standard and Procedures Maintenance Standard and Procedures
Awareness and Training Standard and Procedures Media Protection Standard and Procedures
Audit and Accountability Standard and Procedures Physical and Environmental Standard and Procedures
Security Assessment and Authorization Standard and Procedures Planning Standard and Procedures
Configuration Management Standard and Procedures Personnel Security Standard and Procedures
Contingency Planning Standard and Procedures Risk Assessment Standard and Procedures
Identification and Authentication Standardand Procedures System and Services Acquisition Standardand Procedures
Incident Response Standard and Procedures System and Communications Protection Standard and Procedures
System and Information Integrity Standard and Procedures

SUPPORTING DOCUMENTATION
FIPS 199 and 200 Assessments Risk Assessment and Business Impact Analysis
ISSO Appointment Letter System Interconnection Agreement Template
Configuration Control Board (CCB) Charter List of Approved System Interconnections
CCB Minutes Template System Inventory List
Change Request Form Template List of Approved Hardware
Security Impact Analysis Template List of Approved Software
Network Diagram List of Approved Ports, Protocols and Services
Data Flow Diagram List of Approved Vendors
Media Transport/Destruction Form List of Approved Users
Rules of Behavior for Users ATO Request Letter

Key tasks for each FISMA phase

The FISMA process is based on a Risk Management Framework defined by NIST. This framework, illustrated below, is designed to create a repeatable process that accomplishes the following tasks:

  1. Categorize the sensitivity of the researcher’s data and the information system, followed by the enumeration of risks that may compromise the confidentiality, integrity, and availability of both the data and the information system.
  2. Select a specific set of security controls based on the sensitivity of the data and implement these controls while architecting the information system during the software/system development life cycle (SDLC).
  3. Implement and test the security controls as the information system is built.
  4. Assess the performance and effectiveness of both the information system and the security controls to provide assurance that they are working as intended.
  5. Gain authorization and approval from the contracting/granting agency for the information system to begin processing, transmitting, and storing federal data to accomplish the research mission
  6. Continuously monitor the effectiveness of the security controls to ensure they are effective during the life cycle of the information system.

The following is a task list for each phase that will guide researchers and their IT staff in creating a FISMA-compliant environment, if they must meet such a mandate.

PHASE TASKS
Initial Planning
  • Determine whether FISMA language is included in the contract/grant
  • Contact UAB Enterprise Information Security and the federal agency’s ISSO, Contracting Officer, Program Director, and/or AO for guidance and to determine whether FISMA compliance is required for the project
  • If possible, negotiate with the federal agency to set FISMA deadlines
  • Begin planning for compliance and factoring it into your budget
  • Assign SO, ISSO, and SA roles to staff members
RMF Step 1: Categorize the System
  • Categorize the data and the information system (Low, Moderate, High) using FIPS 199 and 200
  • Conduct the risk assessment and business impact analysis
  • Determine project requirements
  • Create an information system description and begin drafting an SSP
  • Begin the SDLC process by designing the information system and determining ways to protect the federal data it will use
RMF Step 2: Select Security Controls
  • Select the appropriate security controls detailed in NIST SP 800-53 (Low, Moderate, or High) and add them to the SSP
  • Detail in the SSP how all of the controls will be implemented
  • Finalize a rough draft of the SSP and submit it to the federal agency’s AO for review
  • Continue designing and building the information system; incorporate methods to enforce the controls into the system architecture
RMF Step 3: Implement Controls
  • Write a rough draft of the standard and procedures for each of the 17 FISMA control families
  • Test the procedures to determine their effectiveness and update them, if required
  • Approve and adopt the final drafts of the standards and procedures
  • Complete the build process for the information system and its associated technical controls; Conduct internal testing of the information system and technical controls
  • Complete a final version of the SSP
  • Create the required supporting documents detailed above in the Checklist of FISMA deliverables section
  • Review all documents and controls to ensure they are ready to be examined by a third-party assessor/auditor
RMF Step 4: Assess Controls
  • Have a third-party assessor/auditor evaluate the effectiveness of the information system’s controls
  • Develop a SAR and POA&M
RMF Step 5: Authorize System
  • Draft an ATO Request Letter
  • Submit the SSP, SAR, POA&M, and ATO Request Letter to the federal agency’s AO for review
  • If an ATO is granted, the research mission can begin
RMF Step 6: Monitor Controls
  • Continually review the effectiveness of the controls
  • Address deficiencies detailed in the SAR and POA&M
  • Regularly update and review documentation
  • Conduct annual self-assessments of the controls
  • Undergo a third-party assessment every three years in order to renew an ATO

Glossary of terms and acronyms related to FISMA

This is a list of acronyms and FISMA-specific terms. The FISMA-specific terms are derived from NIST Special Publication documentation.

Assurance (or Information Assurance): Measure of confidence that the security features, practices, procedures, and architecture of an information system accurately mediate and enforces the security policy.

Authorization to Operate (ATO): The official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls. An ATO must be issued to a research organization before it can begin working with federal data associated with a grant or contract.

Authorizing Official (AO): 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.

Availability: Ensuring the timely and reliable access and use of information.

Business Impact Analysis: An analysis of an information system’s requirements, functions, and interdependencies usedto characterize system contingency requirements and priorities in the event of a significant disruption.

Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

Configuration Control Board (CCB): A group of qualified people with responsibility for the process of regulating and approving changes to hardware, firmware, software, and documentation throughout the development and operational life cycleof an information system.

EISO: UAB’s Enterprise Information Security Office

FIPS: Federal Information Processing Standard

FISMA: Federal Information Security Management Act

Information: Any communication or representation of knowledge, such as facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual.

Information Security: The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

Information System: A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

Information System Security Officer (ISSO): Individual who is assigned responsibility for maintaining the appropriate operational security posture for an information system or program.

Integrity: Guarding against improper information modification or destruction, which includes ensuring information non-repudiation and authenticity.

IT-SP: Information Technology Security Plan; see System Security Plan

NIST: National Institute of Standards and Technology

Personally Identifiable Information (PII): Information which can be used to distinguish or trace the identity of an individual (e.g., name, social security number, biometric records, etc.) alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual (e.g., date and place of birth, mother’s maiden name, etc.).

Plan of Action & Milestones (POA&M): A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.

Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.

Risk Assessment (RA): The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis.

Risk Management: The program and supporting processes to manage information security risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, and includes: (i) establishing the context for risk-related activities; (ii) assessing risk; (iii) responding to risk once determined; and (iv) monitoring risk over time.

Risk Management Framework (RMF): A six-step process created by the National Institute of Standards and Technology, detailed in NIST Special Publication 800-37: Guide for Applying the Risk Management Framework to Federal Information Systems.

Risk Mitigation: Prioritizing, evaluating, and implementing the appropriate risk-reducing controls/countermeasures recommended from the risk management process.

SSP: See System Security Plan

Security Assessment Report (SAR): This deliverable is one of three key documents in the security authorization package developed for authorizing officials. The assessment report includes information from the assessor/auditor that is necessary to determine the effectiveness of the security controls employed within or inherited bythe information system based upon the assessor’s findings.

Security Control: A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.

System Owner (SO): Official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system.

System Security Plan (SSP): Formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements.

Threat: Any circumstance or event with the potential to adversely impact organizationaloperations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.