How far can we extend a deny-by-default approach as we build out our zero-trust architecture? Can that aggressive security tactic work for the business without disrupting productivity? Conventional wisdom says no, but we say “yes it can.”
Check out this post for the discussion that is the basis of our conversation on this week’s episode co-hosted by me, David Spark (@dspark), the producer of CISO Series, and Geoff Belknap (@geoffbelknap). Joining us is our sponsored guest Rob Allen, chief product officer, ThreatLocker.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, ThreatLocker
Full Transcript
Intro
0:00.000
[David Spark] How far can we extend a deny by default approach as we build out our zero trust architecture? How do we make that work for securing the business when it could disrupt productivity?
[Voiceover] You’re listening to Defense in Depth.
[David Spark] Welcome to Defense in Depth. My name is David Spark. I am the producer of the CISO Series and joining me as my co-host for this very episode, not the first time you’ve heard him or the first time if this is your first episode. So, it’ll be the first time you heard him and the first time probably you heard me. It’s none other than Geoff Belknap. Geoff, say hello to the audience.
[Geoff Belknap] Hello for the first time today. And if it’s not the first time today, I’m sorry.
[David Spark] They appreciate you, Geoff, as do I. And I also appreciate our sponsor who is ThreatLocker, zero trust endpoint protection platform. That is ThreatLocker. We’re actually going to be talking more about them later in the show. And they brought us our guest for today. But before we introduce him, let’s talk about our topic. Zero trust has been quickly accepted as best practice for developing a sound cybersecurity architecture, but does it start to break down when we get to endpoints and start allowing exceptions for applications? When we start adding PowerShell and other apps to allow lists, have we released the horse out of the zero trust barn and the architecture just falls apart? Geoff, what do you think?
[Geoff Belknap] Yes, that’s it. As soon as you add PowerShell, it’s all over. No, look, I think at a very high level, one of the key principles in zero trust can be use least privilege access. And you can decide how you want to do that, but it’s not don’t allow anything ever. It’s not don’t ever work. It is be smart about how you make those choices. And I think our guest today can really help us sort of sharpen that thinking.
[David Spark] And let’s get to that. I am very thrilled to have our guest today, all the way from Dublin, Ireland. He is our sponsor guest from ThreatLocker, the chief product officer, none other than Rob Allen. Rob, thank you so much for joining us.
[Rob Allen] No problem at all, Dave. It’s a pleasure to be here.
Where does this effort fall flat?
2:16.057
[David Spark] Andrew Wilder of Community Veterinary Partners says, “Zero trust is a great idea but needs to be implemented from the beginning. Trying to retrofit deny by default into an environment that was built differently will lead to chaos. Of course, you can stop the bleeding and start implementing this moving forward, but you will still have a giant backlog of access issues.” And Chris Yu who’s a consultant said, “Grafting over-porous architecture into a deny-by-default platform can have more pain if there’s no documentation and whoever wrote/supported the migration target is unreachable. Stop and talk to whoever was responsible for the monitoring and inventory, drill through whatever Swiss cheese they handed you, and get that solid.” So, Geoff, this sounds like a security program says, “All right, we’re going to now go zero trust,” and you start to roll that out and that becomes a painful experience. Have you been in that space before?
[Geoff Belknap] No, every place that I’ve worked, especially if you’re one of my former colleagues listening, has been perfect in every way. We knew every piece of software and every network connection in the environment, and everything was perfect. But if you work in an environment unlike the ones I’ve worked in, it can be very challenging. We sort of talked about this at the top. A lot of what we’re trying to do, even as security practitioners, is enable the business. And certainly sometimes what happens when security practitioners are not always involved in every decision is we lean a little too hard on enable and not enough on protecting the business or making wise risk-informed decisions. So, yeah, it can be very difficult to start if you didn’t start from a thoughtful zero trust perspective to begin with, but you really have to at some point rip off the Band-Aid and really try. And there’s no better time to do that than now. I mean, the better time to do it would have been 10 years ago or whenever your company started, but if you’re not in possession of a time machine, now’s a pretty good time too.
[David Spark] Rob, our audience would love a Greenfield situation where they get to start fresh and roll it out piece by piece and know every single endpoint as they’re doing it. But as Geoff was mentioning, that is a rare situation. So, per the comments both Chris and Andrew make here, does it lead to pain when you start rolling out zero trust in an already well-defined environment?
[Rob Allen] So, it depends on what approach you take. It depends on what tools you use. So, I had a conversation today with another podcaster, and I’m sorry about this. I have spoken to other podcasters, but I spoke to another podcaster today.
[Geoff Belknap] How dare he?
[David Spark] He’s cheating on me already.
[Rob Allen] I know. I’m sorry. I feel really bad now.
[David Spark] Good.
[Rob Allen] But yeah, so I was speaking to somebody else today about it, and they mentioned other tools that are available. And they mentioned a certain allow listing tool, which is built into Windows. And they mentioned that it can be challenging. It can be difficult. It can be overwhelming to try and implement that tool. And I absolutely agreed with them. I’ve spoken to organizations who’ve spent multi-year projects trying to implement what is built into Windows, AppLocker which is built into Windows, and I’ve just not turned it on yet because they haven’t got to the point where they could. So, it absolutely can be difficult, but I suppose the point is it need not be difficult. There are other tools available to do it that make it easy, manageable, and attainable without that pain.
[David Spark] So, walk me through where the most common pain is and how to deal with it.
[Rob Allen] Well, the first thing is assessing what’s in the environment. So, that itself is a scary thought. I mean, one of the things that I find very interesting is when we work with customers, when we deploy an agent, when we catalog what’s in their environment, there are always surprises. There are always things running on their machines that they had no idea was there.
[David Spark] That’s always the case, always.
[Rob Allen] Correct. Absolutely. But again, it’s when it starts being dangerous things. It’s when it’s things like remote access tools. I mean, what organization can honestly say how many remote access tools are running on machines in their environment? I would argue very few because they’ve no visibility. They don’t know what’s happening on their machines. And again, things like remote access tools are not going to get blocked by your traditional security tools. They’re not inherently bad applications, but do you want a remote access tool like TeamViewer or AnyDesk or LogMeIn to run on every machine in your environment? Absolutely not.
What needs to be considered?
7:08.523
[David Spark] Mauricio Ortiz of Merck said, “The deny-by-default idea would get you fired quickly.” By the way, we’re going to address this term deny-by-default but let me go on with Mauricio’s comment. “It goes against the mantra of enabling the business to innovate and be agile. The zero in ZTA, zero trust access, is misleading as you must trust or allow some risky transactions or activities, but the key is to understand what are those and implement controls and monitor them to prevent abuse or threats.”
Tolgay Kizilelma of the Dominican University of California said, “I think the right answer is it depends.” Oh, he’s talking to you, Rob. “How well it’ll work is based on the context of every organization/industry. They have different cultures, different risk perspectives – capacity, appetite, tolerance. Try to answer this question for a higher education institution versus a military/defense organization. The technical aspects of cybersecurity should be aligned with business objectives and outcomes as a business enabler.”
All right. I want you to first, because it is a hot button term that gets people a little wound up as it did Mauricio here, the deny-by-default as you approach it with ThreatLocker, and I want you to feel free to explain how you guys approach it over there, how does that work?
[Rob Allen] So, I’m going to shock you, but I’m going to disagree with Mauricio, okay? It will not get you fired.
[David Spark] Yes.
[Rob Allen] The thing about the majority of users and the majority organizations is that they do the same things with the same software every single day. They use Office, more than likely they use Office. It’s pretty ubiquitous at this stage. They use browsers, video conferencing tools, probably a line of business application or two or three. But most users don’t really step outside those boundaries. Most users don’t really need to step outside those boundaries. And fundamentally, that’s what we’re talking about here. We’re talking about controls. We’re talking about setting boundaries around what users are allowed to do. So, as long as they stay within those boundaries, there is no deny, there is nothing getting blocked, there’s nothing getting in their way.
Now, if they step outside those boundaries and try and run a random Chrome extension, coupon clipper, or 7-Zip, or some other random piece of software that hasn’t been approved, absolutely, it is going to get blocked or it is going to get stopped. But that’s to the organization’s benefit because realistically, every piece of software that runs is potentially dangerous. I like to say to people, when you think about everything that you use in your computer, whether it be Chrome or Zoom or Office or anything, assume all that software is full of holes because it probably is. There’s vulnerabilities in pretty much everything. I mean, look at an average patch Tuesday from Microsoft. The amount of vulnerabilities, zero days that are fixed every single month.
But our suggestion of deny by default, it basically means that assume that software’s vulnerable. Assume it can be exploited. What’s the next thing that will happen in most cases? It’s something will run. So, whether it be a piece of malware, or as I said, a rat, something along those lines, it’s something will run. Now, if you stop that something from running, that is that breach, that attack stopped at source. I know it was mentioned at the very beginning about PowerShell, and how having PowerShell in an environment immediately negates allow listing or zero trust approach. It absolutely doesn’t.
The point with something like PowerShell is not about stopping it from running because it’s a useful tool and it’s a valuable tool for most administrators. It’s about controlling what it can do. So, denying by default what PowerShell is allowed to do. So, does PowerShell need to access every single file in the organization? Absolutely not. So, why would you let it access every single file in the organization? Does PowerShell need to access the entire internet? Short answer, absolutely not. So, similarly, why would you let it access the entire internet?
[David Spark] The idea is to limit the capabilities of the software that you’re allowing.
[Rob Allen] Correct. Absolutely. So, again, it’s just expanding on that concept of deny by default. So, we’re not just talking about what can run and what can’t run, although what can run or what can’t run is obviously very important. We’re also talking or extending that to what things can do when they’re running. And it’s not just PowerShell, it’s all of those other dangerous Windows components, those things that are sitting on our computers right now that can be weaponized and used against us.
[David Spark] Geoff, I am throwing this to you. How do you approach the deny by default? And do you use a different term because you think it may be very loaded when people hear it?
[Geoff Belknap] Well, I think the way I think about it is just the broader term of use least privileged access, right, and verify explicitly. So, that is just another way to frame deny by default. And to be clear, what we’re saying is not ban anything from running unless it’s been pre-blessed and signed and etc., ahead of time, although certainly I’m sure there are environments where that’s appropriate. What we’re saying is don’t let anything have broad access by default just by virtue of it being on the device or on the network. Ensure that this is either a program or an identity or a system’s token that should exist, that has reasonable access, that’s coming from a reasonable location, a reasonable machine, whatever it might be, and only grant it enough access that it needs, which means you, your system, or you as an individual, need to have enough context about what’s appropriate.
I think just what Rob said a minute ago about PowerShell, you can’t just go… Well, you can, but I don’t recommend this. You can’t just go, “I allow PowerShell to run on every computer in my environment globally with full access to everything and egress to the internet.” That is one choice and certainly your threat actors that may be interested in you will thank you for that choice, but you need to have some context ahead of time of what is PowerShell doing? What are these pieces of software that I’ve implemented or I’m allowing to run in my environment doing? What’s appropriate? What’s not? And making runtime decisions based on that context. And that sounds really straightforward, and it is, but the trick is building that context and understanding and building an environment where you can make those decisions, and that’s where a lot of people get hung up.
Sponsor – ThreatLocker
13:35.508
[David Spark] Well, our sponsor is the fantastic company of ThreatLocker and let me tell you a little bit about them. So, let me ask you, audience, do zero day exploits and supply chain attacks keep you up at night? Of course they do. You work in cybersecurity. What other things that’s scary about cyber? Well, you don’t have to worry anymore. You can actually harden your security with ThreatLocker. Imagine taking a proactive, deny-by-default – we’ve been talking about it – approach to cybersecurity, blocking every action process and user unless specifically authorized by your team, just what Rob was talking about.
ThreatLocker helps you do this and provides a full audit of every action – that’s good – allowed or blocked for risk management and compliance. Onboarding and operation is fully supported by their US-based support team. Stop the exploitation of trusted applications with your organization to keep you running efficiently and secure, protected from ransomware. Worldwide companies like JetBlue trust ThreatLocker to secure their data and keep their business operations flying high. You don’t need to be an airline to use it. Let me point that out. To learn more about how ThreatLocker can mitigate unknown threats and ensure compliance for your organization, just go to their website. That is ThreatLocker.com. Check them out.
Who owns this issue?
15:05.169
[David Spark] Richard Splane of Meirliún Consulting said, “Viewing ZTNA,” we’re talking about zero trust access, “As an impediment, draconian or is overburdensome is like viewing ISO or SOX in the same way. We can view these as opportunities to adopt best practices, guidance to inform our strategy, or a framework to ensure a thorough security architecture is implemented. I view zero trust similar to the idea of design for six sigma. Get the design right to prevent the exception.” I like that. Jerich Beason, who’s the CSO over at WM, said, “Zero trust marketing problem is the word zero. We have less implicit trust than ever before, but you must have some level of trust before you allow, which is why I’ve always opposed the “never trust, but always verify” mantra and have instead said, “Verify, then trust.” Once we verify who needs to run PowerShell and from what machines, after requiring strong authentication of both, we trust it, then allow it.” All right. I’ll throw this to you, Geoff. Are you having a problem with the term zero trust? Because yeah, at some point you got to trust somebody somewhere.
[Geoff Belknap] Yeah. I mean, look, most people don’t take this literally. Zero doesn’t mean actually zero. It’s sort of an asymptote, like as close to zero as you can get as possible without completely destroying your business or your capability to run the technology stack in your environment. So, I think Jerich is exactly right here where, yes, an ideal state would be zero trust. An ideal state would also be all of the computers in your environment are encased in concrete and buried six feet underground. That would be very secure. So, what we want to do is get as close to a more ideal state as possible. And that’s like, look, as security professionals, we’re just trying to get a little bit better every day. Every time we approach a problem, we want it to get a little bit more secure. If we can do a sub-function change, great.
I think in this case, any opportunity that we have to make it easier to get to a point where we’re not just by default trusting things, that we may be denying things by default because we have the ability to make contextualized decisions about access or about where we want things to run, that is better. And I think we shouldn’t get hung up on the word, but we should get hung up on trying to get closer to that than we were yesterday.
[David Spark] Well, I like what Richard here says, saying he likens zero trust to the ideas designed for six sigma. It’s just a design architecture, like a philosophy of how you should approach security. You’re nodding your head. You’re on board. Yes, Rob?
[Rob Allen] Absolutely. Absolutely. I mean, interestingly, the other comment about verify then trust, forgive me for, again, being the one who disagrees, but that is an accident waiting to happen. Allowing PowerShell to run unrestricted, which is effectively what we’re talking about on what machines for what users, is really dangerous. And that’s precisely what we’re talking about, which is just, again, because a user may have needed to use it or do a thing with it once doesn’t mean it needs to be used or allowed completely unrestricted. Verify then trust or trust but verify. I think, am I right in saying now, obviously, I’m not an expert in all things American, but I think that was a Reagan thing, wasn’t it?
[David Spark] Yeah, it was a Reagan era comment. Yeah. Well, the security industry, by the way, adopted it.
[Rob Allen] Correct. And that is literally what the security industry has looked like for the last 15 years. It’s been trust but verify. So, allow everything to happen unless we know it to be bad, allow everything to run unless we can identify it as being bad. And that approach, unfortunately, has been proven not to work.
[David Spark] Yeah, because the thing is by the time you get around to verify, the problem could have already happened.
[Rob Allen] Absolutely. And realistically, if your strategy is to wait for something identified as bad to run, then the fact is it’s probably too late. Your data’s already out there. It’s on the dark web. It’s for sale. And it’s basically a cleanup operation at that point. So, as I said, that approach, that strategy has pretty much been shown not to work. So, why not try something else? Why not try something different? Which, again, is about applying controls within the environment.
Now, look, I’m never going to say to somebody you need less security. Okay, they are not words that will come out of my mouth. But what I try to recommend to people is that you should have different types of security. So, you should have a certain amount of detection. Okay, response if something happens. Take an action. There is a time and a place for that, absolutely, and there is a value to that. But what we find is a lot of organizations put all of their eggs in that basket. So, they have layers and layers and layers of detection, all fundamentally looking for the same known bad things, fundamentally looking for the same or trying to identify the same threats and very often falling over each other, trying to stop them once they do find them.
So, as I said, what we try and suggest to people is to balance the security between detection and also protection. So, proactive, blocking things by default, controlling what things can do. I mean, there’s other aspects to it that I could mention. Network control – so same principle, but for networking. So, I mean, you mentioned at the very beginning about flat networks. Flat networks are so common. Flat networks are a thing. They very much are. But again, just because a flat network is a thing doesn’t mean that your servers, for example, or your machines need to allow every device on those flat networks to connect to them. So, that’s where the deny by default for networking, which is what we call network control, comes into it.
Or again, what applications, what programs have access to what data? So, your traditional approach to data is typically user-based. So, it’s Geoff has access to a folder. The problem with that though is once Geoff has access to a folder, everything Geoff runs has access to that folder as well, whether it be good, bad, Angry Birds, or a piece of ransomware. So, what we’re saying is block everything except those things that need access to that data from having access to that data. So, it’s just taking that principle, and I know it might sound scary of deny by default but expanding on it. And it’s not just about what can run and what can’t run.
[David Spark] I like what you say there. You’re starting with the concept of deny by default, but it’s essentially allowing it to breathe and have exceptions that can be managed is what it is.
[Rob Allen] Absolutely.
[David Spark] If we just live sort of by this strict rule of deny by default, then, yes, the business won’t operate.
[Rob Allen] The bit that’s missing there is the permit by exception.
[David Spark] Yes.
[Rob Allen] So, it’s not just deny by default, it’s deny by default and permit by exception. And the permit by exception is the bit that allows your businesses to run.
What do most people think it is and what’s the reality?
22:11.142
[David Spark] Anand Thangaraju of Goldilocks Ventures said, “A deny by default should be carefully tuned based on anomaly detection, context-aware policies, and automation. That could meet the 80-20 criteria where the rest of the 20% is the hard part involving reverse proxy architecture, human elements, and packet inspection that can add overheads.” Anand here adds sort of a lot of sort of concerns that may be in a deny-by-default environment. Some that you touched upon, Rob. Geoff, what do you think about this? I mean, is he sort of describing the environment you have to deal with?
[Geoff Belknap] So, the bottom line is yes, but I feel like Anand might be going the other way, where people sort of get triggered a little bit on the phrase “zero trust” and really hone in on the “zero.” I think here we might be overreacting to this as a suggestion that absolutely nothing in the environment should ever run by default. And instead, I think of a deny by default, maybe differently than Rob, but in the sense of this should be a goal, an objective, something we’re headed towards. And the more that we can do, the more we can think about our environment, if we head in that direction, we’re going to be happy with the results.
If I go back to the PowerShell example, we should think not that no PowerShell should run anywhere in my environment. Although if I can run an environment without PowerShell, that might be better for me. But how do I want to let it run by default? Obviously, I need to let it run, but what access do I want to give it by default? And just start thinking about how do I collect enough context, enough information about my assets, servers, laptops, tablets, etc., and how they’re being used and by whom and for what purpose to be able to make smart decisions about what should run, when, and under what conditions.
[David Spark] All right, Rob, I’m going to let you close this up. Your thoughts about, well, how Anand sort of addresses the deny-by-default environment that is created?
[Rob Allen] Well, I suppose the key to making these, I suppose, educated decisions is about having the information to base the educated decisions on. And I suppose to some extent, it comes back to what I said earlier, which is who truly knows what’s happening in their environment, what’s running in their machines. I would wager not many organizations, and it’s not just what programs, it’s what PowerShell scripts are running in your environment.
Again, customers I work with never cease to be amazed at the amount of PowerShell that’s going on. They very often don’t know what it is. They don’t know what the scripts are. Well, very typically, they will know what is pushing the scripts, but they have no idea what they’re doing. So, part of making an educated decision about what’s happening and what should be allowed is about knowing what’s happening in the first place. And that’s one of the things that we’re very strong on is giving people visibility, giving them information to make that educated decision about whether something should be allowed or shouldn’t be.
[David Spark] Very good point.
Closing
25:15.819
[David Spark] Well, that brings us to the very, very last part of our show, where I ask you which quote was your favorite and why? And I’ll ask you, Rob, which quote was your favorite and why?
[Rob Allen] David, your quote was my favorite.
[David Spark] My quote? You’re the first to quote me.
[Rob Allen] Your quote.
[David Spark] Which quote are we talking about?
[Rob Allen] When we start adding PowerShell and other apps to allow lists, have we released the horse out of the zero trust barn and the architecture falls apart? I say not.
[David Spark] Well, that’s why we set it up that way.
[Rob Allen] That is why you set it up that way. I say not. Now, again, it’s a common misconception. It’s okay, well, we’re going to allow PowerShell to run. We’re going to allow regsvr and rundll and .4 files to run. So, therefore, zero trust isn’t going to work. As I said, it’s not only about what can run or what can’t run. It’s also about what things can do when they’re running. So, by limiting those access…
[David Spark] What things can do while they’re running. That is key.
[Rob Allen] Correct. So, by limiting access, by limiting interactions between applications, by limiting where things can go on the internet, you can stop so many of these attacks in their tracks.
[David Spark] All right, Geoff, I throw it to you. You may not quote me. Who would you like to quote?
[Geoff Belknap] I’m going to go with Chris Yu, who said grafting over-porous architecture into a deny-by-default platform can have more pain if there’s no documentation, and whoever wrote or supported the migration target is unreachable. Stop and talk to whoever’s responsible and drill through that.” And I think this is a great way. If you’re not going to buy your way out of the problem, you’re going to do it manually, this is the way to do it. You got to really just understand what’s talking to what in your environment, what does your network connectivity actually look like, what’s actually running on the desktops, the servers, and just start doing the hard work. The best place to start is anywhere and the best time to start is now. It’s not going to be easy, but you are going to be glad you did it.
[David Spark] Very good. All right. Well, that brings us to the very end of the show. I want to thank our guest who I’ll have the very last word, and I want to thank you too, Geoff, as well. But ThreatLocker, our sponsor, zero trust endpoint protection platform. Remember, ThreatLocker.com. Now, Rob, we always ask, are you hiring at ThreatLocker? Yes?
[Rob Allen] We are very much hiring at ThreatLocker. Yes. We have all manner of roles.
[David Spark] All right. So, they’re all on your job site on ThreatLocker.com. Now, do you have any special offer for our audience as well? I know you guys have a big event you do every year.
[Rob Allen] We do. And that very nicely leads us into our special offer. So, we run an event in February every year here in Orlando.
[David Spark] February 2025 will be the next one.
[Rob Allen] February 2025 will be the next one. It’s in Orlando, in Florida. Now, I don’t know if many people or any people who are listening to this have ever been to Orlando in Florida. February is a very nice time of the year to be here. It’s warm. It’s not too hot. It’s basically like a warm summer’s day back home for me.
[David Spark] Because February in New York and Boston stinks.
[Rob Allen] Mm-hmm. Look, I’ve never been to New York or Boston in February, so I’m not going to make that.
[David Spark] I can tell you. I’ve been to both.
[Rob Allen] But it’s a really nice time to be in Orlando. We have an event here. It’s basically, as the name suggests, it is zero trust focus Zero Trust World, but we’ve got some incredible speakers. We had Mark Rober last year, we had Captain Sully the year before, we’ve got hacking labs, we’ve got training. It’s a really, really cool event. And I believe we’ve got a $200 off voucher.
[David Spark] Yes, we do have a coupon code. I will say what it is, but we will also put it onto our blog post. For those listening, it’s ZTW, so Zero Trust World, ZTW Defense 25. If you can’t remember that, just go to the blog post for this episode. You will see it published there as well. Thank you very much, Rob. Thank you, ThreatLocker. Thank you very much, Geoff. And thank you, audience. We greatly appreciate your contributions and for listening to Defense in Depth.
[Voiceover] We’ve reached the end of Defense in Depth. Make sure to subscribe so you don’t miss yet another hot topic in cybersecurity. This show thrives on your contributions. Please write a review, leave a comment on LinkedIn or on our site CISOseries.com where you’ll also see plenty of ways to participate, including recording a question or a comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at [email protected]. Thank you for listening to Defense in Depth.