U.S. Department of Defense sets its cloud security guidelines
By Jodi Kohut
Those watching federal cloud security in the defense space were pleased to learn the Defense DOD Cloud Computing Security Requirements Guide (v1) (SRG) last month. This 152-page document outlines the security requirements that Department of Defense (DOD) mission owners must adhere to when procuring cloud-based services. While the document is very thorough and is required reading if you currently, or intend to provide, cloud-based services to the DOD, I wanted to cover some of the things that stood out to me.
CSPs are not compliant, but their offerings can be. The requirements guide makes it clear that there is a distinction between a Cloud Service Offering (CSO) and the Cloud Service Provider (CSP). A CSP can have multiple CSOs, all with different security postures.
This has always been the case. However, by making this distinction, DISA has reduced some areas of common confusion. This distinction should also make it clear that utilizing a compliant infrastructure as a service (IaaS) or platform as a service (PaaS) at a CSP does not make the resulting offering compliant. The CSO itself has to be fully evaluated for the Federal Risk and Authorization Management Program (FedRAMP) compliance.
Compliance responsibility is on the prime CSP. Expanding on the last point I made: Everything you put in a CSP environment is not automatically compliant. The SRG states that, “While the CSP’s overall service offering may be inheriting controls and compliance from a third party, the prime CSP is ultimately responsible for complete compliance” (p. 3). This language gives me the sense that if mission owners want to work with a federal integrator (prime contractor) to move an application to a FedRAMP-compliant or soon-to-be-FedRAMP-compliant platform or infrastructure — and that integrator will be performing Operations and Maintenance (O&M) — they will also be responsible for the compliance of the solution and the underpinning platform or infrastructure services from a commercial cloud service provider.
In essence, the solution enabler becomes the prime CSP. This is perhaps an important nuance that may have important ramifications for the integrator and those who provide what DISA dubs commercial cloud service providers. Keep in mind that the SRG also recognizes the existence of DOD-owned and operated CSPs.
FedRAMP + controls. Because DOD systems are categorized differently from other federal government systems, the SRG lists additional security controls and enhancements that are necessary to implement for DOD systems. These controls are over and above the FedRAMP moderate baseline, and as such are called, “plus” controls. The SRG has dealt with privacy and security requirements as “overlays” to all of the FedRAMP and FedRAMP plus baseline controls.
Expanded CSP roles and responsibilities. (Appendix C-1). The SRG denotes that it is the CSP’s responsibility to provide Computer Network Defense (CND) services (all tiers) for its infrastructure and service offerings. CSPs must be willing to provide their own CND services and to be able and willing to contract for more advanced security services as required by a mission owner. Here again, a prime CSP must be willing and able to provide complete compliance, including Computer Network Defense Service Provider (CNDSP) services.
A few takeaways
While this is not an adequate summary of the SRG, this long-awaited guide has provided some clarification around DOD’s expectations from Integrators, CSPs, and DOD mission owners. The DOD has clearly laid out for Integrators and CSPs the expectations for inclusion into the DISA Cloud Service Catalog. It will be interesting to see how and if the definition of a prime CSP evolves and how the industry and government alike adapt to that distinction.My initial reaction to the SRG is that it limits the playing field of prime CSPs that are able to comply with these requirements today. For small integrators trying to migrate applications to the cloud on behalf of the federal government, it makes the proposition riskier. For example, if small integrators move something to an Amazon Web Services or Microsoft IaaS solution, they are now responsible for the security of the application and that underlying environment. The way this is currently written, I believe that integrators will have to decide whether or not they will take the risk to take responsibility for the application and the underlying environment.
(This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit Tech Page One. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.)
Commentaires
Enregistrer un commentaire