Security tools are supposed to solve problems and make our lives easier. Why does it seem like they’re doing the opposite and creating more work?

Check out this post by Caleb Sima of WhiteRabbit for the discussion that is the basis of our conversation on this week’s episode co-hosted by me, David Spark, the producer of CISO Series, and Edward Contreras, senior evp and CISO, Frost Bank. Joining us is Evan McHenry, CISO, Robinhood.

Join the conversation on LinkedIn

Huge thanks to our sponsor, Endor Labs

Full Transcript

Intro

0:00.000

[David Spark] Security tools are supposed to solve problems and make our lives easier. Why does it seem like they’re doing the opposite and creating more work?

[Voiceover] You’re listening to Defense in Depth.

[David Spark] Welcome to Defense in Depth. My name is David Spark, I am the host and producer of the CISO Series, and joining me as my co-host, one of your favorites, a new entrant, but now he’s crossing over from hosting in 2025 now to 2026, none other than Eddie Contreras, senior EVP and CISO at Frost Bank.

Eddie, thank you so much for joining us.

[Edward Contreras] David, thank you for having me back yet again on a new year.

[David Spark] It is great to have you back. Our sponsor for today’s episode is Endor Labs. Scale your engineering impact, not your security backlog. Ship secure code by default, whether it’s written by humans or AI, with security built into every commit, and we’ll have more about just that a little bit later in the show.

But first, let’s get to our topic. Eddie, new tools very often require an extra lift from your teams. Like this was kind of the big selling point of AI was that it was going to reduce the workforce, which we discovered it was the complete opposite.

It made you [Laughter] increase the workforce. But as Caleb Sima of WhiteRabbit pointed out, this often isn’t matched by the tool’s increase in value. So, have you seen this disconnect that it’s supposed to provide all this great value, but the work you put into it isn’t sort of counterbalancing that?

[Edward Contreras] Everywhere you go, every conversation you’re in, this happens so often. And I’ll throw a number out there that I’m going to revisit throughout this podcast, 2080. 2080 is not just a concept on delivery, but it’s the number of hours every single employee has available to them every year.

[David Spark] Oh, this isn’t 20/80 because I’ve heard that too.

[Edward Contreras] Exactly, exactly. This is the number of hours available per employee. So, when we talk about value and we talk about solving problems, when you start to get below that number, you have to have a real conversation. Am I providing value or is this just a shiny object that’s now the front part of my conversation?

We’ll continue to that number.

[David Spark] That’s an interesting number because I’ve heard actually the opposite, 80/20, but not 20/80. I thought you were introducing it in a new way. But no, we’re talking about 2,080, correct?

[Edward Contreras] Correct, correct.

[David Spark] All right. Let’s bring on our guest. Thrilled that he’s joining us here. We’ve actually had his predecessor on the show before, and it is the current CISO for Robinhood, none other than Evan McHenry. Evan, thank you so much for joining us.

[Evan McHenry] Thanks, David, for having me. Looking forward to the chat.

Why is this happening?

2:50.312

[David Spark] Erik Cabetas of Include Security said, “Most every security tool is going to cause ‘more work’ because it gives you more information. You’ve got results, awareness, observation, insight, detections, etc., for you to make risk decisions on.

So, if tools are all giving you something new to process, understand, take action. The best tools are optimized to give you the least amount of additional work with the highest quality of information.” So, essentially high signal-to-noise.

And Greg Notch, the CSO over at Expel, said, “Every security tool provides one of the following four capabilities – visibility, detection, prevention, or response. The only one of those categories that doesn’t require additional effort is maybe prevention.

But that’s only true if the false positive and false negative rates are very close to zero, which I have never experienced. The entire industry is about providing treatments, not cures, because the cures are usually out of security scope. Value is hard to define.” Let’s lean on that last line from Greg.

Value is hard to define, Eddie. Do you think it is?

[Edward Contreras] Value is in the eyes of the beholder, right? You have to understand how your program is functioning. Fun fact for the audience, I’m a huge country western fan, and there’s a line in a song by Toby Keith that just comes back to every security practitioner – wish I didn’t know now what I didn’t know then.

If you’re blind doesn’t necessarily mean you’re secure, and you have to know that. And I think the challenge with these security tools is they do shine a light, and they all cause work, and if they’re not causing work, what are you doing buying a tool, right?

You don’t buy a tool just for information. You buy a tool to solve problems.

