GSA / GSA/fedramp

Response to Acquisitions RFI Provided by CSRA

Open
#6 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
19
Forks
15
PR merge metrics
No merged PRs in 30d

Description

# Question/Comment on FedRamp RFI Directory
## Name and Affiliation
CSRA
Shaf Mohebbi, Business Development Senior Principal

## Cloud Services
Providing clear specifications and requirements around the usage of cloud services is an important way to improve the acquisition process. An example of this is providing AWS EC2 hours with specific instance types, required storage volume with storage type, database services with product type, size, storage size, backup, etc.

A negative example is using one Cloud service provider’s specifications and requesting a quote for another Cloud service provider’s services. The example that CSRA has seen was when AWS specifications were used to request a quote for Azure. Even though the services from the two Cloud service providers are similar, they are not the same, hence a one-to-one mapping is not always possible. An example of the lack of a one-to-one mapping is that the AWS EC2 instance type and the EBS storage type do not have direct correlation with Azure all the time. Azure instance types and storage types are different from AWS and the pricing also significantly varies. Unless specific requirements for Azure are written, the responding companies will have to ask several questions for clarification related to the specifications/requirements, leading to repeated amendments in solicitation.

## Cloud Security
Security requirements vary by agency. Some agencies require the service providers to be in compliance with FedRAMP, NIST requirements, and in addition, they do have specific requirements (e.g., FIPS 140-2 requirements for storage or additional data protection/encryption requirements). Sharing references and detailed requirements around security for storage (backup, archival), computing, networking, monitoring, SSL, key management (software-based or hardware-based) etc. is important.

A clear definition of security requirements for cloud environments (FedRAMP low to HIGH) and various FISMA data classification levels (low to sensitive) is very important for clarity. Decoupling of transport layers (if any/if needed) should be specified. In our experience, some agencies do not want workloads of different FISMA levels to be mixed (e.g., FISMA low traffic should not be mixed with FISMA high traffic and/or lower environment traffic should not mixed with production environment).

When a solicitation is issued, details around ATO requirements and process followed by the agency to obtain a cloud environment ATO and application ATO would help the vendors share their expertise, provide comprehensive response, and in turn help the agency understand and evaluate the proposal accordingly.

A positive security example was a requirement to use a central governance/deployment hub (cloud management platform (CMP) and cloud access security broker (CASB)) which is a trend that is consistent with hybrid and multi-cloud strategies. Combining this with either a PaaS or bespoke CI/CD capability, the agency was looking to develop shared services across all of their environments which is a good practice.

Further clarifying the GSA position on inheriting security FedRAMP accreditations would help define the boundaries for the agency, intermediaries like system integrators and the accredited Cloud Service Offering (CSO). The FedRAMP Rev 4 Baseline identifies 450 Controls and Enhancements for LOW/MODERATE Impact Levels which are tested during the FedRAMP Authorization Process but when establishing the Authority To Operate (ATO) the Shared and Customer Specific Controls ownership becomes convoluted.

## FedRAMP PMO
The following is a positive example of a federal agency showing understanding of the ATO process.
“Provide a detailed description of how the vendor will organize logical boundaries, define inheritance between layers of the cloud stack, and manage inherited/inheritable controls.”
This is a strong example because it addresses a number of issues with ATO boundary acceptance and is a key consideration for agency adoption in the risk acceptance process.

## Additional Question/Comment

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.