CyberWire Daily - Strategies to get the most out of your toolsets. [CyberWire-X]

Episode Date: December 18, 2022

With a recession looming, many business leaders are looking for ways to cut spending wherever possible. And while tool bloat affects many security teams, it can be a challenging problem to tackle for a couple of reasons. First, there’s the fear that security will be lost if a tool is removed. Second, there’s the daunting task of unraveling complex systems. And finally, there’s the perennial talent shortage. Like all challenges in security, they’re made even worse by the fact that there’s not enough people able to tackle them.  During this CyberWire-X episode, host Rick Howard, the CyberWire’s CISO, Chief Analyst and Senior Fellow, speaks with Hash Table member Ted Wagner, the CSO of SAP National Security Services, and host Dave Bittner speaks with sponsor ExtraHop Senior Technical Marketing Manager Jamie Moles. They discuss solutions to help business and security leaders to not just address these challenges, but to get more out of their tooling as they do. They discuss strategies for how to determine which tools you actually need and which you can get rid of, as well as the step-change benefits that can be realized when you consolidate, automate, and integrate your security solutions.   Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. Hey, everyone. Welcome to Cyber Wire X, a series of specials where we highlight important security topics affecting security professionals worldwide. I'm Rick Howard, the Chief Security Officer at N2K and the Chief Analyst and Senior Fellow at the Cyber Wire. And in today's episode, we're talking about cybersecurity orchestration. A program note, each Cyber Wire X special features two segments. A program note, each Cyber Wirex special features two segments. In the first part, we'll hear from an industry expert on the topic at hand.

And in the second part, we'll hear from our show sponsor for their point of view. After the break, I will speak with Ted Wagner, the CISO of SAP National Security Services, about what he does in orchestrating his own internal security stack. It's time to get more security out of your security. Experience the power of network intelligence with ExtraHop and consolidate IDS, NDR, and packet-level forensics under one platform for faster response. And don't stop there. Gain greater, more reliable threat context, accelerate security operations,

and get more out of your SOAR by integrating ExtraHop Reveal X and Splunk SOAR. Learn how by visiting extrahop.com slash cyberwire. That's extrahop.com slash cyberwire. That's extrahop.com slash cyberwire to learn more. And we thank ExtraHop for sponsoring our show. In the last decade, the complexity of our digital environments has exponentially grown. Things have changed a lot since you and I started, Ted, back in the late 1990s. I think we had tin cans connected with string back then. That's exactly right.

And we thought we were cool doing it, too. Back then, we just had one perimeter, but fast forward to today, you know, we're recording this at the end of 2022. We have material data scattered across multiple data islands, endpoints, data centers, cloud environments, sometimes multiple cloud environments, SaaS services, mobile devices, including personal devices. And so the overarching question for all security leaders is, how do you secure those environments? Do you build a specific security stack for each data island and manage it that way? Or do you install some sort of centralized orchestration platform where you can make one security policy in one place and the platform updates the security controls on all the data

islands simultaneously? So that was a big explanation, Ted. But at SAP, how about just giving us a sense of the number of data islands that you have to pay attention to? It's growing. So the way I look at the question is it's somewhere in between the two examples you provided or two places on the spectrum. Someone asked me a few years ago if data centers were going away. I said, no, they're not. We just won't own them or we won't be responsible for them. Our data is still in data centers, but they're in Google's data center or they're in AWS's data center. And your point to mobile devices and all these other devices where data is residing physically in many different places.

Data is residing physically in many different places. So what I try and do is then, in a virtual world, create this mystical security boundary where I try— I like it. I think we should market that. Go ahead. I try and figure out where the data is coming and where it's going, particularly in and out of that boundary. So at those entry points to the boundary, we pay particular attention. But within the boundary, our data does reside in many, many physical places. And when you talk about boundaries, do those align with my data island idea? Yes. The boundary might not be contiguous. Let's put it that way. So all those islands, we don't count the oceans in between those islands, but we count all the islands. How about that? Okay. And it's a typical data at rest, data in motion. I think that's what you're trying to get to, right? There's data that's stored in all those places and then data moves between all those places. So it's kind of a two-step thing. I

was being too simplistic, just thinking that it's just on the island. To help our executive team understand how we do this, I draw all the islands that are in our boundary and describe what security posture, what security level they're at, and then how do they communicate. It's very confusing. Do you have an artificial thing that you guys developed or do you use some standard for how secure something is? What do you tell the board and your senior leadership about that? The image that I provided them was all those elements that we just discussed, the mobile devices, the data centers, the cloud software as a service or infrastructure as a service, and how do we interconnect them and protect the data.

