Q & A with Matt Hoag, CTO, Koch Business Solutions, Taking on Zero Trust, Episode 2

James Winebrenner, Elisity CEO, and Matt Hoag, CTO Koch Business Solutions, discuss partnering with disruptive technology startups to secure and modernize complex manufacturing environments.

Over the past decade, Matt has focused on strategic roadmap development and execution at Koch Industries. He has helped lead organizations through infrastructure modernization efforts focused on ensuring the success of moving significant portions of their application portfolio to the cloud, while improving the end-user experience. 

James: Matt, it's great to sit down with you. Thank you so much for taking the time. I'd love to just get started with you sharing a little bit about your background and your role with Koch.

Matt: Yeah, I appreciate you inviting me, James. So I'm with Koch industries, I'm actually part of the Koch Global Services Group. I've recently started to transition into the chief technology officer role there. I've been at Koch for a little over 20 years. And been in various different IT technology roles and seen a lot of different changes over the years. Over the past five years, I've been with the enterprise architecture team and really starting with a mandate of how do we really digitally advance the business. As we kind of stepped back and looked at this, it was one of those things where we felt like our core infrastructure just wasn't prepared for that, from a network, a compute, application, really working up the stack to really modernize those things and prepare for that digital business future.

James: I think, for me, it's been really neat to get to work with Koch over the years, just because of the breadth of what the portfolio represents. Please share a little bit about some of the different things. And I love that, you talk about digitization in a way that it's a very much a physical infrastructure company. There's so much that's happening from a physical infrastructure perspective.

Matt: When I started there it was just the core Koch companies. And then in 2004, we had an acquisition of Invista, which was the DuPont textiles and interiors. The Invista acquisition doubled our footprint from a employee base and from a location base. 2005, we acquired Georgia Pacific, which doubled us again and talk about some growth pains there. And over the years we've had several large step-out acquisitions, a lot of organic growth as well, and I think a lot of our businesses are kind of that manufacturing footprint, a lot of physical infrastructure, those types of things. But most recently we've been doing a lot of acquisition and investing in more technology based companies as well. We recently finalized our acquisition of Infor. And then we have Koch Disruptive Technologies that, as the name would allude to, they invest in a lot of things that are going to be disruptive to the world from a technology base.

James: It's awesome to see the growth. And again, everything from paper towels to oil, to textiles. And now, I think what's really cool, is to watch the ability for you guys to then sell Disruptive Technologies back into the market and help other organizations that are going through that transformation. So, it's an incredible portfolio.

James: I love your perspective, Matt, because you get to see across all of those different internal stakeholders and internal customers. As you sit here at the beginning of 2021, what do you see as maybe the biggest opportunity and also the biggest challenge in terms of the business and this digitization trend, but how it's enabled around secure connectivity?

Matt: I think as we look at 2021 and beyond, we continue to see a lot of growth. Obviously, coming out of 2020, there's a lot of opportunities around, whether that be acquisition or additional growth or whatever. And I think that as we do that, we are trying to find new and better ways of integrating those businesses into our companies. And part of that is moving faster.

Historically it's been very heavy IP routing, firewalls, those types of things to stitch these networks together. And that takes a lot of time and effort. And that's where, I think, one of the key things for us is how do we move forward at the speed of business, not at the speed of traditional IT?

James: No. I totally understand. And I think, again, there's a lot of those legacy controls have been... We haven't seen a lot of innovation in, frankly, decades. But they're still required. I think one of the things we want to chat about today a little bit is, how do we see that evolving? What are the things we can do to help drive, I think, a better balance in how we can move at the speed of business, but do so securely?

I think one of the things that's interesting, I would love your perspective is, there's so much focus around users and applications. And a lot of discussion around security is really focused there. But given how much of Koch's environment is literally physical infrastructure, can you share a little bit about how do you think about the assets of the enterprise and what's important to be connecting and protecting?

