Security Field Day Delegate Roundtable: Enforcement

So I'm gonna lead this discussion off for the next half hour by talking about something that was actually a topic of conversation just a little bit ago. And that's enforcement. So we can have the most carefully crafted security policy in the world, the most, uh, rigorously tested, legally observed thing.

And if we put it into practice in the wrong spot, nobody's gonna care. And they're gonna walk around it, you know, uh, it, the, the, the meme picture of the sidewalk with the gate on it. And then there's just open space around it, and everyone's like, yank gonna walk right around it.

So part of the challenge that we run into in these kinds of situations is effective deployment and enforcement of policy, but also because we're always fighting, uh, resource contention. As one of my favorite paddle tech YouTubers said, opportunity costs spares no one. We have to think about how we're going to be able to do this in a way that does not stretch our security operations team to their breaking point.

So I'm gonna go ahead and I'm gonna open the floor up to our delegate audience. Where should we be enforcing these policies and why should it not be the network? I would say it differs for each organization.

So you say shouldn't be the network. What about eds where you have b another situations where you have BYOD where you can't install an agent or push policies out to it. The network's, your only enforcement point to protect those and prevent them from being threats to your managed assets.

And you are, and to be fair, you are in a very unique position because your customers, your employees, so to speak, are completely unmanaged because legally you don't want to manage their devices. But, and that's in a higher ED EDU because for example, in K through 12, those devices, the, the official devices are fully managed devices. Like my kids whine about the fact that their, their laptops are filtered when they're at home.

But because it's a school asset, it is required to be filtered 24 7. So you have a unique challenge because you need to create an enforcement point that's close enough to the device to be effective, but can't be the device. 'cause yeah, look, kids just install this agent on your MacBook.

It's not gonna cause any problems, I promise. We're good if we can get them to go to class, much less install something we tell them to Fair. So, so there's one vote for doing it in the network because we have unique challenges at end user devices.

I'd argue also that if your end user devices are all mobile tablets and phones, apple ain't gonna let you run an agent on there. And IOT devices, I mean now iot devices are everywhere. We have cameras, we have refrigerators speaking to the network.

We have, you know, especially in enterprises. Oh, are you saying that a security camera could be used for nefarious purposes or a Fish tank? Yeah.

Yeah. Ask the people at shomi what it feels like to have their, their cameras being used as the world's largest botnet on a daily basis. Ask CloudFlare how it feels And as Jordan just, I mean, yeah, I mean, fish tanks absolutely.

Thermostats. Yeah. Yes.

I mean, smart refrigerators Lit, literally anything can be compromised because literally everything runs in OS that can be compromised. Now we're not in the good old days of like hand coding FPGAs with our, with FORTRAN to get it to be able to display a temperature. Now it's like, oh no, everything has a web hook.

Uh, I probably still have some infrastructure that is at PGS with, with fortran. So yes, the new stuff, but also from a critical infrastructure perspective, yeah. Legacy equipment.

But see a lot of people are, what they're wanting to do is take that, that legacy critical infrastructure and front end it with something that's easier to manage and that creates extra attack services. Because now not only do I have to worry about those crazy old COBOL bugs, but now I have to worry about did the company that made this box that's front ending my thing go out of business four years ago? When was the last time they got a security update?

Or, you know, if it's consumer iot, we'll just shut the stupid thing off because we can't afford to keep the servers on anymore. So, so we have challenges when it comes to enforcement and Jordan's thinking about something really hard, I can tell. Yeah.

Um, Jordan, why do you think that enforcement shouldn't be in the network? I, I wouldn't holistically say it doesn't belong in the network. I think the, the challenge is that historically we've looked at security as where can I create a choke point where my devices go through?

And traditionally traditional networks or traditional environments, that was the network. And that's why we kept installing security into the network. And that's, I think the default shouldn't be to assume that we put in the network going forward because the, the profile of where your users or consumers sit, where your applications sit, it's not what it used to be.

And we don't have the same choke points that we've always had. So there's always gonna be environments where you still have all of your devices or maybe you are responsible for protecting that network, in which case the network security is absolutely the right way to go about it. The, the challenge really comes down to this, is that we need security through depth.

I mean, we talk about defense in depth, but as you do that, the more enforcement points you have, the harder it is to keep a consistent policy across all of them, or to have a consistent experience for your users across all of them. And the more bifurcated that becomes, the more difficult it is for you to have a consistent application of that policy. And so there's a point at which there's diminishing returns and even risk by having too many enforcement points.