And so you give it a score somehow? Is that how you guys do it? Well, what I was trying to do is just show them the diversity of the environment so that we have a lot of islands. And to your point, the score, if it's only infrastructure as a service, we have the burden of protecting through the application layer. If it's software as a service, then we are relying on that software as a service provider to secure through the application layer. So to protect all those services, those data islands, as I like to call them, the two extremes of the spectrum are you design and deploy a security stack for each of the data islands. On the other side of the spectrum is sign up for an

orchestration platform like some of the big firewall companies like Cisco and Palo Alto Networks and Juniper, where they have systems that can operate on all the data islands. You set the policy once and it kind of updates everywhere it's supposed to go. Those are the two extremes, but I expect that most people are in the middle of some sort of hybrid approach. How do you guys do it? We're in the middle. We do like observing our endpoints. We're very heavily invested in endpoint security devices. We want to get as much data from our infrastructure as we can, and we have lots of opportunities to do that. I mean, the explosion of data is amazing.

Yeah, I'd say. You're collecting telemetry from all those devices, the endpoints, all the cloud stuff, collecting it somewhere into your SIEM or SIM? Is that what you're doing? Yes. We have log forwarding capabilities, and we are interested in event data, transactional data. We actually have two endpoint devices. Antivirus stuff?

Yep. So we like a little diversity because maybe we might pick something up with one collection capability writes another. And in these cloud environments, you can get cloud-native security monitoring like GuardDuty as an example for AWS. So you're managing a mix of security vendor products and your own SIEM SOAR capability,

collect the telemetry and then update the systems in each of those data islands? That's correct. And we haven't gotten to Nirvana yet. So our SOAR capability is a little more than embryonic. It might be a goofy teenager at this point. We're freshmen in high school. Don't give us a driver's license. Yeah, I do.

Yeah, you're in driver's ed class. Okay, you're not really on the road yet. And I want to go back to something you said before. You do a lot of log forwarding stuff. Any API, XDR, EDR kinds of things too? API, yes. We have not embraced XDR yet. We're still in the kind of wait and see sort of scheme. The reason I asked you that question is because you and I've talked on the

show about a new security architecture that's down the road or that's soon, I think, within the next two or three years that I think all of us will be using. It's called SASE, Secure Access Service Edge, and its cousin, Secure Service Edge, both doing similar things, just a little bit different ways to do it. And you guys are kind of down that path already, right? You've already done some SASE things. We are. Our end users are connecting to our security boundary. We're using a SASE model there. We're knee-deep in an identity project by an identity provider. They'll be a cloud-based identity provider. So we think there are some great opportunities with identity. There's some contextual components that we can leverage.

In another recent cliche is identity is the new perimeter. You've heard that one? Oh yeah, heard it. So we embrace things like that because we think these investments will reduce the noise on our network, will make it so difficult for an adversary to penetrate these technologies that there'll be less for us to investigate. Well, let's explain a couple of these things, Ted. First, you want to take a shot at explaining what Y says. He's so important and new. For example, when we were using the old VPN appliance where we had a client on an endpoint like laptop and an appliance sitting at our perimeter, that appliance was only as good as its ability to be patched. And since we wanted everyone to have ready access to the perimeter inside of our corporate network, downtime on that appliance. And if you think about it, it's more than just

the application on that appliance. It's the firmware, it's for our IT brethren. Is the hardware current enough? Is it robust enough? And they had to have a failover, all those things. And if the failover, all those things. And if the failover was on the circuit that went down, you had so many opportunities for failure. Now we rely on a vendor who we've scrutinized their security posture, but we feel comfortable with it, with getting into that bed with them. But they have diversity in their infrastructure. So they do all the failover. They do all the patching. And it's not that one device that is dependent upon being fully patched.

It's a much more quilted fabric that we can depend upon. I think the major innovation from our point of view, because you and I worked together at one company a long time ago we still had t1 lines internally all the network traffic for the organization would be an internal behind the perimeter kinds of things right and those are really expensive and what's happened since those old days connections to the internet are pretty cheap these days and so what sassy enables is a cloud service provider security vendor so that wherever you are in the world, even if you're in one company or the other, your first hop to the Internet is to this SASE vendor who is running an approved security stack that the customer says, yeah, that's what I like. So it's all that traffic is getting inspected right away. And what you said is absolutely right. We get this cloud provider benefit where they do all the blinky lights. All we have to do is manage the policy. So that's

