Network and Security Convergence

Thank you so much everyone for being here. I'm so excited to be with you today. We have a great panel for you.

My name is Annika. I'm on the product team at Cloudflare responsible for our network services and joined by a fantastic panel.

We had Trey Guinn, who's the field CTO of Cloudflare.

Thank you so much for being here, Trey.

Gary James is the vice president and practice leader of US Network and Edge at Kindle.

Thanks for being here. And Aaron Severance is a managing director for client advisory services and cyber resiliency at Kindle.

Thanks again for being here.

So the conversation that we have ahead of us is around the convergence of network and security.

We're going to start by painting a little bit of a picture of where we've been.

We're going to talk about what's changed and some of the challenges that network security and IT leaders are facing today.

And then the exciting part we'll get to is where we're going. What does an architecture of the future that helps address those challenges look like?

But let's start by winding back the clock a little bit.

And Trey, I'd love if we could start with you.

Can you tell us a little bit about what your first job using a computer looked like?

And just paint us a picture of what the world looked like at that point.

Yeah, it's fun. I'm going to date myself, right? The back, I guess, first job was freshman year in university, came home, did a summer job doing data entry at a hospital, right?

It was like 1999. This is strangely the same year that MPLS was invented, right?

And so what does the world look like? You went to an office, you got onto a computer that was sort of chained to a desk, and you worked with an application and data that did not leave the building, right?

Everything was in one place.

If we did have email, you definitely couldn't get it at home. There was no remote work, there was no VPN, et cetera.

It was a very simple time. And I think one thing that made it so simple was just so little was digitized.

There was like a couple things that were digitized, and those were the things that ran on that simple network that was maybe like one building or two buildings.

So it was a funny world way back in the dark ages.

Yeah. And then Gary, what about from a networking perspective?

Well, I mean, if you think about it now, the networks themselves weren't software defined as they are today, right?

You had typical MPLS connections that were out there.

You also had multiple different point solutions for products that were sitting out there as well.

I mean, really the legacy network architecture that, you know, really isn't in today's modern contemporary network architecture.

And one thing I didn't hear you say is security, because as we know, network and security have been siloed for a really long time, and especially in that legacy architecture.

But I wonder if Aaron, you wouldn't mind touching on that too.

Yeah. I mean, I think if we're talking about the late 90s and the early 2000s, the concept of network security, let alone IT security, just really wasn't a significant player in the conversation at that point.

At most, you would see firewalls for consideration for protecting a data center or protecting edge access.

And then for the most part, identity access management was managed by your server administration teams.

And data architecture didn't really address security at all.

You really weren't talking about encryption at that point.

So it's a very different world that we're looking at today. And don't even get me started on OT.

Those guys were in a cave and didn't really participate in the traditional IT conversation at all at that time.

Crazy simple world, right? Yeah, very much.

I mean, like security didn't have any risk to manage because there was no digital systems.

Yeah. And yeah. So I guess it's a little different now. Yeah. Our customers will articulate this sometimes as castle and moat architecture.

Everyone's familiar with this concept.

But the idea is you have your applications and your users all within this corporate perimeter.

And then you can have a moat and someone sitting and watching every packet or request that comes in or out of your network and enforce security that way.

And what our customers have described to us is the two major changes that have created a lot of challenges for them.

And we'll get into what some of those challenges look like in a second.

But those shifts are the applications leaving the data center, right?

The shift to the public cloud, embracing SAS and IaaS and just moving those applications outside of the purview of sort of within the corporate WAN.

And then the other shift was users, right?

More recently, maybe, but users now in a lot of cases can work from anywhere.

Companies are continuing to embrace hybrid work. And so you went from this picture where everything internal was literally internal inside within this physically defined corporate perimeter to now users can be anywhere and applications can be anywhere.

And that means that the way that you have to think about access and also think about threats has totally changed.

And so Trey, you spend a lot of your time talking with customers.

I wonder if you have some examples or maybe stories of what this looks like for some of them.

Yeah, it's interesting. You see organizations that go down this journey, right?

They've started to adopt cloud computing 10 plus years ago, but the goal was trying to make their infrastructure more dynamic, be able to deliver applications in a faster way that was sort of supporting the business and able to respond to market demands, etc.

And that made sense.

That was sort of the step one. So we have this big shift towards cloud computing, SAS, etc.