Mm-hmm. And so I think that organizations are, are challenged with how do I reduce the number of enforcement points? How do I put them in the right places depending on what I'm protecting, I think, I don't think we can default, like the, the firewall is no longer the thing.

Like that's no longer, we, we can't just funnel everything through a firewall and do it all there. What that looks like is gonna change depending on what your organization is and what you're actually protecting. You heard it from Jordan, firewalls are dead.

That's not what I said. I know. I, I'm terrified, Gary.

Yeah, no, I think, I think what we're, so two things. I, yes, too many enforcement points is absolutely a problem. Um, but that being said, we need different levels of enforcement at different parts along the path.

Mm-hmm. I do think what we're doing more of is pushing enforcement closer to the edge, as close to the edge as we can get it. Mm-hmm.

Yeah. So we're less funneling it through the firewall and letting it make all the decisions and or pushing it all the way out to the access layer devices as opposed to Core. So I actually want to talk about that thing that you just said because it's an important thing for people to conceptualize.

If you're old, like Wolf and I, you can tell about the gray hairs. Um, there is a three tier network model, right? Well, I'll just use Cisco's example because they're probably the most well known.

You have a core of your network that does certain things. You have a distribution layer that does certain things, then you have an access layer where all your users live. That model still exists, but I'm going to change the, the labels on it to make it make sense.

The cloud, the internet and my house, because that's how most remote workers look. Now, the corporate enterprise network access layer is riddled with Xbox and smart refrigerators. The distribution layer, which is where historically we have wanted to do policy enforcement because it's a choke point that everybody has to go through.

That's the internet. Good luck kids. And the core of my network where I need high speed packet switching and everything like that, where all my traffic eventually lands is now somewhere in Amazon, Google, Oracle, Microsoft, because we have moved everything to the cloud.

Great. For those of us who need to be able to log on and check things and run applications from anywhere in the world. Nightmare for my operations team, right?

Because how am I gonna secure this? Where exactly is the button in the Amazon works, uh, marketplace to install agents on all of my servers? I don't know.

So we've cr we've, we've essentially created the same model with radically different like components, but we're still thinking about it in the way we used to. Oh, well okay, I'm gonna install the agent on the SD-WAN gateway at my house. Dad, I can't get to Xbox Live.

It says it's content blocked. Can you fix it? I'm just gonna turn it off.

'cause my kids are whining louder than my boss. Policy enforcement gone. So can we still use the same ways that we used to do security in a modern world where there is no such thing as an enterprise network anymore?

I might add something and say, context is king And Oh, now you're gonna split hairs. Thanks Rudy. Hey, there's the, it depends answer.

That's What I was heading. Do you, do you give that power to the GRC team? An interesting conversation I've been having with Kerry or who gets to decide what happens and who gets to make that judgment?

Yeah. And I feel like that goes back to tool distribution, right? As far as, okay, if you have a help desk team and you have a SOC team and uh, an analyst team who's gonna make that decision to press the magic button to enable policy enforcement?

'cause sometimes, and that's not to, you know, say anything negative, but they may not have the, the skill set or the, the depth or that experience to go, okay, I have to make that judgment call and when to apply it when not to. So, and Who to apply it to because we all know that policy enforcement works great until you accidentally knock something off the CEO's machine. Exactly.

And then the phone calls start. Well, I, a couple things here though, I think we need to break out. We need to remember that just because it's enforcement points doesn't mean there isn't also decision points, information points, right?

And other things going, the integration between them. The second thing I would say is, back to your point about context. The way I tackle this is I wanna know my, my user persona, my device.

And that can be no user persona. If it's IOT to what you said and what resources accessing and then what is the path along that on building defense. I think the problem with, uh, I always get so frustrated with defense and depth because I'm like, okay, against what?

And applied where. So you're all dancing around something that, uh, Tom alluded to when he started talking about the changing model. And I heard you've mentioned this beforehand, but not now.

And that's this concept called zero trust. Oh Yeah. We're, we're Getting there.

Which is, this is where, not where we're getting to where we are. Yeah. And people who aren't here are the ones who are having a problem.

Right. If you're not doing zero trust, you're having these problems with, I think I have a gazillion policies and too many control points and too many tools. And part of what you're alluding to Jordan is not the fact that we have too many enforcement points that then gives, uh, confl you can't keep policies up to date, et cetera.

It's that the tools are not built to operate at scale because we've never had to operate at scale before. The people who do this zero, uh, trust at scale do not have these problems. And they've built tools to solve this, but to work at scale.

So Jack, I'm gonna poke on that for a minute because I'm going to make a supposition statement. The people who are doing zero trust at scale blew up their old model and rebuilt things because they realize the only way to get it to work at scale was to ditch the old model. Absolutely.