[David Spark] That’s a good point right there.

[Edward Contreras] You should anticipate more work. And the volume of work, again, is subjective, eyes of the beholder, but really, you have to look at the output of these tools and think about, okay, now that I have this tool here, am I ready to conduct the work that it’s about to hand over to me?

[David Spark] That is a good point. So, Evan, have you experienced this problem? And do you see sort of the light at the end of the tunnel? And is that sort of assumed when you go into a new tool?

[Evan McHenry] I think it’s assumed when you go into a new tool. And yeah, I see the problem. I don’t think there’s a light at the end of the tunnel. I think this is going to just continue to haunt the industry. At Robinhood, I also run the IT organization, and we have one of our core operating principles is being lean and disciplined.

So, what I’ve done with the security organization is I’ve brought in some of the evaluation criteria that we use for vendor selection in IT into security as well. We’ve been using that for the past several years, and it’s working out. So, what we like to do is use total cost of ownership as a primary forecasting exercise for every new tool that we bring in.

[David Spark] And can you walk through the details of what TCO, total cost of ownership, looks for you?

[Evan McHenry] Yeah. So, for us, we look at a three-year horizon. So, we will look across three years, and we will forecast what is a successful TCO for this tool. And we ask the vendor to go get some of their existing customers and ask them what their TCOs were, and we bring those results back to us.

And I will, of course, go and sidebar with some of the customers, CISOs or CIOs, and find out what’s true there as well. But overall, we look at staff that it will take to manage the tool, the ROI that tool is expected to bring in to solve whatever problem that we’re trying to solve with it, manage service providers for initial setup and maintenance, and any support contract fees as well, and then we run those across three years.

At that point, we set clear success and failure criteria at year one, year two, and year three, and review the contract against what we forecasted at those yearly marks to determine, are we within what our TCO expectations were, or do we need to re-evaluate the tool here?

How are the vendors handling this?

6:55.282

[David Spark] Mo Sadek of ActiveFence said, “It’s an expectation problem. I don’t think anyone would overestimate the value of a tool or vendor that was upfront about the level of effort it takes for baseline to be established before real value. In the AppSec POC space, we always had to do substantial tuning to get usable, not even good.

Now, the vendors that won out in the end were always the ones that had a clear path to success that our teams were able to roadmap and resource.”

And Jon Rose, who’s the CISO over at IOmergent, said, “Very few security tools work well out of the box. They almost all require some level of tuning and configuration.” We have heard that often. He goes on to say, “Often time, much more effort than what the sales team promises.

I’ve seen many times where security teams don’t leverage the vendor’s tech support to review configurations, suggest tweaks, and help build an operational process. If you have done all that, and the tool is still a time suck or missing key features or functionality, it’s the wrong tool.

This often indicates the product/engineering teams are too far from the actual problem. They don’t understand how security teams work in practice.”

I would assume this is part of the sales process that you say, “We want help deploying this,” because you’re buying a tool. I got to assume the sellers know what all the pitfalls are of this product to help us avoid [Laughter] them when we deploy it.

So, I got to assume that can help in terms of getting the thing up and running. Yes, Evan?

[Evan McHenry] Yeah, I think what I found is there’s about three models here, and I have a preference, but I’ll save that for a moment. But one model is the vendor is a software development company that has managed service providers for setup, and they will offer you those services for a price, obviously.

Another model is they’re a managed service provider that uses software to sell their services, and those are pretty hard to pick apart. So, that’s where I like to talk to some of the vendor’s customers to really understand how often are you going to their MSPs or their professional services contractors to get help there.

And then the third one is we’re a software development company. We don’t have a managed service provider. It’s up to you to figure it out, but we’ll let you work with our engineers directly.

I love that model. I like that model because it provides on-the-job training for my staff. And generally, the engineers will tell you the hacky ways to manage their platform if you can work directly with their FTEs. That’s a model that I’ve found a lot of success in.

My second follow-up is I’ll go with the company’s managed service providers, but I’m very allergic to any vendor that looks like they’re a managed service provider or professional services contracting company that sells software, and that’s really hard to suss out.

[David Spark] Good point. All right. Piggybacking what Evan just said, Eddie, have you had this experience with the sort of the three different models? And I got to assume you kind of lean on the seller to help you get the product up and running?