fabulous. And so the components of SASE, though, were that one hop out to a cloud provider, pairing connection with giant internet connectors like Google and Netflix and those guys that make the traffic so fast, right? And an SD-WAN component to make sure that the traffic was getting there as fast as you can. That was sassy. Since then, SSE has come out dropping the SD-WAN component. We've discovered that maybe not everybody needs the SD-WAN piece. So it's still pretty good, right? And it takes the burden off you and me. So we don't have to manage all that security stack equipment. All right. All we have to do is, you know, figure out, you know, who we want to go where and let the, let those folks figure that out. I really liked that idea. And I think it's the future. I agree. We, we are running as fast as we can to get rid of the last remnants of our data

center so that we will be totally cloud native. No more hardware, no more co-location, and totally dependent upon those service providers. And you said you've embarked on an identity project with a service provider. Is that a software-defined perimeter kind of thing? It's a service. It's one of our islands, right? It's in our boundary. Yeah. But it's in their data center. It's no longer going to be in our data center. You know, in the old days when you and I did this, you'd have to, from the internet, log in through the perimeter defenses to the workstation that you wanted to get access to. And then provide your user ID and password.

And in hindsight, that's ludicrous that we would let that happen. your ID and password. And in hindsight, that's ludicrous that we would let that happen. What these new SDP services, software-defined perimeter services, these new identity services, you go to a different location altogether, log in, and the service authenticates you to make sure you're who you are, and then decides if you are authorized to go to the place you want to go. And then if it's really fancy, it'll establish the encrypted tunnel to that thing that you're trying to get to. And that's it. You don't let bad guys inside your perimeter just to authorize people, which is another fantastic feat. You'll probably remember this problem is when we're using Active Directory as our identity provider. If we wanted to share identity with another enclave, we had to create a trust between

the two enclaves. Oh, yeah. My head still hurts from things like transitive trust and all that stuff that I never understood. All those trusts were filled with problems, right? And so now we're unbuckling identity from our active directory. Now it be in the corporate secure network. Or, yes, you're also authorized to be in that lab, which is a different security posture, and we don't create a trust between the lab and the corporate environment that may cause us trouble down the road. The relationship is with the user or their device, you know, or both. That'd be the better way to do it. So these are pretty advanced concepts, Ted. How do you convince your senior leadership team that you guys need to jump out here and be in the lead where most people are still thinking about it?

We've had a receptive executive team, for one. We have the benefit of some success in our past by going to cloud-native things. We are also a cloud provider, so it's sort of like you can't, if I say, hey, this is a cloud service, they can't say, oh no, I don't trust those guys. They just can't say that. Okay, I get that. But then I do have to get to the next level of detail

about these are some benefits. We can really get into some behavior analytics with these new logging capabilities and some contextual information about where people are coming from and where they're going. So there's some robust logging and auditing capabilities in these services. So when I get into that kind of discussion, the benefits are pretty easily accepted. All right, Ted. Well, I could talk to you about this stuff forever, but we have to end it somewhere. Any last words of wisdom for the audience? I will say this. Challenging cloud service providers and these vendors, they frequently provide information about their security posture. An informed decision maker is always in the best position to understand

the different security offerings and security levels. And so that, because if you're not aware of what the security postures are, you may end up with a lower posture than you really need. All right, good stuff. That's Ted Wagner. He's the CISO for SAP National Security Services. Did you call that, how did you say it in NAS2? How do you do that? SAP NS2. SAP NS2 and EIEIO. All right, good.

No USC. Next is a conversation between my colleague Dave Bittner and Jamie Moles, the Senior Technical Marketing Manager at ExtraHop. Jamie, can you give us a little bit of the lay of the land when it comes to how people in security collect the tools they have, how they choose. And it strikes me that we often end up with a bit of a pack rat situation here. Yes. Yeah. So security very often is not there at the beginning. They're not the people who build infrastructure very often in corporate enterprises. That's usually done by IT teams, network operations teams and the like. And those usually done by IT teams, network operations teams, and the like. And those infrastructure solutions that are selected, let's say Microsoft for their Microsoft

domain networking capabilities and the ability to work with their workstations, etc., and their servers, they provide infrastructure capabilities, printing, file sharing, user authentication, network access to the internet, Teams communications, and things like that, all of which have a level of security built in. So Microsoft are actually quite good with their server platforms, certainly providing hardening guides that IT guys can use to better secure their offerings in whatever manner they've been deployed within that organization. But there's always gaps and there's always better ways of doing things. So for example, on a Microsoft network that's connected to the internet, Microsoft don't produce firewalls. So you're going to have to go to a separate provider to put a firewall between that network and the internet. And by Palo Alto, it might be

