Part 2: FedRAMP, Inheritance and Key Controls
I am leading the FISMA project at Sonian, and we’re getting closer to achieving our first FISMA Moderate accreditation. For background on FISMA, read my first blog post on this subject.
With FISMA Moderate accreditation, Sonian will be able to manage non-defense government data. The accreditation is granted in the form of an “Authority to Operate (ATO)” bestowed upon a project by the government agency that will implement and utilize the product/service. A cyber security team within the government agency evaluates each project’s security documentation and gives the thumbs up or thumbs down. It’s an iterative process, that starts with extensive documentation, and audit, and government review and oversight. FISMA applies to both third party services purchased by the government, as well as internally developed and managed IT projects.
FedRAMP… Briefly
Currently, if a vendor wants to sell the same IT service to more than one government agency, FISMA requires an ATO from each agency, which adds time, complexity and cost to the procurement process. Historically, each agency has implemented and interpreted FISMA standards differently. The National Institute of Standards and Technology (NIST) devised the “FISMA Reference Architecture” for all agencies to follow, but in reality the local interpretation has varied. A “new and improved” accreditation standard is supposed to fix some of these issues. FedRAMP is a single umbrella guideline encompassing current FISMA rules, as well as updated rules that better align FISMA with technologies such as Software as a Service (SaaS) and cloud computing. When the legislation that created FISMA was drafted in 2002, SaaS and cloud computing were not on government technologist’s radar. FedRAMP is a modernization of FISMA, and also strives to streamline government IT purchasing, lower costs, and expedite project time lines. FedRAMP will benefit from FISMA’s first decade, so I am hopeful for an improved certification process when FedRAMP is officially ratified in about a year. There is already quite a bit known about FedRAMP and Sonian is working on a dual strategy to get FISMA Moderate for one agency, and then focus on FedRAMP for all other agencies.
Responsibility Inheritance
FISMA wasn’t designed for an Information Technology world hurtling toward SaaS and cloud computing. Since Sonian is software as a service powered by the cloud, there is a lot of new ground to cover when describing a system that has the concept of inheritance between the cloud provider and the software application layer. In our case, Amazon Web Services (AWS) is the cloud provider, and Sonian is the application layer. The first milestone in the FISMA project was to establish the system boundaries between the cloud provider and the application. There wasn’t much prior art to reference when establishing the boundaries, since Amazon and Sonian are charting new territory together while jointly pursuing a cloud-focused FISMA Moderate ATO. As an aside, it’s exciting to be part of a transformational shift in government IT, even if the major category means becoming compliant with a set of government-imposed rules. What Amazon and Sonian are doing will pave the way for other cloud and SaaS providers to make their services available to the government, with the ultimate goal and accomplishment making most efficient use of tax payer funds.
Sonian inherits all of Amazon’s controls for physical hardware, media management, data center operations, and all the other aspects of a cloud infrastructure that is a general support system for SaaS applications. Sonian’s responsibilities began at the OS layer right above the hypervisor. Sonian must prove that the application is not vulnerable to malicious (or accidental) intent, or allow any security holes that can compromise the system’s integrity. In many cases the Sonian documentation will refer to a section in Amazon’s documents, and in turn, Amazon’s documents refer to the application layer’s documents for information on how a specific security issue is managed. A good example is multi-factor authentication (MFA). FISMA Moderate requires a MFA authentication to sensitive control panels. Amazon provides MFA support for the AWS Console, but it’s up to the AWS customer to document and prove MFA is used where required. With the cloud, full system integrity is only as good as the weakest layer in a full cloud stack (physical, virtual and up into the application.)
Key Controls
A FISMA Moderate Authority to Operate (ATO) is granted when a government cyber security team reviews over 400 controls, ranging from policies encompassing employee training & criminal background checks to certifying the cryptography strength used to secure government data. Literally no stone goes un-turned in the documentation and review process.
The System Security Plan (SSP) is the main work product produced during the accreditation process. Some SSP’s can be thousands of pages for a FISMA Moderate review. A full package includes the System Security Plan and a dozen supporting documents covering all aspects of IT best practices. Some of these artifacts resemble ITL documentation, which non-government IT departments have embraced slowly over the past decade.
Within the 400 controls, there are 40 “key controls” that cover the most important security concerns. The key controls touch the twelve control families in some fashion, so it’s a good way to start a FISMA project by focusing on the key controls first, and then complete the remaining 360 second. The key controls will identify any glaring errors or gaps that need to be filled prior to the ATO grant. For FISMA newbies, starting with the key controls is an on-ramp to FISMA immersion without getting overwhelmed by the project’s enormous scope.
