Prepping for FedRAMP – 5 Things CSPs to Note
Originally published on www.fedrampfastforward.com
BrightLine works with many cloud service providers (CSPs) which have built successful business by providing services to the private sector. With the growth, not to mention CloudFirst mandate, many of these CSPs are taking a much closer look at the potential to work with the Federal government. Today, part of the price of entry is compliance with the Federal Risk and Authorization Management Program (FedRAMP).
Some of the similarities between FedRAMP and other programs have been discussed in previous posts, such as comparisons with PCI, and an overview on the program can be found at https://www.fedramp.gov. However, one question we are continually receiving is what the biggest pain points are for CSPs that are beginning to consider FedRAMP. Based on the assessments the team has delivered, and many discussions with CSPs early in their evaluation stages, below are 5 key areas to understand when kicking off a FedRAMP initiative. The first three are related to the initial planning and scope, while the last two focus on some of the more frequent findings and/or pain points on specific controls.
1. Prep Work and the System Security Plan (SSP)
Like an ISO, PCI DSS or other assessment, a CSP will need documentation pertaining to the policies, procedures, configurations, etc. However, unlike most other assessment frameworks, FedRAMP requires the CSP to actually complete a comprehensive narrative for each control before the assessment begins. This first major step of the FedRAMP process is to complete the System Security Plan (SSP). The SSP must be completed by the CSP intending to apply for a provisional Authorization. The goal of this document is to document the controls and the implementations related to the CSP’s offering. The effort to complete this document varies by organization, however CSPs should assume this document will take no less than three (3) months to complete, specifically for an organization that has a mature governance, risk and compliance (GRC) program. Any what many CSPs get pushback for is that it is not enough to simply restate the control – “yes we have a firewall” it is necessary to describe in detail, how the control meets one of the 360+ NIST control requirements. Last, any CSP considering FedRAMP should consider taking the free training around both the program and the SSP. The training is informative, yet concise. Further details can be found at https://www.fedramp.gov/resources/training/.
2. The Boundary
How a CSP delivers services specifically for federal customers can vary greatly. FedRAMP uses the term system boundaries to describe the in-scope environment. Some CSPs will setup specific environments specifically for federal customers, which will be the boundary, while other CSPs use the existing infrastructure that is in place for the private sector and try to make sure the entire environment meets FedRAMP. FedRAMP takes into consideration the entire in scope application, platform, and infrastructure, which includes components that may be considered out of scope with other assessment frameworks. For that reason being able to articulate where the system boundary starts, stops, and what types of dependent interconnections are in place is critical.
3. Internal System Connections
When CSPs establish their system boundary there is also the consideration of how internal systems connect to the cloud environment. Security Assessment and Authorization (CA) control number nine (CA-9) was newly added when FedRAMP Version 4 controls were published. Many CSPs assume the boundary is the extent of the assessment, but depending on how administrators, employees and third parties access the cloud environment, desktops, laptops and other mobile devices may be brought into scope.
4. Vulnerability Scanning
Within internal threat and vulnerability management programs NIST 800-53 revision 4 Risk Assessment Control #5 (known simply as RA-5) is becoming as well-known as PCI’s 11.2. CSPs are typically aware of the FedRAMP vulnerability scanning requirements, which are formally documented, but the implemented controls related to RA-5 are often not meeting expectations. The reasoning fora finding is typically from one of the following heard responses:
- “We’re progressing with an Agency Authorization, which is different than JAB”: It is not uncommon to hear CSPs consider the requirements posted are specifically for joint authorization board (JAB) authorization and may not be applicable to those going through an agency authorization or CSP supplied authorization. A CSP’s mileage may vary depending on their agency, but the requirements do not change based on FedRAMP route.
- “We perform unauthenticated scanning, but it is more frequent than the standard”: While the latest version of the Security Assessment Report (SAR) does have a section for unauthenticated scan reports, the requirement is still for monthly, authenticated scans. A CSP not performing authenticated scans will likely have high risk findings relating to several controls in addition to RA-5.
- “Our databases are scanned during the infrastructure scans”: The infrastructure vulnerability scans cover the operating system supporting a database and will frequently discover missing security patches for a database; however, the infrastructure scans will not detect file system permissions, table specific settings, audit and logging, etc. These other items need to be detected with authenticated database scans.
All of the CSPs we have seen implement cryptography to protect date at rest and in transit; however, many are not meeting the requirements expected by a federal agency, in particular using cryptography in line with Federal Information Processing Standard 140-2 (FIPS 140-2). The main control this affects is SC-12, but indirectly it may affect several others. More often than not, we see cryptographic settings configured to include encryption allowed by FIPS 140-2, but the configuration also supports connectivity from non FIPS 140-2 technologies.
The above are five of the more relevant things a CSP can consider when gearing up for FedRAMP. On final item to consider is how the project will be managed. Many CSPs may have never worked closely with the Federal government and may not be accustomed to some of the nuances. For example, some assessment frameworks more or less require a clean report to pass. With FedRAMP, an authorization can be granted to an organization with findings, but that organization must have a plan of action and milestones (POA&M) documented that addresses these findings. This requires project management, beit a dedicated public sector team or some carved out section of an otherwise formal program management office. Certainly, CSP teams that have members that have worked with certification and accreditation (C&A) programs, the Federal Information Security Management Act (FISMA) and other public sector assessments frameworks often will have an easier time getting the FedRAMP project started, keeping it moving forward and working with their sponsoring agency or the JAB.
About MATT WILGUS
Matt Wilgus is a Principal at Schellman, where he heads the delivery of Schellman’s penetration testing services related to FedRAMP and PCI assessments, as well as other regulatory and compliance programs. Matt has over 20 years’ experience in information security, with a focus on identifying, exploiting and remediating vulnerabilities. In addition, he has vast experience enhancing client security programs while effectively meeting compliance requirements. Matt has a strong background in network and application penetration testing, although over the past 10 years most of his focus has been on the application side, with extensive experience testing some of the most well-known IaaS, PaaS and SaaS providers.