Matt: I would definitely say that the applications and users are absolutely important, starting with the people in process. End user experience is of utmost important to us as well. I think when we start to get into more of the manufacturing footprint of the business, what we see is a straining of the old models. So if you look at what we've done over, let's say, the last 15 years or so, where in most of our business units, we've done a really good job of implementing the Purdue model and really thinking about how do we really segment those physical assets and the control of those physical assets, where sometimes they're dangerous. Certainly we don't want any accidents or things like that from a technology perspective, but also just general runtime, especially like coming out of 2020, and even still today, runtime is super important. One of our business units, toilet paper, they say they can sell every square of toilet paper they can make. So we need to be making as much as we can, that kind of thing.

That's where, I think, the security of that is really important. But as we move into this future of more and more automation of manufacturing and then machine learning, AI, big data analytics, all of those things have some ties to the cloud. And as you think about the historical Purdue model, I think the model itself, fundamentally, is probably not a bad mental model. Physically, how it's been implemented for decades, doesn't scale. And we're really starting to see, that's becoming more and more Swiss cheese, which is really scary for our OT guys. And so that really needs to change and be much more flexible to allow for those more cloud-based technologies and even down into the edge.

When we talk about cloud, we talk about that more of how things work, not necessarily where they work. So when you think about edge technologies, whether that be the edge of our network, the edge of the cloud, the edge of a carrier network, whatever that is, those things are really straining that historical security model.

James: I love the way you represented that, where the Purdue model was probably the right approach for the way things were being built 10, 15 years ago. If I'm living in a world where I want to get data from a sensor that might be a level one, I want to get that data into an AWS outpost or into a cloud edge so that I can analyze it and then action it, the idea of Swiss cheese I think is perfect. I've got an algo poke a bunch of holes in what was a very regimented, very sort of physically segmented network, and I think we definitely need to rethink the way we implement those controls.

Your background's amazing on this, Matt, because I think you've got the view across looking at the business process and then how does that get enabled by underlying infrastructure? And then how do we secure it? And so you've been dealing with these different stakeholders over the course of your career, and when I look at the traditional networking teams, they're very, very, very focused on availability and performance. That's the remit. Nobody ever wants it to be the network's fault, but it's always the network's fault until you can prove otherwise.

And so, just the way that the networks are architected it's so that we don't have single points of failure. We don't have single paths, et cetera. And then the security team comes in and says, "Well, wait a minute. We have to secure this." So we need to put controls in place. And all of the work that was done to build this highly available, highly resilient, high-performing fabric, we almost kind of like carve layer through railroad tracks through that environment to get traffic to the security control. And those teams have had these kind of diametrically opposed goals. How do you see that evolving and how is Koch thinking about this? How are you thinking about that in terms of increasing the security posture, but leveraging a lot of that availability and performance that the network teams have been focused on.

Matt: Historically you're absolutely right. These have been very diametrically opposed organizations. The networks team goal is to connect things and the security team's goal is to make sure things aren't connected if they don't need to be. And historically, we've really looked at security as almost an afterthought, a bolt-on, and that doesn't work very well. And getting back to the previous point, that doesn't help from a end user satisfaction perspective either. So over the past several years, I think we've done a pretty good job of starting to line those groups up to really think about it as more of a holistic solution. So it's not a network solution with a security solution. It's a network security solution. But even then I think we still get misaligned priorities. Security has priorities, network has priorities, and the business has priorities, and when we don't get those priorities mixed well, that's where we get unsatisfied stakeholders, first of all, but also we get timelines out of sync and potentially security problems as well, when either network moves faster or security tries to do things that aren't necessarily ready for the environment.

James: And in terms of some of the trade-offs that you've seen get made so that you can still deliver for the business, what's been the impact there and how do you see that evolving?

Matt: I think, from a trade-off perspective, this is where when I talk about that strain in the environment, I think it's timelines are shrinking and there's more pressure to move faster. There's more pressure for more connectivity. And it's difficult to keep up with that with current architectures. And that's where I think those architectures and the thought processes need to change. So in our business network, we've really started to decentralize things. So we're not necessarily, in some cases we are, but we're not necessarily always tied to the data center, and our security has had to evolve to those types of things. And I think that while the OT space is trailing that, I think it's moving very quickly towards that direction as well.