Because the old models do not work. Because you say that people who are doing zero trust have the don't have this problem qualifier people who are doing zero trust, well aren't having this problem. Yes.

'cause there's a lot of people that are about 20% into their zero trust deployment that are pulling their hair out right now because they can't solve a problem. I, and they're ready to, to kill it because they're like, we can't make this work because old thinking meets new model and they can't make them compatible when the real answer is ditch the old policy and craft something better to get around the problem. Right.

But, but explicitly zero trust is a different paradigm, a different way of architecting and thinking about security. You No, it's not, it's a thing on a checklist that the vendor told me that I need to put in here. If I wanna be modern.

The, the, the guy at the booth at the trade show, my CEO EO went, told me that he's Got a skew for you. Several excuses. When we think about zero trust, though, first off, back to enforcement, I think about the system model, right?

Mm-hmm. So we're talking users, devices, networks, applications, data. We may have Pips and Paps and PDPs across all that.

But secondly, I think though the thing that we all got wrong, anyone who's contributing, giving feedback to 800 to oh seven in this document on zero Trust obviously was it only shows one. Like there's, there's just one policy between your user and your device and your resources. Yeah.

Whereas the reality is we've got a multitude we're trying to integrate. So I, so my argument to that is two things. There's also, not only are we thinking about security wrong, we're thinking about identities wrong.

Okay? And everything we do, you can very simplify the entire security model by thinking everything that happens is an, uh, a thing. Trying to get access to a resource.

Yeah. It doesn't matter what the thing is or what the resource is. Authenticate that thing, authenticate the resource, decide if they're allowed to do the transaction on every transaction.

It's a very simple model. Yeah. When you don't distinguish between humans and non-human when you don't say there are 17 different categories of humans and 17,000 different categories of non-humans, it's a very simple model of we're simply trying to get access to this.

Who is what or who is trying to get access to what or whom? And authenticate on both sides, and then I'll decide to allow or not allow. Now, within that, you have different ways of doing those things, depending on the computation and tools and everything else that you have resources available to do this.

But it's the same activity you're doing all the way along. And if you remove the special cases, it becomes, and you you boil it down, it becomes a lot simpler to deal with. I've got a couple of comments on this.

I spend a lot of time in and around zero trust. Mm-hmm. Um, first you're a hundred percent accurate.

It's, it's not, we think about things and identity as a user, it's consumers and services. Yep. End of the day, you have something consuming a service.

You have the service they're consuming and you have to understand the flow between it. And that's the challenge. So when we talk about the challenge around implementing zero trust, it's the same challenge we had with implementing microsegmentation to implement zero trust correctly.

You have to understand every flow, every component, everything on your network. And so my, my challenge to this, you're gonna challenge me and that's fine. My challenge to this is I think the number of organizations doing zero Trust well is less than the number of people sitting around this table.

Because it is a, the idea of, of converting a Brownfield environment into a zero trust architecture is so radically different in the way that you approach in doing things to get to what I think you're about to say. And that is that you don't need to know it if you build the architecture correctly from the ground up. But no one starts there.

That's not a what I say. Okay. So I'm glad I could surprise you.

So I will, I will extend on what you said and then I'll argue with you. So I think about authentication, I think about authorization, I think about network level access. Those are the three, the A that I think about.

I agree. I think what I hear you saying, where I agree is if we say you need to know all your data, you need to know all your users, you need to know all your data flows, you need to know all your access flows before you build it. I disagree with that statement.

We Haven't been able to figure that out. I'm gonna with you. We haven't been able to figure that out for 30 years.

Never gonna happen. Oh, When I, so for organizations that built it fresh, they're probably in a great spot. Uh, I am on a very, my very much a brownfield, my oldest system traces back to 1967.

Mm-hmm. So I live in Brownfield. Uh, if you take it persona by persona, it has to be grouped up.

But there's 17 different types of users. We're not getting anywhere either. Right.

But if you take a persona by persona, use case by use case, I think you can apply it to a use case. Mm-hmm. And that begins a transformation as opposed to trying to architect fresh.

A Hundred percent. So the, it's not the entire architecture. I know we're kind of deviating into a zero trust conversation, but mm-hmm.

I wanna follow up on that. And that is, uh, John kinder bag, cloud security alliance. I love winding up, John.

Yeah, yeah, Yeah, me too. Um, but this idea of protect surface, so rather than thinking about your environment as an attack surface, that's, that's an old way of thinking. That's castle and moat.

