Steve Zaliewski (2:21)

Yeah. You're not going to do it just because you love me. Okay. And so a doubling of the budget really is. There's probably been a change in something, perception, risk, something. And so I want to know what it was that caused it. Because now the replan is. I got to make sure I get that right.

David Spark (2:38)

Good answer, Steve. I love that. Well, I'm interested to know other people what, what they would do of all sudden their budget would change. But that's not our topic for today's show. I want to bring in our guest. Thrilled to have him on board. And it's with actually our sponsor who has been a spectacular sponsor of the CISO series tines. I mentioned them just moments ago. He is the field CISO over at Tynes, our sponsor guest, Matt Muller. Matt, thank you so much for joining us today.

Matt Muller (3:05)

David. Steve, great to be here with you both.

Host (3:09)

What about this AI security challenge?

David Spark (3:15)

How do we create AI security champions? So a recent report from the education company section found four categories of workers in North America when it comes to explicit AI tool use. Now, the smallest group were using AI tools daily, followed by about a quarter of workers that were using the tools weekly. And the vast majority were newcomers with no formal training or specific employee encouragement to use the tools, with about a tenth classified as skeptics. So the report shows that there was a clear wave of early adopters that could be used to push security awareness and best practices with this new tech. Now, how do you approach these people at the head of the AI class to turn them into your security champions? Steve and are there any lessons we can learn from previous tech shifts like cloud adoption or bring your own device byod?

Steve Zaliewski (4:11)

Steve yeah, so when I looked at this question and these stats, the first thing that struck me was for the early adopters, engaging the early adopters with my experience is there's actually three types. And the way I characterize them is there's those that want to do the right thing, so they're playing with the stuff, but they understand security and so they want to do the right thing. And if I educate them that the stove can be hot, they'll understand that and do it appropriately. Okay, the second part are the ones that feign ignorance all the time, which is they don't care about security, okay? They want to just do what they do. And then when they're called out, they always say, well, I wasn't trained or I didn't remember or I forgot. So their whole goal is deny, deny, deny, okay? And there's a lot of that. And then the third ones that I worry about are the entitled ones, the ones that know better, but they believe that they can put the business interest first over security and actually put the entire company at risk, not just the program. So when I look at the early adopters here, that 10 or 15% what I really say is I get to look at those early adopters through this different lens of wanting to do the right thing, claiming ignorance all the time or claiming entitlement to know better and therefore hold the accountability of the training. Understanding from that perspective.

David Spark (5:40)

All right, good point. But ultimately, you want the people who know security and are early adopters to be your security champions, ultimately.

Steve Zaliewski (5:49)

Right. And the security champions then are those that want to do the right thing. Okay. And like, so I can put money and time into that. Right. But I also have to understand the other two types because those ultimately are the ones that are going to do the greater damage to me. So how do I hold them accountable in the training to get them aligned?

David Spark (6:10)

All right, Matt, this is a good outline of it. How do you bring these people on board to be security champions?

Matt Muller (6:18)

Yeah, I mean, I completely agree with Steve. You have to differentiate between the folks for whom the grass is always greener with some new technology versus the folks who are just trying to find the path of least resistance in getting their job done. And I think for those folks, I look a lot at the early days of Slack when, when everybody had different tools and Slack's literal adoption strategy was find a team, find a small group of people in the organization that wants to go adopt Slack. And of course, there may or may not be a corporate policy related to that. And this was something I dealt with earlier in a previous role as well. And what I did was I found the Slack champions who were using it for their one small team. I said, hey, show me how cool this tool is and educate me on this. People love teaching other people.

David Spark (7:03)

Also, I'm assuming you learned something because my guess is you were not a Slack expert when you were asking them, were you?

Matt Muller (7:08)

Absolutely not. And so it was sort of understanding beyond just the literal technology itself. Why are you so excited about this thing? Right. How does it help you get your job done better? Help me understand, in the balance of equities here, I see the risk, you see the reward. Help me see the reward.

David Spark (7:24)