James: So the idea that we could have control sitting at the data center edge and ensure that we're securing connectivity there, in a lot of cases, these traffic patterns are changing to the point where I don't even come anywhere close to it. So I've got to be able to take the policy that was implemented in that control and figure out a way to get it back out to kind of the edge of that asset, wherever it lives.

Matt: Yeah. I think several things are driving us that direction. Cloud computing is one. And when I say cloud computing, I think about it wide spectrum, anything from SAS down to IaaS and everything in between, including some of the edge capabilities we talked about earlier. And I think that that is driving a lot of that. And then we went on a journey, I'm sure you're well aware of this, about five, six years ago to deploy SD-WAN. And really the goal there was to distribute that network. As we move to more cloud-based applications, centralizing data flows through the data center just didn't make any sense. And so really starting to push that out further. And that created new security problems. So to your point, we had the perimeter of the network, when the real perimeter was the data center, we had two, three choke points in the entire network, that was pretty easy, relatively speaking. But now, we've got somewhere in the neighborhood of 750 sites and each one of them could potentially be an egress point. Managing a firewall and a policy set for each firewall there just isn't realistic.

James: Yeah. No, the scale I think, of the problem statement for you guys is really, really important to understand. And to your point, we can't really compromise the connectivity because that's what's enabling the new growth in the business, but we've got to figure out a way to get that control kind of distributed. I know we chatted about this before, but I think as the industry kind of looks at what's the best way to solve this problem? There's been lots of discussion around this concept of zero trust, and it's probably one of the most overused and misunderstood terms. But we'd just love your kind of perspective of, what is zero trust mean in terms of kind of how Koch is thinking about this problem? And maybe how do you kind of put a better definition on it such that it's more meaningful?

Matt: A couple of different thoughts there. One is, we've, and when I say we, I really mean our security leaders, have done a really good job of helping connect with our businesses over the past few years of making sure that our business leaders understand that cybersecurity risk is just another form of business risk and it has to be treated just the same. And so, I think that conversation with the business on how we think about those risks is going really well. When you talk about zero trust and you bring that to the business as a, we want to shrink the footprint or the blast radius of whatever process that you're doing, I think it makes a lot of sense to them, because they understand the manufacturing, the OT, those types of things, what impacts those business aspects.

I think the bigger challenge is really in the technology space, where a lot of technologists, they read about zero trust networking, and it really starts with that, nothing trusts anything. And instantly they're like, that won't work. And the simple answer is that's true, that won't work. So we think about zero trust is kind of a North star. So every decision you make should take you in that direction, but it's not something you're going to get to tomorrow. And the simple fact of the matter is that applications are really what, I would say, kind of hold us back. So as we work to modernize applications, move more things to the cloud and stuff like that, that's where zero trust becomes more realistic. Until we're there though, a lot of our legacy applications just aren't going to work or aren't going to work well in a zero trust environment.

So we kind of break it down into layers. So our first thought from a big step into zero trust is, how do we get our users off of our network? And this is where right, wrong or indifferent, the pandemic has really been helpful here, where we've proven that it's possible. We've got 90 plus percent of our workforce that at some point has worked from home, and we've been largely successful there. We've done a lot of, we've done some software defined perimeter and things like that that's really helped us. Obviously we weren't planning for the pandemic, but we've talked with a lot of peers in the industry that this has been a very difficult transition. And I think that when you're looking at those legacy security constructs, having 90% of your people working from home not on your network is absolutely a concern. So hopefully we're good and lucky at the same time.

James: I think that you're spot on with this idea that that zero trust becomes a goal. We may never actually get to 100%, but we should be making sure that we're kind of taking steps in that direction. And I think that we have to provide tool sets to make it easier for everyone, the security practitioners, the application developers, the infrastructure engineers, to be moving in that direction. And one of the things you've talked about and I want to kind of double click on is, leveraging the transition to some of these cloud based technologies as an opportunity to more tightly integrate some of these concepts.

