Every federal agency has security compliance requirements that must be met on an annual or ongoing basis. Two of the most important requirements are FISMA (Federal Information Systems Management Act) and FedRAMP (Federal Risk and Authorization Management Program).
While these two federal requirements have a lot in common, they pertain to different types of systems. Generally speaking, FISMA relates to on-premises systems while FedRAMP relates to systems in the cloud. Together they provide a two-pronged approach to security compliance, ensuring all systems are considered when it comes to security, regardless of where they’re located.
Let’s take a closer look.
Enacted in 2002, FISMA defines a comprehensive framework designed to protect government information, operations, and assets against threats. FISMA requires that federal systems meet a set level of security requirements (also known as “controls”) identified in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, “Recommended Security Controls for Federal Information Systems.” Systems that meet FISMA compliance requirements can receive an Authority to Operate (ATO)—which is the ultimate goal.
FISMA defines a broad set of security requirements—far too many to list here. That said, there are a handful of high-level requirements that are worth noting. In a nutshell, agencies should:
- Maintain an inventory of IT systems
- Categorize data and systems according to the risk level
- Maintain a system security plan
- Utilize security controls
- Conduct risk assessments
- Perform certification and accreditation
- Conduct continuous monitoring
Remember, these are the most basic, high-level FISMA compliance requirements. There are literally hundreds of additional security controls that cover everything from small technical details to program-wide decisions that impact funding, hiring/personnel security, disaster-recovery plans, data-protection mechanisms, privacy, and more. For more information, visit this page on the Cybersecurity and Infrastructure Security Agency website.
In 2010, the federal government released its “Cloud First” policy, which encouraged agencies to move data to a cloud environment wherever possible, citing dramatic cost and resource savings. Just one year later, the government enacted FedRAMP as a direct result of the Cloud First policy, to ensure data within the cloud is equally protected against threats.
FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. Specifically, FedRAMP requires that federal agencies protect all government information that is collected, maintained, processed, disseminated, or disposed of by cloud service offerings.
Because many agency cloud environments are provided and managed by a third party, this adds a level of complexity to the questions of security and compliance. To help minimize that complexity, the government has provided guidelines specifically to address questions relative to FedRAMP on a dedicated FedRAMP site. In fact, the government has gone even further by providing an Agency Authorization Playbook, which outlines each step of the FedRAMP ATO process.
Like FISMA, FedRAMP defines a broad set of security requirements. Therefore, when it comes to getting an ATO for cloud-based systems—particularly systems provide through a cloud service provider (CSP)—the government provides advice in three phases: pre-authorization, during authorization, and post-authorization.
Pre-authorization: During this phase, agencies are encouraged to perform the necessary research to find those providers that best meet their mission needs and requirements as they relate to security in the cloud. Agencies can do this by checking the FedRAMP Marketplace to see if there is a cloud service offering (CSO) that is already FedRAMP authorized or currently in process.
During authorization: While many CSPs are already FedRAMP certified, agencies must still ensure the validity of all CSP claims. To accomplish this, the government recommends agencies take the following steps:
- Review the CSP authorization package.
- Determine if the risk posture is acceptable.
- Determine if the CSP needs to meet additional requirements for agency mission/business needs.
- Approve the CSP package for authorization.
If an agency accepts the risk posture illustrated by a CSP’s security authorization package, the Agency Authorizing Official (AO) then issues an ATO letter—and sends the letter to the FedRAMP Program Management Office.
Post Authorization: It is important to note that while the CSP technically handles the security of agency systems within its cloud environment, the agency is still ultimately responsible for the protection of agency data. Based on that understanding, agencies must ensure the CSP continues to meet FedRAMP security requirements throughout the lifecycle of the systems in question.
Specifically, the government recommends the following: “Continuous monitoring of a cloud system includes monthly meetings between an agency and CSP to review a system’s high-level transaction reports, security scans, and updated POA&M [Plan of Action & Milestones]. Agencies should also assess CSPs annually, reviewing details about system changes and updates, and ensuring compliance with the originally accepted risk posture.”
FedRAMP vs FISMA Conclusion
In summary, FedRAMP and FISMA are separate initiatives that are closely tied by NIST 800-53A controls. The two have nearly identical goals: to protect federal government systems and data. Yet, with agencies implementing increasingly diverse environments, including a dramatic shift to cloud computing, it is equally important to ensure the security of data in the cloud as it is the security of data on-premises—and to do so with specific requirements relative to each environment.
Whether you use the cloud for Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS), SolarWinds products give you critical insight into your cloud-based computing, allowing you to isolate and address issues specific to private, public, and hybrid cloud implementations. Learn more here.