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.

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 those new data sources?

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

Let’s do a quick example. You have a fictitious service running on an EC2 instance and it plugs into your IAM—remember that Identity and Access Management tools. You have monitoring on it, you’ve got the logs going places, it has a security event manager looking at it, so your SIEM’s got it covered. And you’ve got your store platform has the ability to create accounts, shut it down, do all the things to it. Your Zero Trust policies indicate that if an employee has put in their notice, or they’ve otherwise been put on a watch list because management a little worried about them or HR is investigating them, then they cannot access this resource.

So today, I log in, I authenticate using IAM, I used my correct multi-factor authentication. It is successful, and then I go to access your application and the Zero Trust policy engine says, “Yep, Jesse can now get in.” And then tomorrow, I put in my notice in the morning and I’ve got two weeks left. I go to log in to use your service, but today I’m on the watchlist. And so your service goes to the policy engine, says, “Can Jesse login?” And the policy engine says, “Hey. So, he’s authenticated correctly; he does not have an increased risk score except for this anomaly where he’s also in the watchlist.”

Now, suddenly, Jesse doesn’t get access to that particular resource. And if I get an offer to stay and I rescind my notice, and now I’m off the watch list and now I’m back, so in theory, I should be able to access that same application. However, you could also put in rules that says if somebody rescinds their notice and they stick around, they stay in a watchlist for a while. So, perhaps you do allow me access to that system, but you do better monitoring on what I’m doing in that system. Or even better yet, I can only access some of those resources, not all of them available in that application.

If you design your infrastructure correctly, and you design your applications in a dynamic fashion that allows this to happen with granular rule sets for permissions inside of the application or resource, then you can do this kind of nuanced access through the policy engine that you cannot otherwise do in a traditional format where it’s just, you’re in and you get everything. This is even better than role-based access controls because it’s granular permissions about individual little things that I can access or do and that application. That’s a good primer on how to think about implementing your own Zero Trust architecture.

Now, for the tip of the week. I cannot stress enough this point to secure your cloud storage. Everyone says this; all the cloud people get tired of hearing it. I know. So, do I. However, all of us have had some permissions somewhere that we didn’t change, or we changed to the wrong thing—“Oh, we’re just going to do this to test for a little while.”—and then it’s like the days of yore with anonymous FTP sites, and suddenly there’s a wide-open, world-readable and world-writable upload and download site for [whereas 00:10:47] and other nasty things you don’t want in your infrastructure.

So, you open your cloud storage, like S3 buckets, and it’s just free storage for anybody and everyone. Or even worse, it is something that you do not want the world to see: your secret plans for your next go-to-market strategy. So, just go to your cloud provider, like AWS’s own documentation has a topic called, “How can I secure the files in my Amazon S3 buckets?” Just go read it; go do it. Every time and every single time you come across storage that you haven’t seen before, audit it. Audit your storage regularly; make sure that somebody hasn’t changed permissions just to test this one thing. We all know that all changes are permanent until replaced. And that’s a wrap for the week, folks. Securely yours, Jesse Trucks.

Thanks for listening. Please subscribe and rate us on Apple and Google Podcast, Spotify, or wherever you listen to podcasts.

Announcer: This has been a HumblePod production. Stay humble.