And Steve, I'm going to throw this to you and I want your take quickly on this, Matt, but quick. Steve, this is a perfect example because these people using AI tools are probably using them, but the ones that you like, the ones you want to turn into security champions, are probably using them in ways that you don't expect. And the other two groups you mentioned as well, you're going to need them to teach you how they're using the AI tools, aren't you?

Steve Zaliewski (7:49)

Absolutely. An AI tool, in my perspective, is a stove. And I taught you how to cook. Okay. But I didn't teach you what to cook. And that's what Matt's calling out is. So I gotta now look over their shoulder to see what type of food they're making. Okay. To be able to understand what the implications are for both how to keep them safe, but also to be able to protect them if they're doing some things that I never anticipated. Right. Like putting a whole bunch of hot oil on the stove and wanting to cook a turkey. Okay, go. Well, that's different than making an omelet, and I never anticipated that.

David Spark (8:27)

And Matt, your take on learning from these people.

Matt Muller (8:31)

Yeah, I mean, when you learn what goals people have, that's where you have to tie it back to your actual risk appetite. Right. Like, if you are in a highly regulated space, if you have HIPAA considerations, sometimes there's just some data you literally cannot put into public chatgpt. Right. And that is just the bar in the line that you have to hold. But being able to say, well, this isn't necessarily what we can use ChatGPT for, but if you're just writing a casual email to your coworker, that sounds amazing. Right? Like, I'd love to enable you to do that safely, but yeah, you definitely can't just say like, okay, I understand. That seems cool. Go for it.

Steve Zaliewski (9:04)

Well, and there's can't versus shouldn't. Okay. And then the question is, who makes that decision? You as the ciso, or does the business decide how much risk? And so I always say, let's look at it that way too. So therefore, we're having a risk conversation. So the business realizes there's no get out of jail free card here.

Host (9:25)

What we've got here is failure to communicate.

David Spark (9:30)

Do we put too much focus on language in cybersecurity? In a recent LinkedIn piece, Jay Davey, VP of Cybersecurity Operations at Planet, argues that framing security operations as a security function is a result of vague language leading to a misalignment with this core function. As a result, the SOC embraces a more limited approach that focuses narrowly on threat detection and incident response, rather than improving operational quality and underlying issues. And actually, David goes into great length explaining sort of the philosophy around security, that it sort of. It gives people a feeling of safety, the feeling that they can do their job. So I'll start with you, Matt, on this one. Is that something the soc can tackle? Because often they're just given sort of worker bee type functions. And if so, how do we start Shifting to a broader operational quality role for the SoC. So trying to achieve what Davey is talking about, sort of this overarching security philosophy.

Matt Muller (10:34)

Yeah, I agree with half of that sentiment. I agree that the SOC has sort of been treated as a little bit of an island historically. Right. Where alerts from mysterious systems popped in and you had to go resolve them. Right. And that resolution was entirely contained in the SoC. So I do think there is something to be said for the fact that security operations doesn't exist in a vacuum. Right. There's a larger picture here to look at. That said, if you look at things like the nist, csf, incident response and detection are very much part of the security life cycle. I sort of think that the larger picture for the SOC may actually be how do we help quantify a little bit more of the risk that the business is maybe intentionally or unintentionally taking on versus saying that this is now a quality issue.

David Spark (11:20)

All right, Steve, I throw this to you. Your take.

Steve Zaliewski (11:23)

So we never should have called it a society we screwed up on day one. Because what it really is is the operationalization of our siem. We're trying to find attacks and we're trying to manage an attack when it happens. That's what it was originally designed to do. And for most organizations, that's what its accountability is. But because there's lots of security tools, and so therefore security operations enter the equation, when people see it's a security operations center, they go, well, then that's where it should go. Okay. And that, I think was the fundamental mismatch of what we were trying to define the term to be versus what it has in essence adapted itself to be. And that's where this conversation comes in, is isn't security operations of tools and IT function? Yes, because the SOC is designed to be able to identify and manage the attack surface. And let's maybe go back to square one and get clear on the differentiation and then decide whether you do want your incident response teams to take over the accountability of what I call simply the efficiency around the service level agreements that the tooling has to be effectively deployed.