Checkpoint, it might be any one of the other firewall experts. Microsoft do provide software firewalls that run on their servers, host-based firewalling, but it's not the same thing. That's designed to protect an individual device. It's not designed to protect a network communicating with the outside world. So security teams take a look at the existing infrastructure and look at ways that security can be improved. So the example of the firewall, protecting the inside of the network from the outside world. They might also put in place things like,

okay, we've got single sign-on on our network because we're using a Microsoft domain environment, but we want to protect it better. So let's implement two-factor authentication. Now that doesn't come as a default with your operating systems and your directory login environment, but there are other providers that can do that and do a very good job of doing that.

And you might want to do securing of traffic going across your network using SSL and TLS ciphers and things like that. There are tools that can make that better. You might be concerned about the traffic that's going through your network and coming in and you might want to understand and you're the security posture of your environment let's say for example you've got a good strong dns implementation in your environment the basic tools that come with your operating system for understanding dns are okay but there are better tools out there there are There are providers who provide specific products designed around knowing and understanding DNS, looking for problems when it doesn't work.

We do it within our solutions, as an example. And so generally speaking, when it comes to tool set selection, the security teams are going to look at what they've got in place. They're going to make considerations towards how they can secure the environment better. They're going to then go out to the marketplace and identify vendors who provide solutions that might meet their requirements. And then they'll often go through a process of narrowing down the vendors based on things like functionality, based on things like functionality, based on things like price, based on things like support. You can buy a really great product, but if you have issues

with it and the vendor doesn't answer your calls, they're not going to be a vendor next year. And things like that. So there's a whole bunch of considerations that security teams put in place. And they're always going to take an approach of breaking down the entire environment and saying, right, we need some network security. We need some user entity behavioral analytics security. We need some firewall security. We need some endpoint security like an EDR. We need to have antivirus. We need privileged access management. There's a whole raft of areas of security domains that security professionals can look at and say there's quite a few things we could do with this well-built, functional environment that IT and infrastructure have created, but there are things we can do to level up the security to better protect the organization against potential threats. And that's generally the way they work, looking at what's already been built and thinking about what's the gap between good and very good, and how do we bridge that gap in terms of protecting the environment. And so what's the problem here? I mean, if I do that, I'm looking for gaps, I'm filling them.

What's the potential peril I face? So when we talk about things like tool sprawl and tool bloat and things like that in corporate environments and large network environments, some organizations can be very siloed internally. In organizations like that, people like to sit in their own team and do their own job and there is some cross-department communication and collaboration but generally it's like you stay in your lane i'm going to stay in mine and we'll be happy and that can introduce issues um so for example, I might, as a very large 100,000 people worldwide corporate,

let's say I do manufacturing of some sort, I'm going to have locations globally, all over the world, I'm going to have supply chain locations, manufacturing locations, research and development, different corporate headquarters, different legal structures, all sorts of things. different corporate headquarters different legal structures all sorts of things and one it department is not going to cut the mustard so i'm going to need it departments potentially across every function of the business and they're all going to be probably fairly independent with their own heads and they may choose different tools to do the same job because actually maybe the requirements for security tooling and research and development maybe the requirements are different to the guys who are doing tooling in manufacturing and it's perfectly legitimate that they come up with their own sets of requirements

evaluate tools and come to conclusions that actually tool a suits me, tool B suits me. But that then means that your organization has two tools doing the same thing. And you then have two legal and commercial relationships with vendors where maybe you could have one. And what we see very often, and that's okay if it's only for one or two tools or one or two solutions. But what happens if, okay, let okay, I've got seven departments worldwide, seven IT teams. What happens if I then have seven security teams as well

and maybe seven network operations teams? And they're all doing the same thing. They're all reviewing and selecting their own tools. And let's be clear about this. Part of this is just due diligence what matters for us part of it's a little bit of ego and i i've been in those teams myself people who people who are going to be running and using these tools like to be the ones choosing them you know i might have a preference for a particular vendor and my my colleague in the us might have a

preference for a different vendor and there may also be regional impacts on that. Maybe in the US, you have different suppliers and different software companies who don't sell to my region. So I have to sell. I have to select something different in my region. So there can be very good reasons for this. Regulatory reasons, I would imagine as well. That can come into play as well.

