TIC 3.0: Great Work, but Not Zero Trust

DHS recently published version 3.0 of the Trusted Internet Connection (TIC) architecture. A response to changing IT conditions, Executive Orders, and OMB mandates, the new architecture seeks to support IT modernization through cloud adoption while keeping security as a top priority. The comprehensive set of documents includes an overview, a catalog of security capabilities, a reference architecture, guidance for pilot programs, advice for service providers, and a very helpful set of use cases relevant to agency needs. Moreover, it wisely urges the deployment of security measures throughout a network, rather than at any single chokepoint.

It’s a great piece of work, and a much-needed contribution to the world of government cloud computing and networking, and the primacy of security is clearly very welcome to security nerds like me. While some aspects of the security recommendations are loosely consistent with a zero-trust (ZT) architecture, the “trust zone” concept is squarely at odds with the ZT mindset.

The TIC 3.0 documents urge deployment of security capabilities throughout a network, putting them generally closer to the data and systems they protect. This approach makes sense and is commensurate with key principles of ZT networking. Moreover, the reference architecture and use cases show clearly where each capability should reside. Good work

However, the TIC 3.0 Reference Architecture proposes the use of “Trust Zones” (notice the “T” word. It gives an example of three zones, each with a different level of trust: High, Medium and Low. The documents aim for description over prescription (a great idea), so government agencies are free to create more trust levels, such as “Low”, “Somewhat Low”, “Medium”, “Somewhat High” and “High”.

However, the central concept of a “Trust Zone” is squarely at odds with ZT philosophy. One needn’t look beyond the name: in ZT networking, there is no such as a “trust zone”, which is why it is called “zero trust” in the first place. In a ZT network, all entities are untrustworthy until proven otherwise, and connections between them require validation before they can occur. Moreover, the TIC 3.0 examples state that a cloud service provider (CSP) is an example of a “High” or “Medium” trust zone.

The example also contradicts a fundamental concept in cloud security: the shared responsibility model. Simply storing information “in the cloud” does not make it secure, or available only to those you trust. If sensitive data is unencrypted, it is still vulnerable even if it is stored in a “High Trust Zone” cloud providers’ network.

The “Trust Zone” concept is clearly not commensurate with these zero-trust requirements. In fact, it more closely resembles the old on-premises concepts of an internal network (“high trust”), a DMZ (“medium trust”) and the Internet (“low trust”).

DHS has responded to this observation by touting the flexible and dynamic nature of the trust zones. Flexibility and dynamism are essential characteristics of the zones, and are also in tune with the requirements from the White House and OMB to promote modernization of government IT systems. However, DHS still calls them “trust zones”. “Trust” and “zero trust” just don’t go together.

Beyond the trust zone recommendation, consider the name of the initiative itself: “Trusted Internet Connection” (there’s that “T” word again). So, at the risk of excessive repetition, I’ll say it once more: nothing in a ZT network is “trusted” – especially the Internet connection.

DHS is doing fantastic work, and the TIC 3.0 recommendations are no exception. The intent of these comments is to be constructive and to enhance an already great piece of work. Recommendations of this nature, with a such an enormous scope, are tremendously difficult to produce, and I am personally very grateful for the dedication and expertise of DHS and CISA. I just would like them to revisit the “trust zone” aspect of TIC 3.0.