I don’t know about the rest of you, but I’m getting a little tired of cyberattacks. I don't mean on my personal accounts or machines, but just in general. It feels like we are seeing an increasing number of these things. Just in the last few months, we have seen attacks on casinos, electoral records, universities, and even cybersecurity service providers.
It’s really depressing.
Here’s the question, though: why? Why are these things happening with an alarming frequency? Aren’t organizations aware of the need to defend their networks and their data? Aren’t cybersecurity professionals always learning new defenses and upgrading their tools? Of course they are. On top of that, most nations have laws requiring organizations to take stringent steps to protect data. So why, then, are successful attacks increasing?
Well, there are many answers to that question. Part of it is the increasing complexity of enterprise networks. Part of it is the increasing sophistication of bad actors. Part of it is a lack of secure coding and programming. Part of it is a lack of training and the fact that, no matter how much you train, if the bad actors are always a step ahead of you, you’re always fighting to catch up. Part of it is budget, because it costs money to protect a network.
In other words, the entire system of removing vulnerabilities and flaws has, at its core, vulnerabilities and flaws. Which is why we’re seeing a shift in how we think about security. Over the last few years, the entire foundation of cybersecurity - the premise upon which most network security frameworks operate - is moving to what is known as a Zero Trust Architecture (ZTA). Today, we’re going to take a look at ZTA.
What it is and Why We Care
Zero Trust Architecture begins with the premise that a network should never trust anyone and should always verify two things:
1) users are who they say they are, and
2) users are authorized to do whatever it is they are trying to do.
A common illustration is to view a network as a castle.
To defend a castle, a king might build a moat around it. He might have a drawbridge and a portcullis to block the gate. He might place guards in towers and along the walls to keep a watchful eye for invaders. He can take many steps to keep an uninvited guest (or army) from attacking and entering the castle.
Once in, however, a person is free to move wherever he or she may wish. Want to walk through the gardens? You’re free to. Want to visit the stables? No problem. There's no one to challenge you. Want to visit the throne room? Ah, here, you might find a couple of guards but, in general,
anyone who can safely enter the castle is free to move about.
Cybersecurity has been very similar. Enterprise networks are intent on keeping unwanted visitors out. We use IDSs and IPSs (Intrusion Detection and Intrusion Prevention Systems) to guard incoming traffic. We give all of our employees and vendors usernames and passwords. We encrypt our hard drives. However, once in, users of many network can move about with little to no challenge.
There have been efforts to mitigate this over the years. The Principle of Least Privilege was developed to give employees access to areas needed for their jobs, and no more. For example, if I’m in the accounting department of a hospital, there’s no need for me to be able to access employee time cards, or if I’m a software developer, I shouldn’t have access to patient health records. That kind of thing. Businesses have also tightened security on passwords, increasing length and complexity, as well as making sure passwords are changed regularly.
Or, at least, they should be. That’s ultimately the issue here.
If I’m a bad actor who gained credentials to your network and I was able to log in, then unchanged passwords can allow me access for weeks, months, or even years to come. Furthermore, if controls are minimal within the network, then it becomes easy for me to escalate privileges and access more restricted areas – if privilege escalation is even necessary. What ZTA does is afford tighter security measures at more frequent points within a network. In cybersecurity lingo, we call this granular control, and it is the lifeblood of ZTA. It’s the understanding that no network traffic should be trusted, and any attempt to access a resource must be verified. However, this is only the very beginning of that understanding. As understanding increases, the organization begins to shift even more towards the Zero Trust.
Implementing Zero Trust Architecture
Implementing ZTA begins with some very basic tools. Remember, one of the key philosophical concepts behind ZTA is, “Never trust, always verify.” The first step, then, is to begin securing access. According to the 2020 Verizon Data Breach Investigations Report, stolen credentials were responsible for 80% of security breaches.
Did you catch that? Stolen and brute-forced credentials account for more than 80% of breaches. Mitigating risk should begin with credentials, and in a ZTA environment, there are three ways to approach this. The first is having a strong password policy.
Let’s say you have an employee named Steve who decides to use the same password for his work email that he uses for his personal email. While this is obviously a bad idea (and no cybersecurity professional will ever tell you to do this), it happens more often than you might think.
Actually, you know exactly how often it happens, because you probably do it yourself.
In any event, let’s assume this employee is checking his personal email out in public, using some coffee shop’s public wi-fi. Unbeknownst to him, there’s a gentleman in the corner who’s using Wireshark to intercept network traffic, including his email password. Once intercepted, he sells the password on the dark web. Over the course of the next year, that password becomes part of a password-cracking dictionary, and someone uses that dictionary to attack your network email addresses. Want to guess whose account this bad actor is able to log into?
Now our bad actor can navigate through Steve’s account, appearing legitimate to the system (since he had a legitimate username and password), but able to do untold amounts of damage.
But what if Steve had to change his password every three months because your company decided to begin migrating to a Zero Trust Architecture? Now, when the bad actor attempts to login with Steve's credentials, he finds out the password is no longer valid. instead of giving bad actors unfettered access to his work account, both Steve and your company have prevented what could have been a pretty horrendous cyberattack.
Another step towards ZTA is to introduce multifactor authentication (MFA) to your apps and accounts. By forcing anyone logging in to verify that he or she is, in fact, attempting to log in, you are thwarting any bad actor who does happen to gain access with brute force or stolen credentials. I use MFA on my bank account, for example, as an added layer of protection. I don’t want my bank assuming that, just because my username and password are entered, it’s me trying to access the account. So any time I log in now, I get an alert that a login attempt was made, and I have to verify that the attempt was me. If I ever receive an alert that wasn't my attempt, I would reject it, and the account would not let the thief in. I still use a lengthy and complex password, I still change it periodically, and I do not use that password anywhere else, but MFA helps me know that the bank, per my request, doesn’t trust and always verifies.
Migrating to stronger policies and MFA is a great start, but there is more to Zero Trust Architecture than just those these two things. The next natural progression would be to apply MFA to your third-party vendors. Remember that Target breach several years ago? It happened because one of Target's vendors was breached, and the attackers were able to leverage the information they received to access Target's network. By implementing MFA for third-party vendors, organizations can add an extra layer of verification for logins. Incidentally, if you want to read a fascinating article on supply chain attacks, click here.
Another crucial component of Zero Trust Architecture is transitioning to a Single Sign-On (SSO) system. By implementing SSO, you are reducing the number of credential attack vectors. If Steve no longer has separate logins for email, a main account, various servers, or any other access he may need, you’re reducing his overall available attack surface. Further, by reducing the attack surface here (and by implementing the granular control over his credentials we talked about a moment ago), you are significantly reducing the risk of a successful attack.
Problems with ZTA
None of this is to say that Zero Trust Architecture is flawless. There are numerous potential issues, including the actual migration to ZTA. This is a change in both defense and offense that affects the
entire organization, often requiring years of preparation and actual change. In fact, Okta, an Identity and Access Management Company headquartered in the U.S., breaks the transition to ZTA into five phases, noting that each phase can take upwards of 18 months to implement.
In other words, it’s not a quick fix. It will take time and a good deal of restructuring, training, and – most likely – troubleshooting.
"There are no shortcuts, which is why it is so hard to implement."
- RackTop CEO Eric Bednash, DarkReading 2022
Another problem with ZTA has less to do with the structure and implementation of it, and more to do with perception. The perception that many C-level employees (and some cybersecurity professionals) have of Zero Trust Architecture is that this is the cure-all for breaches. However, we have to remember that ZTA isn’t the silver bullet that will kill security concerns. It’s not going to stop everything happening today, and it definitely won’t stop all of the unforeseen attacks in the future. While preventing all successful attacks is a fine goal, it’s not feasible.
"Perfection is not attainable, but if we chase perfection we can catch excellence." - Vince Lombardi
It's kind of like personal growth: we can strive to be perfect, but we know we won’t be able to reach it. It is best to hold onto this goal with an open hand. Zero Trust is the same thing. We can narrow down and eliminate attack vectors, and we can work hard to verify every activity, but all we’re doing is narrowing the field of attack, not removing it. Credentials can still be stolen. MFA won’t always be set up in a timely manner. Insider attacks can still happen. We work hard to minimize them, but eliminating them is impossible.
Even if all your network has is one vulnerability and you've managed to eliminate all others, you still have the one vulnerability. That single, deadly flaw.
Final Two Cents
We won’t go into them here, but this is why having solid incident response and disaster recovery plans is important. Remember, assume your network will be breached, never trust, and always verify. It isn’t enough to just change passwords or use MFA. It isn’t enough to rely on your IPS and IDS. And, instinctively, we know this.
We are all familiar with the concept of “defense in depth,” and hopefully we implement that. What ZTA does is provide a structured response to DiD, with a foundation that takes little to nothing for granted.
If you or your organization are looking to implement Zero Trust Architecture, I would highly recommend the following resources:
“Embracing a Zero Trust Security Model,” National Security Agency, 2021, 1
Identity Defined Security Alliance , The Path to Zero Trust Starts with Identity.
“Advancing Zero Trust Maturity Throughout the User Pillar,” National Security Agency
Comments