If security and usability represent opposing forces, how strong is the tension between the Infinite Enterprise and Zero Trust (ZT)? On its face, it's safe to say, "incalculably high," and mathematicians might represent this as infinity divided by zero, which is undefined.

In the real world, networks have become more distributed over time and have brought along attendant questions around security. As a result, highly distributed networks and applications do not make security any easier. With the onset of the pandemic a year and a half ago, the whole world was thrust into a new operating environment dubbed by Extreme Networks as the "Infinite Enterprise" In essence, thousands of enterprise entities that would never have considered remote work for the vast majority of their employees were all of a sudden forced into doing just that. Talk about a massive sea change. At the same time, the need for network, application, and system security has never been higher. A set of organizing principles for a more robust security model uses the catchy phrase, Zero Trust. After cutting through the marketing fluff, there is no question that core principles of zero trust and the three tenets of the Infinite Enterprise are relevant to systems and networks the world over.

However, we all know that security and usability are often opposed to each other. So, should the Infinite Enterprise and Zero Trust be considered as polar opposites? There will inevitably be trade-offs to choose along one dimension or the other - either favoring the Infinite Enterprise with better usability or conversely leaning toward stronger security. Are they mutually exclusive? We certainly hope not if, as an industry, we're going to achieve an enforceable security stance. In this and future blog posts, I will explore the intersection between these opposing forces and discuss some cohesive properties that result from a careful examination of the possibilities.

But first, I will dive into a few motivating questions around Zero Trust and modern networking to set the stage for what is yet to come.

Zero Trust Starting Points

What is the "correct" generally accepted definition of Zero Trust in the industry today? With so much marketing material flying around, it can be difficult to see the forest for the trees. NIST has produced NIST Special Publication 800-207 "Zero Trust Architecture." Google has also been a leader in this space for a long time with the Beyond Corp initiative. Many smaller businesses focus on specific aspects of ZT since providing the entire range of ZT solutions is not usually practical for such entities. The Tenets of Zero Trust section within the NIST publication represents a high-level gold standard for Zero Trust requirements today. Once again, I promise a deeper dive with my future blog posts.

Existing Protocols and Zero Trust Force-Fitting

To what extent is every byte and protocol on the wire authenticated, and between which devices? There are many examples of critical protocols for which there is little or no authentication (DNS, BGP, DHCP, ARP, etc.), but where do we draw the line and for which types of systems? For protocols where secure alternatives exist, for example, DNS over HTTPS (DoH), do we mandate their implementation?

Zero Trust vs. Network Scanning

Should any services be advertised for a non-participating system to see via network scanning for systems that participate in Zero Trust? Secure Shell (SSH) is a secure protocol, but every SSH implementation has the occasional security vulnerability, and there is no end in sight for future vulnerabilities. Should it be possible for unauthenticated systems to scan for SSH daemons in a Zero Trust world? If not, does this imply something about the need for mandatory deployment of access control lists (ACLs), firewalls, and network micro-segmentation architectures? Furthermore, are we just looking at the problem from the perspective of SSH, which receives a ton of scrutiny from the security community? Sadly, many other services that do not receive nearly as much attention from competent security developers. The one truism that always stands up to the test of time, is that enterprise networks are running services and networked clients with vulnerabilities in them right now - full stop. It doesn't matter whether we're talking about a web application, the latest release of the Chrome browser, OpenSSH, or even the use of Link Layer Discovery Protocol (LLDP).

Natural Protocols for Zero Trust

Some Zero Trust architectures build around the notion of a controller that offers a service over Transport Layer Security (TLS), otherwise known as Mutual Transport Layer Security (mTLS). While mTLS offers functional authentication properties, the controller can be scanned by unauthenticated adversaries if the transport layer protocol is TCP-based. Zero Trust principles rightly question whether this is desirable. Or, at least, if a controller is necessary to achieve Zero Trust, then can the controller leverage protocols that cannot be trivially identified through active scanning? We believe the answer is a resounding YES! The formally verified Wireguard VPN is an excellent example of such a protocol. A protocol that never answers unauthenticated traffic of any kind stops the exploit kill chain at the earliest phase possible - target identification. For an adversary that has already gained a foothold in an organization, the chief task for the security defenders is to contain the damage, which requires limiting the possibilities for lateral movement. Making target identification as hard as possible assists with this goal.

Which Threats?

A lot of material exists about the benefits of Zero Trust, but what specific threats do we expect ZT to mitigate effectively? For example, ransomware is a massive problem and a scourge upon society. Do we expect Zero Trust to make a serious dent in ransomware exploitation if widely deployed? Assessing exploitability for a vulnerability is not easy, and there is an entire underground industry around reselling reliable exploits via exploit kits. Does Zero Trust give us an "offramp" for certain classes of vulnerabilities that are widely exploited via exploit kits - effectively make them obsolete? Most likely not, but it is worth diving into this question.

Supply Chain Security and Shifting Sand

What is the relation between Zero Trust and supply chain security? The supply chain is arguably the most critical foundational component of any computing system. The best Zero Trust implementation in the world is meaningless if physical devices are compromised way back in the manufacturing stage. These compromises can take the form of hardware hacks and software compromises as in the case of the SolarWinds attack. Building a house on shifting sand is not the best idea, and supply chain security is the elephant in the security room for the entire industry. Zero Trust may help to limit the damage of a supply chain compromise, but the sky is the limit in terms of what is possible from the attacker's point of view with a supply chain that is untrustworthy. If the supply chain is implicitly trusted, is Zero Trust even achievable? This is an important topic for a future blog post.

Zero Trust as an Enabler?

Can Zero Trust function as an enabler instead of an impediment for the Infinite Enterprise and distributed workforces? Once it becomes clear that security is of paramount importance and Zero Trust provides a set of organizing principles, the goal should be to adopt these principles iteratively over time. IT Operations has had the most significant fire drill of all time, with the pandemic forcing the corporate network edge into people's private homes worldwide. The Infinite Enterprise has worked. However, it is safe to say that a ZT strategy should be well thought out and not implemented haphazardly.

In future blog posts, I will explore how ZT can enable a secure computing stance for all users while at the same time powering the Infinite Enterprise. In the meantime, please take a moment to watch this short video where I discuss Zero Trust and the Infinite Enterprise:

Attachments

  • Original document
  • Permalink

Disclaimer

Extreme Networks Inc. published this content on 23 September 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 23 September 2021 13:21:04 UTC.