Matt Muller (12:48)

I totally agree with that. And if you sort of look at where SecOps or the SoC or whatever sits in the security life cycle. So often it's downstream of sometimes very intentional risk decisions that the business wants to take. And calling it a quality issue, I think we haven't solved vuln management yet. Right. Where we tell engineering teams, go fix all these vulnerabilities, where we create problems for the upstream teams. So I'm not convinced that by treating the SOC as a quality team that will solve those problems, but just in terms of saying, hey, there should be a better feedback loop to the business on the output of your risk decisions. Totally agree with that.

Steve Zaliewski (13:22)

Right? The difference between efficiency and effectiveness. We are supposed to be held accountable to effectively managing the attack. Okay, being effective. What's happening though is we're looking at efficiency of the tools to justify the organization. Are we being good at spending the dollars for the company by being efficient against the tooling in the SLAs as opposed to the SOC being effective at managing the attack surface and the attacks when they happen? And I go, that's the blending that's occurred. So let's get back to understanding what we're ultimately accountable for and where the best place is to spend the money.

David Spark (14:07)

Who's our sponsor this week? Wyatt Tines. And let me tell you all about them. Security teams are facing a constant uphill battle between alert fatigue, repetitive manual tasks, endless false positives, inflexible technology, and the looming risk of burnout. It all adds up, making it tough for teams to stay ahead of threats. Every day, valuable hours are spent sifting through noisy alerts and managing rigid workflows instead of tackling the real security issues that matter. It's draining, and over time it can start to impact even the most dedicated teams. And that is where TINES comes in. Built by security practitioners for security practitioners, TINES is an orchestration and automation platform designed to meet the demands of security teams. TINES empowers analysts and engineers to automate their most repetitive, time consuming tasks regardless of complexity. No coding experience required, just the flexibility to tailor workflows to your team's exact needs. The Result? Companies like McKesson, Canva and Mars are saving hundreds, even thousands of hours on manual tasks, allowing them to focus on impactful work and real time decision making. So if your team is ready to trade burnout for breakthroughs and tackle threats without unnecessary noise, visit tynes.com CISoseries Tines because security work should empower, not exhaust. And let me spell that web address. It's t-I n e s.com CISoseries.

Host (15:56)

It'S time to play what's Worse.

David Spark (16:01)

All right, Matt, you're familiar with how this game plays?

Matt Muller (16:04)

I am indeed.

David Spark (16:05)

All right, two bad scenarios. I'm going to yell at our audience. I have a lot of stuff that came in from the audience, but it wasn't stuff that I was happy with. So I actually went to ChatGPT this time. And asked for what's worse scenarios. So we can credit ChatGPT for this one. And I'm going to admonish that our audience. The last time I posted, I got a lot of likes on the post asking for more what's worse scenarios. But I only got two what's worse scenarios, so please send in more.

Steve Zaliewski (16:32)

Wow, so you're going to let a high schooler decide what's worse?

David Spark (16:37)

Okay, I'm not letting this. You're just. You're calling yourself a high schooler? Steve, you're the one deciding. I'm giving you the scenarios. You're making the decision. All right, all right. High school student Steve Zaliewski is here to answer. Here is your scenario. You discover your vendor has been compromised, one of your vendors, your third party vendors, they've been compromised. Or you find out your internal DevOps pipeline has been hacked. Which one's worse?

Steve Zaliewski (17:08)

Oh, to me, internal DevOps pipeline is way worse. Okay? Because that means my soft center, if it's a third party that's been compromised, I know how to shut them off. Right? I can terminate connections, I can initiate.

David Spark (17:28)

But what do they know? This is a critical third party. You shut them off, you're shutting down critical business operations.

Steve Zaliewski (17:35)

Okay, so wait a minute. So what I'm telling the business is I've shut off the technology. You have to go to manual processing and sends. It sucks and goes down all the time. They may not like the manual processes, but they do have something that they can do. Right? That's what I'm going to take advantage of.

David Spark (17:54)

I had a different take on this. I'm interested to see if Matt has his take on it. Matt, which one do you think is worse?

