Jesse Trucks is the Minister of Magic at Splunk, where he consults on security and compliance program designs and develops Splunk architectures for security use cases, among other things. He brings more than 20 years of experience in tech to this role, having previously worked as director of security and compliance at Peak Hosting, a staff member at freenode, a cybersecurity engineer at Oak Ridge National Laboratory, and a systems engineer at D.E. Shaw Research, among several other positions. Of course, Jesse is also the host of Meanwhile in Security, the podcast about better cloud security you’re about to listen to.
Show Notes:
Links:
Transcript
Jesse: Welcome to Meanwhile in Security where I, your host Jesse Trucks, guides you to better security in the cloud.
Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.
Last week, I talked about Zero Trust as an office building where you have different ways of getting access to different parts of the building. Now, we’re going to talk about Zero Trust architecture or ZTA. That always makes me think of a ZA plan. What’s your plan? When the zombie apocalypse comes, you need to have Zero Trust. You do not trust anyone until you’ve confirmed that they are in fact, not a zombie.
But how do you do this? Well, first you have to define what a zombie is and you have to define what a human is. And you also have to define what kind of resources that they get to access. Zombies don’t get to access anything, especially not brains. But humans, they get to access all kinds of things: defensive positions, food, resources, medicine, shelter, and you have to confirm their identity every single time that they want to access something.
How do you do this? Well, the first thing you have to do is to find this, kind of, statically. Jesse comes up, shows he’s not zombie, gets something out of the kitchen. Next time, Jesse comes back, wants some medicine. You check; yep, Jesse’s still not a zombie; he gets to have some medicine.
However, in a Zero Trust world, what if one time somebody comes along, looks like Jesse, but he’s actually a zombie? He doesn’t get access because the risk has changed. This is exactly what Zero Trust is all about. It’s doing authentication and then authorization based on the current context, what’s happening right now. You let somebody in until it become a zombie.
You let an account into your resources to use your applications until it looks like it’s probably an attacker and not the actual real person behind that account. See how they are just like? When you’re implementing Zero Trust architectures, it’s not quite so as simple as seeing if somebody’s flesh is rotting off their bones. So, what is in a Zero Trust architecture? Well, there’s some basic components.
For instance, you have policy engine, which is basically what determines what the rules are and how they are applied in context, and you have Identity and Access Management—or IAM—and that is how you authenticate and how you determine whether an account actually is being driven by the person or thing that it should be. There’s of course monitoring systems to gather and report on your environment, and then you have a SIEM—or Security Information and Event Manager—and an optional security orchestration automation and response or SOAR tool. And the reason for this is so that you can change the architecture and the environment based on the current status of things. So, the policy engine can alter the environment in a feedback loop. And so the policy engine itself, as you can tell, is the brains behind everything, it sits in the middle and it drives the Zero Trust architecture to implement Zero Trust model in your environment.
So, how does this work? Well, if you talk to John Kindervag, the original creator of the Zero Trust model, he recently has an article where he was interviewed and he talked about some of the methodologies of doing this. So first, you define your protective surfaces—what are you protecting—then you map the transaction flows, what things are talking to other things, what systems are working together? How do your applications work? And then you architect the environment, so you have to put controls where the data or the services are, right?
So, right at every single application, which is great in a cloud environment, especially if you’re doing things like using Lambda functions, microservices, serverless functions, as well. And then you create a Zero Trust policy, and you do that by using the Kipling Method, which is the journalistic method of who, what, when, where, why, and how. There’s even an article that he wrote—John Kindervag that is—a couple of years ago, and he talks about how that applies.
It’s a great reading, but the main thing you have to get out of that is you have to answer all of these questions about what’s happening in your environment. And then lastly, you monitor and maintain your environment. You gather telemetry, you do machine learning and analytics, and you look at risk analysis, and you have automated responses going through your SOAR platform. Those are the five key things. In short, this is what you should take away from that article on Help Net Security.
One, define your protective service. Two, map your transaction flows. Three, architect your environment. Four, create your policies, your Zero Trust policies using the Kipling method. And five, monitor and maintain your environment just like anything else. Make sure it’s working, tune it, tweak it, evaluate it constantly.
This is a never-ending cycle where you should always be analyzing, tuning, changing because your environment that you’re protecting changes. And also the risks that you have will migrate and change over time. And technologies change; you’re going to be moving things, swapping things out, implementing new things. You have to keep this in mind and go through this cycle over and over again, always defining what the new thing is, figuring out how that interacts with other things and how accounts access data and resources within it. And also following your business; how are things changing in your organization? What other types of things are needed for you to do and to protect the environment as close as possible to those new services and thos...
Our TOPPODCAST Picks 
Stay Connected