And you guys have 60 plus companies in the portfolio, you've got tons of application development teams. So, you can't go to try and solve for every application yourselves, you've really got to create a set of tools that make it easy for these concepts to be implemented. I would love to understand kind of, how do you think about, especially with the transition to more cloud based technologies, thinking about things like, hey, if we can create this connectivity fabric that includes identity, that includes this sort of least privileged concept, and then make it simple to consume, how are you guys leveraging things like infrastructure as code and other evolutions to make it self-serve almost for the development community?

Matt: So again, I think some of the things that you said there are kind of North stars. So I certainly won't say that we've been perfect at this and that we're there yet. We've had a lot of difficult learning. So as we started to move into the cloud, a lot of it was lift and shift. And I think we learned a lot of valuable, but painful lessons there where the constructs, whether that be a compute construct, an application construct, or even a security construct, some of those things just don't work well in the cloud. And so we've had to rethink some of those. We have initiatives right now. So in a nutshell, I would say it's a lot of education, but it's also working with partners, external partners, various different companies that help get us to that.

So we work really hard to educate in our technology, from the network all the way up through the application, to think about these things. We use the mental model of Legos. As long as everything goes together similarly, APIs, then putting these things together in bits and pieces is much easier than the heavy integrations that we've had in the past, or potentially placing firewalls at every location. Those are really hard to do. And so, as we start to evolve those organizations and the technologies that we're leveraging, those are the things that we look for is that common integration, the broad applicability. So it's that, I need security policies, I need integration capabilities that can exist anywhere. And building that into the organization, again, I think the technology is the easy part. Not that it's easy, but building that into the people and processes is really a challenge.

James: Yeah. And I think, you touched on kind of being able to do it in building blocks versus more of a monolithic process. And I think that that helps drive adoption as well, because you can't afford to go completely replaced and forklift all of this infrastructure. I mean, again, we talk about the operational technology environment at Koch. I mean, it's billions and billions of dollars worth of OT that, when in a lot of cases, when it was first built and installed, nobody ever even contemplated that I would be talking from here to a cloud edge. But if we can make it easy for, as each of those steps are enabled, the brownfield environment will start to look more, and more, and more, and more like how you would go build a greenfield environment later. I know that's how you guys are thinking about it from kind of a top down perspective. Is there anything you can share just in terms of some of the forward-thinking companies in the portfolio that are really on the cutting edge of that sort of bridging that brownfield to greenfield gap?

Matt: Yeah. I think, so really that brownfield is really the biggest challenge. And as you mentioned, some of those OT technologies, not only is it really expensive, it's very business impactful. And I don't mean like internet outage type stuff, I mean like manufacturing is down. And so you have to be really careful when you play in that space. But again, that's also why security is so important. And so, you kind of have to weigh the backwards compatibility with the forward thinking. So we want to push as far forward as possible, but we know in a lot of those implementations that it's not going to move quickly. A lot of that, your DCS type environment, isn't going to change overnight. And that's where we have to be able to, taking a term from networking, overlay on top of those existing things, because it's not going to change. And I think from an organizational perspective, one of the challenges that we have, and you alluded to, is not all of our businesses are in the same place. Either they're not ready, or financial cycles or whatever it is.

And so we partner with those that are ready and willing, and I suppose you could say more forward leaning, and really, really understand from them, what are the challenges? Where do they think that they need to get better? And some of them, quite frankly, are coming from a brownfield that is not a PCN network. So it's a very flat network, and that's a challenge in and of itself. The thought process there is, can we jump to the next thing? Rather than going to the Purdue model, can we say, what's after the Purdue model, because I don't want to implement that and then have to disrupt it? Because we know that's already a challenge. And so finding those types of things. But also some of our businesses that are really driving a lot more of that AIML big data, where they're starting to see the Purdue model, doesn't let them do what they need or is slowing them down while the business is trying to speed up. That's where I think we partner with them to really what's next.

