1/26/2022

Zero Trust - an architecture, a product or a mindset?

Author: Cole Kennedy

image that shows the zero trust logo
Over the past two or three years, the cybersecurity industry has been awash in articles touting Zero Trust Architecture and product announcements that purport to implement it. Acknowledging the demise of a definable perimeter is a very positive trend; opening corporate networks up to mobile devices, the ubiquitousness of IoT devices and the normalization of remote work palpably shred the paradigm of internal vs. external access, of firewalls and single sign-on. But a clear and common definition of Zero Trust remains elusive.

The Origins of Zero Trust

The term Zero Trust (ZT) is actually over a decade old. It was first popularized by Forrester analyst John Kindervag in 2010 in a briefing called Build Security Into Your Network’s DNA: The Zero Trust Network Architecture. Kindervag’s stated goal was to “look at everything from a data-centric perspective, [to] design networks from the inside out and make them more efficient, more elegant, simpler, and more cost-effective.”
Laudable, but still abstract.
A more actionable definition comes from Gilman and Barth in Zero Trust Networks: Building Secure Systems in Untrusted Networks:
  1. The network is always assumed to be hostile
  2. External and internal threats exist on the network at all times
  3. Network locality is not sufficient for deciding trust in a network
  4. Every device, user and network flow is authenticated and authorized
  5. Policies must be dynamic and calculated from as many data sources as possible

Zero Trust in the IT Marketplace

Initially, ZT was viewed as highly disruptive - by definition ZT redefined enterprise network security from the inside out. The cybersecurity industry began by trying to reposition existing technologies to minimize disruption. The best example lies in VPNs (Virtual Private Networks), letting external users and client devices tunnel into corporate networks, bypassing perimeter defenses while leaving the perimeter itself intact.
After a handful of very visible security hacks involving this technology, the VPN became a strawman for vendors wanting to show their ZT creds and leverage ZT as a differentiator. They began to embrace ZT in earnest, primarily by focusing on different aspects of and methods for authentication. But authentication is just one piece of the ZT puzzle. Moreover, authentication of connections and access to resources increases network complexity, for users, devices and applications. And by itself, it’s still not enough to secure the modern corporate network.
In fact, there is no one set of technologies or a single solution that implements Zero Trust. That’s because Zero Trust is not so much about one or more technologies but instead best viewed as a mindset, an approach to securing networks and the resources (machines, data and applications) that users access over it.

The Zero Trust Mindset

So, if Zero Trust is not a technology and is not embodied in a single solution, what is it? Here at TestifySec, Zero Trust is both a mindset - an approach, a design philosophy - and a business ethos and best practices.
As I’ve highlighted in other blogs and presentations, there are actually four elements to Zero Trust that we incorporate into our design practice and that are forming the foundation for upcoming products:
  • Public Key Infrastructure: every part of ZT services and products depends on PKI cryptography: VPNs, secure connections, authentication, encrypted storage and more. You can’t establish any form of trust without strong encryption and reliable key exchange.
  • Automated Governance: (a.k.a. Policy as Code): given the added complexity that comes with Zero Trust, there is no way to implement and maintain a Zero Trust architecture without automating policy and configuration - humans simply aren’t up to the task. Moreover, defining organizational policy as code is essential to smooth and agile DevSecOps transformation.
  • Supply Chain Security: recent breaches and other attacks highlight the technology supply chain as a key attack surface, and one that falls well outside traditional perimeter security. Supply Chain security spans issues of included backdoors, vulnerabilities, version deprecation and verifiable provenance of code and equipment.
  • Cloud-Native Security: perimeter and endpoint security cannot simply be scaled or extended into the cloud; the distributed nature of cloud infrastructure and application architecture demand a clear vision for security built specifically for cloud deployment. Containerization and cloud orchestration with Kubernetes and other cloud native technologies require out-of-band methods to secure workloads and data.
Building upon this mindset, TestifySec is delivering custom ZT solutions to organizations in enterprise, federal government and national defense, as well as contributing to key open source projects at CNCF (and beyond). Stay tuned for announcements of COTS products and packaged services to help your organization operate more securely in today’s Zero Trust world.