My, my attack surfaces, all the things that are exposed that I need to address versus the protect surface, which is, let me define that. Das the data application. Uh, you know, surface all the stuff that is, is in and around the thing that needs to be protected.

And rather than trying to do everything all at once, kind of modularizing it and saying, okay, I'm gonna pick my most critical and highest risk applications and apply zero trust to that and then expand. And from what I learned on that, it's absolutely possible, but it's a long path. So I want to actually let Marian jump in here because we haven't heard from her yet.

And she's our remote delegate for this one. Marian are, from what you're hearing so far, what are your thoughts about, um, enforcement and things like that? So as an AI governance person, I work with clients who firewalls still do matter.

Uh, but I look at enforcement from responsibility, right? So where the business risk is at, I think you still need firewalls, but with AI driven traffic, you cannot just leave the endpoints, the cloud and SaaS unenforceable. I think you have to do it responsibly, uh, based on business risk.

And I'm the AI governance person here, so, So I'm actually glad that you brought that point up because to something that Wolf just said, I think that we're about to hit an inflection point. So what Wolf said right before this was we have to map everything out if we want to know how to protect it. Because if we, if we leave something unprotected, 'cause we didn't know about it, that's an entry point into our network or a possible place to steal things.

Mm-hmm. How hard is it to map out all of the applications, all of the user data flows, all that other stuff before, two years ago it was not impossible because there was no value in it, right? Why am I gonna track things if I don't get anything out of it?

But boy, what changed in the last 24 months? I'll give you a hint. There are 6 trillion reasons why, and it's ai because now mapping out all of those data flows for ingestion into AI constructs and to deploy AI agents for things like operations has a very real value attached to it.

So maybe not the reason why we're deploying collectors to Hoover up all of that data. Maybe the side effect, if you will, is that having a agentic AI deployed throughout my organization lets me track those things so that as a consequence of that, I have a better way to deploy it. Because going back to what Jack said, 17 different user personas that I have to keep track of becomes 17,000 user personas.

If I start having to do per agent persona security, that doesn't scale. So we have got to figure out a way to simplify the security enforcement model before we unleash a hoard of G on our network. Not to mention the AI regulations.

So you've got the EU Act and others that are gonna really put, uh, monetary fines around how you protect your endpoints and your SaaS points. Why you gotta be bringing up the law, Marian, but she's right, because I promise you the first person that lets their data leak out because an AI agent got tricked into to, to doing that. Do you know what 6% of your yearly global turnover is for a lot of these companies and eye watering amount of embarrassment thoughts?

Have you guys looked back to Jack's point? Have you guys looked at MCP and its authorization model though to keep you all up at night? 'cause once you put in agent ai, you wear it up to M CCP to get tools and everything else.

It's all or nothing. There's no like contacts. There's no re gate.

It's like the backup operators group in active directory. Yeah. It's like, oh, we'll just join that.

How bad can it be? Make it part of admin domain admin's fine. It gets everything it needs.

Yeah. But, but that's the problem, right? Is because we're still thinking about an old ultra permissive model.

It's the permit ip, any, any at the end of the ACL. We'll just stick it in here so that things work and we'll go back and fix it later, which is the second biggest lie that we've ever told in it. It doesn't get fixed.

Yeah. So It does after an incident, Right? Yeah.

Usually when it's CYA it gets fixed real fast. But, but, and this is the problem is we're, we're still running through this issue of whether or not we want to admit it. Most of us in this room have been doing this long enough to have old ways of thinking.

And the generation of people that are coming up behind us have new exciting ways of learning the same lessons that we did when we were their, their age. Because it doesn't matter whether it's a firewall, it some kind of a software construct or an agent that gets deployed, we go into it with the best of intentions. And what comes out the other side is what I like to call experience.

Because experience is what you get when you don't get what you want. And that happens a lot in security. So how can we give them experience while still imparting the knowledge and the lessons that we've learned over the years?

Okay. One of the problems that we're having though, I, I think, Tom, is that we, um, I think there was a, a stat out there that was like 80% of our time in it is just keeping the lights on. Yeah.

Like how do we just keep everything running? So then the other 20% is about trying to do something new, but we don't have the time at the end to bring in something new. Yeah.

So how do we, you know, I look, I, I can, I can go and I, I can paint my house and it's gonna take me all summer, right? If I'm doing it. But if I bring in and pay somebody, they can get it done in three days.

It's Yeah. It's remaining diligent and proactive and trying to find a more, it's, it goes back to one of my favorite automation, right? But like, how do we go ahead scale this to a point where there's accountability, things are airtight, everything's kind of covered.