James: Yeah. And I'll pull on that thread a little bit because I think it really is, I think you used the term overlay and then agility. And so, being able to go into an environment that, again, they may not have even taken the first step of a physical Purdue model. How do we avoid having to take that step, which is almost a step backwards, still provide the segmentation that's required there, but delivered in a way that's more agile, so that as additional connectivity is needed, we're not talking about physical changes that have to happen in the network, we're talking about being able to implement in policy in real time, the micro segmented connectivity for that center, or that PLC, or that HY that's got to get back out to an instance in the cloud? And you guys have a great experience with this type of kind of software defined overlay. How have you seen some of the hardcore OT network guys really respond to, again, very much a software-based view of the world?

Matt: I think, again, it's one of those things where when you run into a lot of OT engineers, just like IT engineers, they're very steeped in their environment. And changing some of those mental models sometimes is hard. Once they get it though, it's a pull. It's no longer a push because they see the possibility, they see the potential for easing the pain that they've been living. And I think it's interesting, where historically in our business network, as we've grown through acquisition, there's really been a push to, how do we not have so much segmentation? How do we better communicate? And things like that. Whereas the OT space is always, hey, this plant needs to be separate. For various different reasons, good business reasons.

And as we start to see things, again, starting with like SD-WAN, where segmentation becomes, I'll say easier, then it becomes a, well, hold on, if segmentation is easier, maybe we should be more segmented, not less. Even in the business network space. And so now we're starting to see business units not necessarily wanting to be directly adjacent on the network to other business units, or even within their business, lines of business potentially wanting to be segmented. And the challenge now is, how do we maintain that segmentation, but still keep that overall collaboration and communication available?

James: Yeah. You almost, you move the choke point from being a kind of network layer construct to where it probably really should be, which is driven directly at the business value layer. If I have a highly available, highly high-performing underlay network, I have the ability to implement segmentation anywhere I want in the overlay, then what drives that overlay policy is really at the business application value level. And I know that I can instantiate any of those segments to construct very, very easily in that overlay. So it moves us up the value stack in a lot of ways.

Matt: I think you hit the nail on the head there with this is all about business outcomes. The network itself has zero value unless you do something with it. And so, I think that we always have to be tied back to those business values. And I think the other piece is, as we move further up that stack, one of the things that we start to realize is our value isn't necessarily in running networks. So Koch Industries doesn't make money running networks. It's a thing that we do because we have to. And so the thought process of that drives is when you look at some of the things that are coming, like a broader LTE and 5g coverage, things like network as a service, where maybe it doesn't even have to be my network, then the thought process is even deeper into, it has to be software for me to protect a network that's not mine, or even people working from home.

James: Right. No. And I think that's exactly it. And this actually sets us up really well for the next point, which is the value is not in the physical infrastructure. The value is really being able to build and maintain that policy that expresses, hey, this is how my business units need to communicate. These are the applications. These are how these assets have to be able to communicate with each other. And if I can make it easy to build that policy and then implement it over whatever underlay I want, whether it's coax network, whether it's a third-party service provider network, whether it's running in a cloud provider, that's really kind of the Holy grail.

And again, it puts the control in the hands of the people that are driving the business value. So we get out of the layer three, layer four sort of D lands, and sub-net blocks and firewalls, and say, hey, I have this asset, I don't care where it's located. It needs to be able to talk to these two applications. And if I can define that policy and then make sure that that's pushed back out into the fabric, then I don't need to even understand networking.

Matt: Yeah, absolutely. And I'm kind of chuckling over here because I think, first and foremost, I'm not really a network guy. So I understand it, but I've never logged into a router kind of thing. And I think we've been tossing around the word easy, and it's not. And that's where I think also as we move up that value chain, those things low in the stack need to truly be easy. Because to your point, we need to be able to have policies that fit business outcomes, not policies that fit network expert's or security expert's mental models. And I think that as easy as possible. I don't know that we'll ever get to a point where it's a truly just drag and drop and any business person can do that. I'm not sure we'll get there, at least maybe not in my career.

