Let's start simply: how many of you are tired of hearing the term "Zero Trust?" And what that even mean? Wendy Nather (@WendyNather) explains in her All Day DevOps presentation.
What is Zero Trust?
With Zero Trust, you should assume everything on the network isn't safe. Yes, your internal network too. It doesn't mean that you shouldn't trust anyone ever. But you have to check trust explicitly. So even if it's on your network and got past your firewall, you still need to make sure it's safe.
The important thing to think about is that successful attackers look exactly like insiders. For example, an attacker once acquired a sysadmin's credentials, came in through a VPN, and looked safe. The only thing that warned anyone was that the keyboard had been changed to Chinese.
Let's say you're in a club and your bouncer is the firewall. "Zero Trust" in this case means the bartender still requires customers to show ID. The bartender doesn't rely on checks and authentication from the bouncer or anyone else. That's because they may be allowing someone in the door based on different policies and conditions. Additionally, someone might not have even come through the bouncer's door. Maybe they came through the back patio. We need to verify identity as close as possible to the point of access.
What's wrong with implicit trust?
Implicit trust is a problem. For example, the Colorado Department of Transportation ran into issues that resulted in ransomware and several weeks of outage. Take some time to look into this story by Googling it.
Let's look at some trust assumptions.
Trust assumptions from Wendy Nather's "ZeroTrustOps: Securing at Scale" presentation.
- "It's only a temporary instance, so it doesn't need the usual security configurations."
- "Nobody will notice this instance."
- "We join everything to the internal domain, even if it's not internal, because that makes everything operate smoothly."
- "If you're part of the internal domain, we don't need to check you again."
We sometimes think it's only a temporary instance, so it doesn't need the usual security configurations. Or we might think that nobody will notice this instance. We can’t make these assumptions.
Will network segmentation fix the problem? Yes and no. It depends on how granular it is. But the more granular it is, the more difficult is to maintain.
Another note on Zero Trust — it's not one tool or technology. It's a different way of thinking about resources both on and off our network.
How to apply Zero Trust
There are different ways to apply Zero Trust.
First, think of the perimeter as being any place where you make access control decisions. For example, if you don't run your own network, then everything is potentially hostile. Move your security to the level that you can control.
Here's one example of a new and common perimeter: when people use the same applications for home and work. For example, if I log into my Google account at work, most companies don't care. However, if I'm logged in to my personal account, it becomes my employer's problem. The perimeter can be affected by which login information I put in.
There are three spots where Zero Trust can keep you safe: workforce, workload, and workplace. For example, in the workforce you want to know if the user is who they say they are. You want to know that they have the correct access and that their device is secure and trusted.
Workforce, workload, workplace slide from Wendy's presentation.
However, zero trust isn't just about users. When looking at workload, what applications are being used and what data is being communicated? And what data is passing between applications and how is it being secured? More and more encryption is used even within our networks.
And finally, let's look at the workplace. We may be using IoT, smart light bulbs, and other technologies during our working day. We may need to look at all devices that come inside with our employees. They may be vulnerable, so how do we segment them from the rest of our network?
Things have changed
In DevOps, you'll be responsible for more of this than you were in the past: when you're designing, coding, deploying and monitoring applications.
When looking at the chart below, consider how everything connects together. Depending on what talks to what, you'll have different security protocols and different security concerns.
Chart that shows potential places authentication could take place
You can look at all of these and see a number of opportunities to do authentication. And as you can see, the table isn't complete. We have some things to work out still.
For instance, there’s one additional problem. Looking at the user role, see how many different authentication methods they must use to prove they are who they say they are. This results in cranky users that have to track all these different methods!
What to pay attention to with DevOps
With DevOps, you'll have to pay attention to impact and scale. Users in the DevOps world all have elevated privileges. They have access to a lot more than normal users would.
Additionally, you should look at inter-workload communications. You may not expect issues with one server talking to another server. However, when attackers attack, they take advantage of these lateral communications that no one thought to block. Yes, it's scary to whitelist everything that should have access to a system. And it may take time. But it will result in more security through zero trust.
Finally, realize that automation can both help and harm. It eases our workload, but it also drives to the lowest common denominator. So if you have to customize one particular thing for each application, you start giving everything the same general security policies and rules. Then you slip into a state where everything is talking to everything else. Policies are looser then they should be. Therefore, you should take the time to figure out granular security policies. Zero trust is not about making everything fall under the same policy.
So where will attackers move next? If we prevent lateral movement within networks, they'll probably switch to lateral movement between applications. You'll have to start thinking about securing your APIs more.
The takeaway message
One final thought to leave you with. Trust is neither binary nor permanent.
For example, your team may trust you to speak on a webinar. But they may not trust you to never break things. And even if they do trust you, that trust shouldn't be permanent.
Think about what you trust someone to do, what conditions need to be true, and for how long should this trust last.