But now I talk to customers, they said, okay, we've done that.

That works really well. But the thing that connects the user to the application is still kind of in that like 1999-esque world.

There was a big bank I talked to out in New York and I was like, I'll forget this, but I was asking them, what's it like with your networking and security teams and what are some of the challenges you face?

And they said, well, let me tell you a story. We made our developers really productive because we've got these dev environments in the cloud.

And we can spin up a brand new dev environment in 30 seconds application server, database server, etc.

And it's literally like an API. 30 seconds later, boom, we've got a dev environment.

And back in the dark ages, we'd had to order some equipment from Dell, wait for it to show up.

So it's just a night and day difference.

But to connect our developer to that environment still takes 12 change tickets that take about six weeks to get done because they go to four different teams.

And literally at the end of that, you have a person who's manually taking a ticket and clicking systems.

And if it goes correctly and no one makes a mistake, then six weeks later the developer has access.

And you're like, okay, this is just an unacceptable environment.

It is interesting how the application environment has moved along so far, but the networking environment and how dynamic the security controls are is really holding the business back.

Yeah, that makes a lot of sense.

And I love that analogy too. And that's totally how customers have described it to us.

It's like networking and security are 10 to maybe 20 years behind depending on who you talk to in this cloud transformation.

And it makes sense that it happened in that order.

I mean, it wouldn't have made sense to develop a whole bunch of cloud native networking stuff without anything to connect behind it.

But now we're in this place where customers are managing these challenges.

I wonder, Gary, what do you hear from customers about some of those challenges and what they look like in the networking world?

Challenges in the networking world?

On a daily basis, we hear things like just the standard of provisioning services or onboarding services from a networking perspective at baseline.

How do we order the services? How do we turn those services up pretty quickly?

We live in a very self-service type world where it's more, from my humble perspective, it's more of a request fulfilled type of activity where, hey, I'm requesting something.

I'd like that fulfilled and I'd like to be able to turn these services up.

The challenges that we see with our customers from a networking is it's not readily there in a traditional sense right now.

And so that's just one that we actually deal with.

So that lack of agility like Trey's talking about, that makes sense.

And then how about from a security team's perspective? I imagine agility also is a problem, but what other types of things are they managing in this new world?

Yeah, it's kind of been a perfect storm in the security space, right?

We touched on application mobility. We touched on users and remote user work environments, sort of expanding the landscape.

But the thing we hadn't really touched on yet is data architecture.

And now, not only can my application be anywhere and my users can access it from anywhere, but now my data could be anywhere too.

It could be housed in a SaaS application, it might be in a cloud environment, or I might still have a home data center that I'm trying to manage that data from.

Suddenly, I've gone from needing to secure a home data center and maybe a few satellite locations to now I've got to secure this entire architecture and how the data is moving between all of those points.

The nice part is that the security approach, the frameworks we're using to address those principles are evolving as well, right?

So now we've gone from what were point solution oriented security solutions to a NIST framework that sort of set a standard of landscapes and now we've evolved into this Zero Trust posture that allows us to talk about Zero Trust frameworks as a way to ensure that we're protecting the data sets, the application set, and the user set in a very intentional way.

And that users are only getting access and authenticated to the specific data they should have access to for the very specific point of time that they should have access to it.

And oh, by the way, we're going to plug in that that also means every access point is potentially a bad actor and we're assuming our network's already breached.

So how do we recover from a breach in our environment? How do we limit the blast radius?

And how do we ensure that we're getting visibility across all of our tools and our capabilities?

It's a very different view from where we were even three to five years ago.

So now we have this framework or the principle or however you want to describe the concept of Zero Trust.

And for the most part, it feels like security practitioners have this understood.

But are we done?

Have they implemented it? What does this actually look like in practice or are people still facing some of those challenges that Amy, Trey, and Gary alluded to?

What I throw onto that too is that we're asking, this is classic, right?

We're asking the network guy and the security guy how you're addressing this.

But this is actually a common problem. It absolutely is. And I think the great point you're alluding to is that both security and network are an ever -evolving landscape and we're seeing new threats emerge.

We're seeing new technologies emerge all the time and it's enhancing the way that we're supporting our environments.

So even in the security space, even this year, generative AI, quantum computing the most recent discrepancies that we've seen on some of the major hacks around tool disparity and tool sprawl that are driving disconnects in the way that we're managing processes and services, it just makes the job harder.

