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.
Information Systems Agency (DISA) released
the
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.)
(
Thank you. If you enjoyed this article,
get free updates by email or RSS - © Copyright Kevin L. Jackson 2012)