[Edward Contreras] Yeah, absolutely. You always need a delivery partner. The reason is there’s a partnership there. One portion of that equation knows their product, and the other portion knows your environment. And they have to coexist, and so a delivery team is the optimal way to deliver something.

I think this is a good time to revisit that 2080 comment that I made earlier. When you’re thinking about a gap versus an enhancement, if your tool is coming in to optimize or enhance, you really have to start to lean on that 2080 number. If you’re solving a problem that is, say, for example, an employee takes 500 hours a year to perform, and all of a sudden, you’re committed more than 3,000 hours to fix that problem, you’ve exceeded what most people would accept as a good investment.

Because now, you’re spending more money on a problem that really was more of a nuance than an issue.

And so, you really have to keep some of these numbers in mind to understand, am I looking too much at the product itself? Am I over reliant on what’s to come just to solve a problem that seems fairly manageable? And that’s where you have to always understand because if you want to get to the total cost of ownership, you have to be true to yourself and understand, okay, how much time am I currently investing in solving this problem?

It’s not just about making a really good tool work and function as the seller wants it, but how does it operate within your environment? It’s very key.

[David Spark] By the way, this is really key that you’re saying this, and I know that I lean on my team because being that I’m not physically doing the hands-on work, you have to ask your staff, is this taking you an hour, two, 12 hours? And they have to understand that when you’re asking this, you’re not asking it to criticize their work, but to understand if this is working in your environment.

Do they get that, Evan?

[Evan McHenry] Yeah. I think, one, as your organization scales more and more, having that you reaching out to them problem becomes really, really difficult for the organization because it’s disruptive. I think, one, building a culture in which people do the inverse, and they come to you and say, “This isn’t working,” is really important as you start to grow your enterprise and your security firms up.

But yeah, I think going to the root of the question here, having that line of communication where the staff is telling you what tools are important or valuable and where the value’s not happening, and then making the quick decision to back out, even if there’s loss, that’s key, especially as your tech stack starts to run.

[David Spark] And they’re being clear like, “This is taking me too many hours.” Not that like I’m not good at my job because it’s taking me too many hours. It’s just this takes too many hours.

[Evan McHenry] Yeah. I think being clear about this takes too many hours, the tool’s not delivering the results that it’s providing. I think overall, identifying that in a proof-of-concept phase while you’re doing a bake-off and an RFP is critical. But if you get to the purchase and you’ve already post set up, having that conversation with your staff that can say, “We’re not getting what we thought we would get out of this, and it’s distracting me from the other work that I have to do day to day.” That’s really critical to have that type of culture built into your organization.

[David Spark] Eddie, I want to know how you handle it in terms of like learning how much your staff is working on things.

[Edward Contreras] Yeah, it’s fundamental in delivery. It is one of those initial steps. I don’t want to pick on a very specific vendor, but most of us use a service desk to be able to open tickets and close tickets. To create a workflow on a product like that, it’s a tremendous effort.

You need developers, you need integration points, you need to understand how flow works between departments. If you’re spending 4,000 hours to design that, and in the past, it was taking you maybe 300 hours a year to solve opening and closing tickets, you’ve over engineered it.

And that’s absolutely something you have to really understand is you’re going to get into a great product, but at what cost? You’ve now extended what you wanted to do to now solving for what the vendor wants to sell you versus what you really needed.

[Evan McHenry] I really like what Eddie’s saying here, which is have a mechanism or operating procedure in which you’re evaluating these things regularly. Us as CISOs, we always have to work with Finance, and Finance absolutely loves it whenever they have executives in their team that’s doing this independently without being forced.

And when you build that relationship and that reputation of being a good steward of the company’s resources and really thinking about, am I solving the problems I’m supposed to be solving? And when you need to go and call for emergency funding for a big initiative that’s critical to securing the company, the conversation with Finance is going to be so much easier.

Sponsor – Endor Labs

14:50.075

[David Spark] Before I go on any further, let me tell you about our spectacular sponsor, and that would be Endor Labs. Now, Endor Labs helps organizations secure the modern software supply chain by focusing on what actually matters – exploitable risk.

So, as software teams increasingly rely on open source cloud-native architecture and now AI-generated code, traditional vulnerability scanning creates overwhelming noise without clear prioritization.

Endor Labs changes that. Built by industry experts in open source security, Endor Labs provides a dependency-centric approach to application security. Their platform analyzes how software is actually built and used, identifying which dependencies are reachable, exploitable, and truly risky.

