Data Security

Maneuvering, Understanding, and Applying Federal Compliance Requirements

By Katherine Teitler

If you are a System Owner (SO) in a commercial organization or a federal agency, maneuvering through, understanding, and implementing federal security and privacy compliance requirements can be a difficult hurdle. The Federal Information Security Management Act (FISMA) and the Federal Risk and Authorization Management Program (FedRAMP) are two very similar and yet very complex and time-consuming federal compliance requirements. When it comes to cloud –based technologies, the process can be even trickier since the data that will be stored in the cloud is now handed off to a third party, who may be located in a different jurisdiction, one not subject to U.S. federal requirements. In addition, your data may be co-mingled with other companies' data, and those companies may have entirely different security and compliance requirements.

Making the Selection is Easier than Anticipated
Regardless of who is writing the check(s) for the cloud solution, budgetary considerations are always on the front burner. The costs associated with purchasing hardware, software, hosting facilities, and staffing for maintenance support are not severely impacted by either the FISMA or FedRAMP compliance selection.

The critical questions that have to be answered prior to traveling down the FISMA or FedRAMP road cannot be taken lightly: Where is the solution being hosted, internally or externally? If externally, does the hosting facility possess a compliance accreditation decision that is current? What method of two-factor authentication is in use, and does that solution satisfy your compliance selection?
Selecting the Authorizing Official (AO) can be a Game Changer

The AO for the FISMA accreditation decision is very straightforward. The System Owner (SO) develops and implements the cloud offering and hires the Third Party Assessment Organization (3PAO) to complete the independent assessment for the accreditation decision. The FedRAMP accreditation decision has two options (both options contain identical security authorization package contents):

  • Agency Path (Option 1): The preferred path by Cloud Service Providers (CSPs) and Software as a Service (SaaS), solution providers. This path contains fewer hurdles and a faster accreditation decision by the AO, who is accepting the system risks.
  • Joint Authorization Board (JAB) Path (Option 2): The JAB path applies when the CSP or SaaS does not have an agency sponsor. The CSP / SaaS challenges and hurdles initially begin with producing the security authorization package. The core documents in this package must be reviewed and accepted by the FedRAMP Program Management Office (PMO), assigned Information System Security Officer (ISSO), and the JAB Technical Reviewers (TR's) from DoD, DHS, and GSA.

Accreditation Decision Delays are Costly

The risks identified in the Security Assessment Report (SAR) for the cloud offering may not be clearly understood by the AO or JAB TRs. When a clarification request is initiated by each of the JAB TRs or the AO on one or more of the risks in the SAR and/or Penetration Test Report (PTR), the accreditation decision is delayed. Identifying potential "red flags" that a FISMA or FedRAMP compliance is off track cannot be solely based on the total number of "low, moderate, or high risks." The SO will have to review several risk factors prior to submitting the security authorization package to the AO and JAB TRs, which include:

  • Was the entire accreditation boundary inventory of hardware and software scanned using authorized tools? Were authenticated scans conducted, where applicable?
  • Are complete risks from vulnerability scans, penetration testing, and security control testing documented in the SAR?
  • Are high / critical risks from vulnerability scanning of the infrastructure, databases, Web applications, and virtual machine environments a false positive?
  • Is the justification sufficient for reducing a high / critical risks to moderate, or a moderate risk to low?
  • Are risks corrected during testing, accurately documented in the SAR, Change Control Board (CCB) and Plan of Action & Milestone (POA&M)? Did the SO authorize each risk-corrected during testing, using the CCB?


Understanding how to manage compliance requirements, as well as identifying potential red flags that may delay an accreditation decision, can ultimately reduce the overall risks within an accreditation boundary. The five (5) examples above are only a short list. The complete list is a moving target.



About the Author: James Biggs is president of JD Biggs & Associates Inc., a Third Party Assessment Organization (3PAO), Security and Privacy consulting firm, specializing in FedRAMP / FISMA / HIPAA compliance assessments. His talk, "Applying Commercial & Federal Cloud Compliance Strategies," will be presented at Cloud Security World 2016 on Wednesday, June 15th.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.