User-based access controls are inadequate. Attackers know that users inherit their full permissions. When ransomware executes under a user’s account, its game over. Traditional role-based access control simply cannot address the core problem: why should every app need access to all your data?
In this episode, Rob Allen, chief product officer at ThreatLocker, explains how their Storage Control solution addresses these challenges by implementing program-level access restrictions that work alongside traditional user permissions. Joining him are Jonathan Waldrop, CISO-at-large, and Nick Ryan, former CISO at RSM. The conversation explores how ThreatLocker’s endpoint-focused approach applies default-deny principles not just to what programs can run, but to what data they can access. This allows users to work normally while preventing unauthorized programs from reaching sensitive information. This streamlined block-request-approve process can resolve access needs within 60 seconds.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, ThreatLocker
Threatlocker.com/CISO
Full Transcript
[Voiceover] Connecting security solutions with security leaders, Security You Should Know starts now.
[Rich Stroffolino] Welcome to Security You Should Know. Today, we’re going to be talking with ThreatLocker and what they’re doing in data loss prevention with their storage control solution. Now, the problem that they’re addressing, it’s kind of a big one here, it’s that user-based access controls just aren’t enough.
Helping us get answers to these questions are Jonathan Waldrop, CISO for hire, and Nick Ryan, the former CISO at RSM. Nick, I’m going to start with you. Why are user-based access controls just not cutting the mustard these days?
[Nick Ryan] Honestly, it’s a problem at scale, right? You really just don’t know people, you don’t know roles, you don’t know departments, especially as your organizations get larger and larger. It becomes a nightmare to be able to remember why permissions were given to so-and-so or should they still have them, things like that.
[Rich Stroffolino] All right, Jonathan. I’m going to come to you. Why are we still struggling with user-based access controls or the fact that they’re just not doing enough?
[Jonathan Waldrop] Yeah, it’s an idea we’ve had for a long time in the security space, and like Nick mentioned, we’ve got people that move around, we’ve got jack-of-all-trades that move from department to department, they need multiple permissions, and somebody new comes in, do they need the same ones?
Who knows? It really gets complicated, like Nick said, at scale where you’ve got lots of different things happening in an enterprise organization.
[Rich Stroffolino] All right. Well, today, we’re going to be talking with Rob Allen, the chief product officer over at ThreatLocker and a familiar face here on Security You Should Know. Now to start out, Rob, you know the drill. We’re going to be answering those three essential questions.
How do I explain the value of storage control to my CEO? What does it do, what does it not do, and the pricing model? Can you help us out here, Rob?
[Rob Allen] How do I explain the value proposition? Well, the value is, would you like all of our information to end up on the dark web for sale? No? Okay. Is there value in that? Yes, that’s broadly speaking the value proposition. What does our solution do?
It does many wonderful things. Helping you protect your data is just one of them. It’s a pretty important one, but it’s just one of them. And what’s the pricing model is, talk to us. It’s surprisingly reasonable, I think is the best way to describe it.
[Rich Stroffolino] Fantastic. Well, we know the problem. We’ve heard a little bit about what storage control is doing here, but I’m sure tons of questions here, tons of details to get into. So, Jonathan, what other questions do you have for Rob and ThreatLocker?
[Jonathan Waldrop] Yeah, so help us understand a little bit just high level, where it’s working. Is it working on a workstation? Is it in cloud storage? Is it in apps and databases, structured data, unstructured data? Can you elaborate on that a little bit?
[Rob Allen] Our focus, broadly speaking, is on the endpoint. So, endpoint being server, workstation, laptop, doesn’t make any difference, Linux, Mac, that kind of thing. Where we are slightly different to some of the tools that are out there, and as you alluded to at the beginning, Rich, the issue is user-based access control is not enough because generally speaking, the way these things are set up is that Rob has access to data.
The problem with that though, is that the attackers know that you have access to data and everything you run has access to everything that you have access to. So, whether it be a Chrome extension, whether it be a remote access tool, whether it be a piece of ransomware, everything that you run has access to everything that you have access to.
And as I said, that is something that they will take advantage of because, I mean, realistically, why does PowerShell need to access every file in my finance folder? It doesn’t. Why does a piece of ransomware need to access every file in our management share?
It doesn’t. So, if you can minimize that, if you reduce what programs have access to what data, you’re going to be in a much better position.
[Rich Stroffolino] All right, Nick, I’m going to come to you. What questions do you have for Rob?
[Nick Ryan] Yeah, I think the first thing is this, this reminds me of the solution from back in the day called Bit9, Carbon Black, kind of that running on all the different areas where there was a file control, where there was a location control. And I guess I’m kind of curious, one of the hiccups that we had when we ran that tool was how do you do it at scale, right?
So, if I have all these different departments, I’m not really sure who does what, do they need access to this application? How do you kind of shortcut the user experience to where they can get what they need, but you’re also putting the stop sign there to check it out in a way that is meaningful?
[Rob Allen] Sure. Well, there’s a couple of ways you can approach it, and we can do it both ways. There’s one that you can do it based on data. So, where that data is, restricting what programs have access to that data. Now, as you said, at scale, that can be a little bit tricky, it can be a little bit cumbersome.
Another way to do it is to look at it from the program level. So, if you look at it across an entire organization – as I mentioned, PowerShell’s a great example because it is so often used for data exfiltration – if you just look across your entire organization, you say, “Well, look, who or why would need to access data of any description with PowerShell?” The reality is probably nobody.
So, you can apply restrictions to programs in the same ways you can apply restrictions to folders. So, again, PowerShell needs to run, it needs to do things, it never needs to access a network share anywhere in my environment. So, why would I let it access a network share anywhere in my environment?
I mean, fundamentally what we’re doing is, and it is similar to the other tool that you mentioned, it’s applying the principle of default deny, but as well as default deny to what’s running, it’s also default deny as to what things have access to.
[Nick Ryan] Yeah, I guess the follow-up question that I would have there from a user experience perspective, is it stop dead in your tracks, and if this is an error email or a “click here,” what does that process look like from the end user perspective?
[Rob Allen] An excellent question, Nick. So, they will basically just get a pop-up saying, “Look, you can’t access this,” or “This program has tried to access that.” They’ll get a pop-up button, “click here” if you want it, if you actually need this access.
Comes through to an administrator. They can approve the request and within 60 seconds, the program will have access to that data. So, it’s a really smooth, really clean approval process, basically blocked, requested, approved, I’ve now got access, or it now has access.
So, it’s really smooth.
[Nick Ryan] Yeah, just one follow-up on that because this part is key is, is there an approval for every single process that tries to run? So, if it’s an installer pack and it needs to bring DLLs in, are you going to get a block for each one or is it once the administrator approves, the entire sequence is going to be?
[Rob Allen] So, that, short answer’s yes. That’s on the application control side of things. Chrome has got 50 different DLLs associated with it. I mean, effectively that, from our perspective, as an application definition, we capture, we have a definition that contains all of those DLLs, and all of those will be allowed to access whatever it is we say they need to be able to access.
So, short answer to your question is yes, we do take care of all those dependencies and other parts of programs, not just the chrome.exe itself.
[Jonathan Waldrop] Question for me on how it’s learning. So, either on initial install, what that timeframe looks like to get to from learning to a blocking mode, but then also is the program learning on the fly? And so, it’s saying, “Hey, Jonathan used to need to access these files here, but now he doesn’t because he’s in a new role.” Somebody forgot to change the RBAC, like we were talking about, it’s difficult.
So, does the system pick that up? Does the platform, rather, pick that up automatically, if you will?
[Rob Allen] So, it’s actually something we’ve always done. We, I suppose, taking a step back, what you begin with is visibility. So, what you begin with is who accessed what, where, and when. So, having that visibility, knowing who’s accessing what data is half of the battle when it comes to actually restricting or controlling access to the data.
So, we have always been able to do what’s called auto-populate, which is basically it’s not quite learning, but it’s not far off it. Insofar as I can click on a button, it’ll show me everything that program X or every data location that program X has tried to access, and then we can build our restriction based on that.
But it’s doing it based on the evidence of what we’ve seen rather than you or any administrator taking random guesses as to who or what might need access to what. As I said, visibility is half the battle. Knowing who’s accessing what and when and where is the other half.
[Nick Ryan] That’s a great question, Jonathan. The other question I would have for you, so when it comes to the data because I think that’s an interesting angle here is from the data perspective. So, say I have a PDF, but we’re not going to do an application block.
We’re going to say that this is a piece of information that we want to make sure that only the C-suite have access to. Can you walk us through what that actually looks like? Is that modifying the hash to approve only X workstations or mobile devices to be able to access that PDF, for example?
[Rob Allen] So, in the example you gave, which is a group of users having access to a PDF file, I mean, that is your traditional user-based access control. So, it’s our role-based access control or whatever you want to call it, so these users have access to this file.
What we’re talking about is basically taking that a step further. I’m not just saying Rob is in the C-suite group, so therefore Rob can access this PDF. What we’re saying is, “Okay, Acrobat, run by Rob can access that file. Chrome can’t, piece of ransomware can’t, PowerShell can’t, nothing other than the program that I specified that Rob is running can access that file.” So, it’s about basically adding to user-based access control or role-based access control, augmenting those rules with program-based rules, which means I can do what I need to do as a user.
So, I can access that PDF file that I’ve been given access to, but I can only access it with a specific program, not with anything. And again, being able to access that with anything is a large part of the problem because that’s how ransomware works.
It runs as me, it can access everything I have access to.
[Jonathan Waldrop] Rob, you mentioned earlier about the kind of one-off approval process for, “Hey, this person needs to access this,” or whatever. Is there a net scale version of that? At least in my experience, I’ve seen a file system have a nine-digit number, and it always flagged as a Social Security number type of thing.
But it was, “Here’s where the number lives on this piece of paper, on this PDF document, and we know that that’s a tracking number, not a Social Security number.” Are there those kinds of at-scale things where you don’t have to go through everybody has their one-off approval?
[Rob Allen] So, we’re not getting into the level of what data is contained within file types. So, we’re not looking for Social Security numbers, for example. Again, we’re just about controlling what has access to specific types of files. We’re not interested in the actual contents of them.
So, that wouldn’t really come up in the context of what we do. I mean, look, Microsoft and other vendors do a perfectly adequate job in that space, but as I said, the contents of files are really not of interest to us. We’re more interested in who and what has access to files, to data.
[Jonathan Waldrop] Is it interacting with cloud apps, like a cloud storage, like a personal Dropbox or a Google Drive or those type of cloud apps?
[Rob Allen] So, we do have a tie-in to SharePoint. Now it’s not strictly speaking for the same purpose. It’s more from a visibility perspective that our customers use the SharePoint connector, it’s just, “I want to see what’s going on in my SharePoint folders.” They can use that to trigger alerts on things like data exfiltration, or our CFO usually accesses 10 files in a morning.
All of a sudden, he’s just accessed 200 files. He’s either had way too much coffee or there’s something not good going on with his machine. So, that’s more the purpose of the SharePoint connector.
[Jonathan Waldrop] Gotcha.
[Nick Ryan] Yeah, speaking of that, I think that’s a great question to build on. Can you talk to us about what this looks like from a mobile perspective, right, with the workforce being distributed, you got people connecting from all kinds of different devices, and we do our best to be able to see all the devices that are connecting in.
But what does that look like from, we’ll go back to that example of the PDF. Well, if the CEO has the email, pull it up on his cell phone, right? It’s not going to be opened by the PDF app. Maybe it’ll be opened by Outlook. But can you talk to us about what that looks like from accessing, whether it’s data or applications from non-standard devices, if it’s maybe a token based on the user or if you include those mobile devices in the rule setup?
[Rob Allen] The short answer is not yet but watch this space. So, right now, I mean, fundamentally to do what we do, and obviously we’ve spoken about one small portion of the overall suite of products that we offer, but to do what we do on mobile is really hard.
It’s especially hard on iOS, primarily down to the restrictions that Apple put in place. So, for us to replicate what we do on other endpoints on something like iOS, it’s not quite impossible, but it’s heading in that direction. So, now we’re primarily focused on what we can control, and what we can control is what we can run on, and what we can run on right now is Windows, Mac, and Linux.
[Rich Stroffolino]We’ve got time for one more question.
[Jonathan Waldrop] Yeah, Rob, you mentioned earlier the various suite of products that ThreatLocker has. Does this DLP product stand alone? Does it need, does it require other products in a kind of a bundle type of thing from ThreatLocker? Do you have to run like a core agent for this DLP platform to run, or can somebody come in and purchase it standalone if they have just that point solution need?
[Rob Allen] In theory, you could. It would be highly unusual and highly unlikely because of the amount of protection that the other things that we do in terms of application control, ring fencing, so on, it would be highly unusual for somebody to just say, “We want a storage control.” I mean, it is the same agent, it’s the same portal, it’s the same bill, everything else.
Generally speaking, people will get our storage control alongside our application control and network control and everything else. It makes most sense in that context. Now, I’m going to probably get myself in a huge amount of trouble here, but what I would say is storage control properly configured, and there is a big asterisk beside properly configured, you could argue that storage control properly configured, like who cares if ransomware can run because it’s not going to be able to get at the data because I’ve got storage control properly configured.
Now, the problem is – properly configured, as I said, it’s a very difficult thing to tie down. So, where people keep data, this person might keep their data in their OneDrive folder, like they’re supposed to. This person might keep it in the root of their user folder.
There’s so many different data locations and trying to keep an eye and keep track of all of them is virtually impossible. So, I’d never say to somebody, “Just get storage control,” but as I said, properly configured, if this is set up right, the potential for damage or data loss is approaching zero.
It may not be actually zero, but it’s certainly approaching zero.
[Rich Stroffolino] Rob, what’s one thing we didn’t ask about that we need to know?
[Rob Allen]Physical storage. So, we didn’t mention things like USB drives. Very often people just completely forget about USB drives, forgetting about how practical, how easy, how convenient they are for people to exfiltrate data from organizations. It’s probably the easiest way for someone to take large amounts of data out of any business, any organization.
It’s just a USB drive, they’re that small, nobody’s going to notice you plugging into your machine. Unless you got serious auditing and logging turned on, nobody’s going to notice you copying files from your SharePoint to that and you just walk out the door.
So, control over those physical devices like USB drives is something we haven’t discussed, but it’s something that a lot of organizations very often miss. So, yeah, block access to USBs. Again, it’s the same process I mentioned. So, it gets blocked, requested, approved, allowed within 60 seconds.
So, it doesn’t have to get in people’s way, but you should not be able to put a USB drive into any machine in any business and walk out the door with data on it.
[Rich Stroffolino] Defending against the sneaker net, that’s what I like to hear. Well, that’s just about it for this episode of Security You Should Know. To learn more, head to threatlocker.com. And if you have any feedback about this show, send it to us at feedback@CISOseries.com.
A big thanks to Jonathan Waldrop and Nick Ryan for helping us learn more about what ThreatLocker is doing here, and a big thank you to Rob Allen for your time and being game to answer all of these questions. And thank you for listening to Security You Should Know.
[Voiceover] That wraps up another episode of Security You Should Know. If you like this program, please subscribe, tell your friends, and leave us a review. All companies showcased on this program are sponsors of CISO Series. If your company would like to be spotlighted and interviewed by our security leaders, go to our contact page on CISOseries.com or just email us at info@CISOseries.com.
Thank you for listening to Security You Should Know, connecting security solutions with security leaders.