And actually, that's quite a big thing when you're trying to move away from tools sprawling you're trying to consolidate things um i did a contract probably 15 20 years ago now for a large pharmaceutical organization and my contract was to do um a worldwide server consolidation project the idea here was there were lots and lots of servers maybe just computers running under a desk that running a worldwide server consolidation project the idea here was there were lots and lots of servers maybe just computers running under a desk that running a web server in offices globally that could be better they could serve the organization better if they were consolidated into a globally central isp and this pharma did sense they they set that up, massive web farm internally, massive VMware farm, and we were migrating machines left, right, and center.

But the interesting thing that we came across was there was quite often servers like this that were running on a PC under someone's desk that had a bit of software on it that was regulated and controlled by the government of that country, and you couldn't touch it. It couldn't be moved off that machine without a complete re-audit of everything, which became entirely impractical. So there are pitfalls to this, and there are sometimes very good reasons why older legacy technologies are kept. And the solution, the traditional solution to tool bloat and tool sprawl is consolidation. Very, very typically, someone new will come into the organization at senior level, or there's a budgetary reason for doing it.

You know, someone recognizes that there's too much out there um sometimes departments get rationalized and consolidated together as well and then it's like okay two departments have joined as one maybe network operations and security operations have come together and it's like okay we we've got all the people sitting next to each other at the same desks in the same room now but they they're using different tools, which makes no sense whatsoever. So there can be a very good reason there to start saying, well, actually, the tool we're using now, we've had it in place for four years. It's time to go back to the vendors and say, what does it look like today? Can it do more? And this is a particular conversation I have a lot of time with CISOs who,

can it do more and this is a particular conversation i have a lot of time with cso's who when they're looking to provision a new tool set there's a couple of things they want to do firstly does it meet the business requirements does it do what it says on the tin but does it also speak to other systems so it's going to help me get a better return on investment on other systems that i'm already using because it plugs straight into them and works with them. But also, is it going to help me replace some of my other systems? So, for example, our tool at ExtraHop, our network security tool, can give you visibility of DNS and other protocols on the network and very, very good visibility in that space as well. If you have another DNS management tool and you're deploying us into your environment for security reasons, actually, we do a lot of network performance stuff as well. So you could probably

say, well, I'm buying this solution because I need it for its security capabilities. But look at all these wonderful network performance and network management things it does as well we're going to get a better return on investment on this extra solution because it's going to help us decommission some of those legacy solutions that have been around for three years and maybe they're not quite cutting edge anymore and extra can do it all in one so i mean there's obviously going to be things like okay well the guys were using the old tools can have to be retrained to use the new tool that we're bringing in but over overall and over time it's going to be a significant reduction in cost in terms of deployment and use of a capability the significant

reduction in cost in terms of license costs and just sheer effectiveness and efficiency of a capability, significant reduction in cost in terms of license costs, and just sheer effectiveness and efficiency of the business. When you bring people together using the same tool sets and working together, they just do a better job. And that's kind of the way I think of it. I'm reminded of that old joke about how there's a group of people and they're standing around a server and they're not sure what the server does. And somebody says, well, pull the plug on it and see who comes running.

Yeah. And I suspect there's a certain amount of that that goes on. But at the same time, I've heard people refer to load-bearing servers where whatever you do, we don't know what this thing does, but whatever you do, don't unplug that one. Yeah, don't unplug that one. It's a keystone. Right, and I suspect there's some of that as well where if we can swing the budget,

we might as well keep that tool running because we're not exactly, that was from the previous folks who installed that and we're not sure what's going to happen if we unplug that. I mean, how do people get around those realities yeah it's like the old old idea isn't it that that something's been done forever no one can remember why it's done this way but no one will change the process because it just works um we the old saying oh we've always done it this way right why does no one can remember the original rationale for doing things this way so they continue to do so and that and that i have

to say actually a lot of the um the the cso's and cios i get to spend time with they're very aware of that and they're very very aware of the fact that legacy systems exist for a reason. There's a saying or a story in the world of CISOs, which they always talk about the CISO who came in to a new organization and immediately started making changes. And one of the changes was something to do with a firewall configuration that made no sense to him. And the end result of it was the next day, a mass mailing system that the company was using to send out invoices failed.

And as a result, the company was unable to bill their customers. And it's like someone coming in and making changes without understanding what was going on. In that case, the abbreviation CISO soon becomes to mean career is soon over. Because the reality is, if you're going to come in to an environment, the first thing you should be doing is learning it. And all good CISOs and CIOs that I've worked with will tell you when they start a new role, they change nothing for three months. They just spend three months evaluating what's in place, talking to people,