And then when we start having disconnects between teams it makes it virtually impossible.

Yeah, you said tool sprawl, which is something I think we hear a lot from customers, right?

You alluded to the threat landscape is evolving so quickly, so there's these new problems that pop up all the time.

And there's lots and lots of vendors that are very excited to sell you a new shiny solution that helps you patch that one problem.

And so you have this pattern in security teams where a problem will arise or a new threat arises we need a tool to solve that.

Let's go buy the tool to do that thing.

And then before you can even actually fully implement it, maybe halfway on board and you're in monitoring mode there's another threat that popped up.

And so I talked to a customer recently a bank in Australia that just finished an audit and they have 80 plus security tools.

The vast majority of those are in monitoring mode today.

And they weren't super confident that even if the tools had caught something that they'd be able to sufficiently go back and look through their logging information and even in post understand what was going on and track it down.

So that kind of sprawl I imagine is super complicated for security teams to manage.

And that's so challenging. You were just talking about an organization that is well intentioned, that they're trying to address the problem.

They actually have budget to go buy all these tools. But then where's the bottleneck?

Is it that complexity is increasing at this sort of slope, the rate at which complexity is increasing is just very unsustainable.

And then you still have human beings at the other end of this.

Where's the talent that knows how to be sophisticated on 80 different tools?

There's the cost of the tooling but also the talent.

It appears to me that that method of new problem add a tool, another problem, add a tool.

Clearly that model breaks over time. Because we know we're going to have more and more problems.

Right, you get about an inch deep mile wide across multiple tools.

You get the tool sprawl, you get the vendor sprawl. It's common.

We see it every single day. And so it becomes part of a consolidation type of tactic.

And different disciplines, different domains bringing in their own tools that overlap or have different functionality or create conflict.

I mean you're creating an ever growing problem.

And not to mention M&A, right? You go buy another company and then they've been on the same journey.

And where you might have 15 different tools for solving X, Y, Z problems.

They have the same problems but they pick 15 other ones.

And so then now you have just this kind of compounding problem.

My favorite line I hear from every large enterprise is, we have one of everything.

Yeah, we love buying tools. Just to kind of wrap up this point, a statistic I thought was interesting from a survey recently done by Software One.

72% of respondents believe that their organization's digital transformation efforts are lagging due to technical debt.

And 51% cited complex legacy IT infrastructure as one of their key challenges over the next year.

So we hear this from our customers in the stories that they tell us about their pains.

But then it plays out in the numbers too.

Okay, so this is kind of depressing. Like we talked about where we started and then we have all these problems now.

But I don't think we're doomed.

I think that there's a better future ahead of us. So if you had to go back to that, maybe that banking customer that you talked to, Trey, they painted you this really exciting story about what their cloud transformation has looked like for storage and compute.

What would you tell them about what a better future looks like for network and security?

Yeah, I think what we see is this need for networking and security to be delivered in the way that cloud computing is delivered.

This idea of, I want a service, I call an API and seconds later, it's delivered to me.

Actually, even better than just hyperscalers, because even with hyperscalers, you have to pick where something runs.

I think the cloud providers that do this really well, like email providers.

If you're going to go get a thousand more inboxes from Office 365 or Google, you don't think anything about it.

You call an API and a thousand mailboxes are up and running.

And you don't think about where in the world it's running. You don't think about latency.

It just works. And it's amazing to think of how could we get there with networking and security?

If I want an identity gateway, click a button or better yet, call an API.

If I want a load balancer in place, if I want other sort of controls and visibility in place, I want to connect a cloud environment to my network.

It should be done with an API call. It's delivered in seconds. I think that's the world we look at and it requires this interesting convergence, right?

Because the network becomes the obvious place to provide security controls.

And so instead of there being a network guy and a security guy, this should be the networking and security team.

And maybe over time, it's just the networking team and they just happen to do security, right?

Or security team. But, you know, that's the world I think we need to get to, which is this converged service.

Because it's the thing that can connect your on-prem mainframe with your cloud environment, your users no matter where they are, and it should just be ubiquitous and actually deliver the benefits of what cloud is supposed to be.

Cloud is supposed to be ubiquitous, infinitely scalable.

You're supposed to just be able to consume it.

I don't want to have to think about scaling up, scaling down.