So, security teams can focus remediation efforts where it counts. By combining deep dependency graph analysis with runtime context and policy enforcement, Endor Labs enables engineering and security teams to reduce risk without slowing development.

As AI coding assistants accelerate software creation, dependency sprawl and hidden risks grow even faster. Endor Labs is purpose-built for this new reality, helping organizations safely adopt AI-powered development while maintaining strong security posture and developer velocity.

You need to learn more about this, you got to go to their site. Go to EndorLabs.com.

What’s our visibility into this problem?

16:25.507

[David Spark] Anthony Harrison, SBOM Europe, said, “All tools result in more work, but having no tools creates risk. The better tools help you prioritize the work. The worst tools give you data, lots, with no actionable insights. And the cost of the tool does not mean that they are better than the less expensive tools.” Jad Elahmad of Century Supply Chain Solutions said, “When I evaluated multiple GRC platforms, one of the top tools in the market looked impressive on paper and had a strong brand reputation.

But once I got deeper into the demo and sandbox environment, it became clear it would create more administrative overhead than value. The framework was powerful, but the configuration effort, maintenance requirements, and workflow complexity would have added work for every team involved without meaningfully improving our risk posture.

It was a good reminder that ‘top of market’ doesn’t always equal right fit, and sometimes a lighter, more operationally aligned solution provides better outcomes.”

I’m sure you’ve seen this happen a lot, Eddie. So, a couple of things. I got to assume, talk to your friends, “Have you used Product X?” That would be the number one. And especially if you’re talking to your colleagues, since you work in Finance, like, “Hey, have you used Product X?

You also work in Finance, yes?” Because talking to somebody in another industry like healthcare may not align to your needs.

[Edward Contreras] Yeah, completely accurate. And there are times you have to make hard decisions. I remember joining a company a while back and I got there and they were using the state-of-the-art SIEM, and you know which one I’m talking about, industry leading, everybody’s using it.

And I asked, “Where does our security operations center sit?” And we had an operations center out in India, and it was only level ones. The turnover ratio there was hovering around 40 to 50%, and I said, “You know what? You can’t have this top state-of-the-art SIEM there.

The complexity that it brings, the expectation of programming skills.” The product was too big for our team, and so we did have to make a change. We brought in a freeware product, but that freeware product, it was easier to train these level one analysts.

Now, if I had level threes and fours, and they did coding day in and day out, that’s a different decision. But it was a decision we had to make, and unfortunately, we walked away from the leading product that was out there because our team, we were overstretched for what we could do with that product.

[David Spark] Evan, you’re nodding your head. Have you had a similar experience?

[Evan McHenry] Oh, yeah. I’ve had several tools over the past several years where there’s, one, just no staff in the industry that has the experience to manage those tools. So, you’re looking at hiring somebody mostly at senior levels and then having to train them up.

And then as soon as you do that, they’re a hot commodity on the market. So, when you’re looking at tools, what is the employee base that’s available to you to hire, and how much is that employee base going to cost you? I think it is absolutely critical, especially the up-and-coming tools that are post IPO, I won’t name names here, but some of them are public companies that very few people know how to actually configure their tools and they’re constantly getting swapped around the industry.

[David Spark] So, sort of closing out this segment, like give me a list, I’ll start with you, Eddie, to protect yourself from making this kind of decision. Because it is obvious, like when you’re going to buy a SIEM or a GRC product, there are the 500-pound gorillas in the market, and you do look at them.

How do you sort of decide early on, yes, this is a good way to go or no, it’s not. So, you don’t waste too much time because that’s the thing, like, just pick either one of these categories. It could be a full-time job looking at GRC tools. Heck, what am I saying?

There are analyst firms, which there are people whose full-time job is looking at GRC tools, right? So, how do you cut down the noise for yourself to sort of start going down the right path? Because again, you can’t make it perfect, but some sort of initial decisions.

[Edward Contreras] Yeah, absolutely. And for those that are fortunate enough to have a dedicated person for a dedicated tool, it’s an unbelievable experience. [Laughter] So, kudos to you if you have that. One of the expectations I have with my leadership and my management team is we do what’s called capacity planning.

I understand you’re busy. Don’t come and tell me you’re busy. I need to see numbers. How many services are you delivering? How long does it take you to deliver those services? I need to see the capacity plan. Because if you are overstretched and you can document that and we can say, “Yes, we do absolutely have a problem here, a problem worth fixing and investing in.” To Evan’s point earlier, you go to your CFO, and you say, “Hey, we’re running at 120% capacity.