The i's are dotted, t's are crossed, but there's no gaps because there's always gonna be those human, that human error element. Like one thing I just came across and I planned on making a video around it, but I haven't gotten that far, is there's a new point of attack right now they're looking at for EDR and XDR solutions where it actually freezes the solution itself. So now we are not just, you're not just, you know, that like forget the whole concept of what we've just been talking about.

Okay, here's the attack surface, how to protect it. Now we're destroying the tools that protect the attack surface. And what it does is it uses either a window or MAC based process.

Id kills it, it puts it into what they call a coma state. And that's it. And it's just like it's flooring.

Because now it's like, again, we're taking the tools that we use, we're disabling them, and now it's creating, creating multiple new attack vectors. So how do we, how do we accomplish all of that? Right?

And like I said, it just goes back to being able to scale it and automation. And now we have to also worry about protecting the tools that we use. Oh no.

We do it in the network. We don't have, we don't have to worry about the process getting frozen on the Mac because of the traffic has to leave the Mac anyway. We'll just do it in the network.

Right, right. Hey, we're back to where we started. Yes.

Full circle. Exactly. God Wolf's going to shoot me down, aren't you?

I love that tactic. I was looking at that the other day. It is super cool.

Yeah. And absolutely terrifying. Right?

This goes back to when we think about that, back to the protect surface, right? We think about the protect surface. We do need multiple enforcement points on that.

And we need to assume we, we've got to stop building our infrastructure and our apps with this idea that the firewall will always work, or the XDR will always work or everything will be patched. Yeah. We have to build it with the assumption that three outta my five controls are gonna fail.

Yeah. So I will, I will counter your argument with something that, that's a people problem. Because there aren't enough grizzled security admins that are developers because grizzled network engineers, grizzled security, um, analysts, we don't trust anything or anyone.

And developers. Well, a, as my friend Yvonne Pep used, used to say that PowerPoint is the world's most successful scripting language. 'cause everything always works in PowerPoint.

We'll just toss this thing over the fence and Oh, you forgot to install a patch on vCenter. And that means that now people have root access to the entire cluster. Not my problem.

I just wrote the software. Like we, we've got to get a tighter integration there. I, I, sorry, I have to say it.

Legally shift left, right? Whatever that means. Um, we gotta start getting people to think about security.

But I would say maybe more appropriately we need to get people to start thinking about failures and security. And Now it's shift everywhere. Yeah.

Go crazy. Also, you run into where not all environments are created equal. Like mm-hmm.

Say you're, you know, like I come from an MSP space, so we might have fabrication centers have an application that only works on a 2008 server. Mm-hmm. The patches aren't there.

Yeah. Who patches 20-year-old software, Right? It doesn't even exist anymore.

There's no patches. It's gone. You know, and we just, but we're still, we still have to be able to support that environment because they have these machines.

They're not gonna replace the machine that runs on a software that runs on an old server. 'cause our IT people say, well, your server's really old. Well everything's really old, but it still works.

We'll replace it when the wheels fall off And we can't find different wheels to glue together to make it work. Yeah. But the, The wheels fall off and then they're like, let's get the duct tape and put those wheels back on because It's some paperclips.

And Yeah, All it goes to, there's no one tool for everything, right? Because you're higher ed, you've got research, you've got teaching, you've got collaboration with various industries. All of those have to be secured differently.

One tool to do it all. Someone makes it, they're gonna be printing money, it doesn't exist. We also have compliancy and governance.

You have factor with both of those. Like, you know, like I said, MSPs, I might have a fabrication center, a hospital and a school district. And I have to have something that I can figure out how to make everything match for everybody or deploy how many different tool sets with how few analysts.

Yeah. I think the important thing to note there is that you have unicorns everywhere. Everything's a unicorn, But unicorns still have four legs and horns.

So there's always gonna be some semblance of technology that is similar enough through all of it, that what we end up deploying. You know, we're not gonna deploy a solution that requires my unicorn to have wings, for example. And I think that that's something that we need to understand.

It kind of goes back to what we've been dancing around here. We can't deploy anything anywhere until we have an accurate picture of what we're doing. And that means that for those of you out there who are listening, that working in enterprise, go out there, find the book of all of the things that have been mapped up and just throw it in the trash right now.

I know it was a lot of paper to print on. Now start over, map everything out, document everything. I mean, why do you think most zero trust solutions start in learn only mode?

Because they're discovering things you may not know about before you hit the big red lockdown button. Because until you know what you have to monitor and enforce, no amount of enforcement's gonna work unless, as I mentioned before we started recording this, you wanna put a police officer outside of every hotel door in this hotel.