So, you know, that is at Cloudflare what we're calling connectivity cloud. We think that this is actually where the industry is going, not just ourselves.

Over time, there will be lots of connectivity clouds.

Clouds because it's like a cloud provider.

You just call an API and it's delivered to you as a service.

But it's connectivity because it's bringing together all of these disparate systems.

And so that, I think, that's the future is how do you move to a sort of connectivity cloud model.

So what I'm hearing is consolidation or convergence, not just of lots of individual different point security tools, which is what we were just talking about, Aaron, and putting those all in one place.

That doesn't actually solve the problem for you.

You kind of really need to weave the networking and the security components together.

I'm curious, either Gary or Aaron, whoever wants to go first, like what would that look like for you in practice and maybe what are some of the outcomes that you can imagine customers seeing in a transformation like this?

I think ultimately, right, what we're seeing is a coalescing of tool sets into a more platform model.

You're seeing a lot of the big suppliers come out with more of an XDR mentality where we're no longer talking about EDR, MDR, SOAR, or SIEM as multiple tool sets we've got to integrate, but they're all being integrated under a single umbrella, a single pane of glass, a single capability that accelerates our capability to acknowledge alerts, to process signals, and to respond to true events in a shorter time frame rather than responding to the noise.

I think the great thing about, as we're talking about the consolidation of network and security, that same conversation is playing out in the WAN and the multi-data architecture landscape, right, where I don't want to worry about managing a WAF in my cloud and a firewall back in my data center and a capability out there.

I want a centralized tool set where I can manage those policies in one place and I can quickly architect and deploy that solution without a big headache.

Ultimately, skills consolidation, optimization, and tools. And I think Gary's...

Yeah, customers should not be afraid to move from a best -of-breed approach from a tooling perspective to a best-of-breed approach from a platform perspective, right?

And the keyword being platform. 100% on tip. What I'd like to see is that that bank in New York go from, hey, in 30 seconds can spin up a dev environment, and five seconds later the connectivity's done, right?

And all my controls are in place. Even if that was 12 tickets, the second someone clicked approve in their ticket system, just a bunch of APIs got called and you're done.

That's the world we have to move to, because then you have businesses that are able to respond to market conditions.

Also, you think about the talent and the folks that, if your job day in day out is to get a ticket and then log into a system and make a change, and then get the next ticket and log into a system and make a change, that's a miserable existence, right?

We have a bunch of engineers, we're talking about talent as a problem, but we have to develop this talent and be interested in, why don't you take that person and help them become a developer?

Someone who's building DevOps pipelines. So I think there's so much potential for not only the businesses to be more agile, but also for the human beings involved in these systems to have a much more interesting career development as well.

Yeah, don't underestimate the time to value to get a solution to market, right?

That is a key metric to where you can capitalize on that to get that opportunity or capitalize on that opportunity.

That time to value actually goes, it goes down.

Absolutely. So I'm hearing a lot about agility, reduced complexity, making it easier.

And I love your point about talent too. I really feel like that's one that's underserved in these conversations a lot of the time, but I consistently hear customers talking about I can't fill these positions that I have open right now, maybe because they're trying to find someone that has expertise in any parts tools.

But there's, you know, once that shifts, then there's a different problem.

How do you keep people engaged and have them working on interesting, high value, high leverage work?

What else if, you know, someone in this room or watching this is thinking about trying to make the case for their organization to go through this kind of transformation, like beyond agility, what else do you get at the end?

Jumping in, you know, one, there's just, there's the raw cost side, you know, generally consolidation leads to lower cost.

Both in the tooling, you know, it's interesting. I think there was a Gartner survey about this, that like two-thirds of people were doing consolidation.

Hopefully I don't get the numbers exactly right or wrong, but I think about two-thirds of it was actually to do with reduction of complexity and one-third of them were doing it to reduce costs.

So one, you get a cost reduction, but the complexity reduction, you think about the cost that has on the business.

Actually, I think the overhead costs, right?

Yeah. Yeah. There's overhead costs. There's, you know, all the staffing, et cetera.

The really compelling thing to me is the opportunity cost. So if you think about I've, I'm a business and we have a new way to interact with our customers.

We want to launch a new digital channel. There's this change in the market.

The difference between being able to get that new channel up and running in a month versus six months.

Like how much is that five months of revenue worth to your business?

Like that to me is generally far outweighs the other costs that we're talking about.