Matt Muller (18:02)

So I respect Steve's view on this, but I have to say I think it's the third party vendor because once a breach has happened at a third party vendor, all of your incentive alignment goes out the window. So do I have breach notification obligations? Do I have the ability to conduct forensics in a vendor system? Probably not, right? Am I going to be reliant on some account manager to feed me back answers when I have maybe a breach notification timeline that I have to hit? So just in terms of the ability to conduct incident response when there's a third party vendor involved, that's so much more variable and so much more terrifying to me.

David Spark (18:38)

That's the correct answer, Steve, by the way.

Steve Zaliewski (18:41)

Well, stop asking a high schooler for an answer, okay? This is why you go to college. All right, I get it.

David Spark (18:47)

Yeah. Well, the way I Saw it is the same thing. It's like, well, yes, they both stink, but at least if it's something in my pipeline, at least I've got some forensics on this. Who knows with third party clown over here.

Steve Zaliewski (19:02)

So, you know, and here's where my mind went to for this. This is an interesting one, right, which was when I was at Levi's, Maersk had a huge out, okay. 65% of my product ships transoceanic.

David Spark (19:15)

That was a massive, massive hack. Yes.

Steve Zaliewski (19:17)

I lost all visibility into my product. Okay? Merus got a massive hack. They were offline for months. Okay. In that case, that's what I said is the good news is I could shut down all the interfaces. So we lost visibility to where all the product was. Okay? That was the bigger risk, was, okay. Now how do I start working with Maersk to know where the product is, when it's going to be delivered, as opposed to worrying about, okay, was there a compromise through Maersk into my internal controls? I was able to get that nailed down relatively quickly. But from the business perspective, no jeans in stores. That's an extermination level event, if you want. And that's where my head went with, which is, hey, that to me was an easier problem to solve, right? Because I understood the business challenge as opposed to kind of focus on the technical challenge. Just as a perspective for the audience.

David Spark (20:15)

All right, two views, but I agree with Matt.

Matt Muller (20:19)

We could even make it one step worse and say you're entirely cloud hosted and your internal DevOps pipeline is in fact a vendor and just make the scenario even worse.

Steve Zaliewski (20:26)

Right, There you go.

Host (20:31)

Please, enough.

David Spark (20:33)

No more security automation. It's something security teams have desired for years and we're actually starting to see some of it take effect. Prior to the rise of AI and LLMs two and a half years ago, automation required increasing the size of your team. I remember actually seeing studies on this. Now it's not seen as a staff reduction, but rather a staff enhancer. I'll start with you, Steve. What have you heard enough about when it comes to security automation? And what would you like to hear a lot more.

Steve Zaliewski (21:08)

Oh, it irritates me. You want to trigger me? You come in and you go, here's how I'm going to help your analysts, okay? Because I'm going to allow them to do their job faster.

David Spark (21:21)

Why is that bad?

Steve Zaliewski (21:22)

Because what I want to do is I want you to own a problem, which was a lot of what the SOC analysts do isn't actually effective because we've got that over Time. So how is this automation allowing me to acknowledge level one, level two analysts, maybe they have a different role to play, not that they can just go faster at their current role.

David Spark (21:45)

Okay, so you've heard a lot that you want to know how they're dealing with the problems. Matt, what have you heard enough about with regard to security automation? What would you like to hear a lot more?

Matt Muller (21:55)

There's a couple things that I've personally heard enough about. I mean, the first being, you know, time to value in minutes, right? Let's be honest. Automation, you know, it's sort of like the old tell me how to make a peanut butter sandwich, right? As soon as you start saying, oh, put the peanut butter on the bread and the person takes an entire jar of peanut butter and puts it on top of the bread, you, you realize that automation, especially if you have complex processes, may actually take a little bit of time to get from zero to one, right? And I think vendors pretending that you can sort of instantly snap your fingers by putting in a platform doesn't actually solve everybody's problem. I think the other piece, and ironically we're seeing this more with the rise of LLMs, is saying that, oh, replacing your existing automation platform with AI is also going to solve all of your problems, right? That's not necessarily true.