And I think that it also has to be something that is broadly deployable. So something that can reach anywhere in our network, whether that be the cloud, the edge, a data center, whatever that is. But it also needs to be flexible enough knowing that you'll never get to one global policy for the entire organization. That's unrealistic. And so I need to be able to get to some of those specific business needs, maybe at a plant level, maybe at a production line level, those types of things, but it still has to be something that can be rolled up and relatively simple for somebody to really understand what's happening and that we're actually protected.

James: Yeah. I think the validation, being able to go back and demonstrate, hey, we truly have limited the blast radius, we truly have enabled the connectivity, becomes a critical part of kind of a closed loop process. And I think, again, you had the opportunity to really work with the doers, the network teams, the security teams in the past. As you start to see some of these changes be implemented, especially around the kind of software abstraction, how are those teams evolving inside of Koch? How are the interactions with those teams evolving? Do we end up organizationally in sort of a new model as a result of this?

Matt: I think the simple answer is probably yes. Right now we are really focused on, what are the processes that have to happen to make that work well? And really that underlying operating model. The thought process of an organization model, I don't want to break things that are working well, and we have a lot of things that are working well, but I do need to change the things that aren't working well. So ultimately I do think that we'll start to see network and security come together. Actually what I would say is, security will become embedded in everything. It's not just a network thing. It's a hosting thing, it's an IS thing, it's a application thing. That security needs to be embedded across everything. And that helps out of the gate to ensure that we're building things more securely, and it helps in the end from a end user satisfaction perspective.

So I think that the simple answer is, I think everybody's going to have to get better at security. I think everybody's going to have to get better at, I'll say scripting. You mentioned earlier infrastructure as code. Again, as we continue to grow, as we continue to scale out, it doesn't matter what size organization you are, as you continue to grow, continuously just adding head count isn't the right way to address those things. So it does need to be those things that are very scalable, very scriptable, and I'll say back to easy.

James: And I think, what easy looks like is obviously very different in infrastructure as code than maybe our concept of the easy button. But I think at the core, if we know that we want to understand identity, whether that's user identity, whether that's identity of an OT device, whether it's identity of data sitting in an S3 bucket, but I want to be able to understand identity and I want to be able to allow connectivity that's based on that identity and a policy around that identity. If I'm building a new application and I can very easily consume that policy as easily as just writing to the Terraform provider, then why would I go try and rebuild the wheel?

It's much easier for me to grab that, build that into my application and then have that, I don't have to go recreate the policy, I don't have to go do all that work again. We can give tools to those developers to make it easier for them to kind of self comply. Versus this being very much a sort of top-down, again, monolithic project to try and go round these things up. So I think that, again, easy looks slightly differently in different contexts, but it's definitely easier than where it's been in the past.

Matt: I do think the identity aspect that you call out is hugely important. So one of the North stars that we've had in place for a while now is identity is the perimeter. It's not new to us, we didn't coin the term. But it really is important. As you start to decentralize the network, as you start to get Swiss cheese in some of those network choke points, when you get to the point where you realize your network really has no perimeter, then you have to be able to trust the users and the devices that are accessing your applications and data. That's really where the trust begins. It's no longer, hey, you're on the network. That's good enough. Because it's just not anymore. And so, one of the challenges that we see is truly identifying. So from identifying an end-user, there's good tools around that. Identifying things, especially when you get into IOT, that's a heck of a lot harder. And then stitching that all together with applications to where you have this consistent flow of trusted application, trusted data, trusted user, trusted device, that's Nirvana. That's where we get to, I'm much more comfortable that I'm as secure as I'm going to get.