So that's a business agility argument, but really that cost there is huge.

Yeah. So I heard three. Service cost, overhead cost, opportunity cost.

So when you're doing an evaluation of a project like this, like focusing on any one individual of one of those is missing that bigger picture.

Sorry.

Yeah. Speed to execution, frankly. I mean, how quickly can you execute on what Trey was talking about?

Having the ability to have all those, have services consolidated in a common manner and your ability to be able to execute on that from a business perspective, because you always want to look at it from a business perspective is key.

So speed to execution. I think that's absolutely right. I think that the final piece of that puzzle is that as you're consolidating tool sets and moving into a single platform, you get increased visibility, you get correlation and you get advanced analytics.

All of those are going to drive perspectives you haven't anticipated yet.

They're going to help identify problems you didn't know you have.

And again, back to that conversation around reducing noise in the system, you get better response to true incidents rather than chasing ghosts in the system.

And maybe last thing there, you mentioned visibility, but I'm curious, we started talking about from a threat perspective, right?

The threat landscape is evolving so rapidly, which is why we have all these point solutions.

So what would you say to, you know, maybe a security practitioner that says, well, I've been taught like defense in depth and I've been taught best of breed.

And I've been taught, I see a new threat, I need a tool to be able to handle that threat specifically.

And now you're telling me, like, I don't need 20 different things, but there's still more threats growing.

Like, how would you answer that concern? I think that's the interesting path that the Zero Trust conversation takes us down.

Right? At this point, we've already assumed there's some level of breach in our system.

So we need to be somewhat disciplined in sitting back and saying, okay, there's a new threat in the landscape.

There's this new idea that maybe I can get attacked from a new vector or a new vulnerability I haven't anticipated.

I need to be able to, one, take the time to understand that threat and make sure I'm putting in tools that address that.

Two, I need to make sure that I've appropriately categorized that new threat that's shown up in the system.

Right? Is it a zero-day threat? Do I have a week to patch?

What's the true level of the vulnerability? And are my tools set up to accommodate that?

Existing? Can I just patch my systems or do I really need a new tool to assess that and incorporate it?

And then finally, if I make the call that a new tool is required, I strategically select a tool that's either integrated with an existing tool set I already have or serves that purpose for a specific reason but has the ability to be API or a CSF compliant so I can integrate that tool set into my existing monitoring stack and get valuable signals that I can then respond to.

If I'm falling short on any one of those, you need to take a look at your landscape and understand, are you more vulnerable across your architecture than you originally anticipated and is there a bigger conversation that needs to be had?

Yeah, at some level it feels like it's kind of a shift from thinking about security in sort of checkboxes, which to some extent you still have some checkboxes.

Compliance is a very real thing, but thinking about outcomes instead or figuring out other ways of measuring success for your security team other than, okay, do we have a this?

Do we have a this? Do we have a this? Those capabilities will be there in the platform.

So then if you assume that all the boxes are checked because you have a unified platform then what can you focus on next?

It's interesting how we say that incentives or what you measure drives behaviors, right?

And so what should we be measuring as security and networking professionals?

Maybe it should be when you do an acquisition, how long does it take you to acquire and integrate a company?

Or if you are, what is the time to onboard a new employee, time to onboard an application, time to launch a new digital channel?

You talk about moving fast, start to baseline those things. If I was trying to make an argument internally, I would say, okay, you know, when we hire a new employee right now, it takes us X number of days, like this should be done in 5 minutes.

If we can go from 3 days to 10 minutes, what's the benefit to the organization?

It's really about enhancing the internal process which is natively built to a platform and process improvement in any organization is always good.

Okay, so this is a great story. I think I'm sold. I think this makes a lot of sense.

But how do customers actually get there? Like there's no magic wand that they can wave that will transform suddenly an entire legacy architecture, all of those different point solutions, lots of probably still hardware and physical circuits and like people have a lot of stuff.

And so how do they get from that world to this really cloud native Zero Trust architecture that we're talking about?

What does that process look like? I think it's a transformation journey, right?

And I think ultimately every organization is going to approach that a little differently.

I think we've helped a lot of corporations and customers take that journey and having a third party come in and help you step back, see the forest for the trees and understand where you might be having some challenges, architect a unified approach and really develop a road map that gets you to that end state is valuable.

I think a lot of us are caught up in day to day operations and we're stuck in firefighting mode.