David Spark (22:44)

All right, so this is something that, that Tynes has spent a lot of time and effort working on. I know you work with teams to help them improve their SOC environment. Let's start with what are you walking into when you're, when you're looking at a customer and you're trying to improve sort of the automation experience there? Like what is the problem as Steve has outlined that they're experiencing?

Matt Muller (23:10)

We see a couple different categories when we come in. The first is we've never had automation. We're drowning in our 30 page runbooks that nobody knows how to follow properly. Or we have a bunch of handwritten Python scripts that one person wrote when they were here five years ago and they left and nobody knows how to edit these and so on and so forth. The other sort of example is teams that maybe have invested a little bit in automation with maybe one of the legacy, you know, soar platforms or automation platforms that were quite frankly fairly rigid in how they let you automate. Right. And I think that's where we saw the fact that you, once you put in one of these platforms, you had to add people because the integrations were fairly rigidly defined and you had to know a lot of code in order to be able to make them useful. And these are folks that are looking for something that really lets the analyst, regardless of their technical ability, go ahead and automate the parts of their job that make them frustrated. Right? To Steve's point, I don't want an analyst doing their same job faster. I want them getting rid of the parts that they hate so they can go do the interesting parts. I was talking to a customer recently who described what they do as anger driven automation, which was kind of fun, right? But they're like, yeah, this thing frustrates me. I don't want to do it. It makes no sense that a human is involved in this process. Let's have automation go do it.

David Spark (24:27)

What have your customers done taught you that has caused you to change your app? Because you know, you do your best effort first stab when you go at it and then you see it operational, like, oh no, this is what they want.

Matt Muller (24:39)

It's actually pretty incredible because folks also ask me, what's the most interesting thing that you've seen someone automate with tines? And quite frankly, I'm like, I'm fascinated by the boring things that people automate with tines. Right. Because it means that they're automating the parts of their job that they just don't want to be doing. We have an annual competition called you did what with tines.

David Spark (24:58)

Oh, that's cool.

Matt Muller (24:59)

And people do show the interesting things. Everything from you can now use an LLM to help you draft a fantasy football team. Not intended, I'm sure, to processing phishing messages and triaging alerts and doing the things that again, if you're a human doing this day after day after day, it just gets mind numbing. Right.

Steve Zaliewski (25:19)

So I want to dovetail on that because I think tines is. I think you actually do more in the way you describe the problem, which was from my perspective, what this automation of what gen is doing is many of our processes that we've automated then result in automation. And then a human gets involved. Eyes on glass to be able to interpret that, to ask a question or to ask a clarifying question, to let the automation then go back and do its thing. But what we've really done is broken through so that the automation and the AI actually can take some of the eyes on glass out of the process. Okay. So that we can get much further down the path because it can ask the questions based on context that used to require an analyst. So that when we get to the end result, we're much closer to not then just having an interesting situation, but being able to recommend the right response. And I think that's the big breakthrough in the last two years that folks like tines, and I'm not advocating for tines, but I'm advocating for the capability of their technology and tines in particular is being able to do. And that got back to the how am I being effective at stopping the attack, not efficient in the use of time, and that's it.

Matt Muller (26:39)

Absolutely. I think one of the things that we've done fairly well is figuring out where to blend deterministic automation that gives you the same result every single time with the predictions and probabilistic outcomes of AI combined with, hey, sometimes you need a human in the loop.

Host (26:58)

How can we align different departments? Objectives?

David Spark (27:03)

Quote buzzwords don't necessarily translate into knowing the business impact, often resulting in an incomplete or inaccurate perception of cyber health. CISOs can't serve as a bridge to the business with buzzwords. And that's what Harsha Bellor put together some strategies for improving business communications. In a recent piece for National CIO Review, he suggested focusing communicating risks rather than controls, reporting on resilience measures rather than just prevention, and using the news as a hook into broader issues. So this is interesting. Like one of the classics is, you know, you'll hear from a vendor says we stop and X million attacks or we stop this or we prevent this. That doesn't translate into business impact, into business resolution or resilience, or doesn't speak to any of it, for that matter. So I'll start with you, Steve. Have you worked on communicating any of this with your business? My guess, yes, because you're known for saying over and over again, how does this help me sell jeans? Give us an idea. That and other strategies you feel have worked that don't speak to the function of the tool but the net result to the business.