We are underfunded by 70%. This solves both of those issues.” It’s a really easy conversation. But if you go and say, “We’re busy and my people are stressed,” you’re fighting an uphill battle.

So, you have to have those numbers ahead of time, and you have to have your management team do that work. It’s not a fun job to do and sit there and figure out, well, I did 10,000 alerts this month and it took me 10 minutes per alert. Oh, I did 50 tool upgrades, and it took me an hour and a half per upgrade.

But you have to know that to say, what problem am I solving? Otherwise, everybody’s in this reactionary state. I’m busy, I’m busy, I’m busy. And then people get burnt out. But you don’t have the data to support that. So, I do think it’s on management, on the leadership team to be able to tell that story and be able to articulate it in a way, exactly what Evan said, talk numbers with your CFO.

If it’s worth the investment, you’re going to get the support.

[David Spark] And let me throw this out at you, Evan, and I’m sure you’ve heard this from staff members. Staff members kind of like to think that they’re super powerful and they’re Superman, they can do it. And when you ask them, “How long will it take you to do it?” And they go, “Oh, I can do that in a half hour,” or an hour or whatever it is.

And you’re thinking, “Really?” And then I always say, like when I’m talking to people, “Be liberal to yourself. Give yourself some extra time. Like, seriously, how much do you think it would take?” And then you start getting larger numbers. Yes, if I’m in Superman mode, I could probably do it that quickly, but we’re not 24-7 in Superman mode kind of a thing.

So, do you have these kinds of conversations with your staff? Because they would like to claim, “I could do that super-fast,” right?

[Evan McHenry] Yeah, of course. And I think this is one where having people that you know, and you can start to understand Bob or Sue, they always like overcommit 20%, and I’ll add that buffer there. Knowing who those superheroes are that love the firefight and love to be taxed is important as well.

But generally, I would say, if I’m having a very quick conversation, it’s 30% additional on top of it. If I can have the conversation in which I can pull back the layers a little bit more, yeah, of course. It’s always I don’t want to be the one sandbagging my boss.

I’m going to say I can do more than I really can.

[David Spark] So, you always give your staff a buffer knowing that they’re going to try to kind of flex a little bit?

[Evan McHenry] I try to. And also, I want to hire people that want to flex, right? I want people that want to overachieve, etc. But I also care about them. I know their mental well-being, emotional well-being, etc., actually leads to better outcomes for the business.

So, I want them to know that I’m coming from a place of positive intent when I’m asking that question. But I also think that’s why it’s important for us as CISOs to reflect on our time doing the work or our time being an engineer and really try to understand what that person’s going through in that conversation and guide them through it, especially if they’re more junior.

[Edward Contreras] Going back to that 2080 number, right? If you’re talking to one of your managers and you tell that manager, “Hey, you’re a team of five. That means you have 10,400 hours to spend this year. You’re telling me you have all your services combined are taking you 16,000 hours?

You’re understaffed.” That’s the numbers you need to say, “I can bring you some relief. There’s an investment opportunity here.” But without that number, it’s really a struggle. And now, all of a sudden, you have a junior analyst or a tier one analyst giving you numbers that you know are not achievable.

If they’re saying, “I can do it in one hour,” yet you’re showing, wait a minute, your team is delivering more hours than what you’ve committed to. There’s something that’s not aligned there and you have to get that alignment.

Sometimes it’s really not that difficult.

24:50.615

[David Spark] Todd Hammond of Pace University said, “This result usually does not root cause back to a tool problem. It is an order of operations problem. Too often, cybersecurity professionals ignore basic principles. In this case, it’s operations management.

Identify the actual problem first and understand the end-to-end process solved without considering technology amplification. Map the workflow without considering technology. Then pinpoint within the workflow where technology can create velocity efficiency.

Then identify cross-environmental integration points. Fit the tool capabilities to process, not the other way around. A manufacturer would never install automation before designing the production line. In cybersecurity, tools are often purchased first and the process built later.

That inversion is why tools end up creating more costs, complexity, and risk than they resolve.” We actually brought this very subject up earlier of that what happens is if you don’t fix your process, you just amplify the problem with tools. Yes, Eddie?

Actually, were we doing this episode with you, I think?