I've got this new problem I'm trying to face or this exposure or this cost cutting exercise that I'm having to account for.

And it gets very hard to step back and think about that big picture.

Ultimately having somebody that's walked the journey helps accelerate it.

Gary, try anything you'd add. Yeah, well obviously it's not an overnight thing, right?

These are journeys, they're big changes and so we have to think about how to do that in a progressive way.

I would echo a lot of what you said, which is it's hard if you're the frog in the water and it's heating up to know that there's a world outside of this pot.

I think it's just a human thing, particularly when every team I speak to is absolutely overwhelmed.

I have yet to meet a networking or security team that says, I'm bored.

They're like, I've got all this free time, we don't do anything on Fridays.

So yeah, trying to get someone to be able to bring that up, but also just to have that perspective.

It's so challenging if you have been doing things a certain way your whole career to sort of shift a mindset.

And I think within organizations people are normally open to working in that direction, but getting some guidance of what a North Star could look like is hugely valuable.

But then tactically, some of the customers I've talked to, they tend to just find the places and either working with an advisor on this, but define a North Star, define all your milestones to get there.

What do you do first?

What do you do second? You realize that you're going to be, this is going to take time.

You need platforms that are integrated and that sort of play well with each other.

And where you start generally is where you just get the biggest bang for the buck as fast as possible.

There was a big manufacturer I was talking to a few weeks ago.

I was on site with them. They have 500 factories around the world, literally every geography.

And where do they do migrations first?

They're like India and South America, because that's where they were just bleeding dry on telecom costs.

So that's just a very tactical way of how do you get started with this?

Because they're starting this transformation. They know that they want to bring networking and security together, but it's so easy when you're sitting under constrained P&L to say, okay, I can actually pay for the transformation by finding these expensive places to take over first.

Yeah, that's a great point.

Okay, so kind of the combination of two things, North Star and bringing in someone who's done this process before to help you understand what a North Star could look like, that's important.

But then milestones along the way and making sure that those milestones are associated with tangible wins that you can actually see for the business.

That's really important because you don't want to be in a situation where you're like, okay, here's the North Star.

It's all the way out there.

Maybe some of us can see it, but we're going to have to do two years of work before we start to actually realize any of those benefits.

Yeah, because there's going to be some new threat that shows up tomorrow.

Everybody's going to pivot focus to that and then we're going to maybe not lose interest, but lose focus.

And that's going to make that hard. Whereas if you have a deadline that's like a month out, then you know you're going to be able to save $10,000 on an NPLS circuit that you're deprecating at a couple of locations or whatever, then that becomes a lot more compelling.

And of course, you don't want to forget that this transformation is not just about technology, right?

Like it's also the people.

We talked about that process, improving process internally, but that generally means you have to go talk to somebody else.

You're going to talk to another team, figure out why this took so long before because, you know, it was always a, you know, pass off a request to the next team and the next team, the next team.

How do you get these teams to work more in sync and with each other? Having an external perspective on how to do that better also is help.

Yeah. I love that you mentioned so not just technology and I think at Cloudflare we're all nerds, so we like to talk about technology a lot of the time, but it's such a, it's so much more in many ways of people, process, a culture thing.

I'm curious from Kindred's perspective, like what has been helpful in helping organizations really embrace or have a cultural shift that enables this kind of transformation to be successful?

It's a methodology fundamentally.

Absolutely. Yeah. It's kind of a systematic approach in terms of how you want to do it.

To your point, I mean, you've got to identify the quick wins or the milestones to keep everything on track and keep everything progressing from that perspective.

I mean, it's the same thing that we do on a regular basis when we're looking at customers through an evaluation or an assessment or any of these type of things and how we structure them.

I completely agree.

And I think ultimately it's about the mindset. A lot of these projects, when you start talking about, I want to revamp my security approach, well, what does that do to impact the data architecture?

What does that do to impact the network architecture?

What does that do to change my end user experience, right?

And all of these conversations have to be had with the various groups. Ultimately, when you start talking about a big change or transformation at this level, organizational change management is going to become part of the conversation.

If you're not addressing it as part of the project plan and the implementation plan, it can easily turn around and bite you and all of a sudden your project comes to a halt when you get one very vocal business unit that says, no, we're not going to adopt that change or you're making my business too painful.