James: Yeah. No, and look, I think that's where, certainly for [inaudible 01:55:39], we think it's part of what we have to be delivering. We've got to make it easier to evolve those policies so that you can get more granular over time, versus this idea that the policy sort of goes in very well, is defined on day one, and then as kind of entropy in the system takes over, I come back in 100 days and it's unrecognizable. Because you're right, the sheer volume of interactions that we're talking about at the asset to asset level, from a device that may exist deep, deep, deep down in a manufacturing facility that needs to be able to drop data into a data lake in the cloud, I mean, we're talking about literally hundreds of thousands of potential asset to asset interactions. We've got to have a policy construct that makes it easier to manage those, not harder.

Matt: Yeah. And I think the becoming more and more granular is also something, I mentioned earlier, really looking at it as layers. And layer, one is how do we get users off the business network? Well, that's not good enough. That's step one, is you're not on the same network as all of the everything else. But step two is, not every user needs access to every application. And I don't even necessarily mean that from a access control list perspective. I mean that from a software defined perimeter perspective. If you shouldn't have access to it, you shouldn't even be able to see it. You don't need to know it exists. And carrying that thought through to manufacturing floor devices is really important as well. Again, that blast radius becomes hyper-local, and I have less of a chance, you'll never get to zero, but you have less of a chance of something impacting an entire plant or an entire business.

James: Right. Right. And again, I think, Matt, you guys have such a great view of the world in terms of the reality of the physical world. And I know Koch has been kind of leading the charge on leveraging a lot of cloud technologies. And you made the point earlier that it's cloud based technologies, not necessarily technologies in the cloud. And I think that this sort of physical world reality, there are manufacturing floors, there are devices, there is a real challenge if the blast radius is too big. Being able to implement policy in those environments, in an overlay fashion is critical. And it's not just something we can say, oh, no, no, I'm sending this traffic off to the cloud and I'll take care of it there. It has to be hyper localized.

Matt: Yeah. And I think, first of all, I appreciate the compliment on how we're kind of leading the charge there. I think some days we're moving really, really fast, and other days maybe not so much. I think the key challenge is everything needs to be moving roughly the same speed forward. And again, back to those priorities, when we start to see, if security isn't moving at the same speed as connectivity, or cloud, or application, that's where we really get tripped up and potentially have bigger outages than we should. And so, keeping all of those things moving. It's the old adage of, if you're not moving forward, you're falling behind. And I think the speed of things just continues to go. So it's back to, how do I continue to accommodate that scale? How do I continue to move our IT resources up the value chain? And how do I make it as easy and flexible as possible to really get to those business outcomes that we need?

James: Totally understand. I think that one of the things that we're talking about with a lot of our customers is, moving security from this model of, hey, I got to have this control because-

This model of, "Hey, I've got to have this control because all the other CSOs in my network have it. I can't afford to go face the board if there's an issue." Almost the insurance approach to security to how does moving towards this model really actually unlock and enable new business outcomes, new business value. We talked a little bit about the need for connectivity into the Cloud Edge from some of these physical environments. What are some of the other things you guys see as, again, it's not getting to Zero Trust overnight. We may never get there fully, but if we can start to incrementally unlock some of this value, how do you see this evolving the business value side of the conversation for folks?

Matt: Yeah, I think probably the number one key is just speed. As we try to continue to evolve our products and services that Koch develops and sells to the world, as we continue to evolve those into more digitally based products as well, you really see where there's no definition of where the business and technology end anymore. It's all one thing moving forward. It's just in and around everything that you do. Being able to do that requires that flexibility and speed of these systems. I think that's where we have to continuously get better.

I think the other piece of that is your comment around all the other CSOs are doing it. We always try to reach out and understand is our point of view wrong. Are we thinking about this wrong? In some cases we are, and we adjust. In other areas, your comment on insurance, this is something where we really take a risk adjusted approach to a lot of these things where not everything needs as much security as everything else. If you're talking about a manufacturing device that has the potential of damaging equipment or people, high security. If you're talking about intellectual property or personally identifiable information, high security. If you're talking about a marketing slick sitting on a website, I want those distributed. I think that we have to be careful about ... This isn't a secure everything at the same level though, either.