[Edward Contreras] I think we were, and Todd is music to my ears here, right? If you unpack this quote, and there’s so much value in the statement, if you unpack this and you see what he’s getting to, you have to know your environment. It really, truly is know thyself and being able to understand where you’re strong, where you’re not strong.

Because if you’re just buying tools based on a good steak dinner or based on a salesperson, you’re bringing a problem to a table where maybe a problem doesn’t exist. And so, understanding those workflows, understanding the mapping. I mean, if you unpack this in totality, it’s threat modeling.

This guy’s doing threat modeling. He’s saying, “Okay, where are the risks? Do I have any controls there to manage those risks? Do I understand the start and stop process of this?” And then once you have that, now is there a solution to help me solve for the gaps or to solve for the optimization opportunities here?

So, I love Todd’s quote here.

[David Spark] All right. I throw it to you. I’m sure you’ve lived this yourself, Evan, of the tool amplifying a broken process.

[Evan McHenry] Yeah, I unfortunately have, and it’s a lot of tough lessons learned throughout my career. The cool tool that everyone’s using doesn’t actually work in my environment. And one of the things I really like about Todd’s quote here is, it’s not said, but there’s so much value in having security leadership have long tenure in a company because they understand all the ins and outs and nuances and the culture of the company and what tools will work and what won’t, and I think that there’s a lot of value there.

[David Spark] Can I take the devil’s advocate argument?

[Evan McHenry] Yeah, sure.

[David Spark] I totally agree with that, but the devil’s advocate argument is they don’t have fresh eyes. Like the broken processes that you’re sort of blind to because you’ve been doing it that way for the past 10 years.

[Evan McHenry] Yeah. And I think that’s one reason I love hiring. I like bringing in fresh eyes and people that as I’m hiring particularly managers into the team, I’m testing them to see, are you going to tell me the problems that you’re finding? Because I know the longer I’m at a company or another person’s at a company, we become numb to some of the paper-cut moments.

But this is where I think security leadership looking at their tools with, one, first principles’ thinking – really, are we solving the root of the problem the right way and the most efficient way? And two, am I creating security tooling that has the best user experience for end users that have to go through these processes as possible and learning the art of user journeys and user stories and product management philosophy?

Because once you bring in security tools that are the easiest thing for a group to use, it’s the paved road that they want to go on and they don’t create shadow tooling, which is the bane. That is terrible when that happens. So, I think overall, though, this quote is spot on, and I really think focusing on first principles’ thinking, being efficient, and are you creating products that your end users want to use is really critical.

[David Spark] Let me throw this also at you, and I’ve said this to my own staff as well. One of my favorite things is when my staff catches me doing something wrong because it realizes we’re not a one-think group, I don’t want to be a one-think group, and I want people to see things that I cannot see.

Eddie, have you had this experience with your own staff?

[Edward Contreras] Oh, yeah. One of the things that I like to pride myself on is I hire people that are smarter than me. A lot of times I have a view, a perception, and an experience that I want to share, but it’s not the right one always. And so, it’s one of a collective.

I’m always looking at my leadership team, I’m looking at my individual contributors, I’m looking across my program to get a new perspective. And I don’t mind sharing my screen, opening up an Excel spreadsheet, and then get comments later on, “Hey, I saw this formula,” or “I saw you were doing this,” or “Your pivot table.” I love that feedback because it gets me better at what I do.

And so, I’m the first to share my screen because I have nothing to hide there.

[David Spark] Evan, similar stories?

[Evan McHenry] Oh, yeah. I mean, I think the closer you are in reporting lines to me, the higher expectations I have of you to be giving me unsolicited feedback and being critical on my actions. Because I’m a human too, and I have my own interests. If you sit down and put an engineering design doc in front of me, I’m going to go back 10 years and just start being an engineer and have fun with it.

And that’s not always the best place for me to be because, especially if it’s someone that I haven’t worked with closely, the title gets scary. And I really love having people in my reporting chain and peers across the organization that can provide that feedback.

Otherwise, we’re just going to make really bad decisions. And I think the best decisions are made with a group of people with different opinions and diversity of thought providing their input.

[David Spark] Excellent point.

Closing

30:38.816

[David Spark] All right, now we come to the point of the show, and you guys spoke very highly, both of you, of the very last quote, so your answer may be that, but I’m going to start with you, Evan. Which quote was your favorite and why?

