Zero Trust vs. Acceptable Trust

Michael Rash Director, Security and Compliance Published 18 Nov 2021

The focus of my previous blog, “The Tension Between the Infinite Enterprise and Zero Trust,” explored two opposing forces: the need for security as envisioned under the Zero Trust banner versus the need for accessible, effortless, and expansive networking. In this blog, I will delve into another area of tension, but this time in the notion of trust itself. On what basis do we trust computing systems? For all possible answers to this question, what threat models present fundamental challenges to these answers?

zero acceptable trust text

If you consider the phrase zero trust, there is a sort of implied nihilistic rejection of the status quo in terms of the current security environment provided by most networks. There is ample evidence that the security status quo in society is crumbling when the announcement of the next big corporate hack or successful ransomware campaign seems always to be no more than two weeks in the future. This in turn, fuels a constant demand for more robust security. Zero Trust can provide a framework to accomplish this goal, but how to achieve it? Zero Trust implies that certain parts of the current security environment need to be eliminated or changed, but what is the extent and depth of this transformation? Further, if you consider the end game implementation of Zero Trust, is one ever really “done”? For any given network, deploying the main tenants of Zero Trust would certainly make it a hard(er) target to compromise. However, two words: supply chain.

No deep discussion on the concept of trust — zero, acceptable, or otherwise, in computing systems will be complete without reference to Ken Thompson’s classic 1984 Association for Computing Machinery (ACM) Turing Award Lecture “Reflections on Trusting Trust.” The innovation from this lecture was the introduction of a backdoor to allow root access via a target binary. By itself, this would not be notable as even trivial changes to source code can do this. What was different about Thompson’s technique was the target. Instead of backdooring source code directly, Thompson targeted the compiler so that it produced malicious versions of compiled binaries, as well as backdoored versions of itself. Recall that modern and not-so-modern C compilers are also written in C going back decades. The final result is a practically undetectable backdoor. It is worth quoting Thompson here:

“The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.” -Ken Thompson

Indeed. These words are as relevant to the security industry today as they were back in 1984.

Now, the vast majority of vendors will not knowingly build a backdoor into their products, so this is where the notion of acceptable trust comes into play. Vendors do not release source code to proprietary applications from the start, so source code inspection is not possible, even if users have the desire and the expertise. Given Thompson’s technique and the fact that the source code is not available, users have no choice but to place some faith in vendors to do the right thing. And the overwhelming majority do just that. In other words, it is acceptable to put some trust into vendor products since the alternative is we just shut everything down. Still, Zero Trust has a core requirement of monitoring, which helps to verify that vendor products are operating in a trustworthy manner. However, vendors themselves can be forced into including backdoors in their products without their knowledge. This simply raises the bar regarding the need for vendors to maintain secure Software Development Life Cycle (SDLC) processes and beyond. Stated differently, vendors today constitute a massive supply chain where users and consumers have no visibility behind the scenes into the security posture of devices, software, and processes.

Supply chain security is a categorically thorny problem. Two important examples of supply chain security gone wrong are the famous SolarWinds hack from 2020 and the Codecov compromise from early 2021. The SolarWinds incident caused a 40% decrease in SolarWinds’ stock price, affecting potentially as many as 18,000 customers. The SolarWinds event brought the issues involved in software supply chain security to the forefront of security risk discussions as never before.

The hack compromised the “Orion” network monitoring software built by SolarWinds to introduce backdoor access to any network where Orion was accessible from the Internet. The ultimate target of this compromise was not SolarWinds itself – the target was all of SolarWinds’ customers. The compromised software was distributed via routine software updates before it was caught. Given that network monitoring software must be usually deployed in a privileged position on the local network to properly function, the effects were quite severe. SolarWinds was a critical member of the software supply chain for every customer who purchased Orion. These customers were forced, unknowingly, into running malicious code with privileged access to their networks. It is hard to overstate the impact of this event and the need for vendors to continually strive to maintain the security of their products.

Another notable supply chain hack was the Codecov compromise from January 2021. Similar to the SolarWinds incident, the target was not the Codecov software itself but rather Codecov’s customers. An interesting knock-on effect from the Codecov hack was the exposure of a GNU Privacy Guard(GPG) software signing key from HashiCorp, one of Codecov’s customers. Signing keys are critical security components since they are used to authenticate products produced by vendors. A compromise of such keys allows attackers to forge malicious versions of products as if they are the original vendor. HashiCorp revoked the GPG signing key pair quickly after the compromise was discovered. However, the bottom line is that the software supply chain has weak points that can affect consumers with several levels of indirection.

Considering the above, is the attitude towards supply chain security still an “acceptable level of trust”? To what extent can Zero Trust principles minimize security risk associated with the supply chain? The SolarWinds hack was a prime example of a successful supply chain attack. But that’s just the tip of the iceberg. Even the strictest application of Zero Trust principles cannot solve the massive scope of lapses in supply chain security.

Now, just in case it seems like we are on a path to doom and gloom, there is some light at the end of the tunnel. The purpose of this blog is to help illustrate the need for awareness of pressing security problems. Looking past the marketing language around Zero Trust, it is important to understand what the real threats are. An important quote from an unknown author is perfectly illustrated by the graphic below. Future blogs, l will explore the application of Zero Trust to help address some of the concerns discussed in this blog.

Figure reference:


Get the latest stories sent straight to your inbox!

Related Stories