Steve Zaliewski (28:20)

Yeah. And the oversimplification for me is you got to talk about the metrics that the business is interested not in the measurement of the security controls themselves. And it's to your point here.

David Spark (28:34)

Let me pause you for a second. Would the business come to you and say, we would love it if security could do this for us? Like, we're getting this much loss or we're getting this much leakage or something like that. Does the business say, can security do this for us? Do you have that kind of conversation?

Steve Zaliewski (28:55)

Yes, a little bit. But I would say no, because it's my job to go to the business. Right. To understand how to sell more jeans and to identify where security has a role to play that prevents them from meeting their ultimate metric, right, which was, how much money did I make this quarter selling jeans, right? That's what they want. And so when I translate that, right, or when we do that, it makes a lot of difference. And my example, I use, and you've heard me say this, and I did it. Levi's is I went to the board and I said, my job is to sell more jeans, not to secure the company. And to do that, I have to protect the brand, we have to protect our people, and I have to protect the supply chain. And that's the three areas where all the cyber attacks fundamentally, right, Prevent the revenue or damage the brand substantially. That will prevent the revenue from flowing. And, man, that just clears the deck for everybody to understand. Now you get it. And then there's a challenge, right, to be able to understand how the controls manage against those risks. But at least you've broken through and you're having a business risk conversation, not a security controls conversation.

David Spark (30:13)

Good points. All right, Matt, I throw this to you. How have you sort of broached this gap and sort of attacked the. The measurements or the metrics that mean the most to the business?

Matt Muller (30:25)

Yeah, I mean, I think there are. There are some metrics that are just silly, right? Like, our firewall stopped 40 billion attacks last month. That's just silly. That means absolutely nothing. Right? And then I think there are other metrics that are actually useful with any security team. For example, like, where is our maturity level on a given cybersecurity framework? What's our strategy for going from level A to level B and so on and so forth. Our mistake comes when we think other people are interested in those metrics. And I really resonated with this article, just saying, you know, look, we have to talk in business risk terms. That's ultimately, if the business is gonna go jump off a cliff, we're measuring and handing out parachutes, right? Like, not talking about how strong our nylon is and, you know, the. The fabric of the parachute. Like, no, they just want to get to the ground safely, right? And we have to communicate in those terms.

David Spark (31:14)

I remember being at RSA and vendors showing me sort of a dashboard and, like, what you just said, and I had said, too, Matt, about, like, our firewalls stop X million attacks. That is literally all the data that was on the dashboard. And I said to the guys, just so you know, cisos hate this. They hate it with a passion. And this is your front page. And what you showed me that they want to see is five levels deep because Then they go, oh, well, we can show you that. And go, click, click, click, click, click, click, click, all the way down and go, that should be at the top. This should not exist. And they're like, oh, well, yeah, we get. And you know, they gave me this. Well, yeah, we do this and this. And I go, no, I'm just telling you, like, I'm just the messenger here. Like, they hate this. Just so you know, they hate it. And you're here at rsa. God knows how much planning you did. And you're literally your front page is something CISOs hate.

Steve Zaliewski (32:05)

So where that resonated with me. And let's do phishing attacks, because this is it, right? Which was to Matt's point, do I want to be able to go to the board and go, there were a thousand phishing attacks today and I stopped 997, or do I want to come in front and go, in spite of everything I do, we average three successful phishing attacks a day. And this is how I manage the damage of those attacks, to be resilient, to move forward. Yes, that's what we want to do, because that's our job.

David Spark (32:38)

Good point.

Steve Zaliewski (32:38)

