Do we trust Zero-Trust?
or NOT ?!
Hi everyone, 👋
In our next column of the ‘To Do or Not To Do’ series, we look to understand whether organizations should implement and trust Zero Trust architecture? Zero Trust is one of the most widely used security concepts, yet ironically, one of the least understood ones. Hopefully, through this column, you will have a good understanding of the Zero Trust concept, why it was created, what it takes to implement Zero Trust, and whether it’s right for you.
The current state of cyber attack
Cloud adoption has lowered the barrier to building new software. On the flip side, it has given rise to new attack vectors that hackers can use to exploit infrastructure vulnerabilities. This is a story best told in numbers:
Globally, 30,000 websites are hacked daily
64% of companies worldwide have experienced at least one form of a cyber attack
There were 22 billion breached records in 2021
In 2021, ransomware cases grew by 92.7%
Every 39 seconds, there is a new attack somewhere on the web.
Traditional security practices aren’t sufficient anymore, and the world is realizing we need more sophisticated mechanisms to prevent cyber attacks.
Coming from the world of traditional security, we're all too familiar with the concept of perimeter-based security. You can access specific resources when connected to a corporate LAN, and you've been verified as trusted. The problem is that this type of security model relies on trust—and while it's great for keeping people in, it's not so great for keeping them out.
But what if the default security posture of an organization was NOT to trust anyone? Enter zero trust architecture (ZTA). The main concept behind zero trust is "never trust, always verify.” This means that no device and no user is trusted by default, even if they are connected to a permissions network such as a corporate LAN or even if they were previously verified.
The Zero Trust model revolves around three core principles:
Never Trust, Always Verify
Always authenticate and authorize based on all available data points, including user identity, location, device health, service, and anomalies.
Principle of least privileged access
Limit user access with just-in-time and just-enough-access (JIT/JEA).
Always assume breach
Verify end-to-end encryption and use analytics to get visibility, drive threat detection, segment access and improve defenses.
Great, so how do I implement Zero-Trust?
I wanted to do a little research on Zero Trust implementation to see the existing literature out there, and I started questioning if the whole thing is just an SEO term being pushed by big tech. On searching ‘Zero Trust’ on the ever-reliable Google, over 30% of results on page 1 and over 40% of results on page 2 were sponsored websites by large security companies.
The strange thing about Zero Trust is that every company has a different interpretation and implementation of it. So we thought it’s best to look at Zero-Trust from first principles and understand why it was created in the first place.
The right question: Why was Zero Trust created?
In the early 90s, the internet started gaining adoption, and that unlocked new modes of sharing information across the world. But this came with a new level of risk that couldn’t be eliminated by cryptographic methods, the foundation of our security stack. As more and more information was being shared through the internet, we were forced to rethink our approach to trust.
That's what Stephen Paul Marsh did in his doctoral thesis at the University of Stirling in April 1994, and he coined the word ‘Zero Trust’ to rethink computer security. Marsh's work studied trust as something finite that can be described mathematically—that it transcends human factors such as morality, ethics, lawfulness, justice, and judgment. Marsh proposed a security model where all users, devices, and networks are treated as untrusted and treated with the same level of scrutiny. The core idea of Marsh’s thesis was to “never trust - always verify.”
In 2009, Google implemented a zero-trust architecture referred to as BeyondCorp. It started as an internal Google initiative to enable every employee to work from untrusted networks without the use of a VPN. BeyondCorp shifts access decisions from the network perimeter to individual users and devices, thereby enabling employees to work securely from any location.
In recent years, the rise of cloud computing, remote work adoption, and the increase in mobile devices have made it difficult to maintain a perimeter-based security model. Zero Trust is seen as a response to this new reality, as the traditional security perimeter has become more and more porous. This has been the reason for zero trust gaining popularity in recent years.
Understanding Zero Trust implementation at Bird-App through the lens of Rahul Ligma
Now that we have established why Zero Trust is becoming more and more important for organizations let’s actually try to understand the ‘how’ of it more deeply. Let’s first take a look at all the components that are included in a Zero Trust architecture:
Zero Trust Components
We think the best way to understand Zero Trust implementation is to see how the above components fit into an organization’s infrastructure set-up and how they impact the employees. We chose Bird-App and its most real (NOT!) employee Rahul Ligma for this.
For readers who need a bit more context, here is a little help:
As a part of this section, we’ll dive into the Zero Trust components and map them to Bird-App’s set-up as well as how they impact Rahul.
PS: The below story is a fictional representation and as true as Rahul’s employment
Rahul’s first day at Bird-App!
Rahul’s first day at Bird-app is going fantastic, and he sees the HR and IT Manager for onboarding!
Bird-App maintains its employee directory in Okta for SSO and uses two-factor Authentication (MFA) for access. The company also uses Certn for the background verification of each employee.
Rahul completes his background verification on Certn, which requires him to provide proof of identity using a government-issued ID. User (Identity, Authentication)
Rahul receives a managed device with certificates installed to verify device identity and compliance. Device (System of Record)
After verification is successfully cleared, the IT manager adds Rahul to Okta’s user directory, and he gets a digital identity for authenticating himself inside Bird-App. User (Authentication)
Rahul needs infrastructure access to push code!
Bird-App’s infrastructure set-up consists of Kubernetes clusters, VMs, and Databases - all hosted on the cloud. The company’s infrastructure resources are all protected by IAM and Microsegmentation.
Microsegmentation is isolating workloads in a network in order to limit the effect of malicious lateral movement. It is either Agent-based (built into the host), Network-based (SDN, VPN, switches), or Native cloud-provided (Security group, Azure firewall, Google cloud firewalls).
Bird-App has set up a VPN as an access proxy that requires a certificate to access the microsegmentation, and IAM resides in AWS.
The star that Rahul is, he puts on some LoFi music and starts writing code. Now he needs access to staging RDS to test his application before he can create a pull request on GitHub. This is what Rahul’s infrastructure access journey looks like:
Rahul uses the client certificates installed in his laptop to connect to the network segment via VPN as an access proxy. Network (Microsegmentation)
Rahul needs to first authenticate himself either via static credentials or SSO using a two-factor authentication system from his company laptop. User (Authentication)
Once Rahul’s identity are verified, the IAM checks whether Rahul’s device has read-write permissions to the staging DB or not, and accordingly grants access for testing. Device (System of Record), Infrastructure (Least Privilege)
Once the testing is done, Rahul logs into GitHub via SSO, creates a pull-request and waits for the approval from his team lead for the code to be reviewed and deployed. Application (Authorization)
Rahul is a star, becomes a team lead! In charge of access and compliance now.
Rahul has an exceptional year at Bird-app and becomes a team lead! Rahul has new responsibilities to manage infrastructure access, security and compliance processes at Bird-App.
The company uses Splunk as a Security Information and Event Management platform (SIEM) to observe user behaviour by logging all real time communication between Zero Trust components and actors. In order to ensure compliance:
Rahul makes sure all customer data is isolated and encrypted at both transit and rest. Data (Encryption)
Rahul ensures infrastructure audit logs are in place to understand exactly “Who did What” and are being sent to SIEM so that alerts can be built on them. Visibility & Analytics (User behavior)
Rahul creates explicit policies so that no team member can write to production DB. User needs to obtain special break-glass privileges during an incident in order to override the policy. Infrastructure (Authorization)
Bird-App gets acquired, and Rahul is let go.
Well we all knew from the beginning how this was going to end, so Rahul being let go from the Bird App is hardly a surprise for anyone (except for Rahul maybe).
HR updates their records to indicate Rahul is no longer an employee at Bird-App. Before Rahul is off-boarded, the resources owned by him are transferred to another team lead. Eventually, Rahul is removed from Okta’s user directory.
Rahul no longer has access to Bird-App’s infrastructure resources. User, Infrastructure
Rahul returns his laptop to the HR. Device
Finally Rahul collects his box of things and exits the premises as seen in the iconic pic below:
Cost of Zero Trust, is it really worth it for your organization?
Now that we understand that Zero Trust improves the security posture of an organization, let’s also take a more pragmatic look to understand if it’s right for you.
A zero-trust policy affects nearly everyone in an organization, so all leaders, managers, and developers need to buy into this approach. Getting an alignment like this, especially at a large organization, takes months, if not years, and that doesn’t even account for the implementation timeline. BeyondCorp, for example, took years to implement at Google.
Even today, there is no off-the-shelf tool/service that can transition you to a zero-trust architecture overnight and do it for all of your network/applications. Moreover, threats on the internet keep evolving, making security an ongoing investment. So committing to a Zero Trust philosophy is not just a one-time process, but a mindset that requires continuous investment in resources, training, implementation, and maintenance.
If your business is young and a breach will have a low impact, you probably don’t need a full-blown zero-trust implementation just as yet. You could just start with a couple of basic good practices like making sure the network's use is always verified, and no-one has more privileges than required.
The need for Zero-Trust in the new world
Organizations have been talking about Zero Trust since the early 2000s, so why is it suddenly getting so popular? Well, the simple answer is that we live in a new world, especially after covid-19. There are a few trends that are being unfolded in real-time:
Sensitive Geopolitical situation
The Great Resignation 2021, followed by the market crash of 2022, creates a transient workforce
Generative AI creates a new identity impersonation problem
Sensitive Geopolitical situation
The world is in an extremely delicate place right now as global tensions are at an all-time high. While physical wars are still being fought today, it is common knowledge that the war of the future is going to be through cyber attacks.
In order to tackle this, private and public companies need to improve their security posture proactively.
The Great Resignation of 2021 followed by the great market crash of 2022 creates a transient workforce
According to the U.S. Bureau of Labor Statistics, over 47 million Americans voluntarily quit their jobs in 2021 — an unprecedented mass exit from the workforce that is now widely being called the Great Resignation. This has been followed by the market crash in 2022, that led to mass layoffs in the tech industry - Twitter, Meta, Stripe, and many more!
Workforce today is more transient than ever, which can lead to ex-employees still having residual infrastructure access if keys and credentials are not actively updated.
Generative AI creates a new identity impersonation problem
We have all seen first hand how far generative AI has come in the last few months. There is very little doubt that the technology is going to be great for the world. However, it also brings a unique set of challenges. With generative AI, bots can finally pass the Turing Test, originally called the imitation game by Alan Turing in 1950. For folks that need a refresher, this is a test of a machine's ability to exhibit intelligent behaviour equivalent to, or indistinguishable from, that of a human. As bots get smarter, there is a risk that they can impersonate employees making organizations more susceptible to intelligent phishing attacks.
This culmination of the above trends leaves no choice for organizations but not to ‘trust’ anyone and always ‘verify’ their identity, aka Zero Trust! The realm of network and application security is changing rapidly, and Zero trust provides a framework to adapt to this changing landscape. Our opinion is that in this new world, implementing Zero Trust is not an ‘if’ but a ‘when’ question. However, the Zero Trust implementation shouldn’t be blindly followed based on whitepapers and guides. Instead, every organization should objectively evaluate its stage, risk, and the vertical they operate in and implement different elements of Zero Trust that are applicable to them.
Thanks for reading To Do or Not To Do!