[Evan McHenry] It was definitely the last quote from Todd. I really, really appreciate the first principles thinking here. I also like some of the subtext, the conversation that you can pull from that quote. It was spot on and exemplifies a lot of how I think about making decisions as well.

[David Spark] All right. I throw this to you, Eddie. Are you doubling down on Todd’s quote, or are you picking another one?

[Edward Contreras] I’d love to double down on Todd’s quote, but I’m going to pick a different one. Variety’s a spice of life, call it that. So, Erik, I’m going to pick Erik.

[David Spark] The very first quote.

[Edward Contreras] Yes. Under the “Why is this happening?” section, right? Erik’s quote is nice, right? And if you think of that last portion of his quote, “The best tools are optimized to give you the least amount of additional work with the highest quality information.” What I take away from there is very smart, right?

He’s not saying it’s going to be easy or that it’s not going to take a lot of money or that it’s not going to be a lot of delivery effort. He’s saying the utopia where you want to go should be that, but it may take you a lot more to get there. So, I like his quote just because you have a North Star, you’re aiming towards it, but it may be very difficult to get there.

So, don’t misuse his quote as it’s an easy delivery or a little bit of work. Usually there’s a lot of work, but at the end, you’d probably want to hit that mark.

[David Spark] By the way, let me throw this out at you, and I’ve dealt not just with security applications, but tools, a tool you’re using, it’s causing your problems, but you can still physically do it. But you know over here there’s a great tool, and sort of the learning curve and the implementation curve, just the thought of it is giving you pain, but then you do it and you get to the other side of it.

And I’ve said this, and I know I’ve said it on the show multiple times, you get on the other side, and you go, “Why did I wait so long to do this?” Yes, Eddie?

[Edward Contreras] Absolutely agree. That’s how I take Erik’s quote there is utopia, your landing spot, it should feel better.

[David Spark] All right. Let me thank our sponsor, and that would be Endor Labs. Scale your engineering impact, not your security backlog. You can actually ship secure code by default, whether it’s written by humans or AI, with security built into every single commit.

You got to go to their website, go to endorlabs.com. When you go there, let me know you heard about them on the CISO Series. Evan, thank you for coming on to the show. We loved having you on the show. Now, here’s my big question for you. Are you hiring over at Robinhood?

[Evan McHenry] We are hiring. We’re constantly hiring. We’re rapidly growing internationally. Go to careers.robinhood.com, and if you see any job postings in security or CorpEng, feel free to send me a LinkedIn and talk to me. I also want to note, I loved this conversation.

What I loved about the conversation most is that I think a lot of us in security leadership and just security practitioners get in to fight hackers, break things, or focus on technology, but eventually you get to a point where you have to have this rigor as a business leader to hold your organization accountable to delivery and report on how you’re doing.

And this rigor is just so important to running highly impactful security organizations, and it’s easy to forget whenever you’re dealing with a nation-state actor or some grossly named threat actor group, but it’s really, really critical to remember that you’re running a part of the business and it’s a critical one.

[David Spark] Excellent point. And by the way, that is a theme of the CISO Series, what you just said right there. So, thank you for doubling down on that. Thank you very much. Evan McHenry, CISO over at Robinhood, who’s also running all of IT, right?

Is that what you’re doing?

[Evan McHenry] Yep. All of CorpEng and security and it’s a blast.

[David Spark] Shouldn’t they double your salary then?

[Evan McHenry] I am appropriately compensated and happy.

[David Spark] Okay. [Laughter] I was going to send a nice email on your behalf there.

[Laughter]

[David Spark] Eddie Contreras as well, who’s the senior EVP and CISO over at Frost Bank, who I think would say the same exact thing as Evan, yes?

[Edward Contreras] Absolutely. We’re always hiring.

[Laughter]

[David Spark] By the way, reach out to either of them. We’ll have links to their LinkedIn profiles on the post for this very episode. And then thank you to our audience. As I always say, and I truly mean it, we greatly appreciate your contributions and for listening to Defense in Depth.

Tell your friends.

[Voiceover] We’ve reached the end of Defense in Depth. Make sure to subscribe so you don’t miss yet another hot topic in cybersecurity. This show thrives on your contributions. Please write a review, leave a comment on LinkedIn or on our site CISOseries.com where you’ll also see plenty of ways to participate, including recording a question or a comment for the show.

If you’re interested in sponsoring the podcast, contact David Spark directly at David@CISOseries.com. Thank you for listening to Defense in Depth.