Home  /  Empower and Protect  /  Reciprocity: The Good, The Bad and The Ugly

Reciprocity: The Good, The Bad and The Ugly

By Gianna Price •  August 22, 2019

There is a lot of buzz around the Defense Information Systems Agency’s recent announcement that permits DoD mission partners and service components to host DoD Impact Level 2 data in FedRAMP-authorized (Moderate Baseline) cloud environments without waiting for an explicit DoD-written authorization.

Is this is a good thing? Sure.

Is this a bad thing? Maybe.

Will things get ugly?  They normally do when you are talking about protecting DoD “publicly releasable information” these days.  Just ask Ms. Katie Arrington, the special assistant for cyber in the Office of the Assistant Secretary of Defense for Acquisition, who is currently on a CMMC roadshow in effort to secure the Defense Industrial Base.

In its current form, FedRAMP is too operationally focused to support reciprocity. If the community wants reciprocity, we are going to have to go back to the days of type authorizations, or find something similar.  Under a proper type authorization, the technology itself is thoroughly assessed independent of its physical or organizational environment.  Installation and configuration guidelines accompany the type, providing consuming organizations deployment options based on their operational need.  Hardening guidelines are evaluated for completeness and security rigor. This approach ensures systems are not over- or under-secured; in addition, it often facilitates needed dialogue between stakeholders.

We hear a lot about reciprocity these days, but it has been years since I have heard anyone pursuing a type authorization.  Siding with the compliance folks on this one, most compliance teams stopped accepting types because system owners failed to provide the hardening guides.  If you ask any CISSP how to secure a system, they will tell you that system security covers several domains.  Implementing the associated security controls across these domains takes the form of technical configuration, administrative policies and procedures, and agreements that can reside at the system, mission and/or organizational level.

Dynamics That Reflect an Identity Crisis

These dynamics reflect the fact that the risk management and compliance community is going through something of an identity crisis.  On one side, we are preaching “Cloud First” and reciprocity: “It will make sense once we get there!”  Then we have governance organizations, such as NIST, likely beating their heads against a wall trying to rephrase the same expectations they have been preaching for 10+ years.  Joining the conversation are the privacy teams (do those exist yet?).  Lastly, industry is being hectored to substantiate how they protect government information when many agencies themselves struggle to articulate how they meet their own security requirements.

The identity crisis we are facing in compliance is not new to the security community.  We are constantly challenged with balancing free and open disclosure and collaboration with security, privacy, and mission.  Which poses a conundrum: what does the government want from industry?  At one point it looked as if industry should put all its eggs in the FedRAMP basket so its solutions can be leveraged across other agencies.  Simultaneously there are RFIs for how to revamp the FedRAMP process itself.  On top of all of this we have the DFARS requirement to implement NIST 800-171 for Controlled Unclassified Information and finally the soon-to-be CMMC requirement for anyone wanting to work with DoD.

Mercy!

Plotting a New Path to Reciprocity

Given that reciprocity is supposed to lead to more consistently sound security postures – as well as simplify life for community professionals – one would hope it would help untangle this web of often contradictory or conflicting dynamics.  So that takes us back to our original questions about reciprocity…

Is this a good thing?  Absolutely! If done properly.  Traditional type authorization may or may not be the final solution.  However, if we can (1) isolate the technology, (2) validate its inherent security and supply chain, and (3) leave the application of organizational and mission common control infrastructure to the deploying organization, we are headed toward increased solution adoption as well as reduced cost and frustration.

Is this a bad thing?  It doesn’t have to be. As mentioned previously, FedRAMP is not currently structured for reciprocity.  In addition, the management of mission impact in DoD exceeds the contexts of a FIPS 199. As long as there is a clear understanding and deliberate integration of how the technology – validated by FedRAMP – sits within the command’s view of the NIST Cybersecurity Framework, the end result could be positive.

Will things get ugly? I hope not.  The reciprocity “easy button” is a popular choice, and is very attractive with the external pressures to improve.  I would posit that if you are in a leadership position and do not know your CSF Tier, you are probably not ready to take advantage of reciprocity from a FedRAMP-certified system or any other security-attested system.  But – if you’re confident that your Tier is based on measured success and you have established common control frameworks to increase security where the technology can’t, then you are ready to leverage the benefits that can come from reciprocity.

Gianna Price

Gianna Price

Gianna Price is an Xacta® solutions architect, cybersecurity subject matter expert, and compliance specialist with Telos Corporation. See full bio...

The Empower and Protect Blog brings you cybersecurity and information technology insights from top industry experts at Telos.

Leave a Reply

Your email address will not be published.

11 − eleven =