Back to that how do we get to zero security, it's start in the places where it makes a difference. Again, for us, I think the key area there is in that OT space. Certainly as we have more and more Cloud computing, I think it has to evolve there as well. We have challenges everywhere. It's really understanding what those big priorities are and addressing them appropriately and making sure that we have our shareholders' interest in mind as well, where it's not just Fort Knox for everything.

The other thing that I would say to that is our thinking has been evolving over the years as well, where our network is not much different historically than any other enterprise our size or potentially even smaller. We're a pretty traditional networking background. As we've evolved, what we've found is you have to be a little more risk-taking with not only the products, but the partners that you select. Because what we found in the market is a lot of times, especially when it's some of these difficult concepts like Zero Trust networking, where you get the thought leadership isn't necessarily in the historical leaders. It's some of those startups. It's challenging to convince leadership that we need to bet some portion of our business on a startup. But we've done it multiple times. What we've found is it's not just the technology. It's the vision of the future, and it's the company's ability to execute. When we buy a product or invest in a company, it's really based, not just on the technology, but the people behind it as well and the vision that they have and their ability to execute.

James: Well, you guys have a great track record. I think part of the reason you have that great track record is because you truly do partner with companies to help drive that vision. I think that when you're disrupting, you have to validate, you have to have folks that are willing to take that risk journey with you. One of the benefits of being able to do what we're doing is we can move really quickly.

But we want to be moving really quickly with partners that are saying, "Hey, let's fact-check this. Let's go try it. Let's see what's working, what's not." Then the ability to iterate very, very fast as we learn together. That's, I think, what's so awesome to see, again, these successful outcomes. You guys have been just a fantastic partner from that perspective. I think the more wins that you notch, the easier it is to take even the naysayers on the business side that are worried about the risk and say, "Hey, I think we can go drive something here."

Matt: Yeah. I think it helps us also refine that point of view of the future as well. When we find those startups that are leading the way and connect with who else are they working with as well it's because it's, "Okay. We don't want to be necessarily on the leading edge by ourselves. We want to have some challenge around that thinking." Whether that be with the third-party themselves or with some of their partners, whether that be in the investment space or the customer space or whatever, it really helps us think through ... Quite frankly, also, when you deal with smaller companies, sometimes you get, I'll say, a better say, a better influence in how do we want to think about what's next. Maybe better impact on the roadmap.

James: If I don't have an existing business franchise that I'm trying to protect, it's much easier to innovate, but we want to be innovating in a direction that we know customers are on board with. The partnership goes both ways. Last question. Just as you think about this whole space and, again, recognizing that there's not an easy button. It's not a forklift upgrade.

We would need to take some of the software defined networking principles that we've learned and really apply it to this problem. Yet we're dealing with real-world, with physical infrastructure. If you fast forward five years, where do you think we'll be from a software defined perimeter, Zero Trust identity-based view of the world integrated with these Cloud technologies?

Matt: Well, I'll tell you where I hope we'll be. I don't know if that's where I think we'll be or not, hopefully with some of these partnerships we can get there, is that I don't have to own the network. Policy sets can better represent business risk and business outcomes. Those can be applied wherever in the world we are, whether that be geographically distributed or from the Cloud to the Edge, to the data center, to the home user, whatever that is. If we can get to that outcome where we can deploy and ensure policy across all of those, and the policy really resonates with the business risk and the business outcomes, I think that's where we want to be.

Again, it lets us continue to move up that value stream where we don't have to own the network to be successful. Proved that through the pandemic. We don't have to own the data center. We're moving more and more stuff to the Cloud. Even at the Edge, when you start to see Edge computing through 5G and carriers and AWS outpost and things like that, it doesn't even have to be our Edge. That lets us focus on our business. Secure the business, run the business.

James: Very good. Well, Matt, I really appreciate taking the time to sit down. It's been a great conversation as always. Thank you.