understanding what is available and why things are in place. And the only time you make changes is when you know for certain that the change you're going to make will not break the business's ability to generate revenue. If you find something that you don't know what it's doing and no one can tell you what it's doing, your answer is not to turn it off. That can be fatal. The answer is to dig a bit more until you find out what this thing is. And then if you have to, do what the old adage was. Just unplug it from the network and wait and see who comes screaming. Because someone will come screaming soon. But you haven't decommissioned the service, so you can always plug it back in again and get it going

again. That's a big thing in networks and servo land. In terms of bottom lines here, I mean, I think a lot of folks, they have a close eye on their budgets these days. We hear about the potential recession looming over us. And so I think it's reasonable to think that lots of people are going to be looking at ways to trim back the tool set that they're using. What is your advice then for folks to take a good, smart approach to this? So I don't know how long you've been having these discussions and i don't know how long your listeners um have been in the industry but those of us who have been in it quite some time 35 years in my case who lived through the dot-com boom and bust years 22 years

ago now will recognize um the upcoming recession and recognize what's happening. And when recessions happen, companies' revenues go down naturally because their customers are being more careful with their money. And customers generally go on the basis of, we need to do what we need to do to keep the company going and keep our employees employed and ride the wave and make it through to the other side. And then we can go back into a growth phase. So it's almost like hibernating in some ways. But one of some of the cost saving things that

happen in those times, the last thing a company wants to do is let people go. So what they will start doing is looking at efficiencies instead so what can we do internally more efficiently in order to save money and that's when ratification of systems very often comes to the fore things like okay do we need all of these products um are there viable open source alternatives that we can get up and running and still run with our systems that will keep us going and see us through and and other things like that but that that in itself comes with the dangers if you're going to switch from one solution to another that hasn't been as well tested as systems that you may have in place for four or five years that's a big risk so if you're going to do anything around

ratification of your systems, tool consolidation and that, you have to refer to your risk registers. You need to know why systems are in place. If they're operational systems, you'll refer to your business risk register. Why is this in place and what's it doing to support the business? If they're security systems, you refer to your security risk register. What is this in place and what's're looking to do is identify solutions that you have in place that might be cross-departmental, that might be cross-geography, that do the same function, or can be tweaked or reconfigured to do the same function and deliver the same capabilities to the business without introducing latency, without introducing downtime, and without introducing a core critical issue that's going to risk breaking the business being able to make money. And actually, one of

the biggest risks that I see quite often with organizations that try to go down this path is they actually do the process very well and they identify a number of systems or solutions that they could do away with and not need and bearing in mind that the world we're in nowadays of cloud and SaaS delivered solutions where actually most of the time organizations are using these on a subscription basis. So it's an OPEX rather than a CAPEX expenditure. You can reduce those expenses just by canceling subscriptions to various services and things like that. Whereas with CAPEX, the money's already gone out. And so it's cyclical as to whether you're going to save any money or not. The risk comes when you've identified the solutions you're going to disable and you turn

them off you stop subscribing to them but then what you're left with no one really understands deeply and this is really a big problem in in space in security. A lot of security solutions are black boxes. And I'm happy to say at Xtrop, we don't consider ourselves a black box, and we're very open about what our solutions do, and we talk to our customers about it. But if you leave yourself with black boxes, very often those boxes don't talk very well to other systems. very often those boxes don't talk very well to other systems. So you actually reduce the operational synergy within your environment, which then becomes a risk in itself. And you then start having to play that off against the risk of that breaking and causing other problems in the business. It's a balancing act. It's like being on the high wire and trying to decide whether I'm going to lean left or I'm going to lean right to make it through the troubled times and get to the end where I can turn my business to a growth state and start elevating things again. We'd like to thank Jamie Mulls, the Senior Technical Marketing Manager at ExtraHop,

and Ted Wagner, the CISO at SAP National Security Services, for helping us with this topic. And we'd also like to add special thanks to ExtraHop for sponsoring the show. CyberWire X is a production of the CyberWire and is proudly produced in Maryland at the startup studios of DataTribe, where they are co-building the next generation of cybersecurity startups and technologies. Our senior producer is Jennifer Eidman. Our executive editor is Peter Kilpie. And on behalf of my colleague, Dave Bittner, this is Rick Howard signing off. Thanks for listening.