Right. And the other 997 is irrelevant. It's for the ones that get through. How do we manage it? And then how we trend that? Because we'd like to get it down to two. But it may be that that is just the sustained resiliency we have to have. And that was where I was shaking my head. Because when I went forward and said, we're not Talking about the 997, we're talking about in spite of everything, for prevent, what do I do to detect contain? And then everybody's in right now they're simply saying, so why can't you stop 100%? And I go, because humans are the weakest link and they make mistakes. And then everybody in that room kind of shakes their head because they understand what I just said. And I go, so what do I do about the fact that they will come through? And now I have to get better at resiliency. And you've taken them through the why can't we just prevent.

David Spark (33:29)

But. But you also pointing out that this is not a thousand links that I had to deal with. I'm only dealing with three now, which is a far more manageable thing that my team can deal with. And thankfully, we bought this phishing tool to get rid of 997.

Steve Zaliewski (33:44)

Well, and we have tines because we've automated when we're notified that somebody goes, oops I fell for the attack and I gave them my password. How quickly can I contain the damage that's occurred between the time they did it and the time they let me know? Right. So it doesn't become a punitive exercise. It just becomes an exercise at speed and resiliency.

Matt Muller (34:06)

One other thing as well, looking at the article where they talk about using the news, I think communication of non risk is also something that's a little bit underestimated as well. I would always have my threat intelligence teams that were looking at articles being published or whatever. Even if the attack didn't impact us, we would actually in the CISO daily roundup just say, hey, here's what's out in the chatter. FYI, we have controls against this. We think we're doing all right here. And it makes the communication of risk so much more credible when you're saying, oh, and by the way, here's the stuff you don't need to worry about.

David Spark (34:38)

Well, that brings us to the very tail end of the show. I want to thank our guests, Matt and Steve. Matt, I'm going to let you have the last word. But first, Matt, I do want to thank Tines for sponsoring this very episode. Everybody, the audience, if you want some help with your automation, you got to go check out what they're doing at tines. So please go to this address so they know we're the ones who sent you there. Tines.com cisoseries tines.com cisoseries T I N E S Just go there. All right, Steve, any last words for today's discussion?

Steve Zaliewski (35:09)

Just a thank you to the audience for doing this. And Matt, nice job today, which was this one is a pretty meaty conversation for me because it's top of mind for everybody, right? Efficiency versus effectiveness. And we need automation. Brilliant at the basics is what we're driving for. And automate. Automate. Automate is a key component component of that. So I thought really, really fun conversation today. Appreciate it.

David Spark (35:33)

And by the way, Steve, I want to say something to you. I just got back from doing a live recording in Dallas and the number of people came up to me telling me how much they loved the show is astounding. I want to thank you as well because they love hearing you on the show. So thank you very much as well. All right, Matt, final words. And by the way, any plug for times or any offer you want to make to our audience and are you hiring? Give us the whole lowdown.

Matt Muller (35:57)

Yeah, I mean, we're hiring. If you want to experiment with Tines for free. We have a community edition that's free for life. And you know, look, I love talking about automation, but I also love talking about the overall approach of cybersecurity and how automation fits into that. Right? It's not your whole program is not automation. And so just in terms of connecting on LinkedIn and connecting on Bluesky, love having these types of conversations. Love the this podcast. Thank you both so much for having me on.

David Spark (36:22)

We will have a link to Matt's LinkedIn profile on the blog post for this episode. Feel free to reach out to Matt directly.

Matt Muller (36:29)

Yes, yes indeed.

David Spark (36:30)

Thank you very much audience. We greatly appreciate your contributions. Especially if you send in what's worse scenarios. I will like you that much more so I don't get taunted by Steve of having to lean on ChatGPT. Go ahead Steve, send us in more scenarios and more questions, comments, online discussions. We love it all. And thank you for listening to the.

Host (36:53)

CISO Series podcast that wraps up another episode. If you haven't subscribed to the podcast, please do. We have lots more shows on our website cisoseries.com Please join us on Fridays for our live shows Super Cyber Friday, our virtual meetup and Cybersecurity Headlines. Week in Review. This show thrives on your input. Go to the Participate menu on our site for plenty of ways to get involved, including recording a question or a comment for the show. If you're interested in sponsoring the podcast, contact David Spark directly@Davidisoseries.com. thank you for listening to the CISO Series podcast.