So you need to make sure you're incorporating organizational change management methodology into these bigger transformation conversations or you're going to stall.

Yeah, that makes sense.

We're here in Chicago this week. We had our customer advisory council earlier today and just maybe one last anecdote to wrap this up that was helpful.

And again, thinking about how those milestones along the way can help build momentum.

I talked to a security representative from an oil and gas company that's along their zero trust journey.

And the person I was talking to was saying initially there were kind of a lot of skeptics about embracing this new technology.

And they're like, oh, we already have so many tools in place.

Like what's another one? And didn't even get the chance to explain we'll be able to get through to these three when we adopt this one.

That resistance was there. And then they onboarded a couple of applications.

They picked like five. And they onboarded those to Zero Trust network access and started using that model instead.

And the next day this guy got a call from one of the people on his team that had been a skeptic about the change.

And he says, hey, did you fix something?

What did you fix? He was convinced that maybe nothing in the access flow had changed, but there was something about the application that they must have changed to create a better experience.

And the security guy was like, no, actually we're just we're accessing the app in a different way.

And the performance maybe could have been like this all along if we didn't have all of this cruft and the backhauling and all this stuff in the way.

And that totally shifted the perspective of the rest of the team.

And they were like, oh, well, let's fix everything.

Let's get this in place so that we can have a better experience across the board.

And so I think making it so that people can see it and feel it in a real way in their day to day workflow is massively beneficial.

Absolutely. To your point, stay focused on why we do this in the first place to serve our end users.

Right. So, yeah, that's amazing. Yeah. Maybe one last question on this piece.

We talked about metrics or measuring success earlier.

If you were going to go advise a customer about this transformation, what are some of the ways that they could know along that journey other than getting calls about, hey, do you fix this thing?

How can someone know that they're doing a good job or that they're headed in the right direction?

Maybe security. Don't end up on the front page of the Wall Street Journal.

Yeah, that's a good metric. No, seriously, though, security is an evolving landscape and we're all dealing with threats on a daily basis that are sometimes tough to keep up.

I think you know that you've got a successful security methodology in place if when you are breached, you know about it quickly, you're able to limit the blast radius, you can quickly contain it and you've got a clear recovery plan.

If your CISO can go into the CEO's office on Monday after you had a breach on Friday and can say it's contained, it's cleaned, we've run the forensics, we know where it came from and we restored the system, you're in a great place.

You're ahead of 90% of the companies out there.

If you're still talking about it two months later, you got a lot of work.

Anything else on outcomes? How do you know if you're doing a good job?

To your point of whether you're doing great if you've got it sorted by Monday versus waiting two months, a lot of that is making yourself relative to other organizations and so I think probably the biggest thing is make sure you have a community of folks that you surround yourself with, connect to other professionals, you're the version of you at another company.

You should have this group that you can get together and compare notes and say this is how we operate, this is where we're succeeding, what can we learn from each other and I think that openness is hugely important.

As an industry, we can learn from each other and then also you really get a feel for am I doing as well as I should be or am I sort of lagging behind my colleagues at other organizations?

Absolutely. And a lot of that feedback can and should be anecdotal so that you can get the really deep, rich stories and that's why I love things like the advisory council where we meet with our customers and they can all share best practices and stories with each other about what these journeys have looked like for them.

But also just as a product person I've got a lot of feedback that people would like to see us surface that as sort of aggregate statistics across the board in maybe it or analytics.

I think we do a good job today at saying here's an overview of your attack surface, we can show you the point of view across your security posture across the board but then being able to compare that in an anonymized, aggregated way and say here's your security score or something compared to other customers that are of a similar size or in a similar industry.

Giving people something that they can kind of anchor on and understand okay, this is how I'm doing because I get the sense that people don't really know.

You know if you're doing a good job within your own job, within your own company but if you aren't having those conversations it can be challenging to understand where you stand.

But I do want to hear from Gary, right?

I mean we started the conversation talking about long provisioning times and challenges with some of the painful points of how I get my network solution incorporated into my bigger conversation, right?

So what does good look like in a network space?

You know, just when you're talking to a CIO or CTO and if they see how quick the business can actually put a plan in place and then it triggers some sort of IT event downstream and that IT event actually bubbles back up and says okay, this is in place, here's where we'll go and we're prepared to make that and move at the speed of business.

Those are the key metrics from my perspective. Perfect.

That's great. Thank you.