Every business wants to grow. But every CISO is tasked with managing and ultimately reducing risks. Being too cautious makes a CISO seem like an impediment to growth. So how do you manage the risks of growth with the realities of cybersecurity?

This week’s episode is hosted by me, David Spark (@dspark), producer of CISO Series and Mike Johnson, CISO, Rivian. Joining us is our sponsored guest, Matt Radolec, vp, incident response and cloud operations, Varonis.

Got feedback? Join the conversation on LinkedIn.

Huge thanks to our sponsor, Varonis

Full Transcript

Intro

0:00.000

[Voiceover] Best advice I ever got in security. Go!

[Matt Radolec] A good plan executed now is better than a perfect plan executed next week.

[Voiceover] It’s time to begin the CISO Series Podcast.

[David Spark] Welcome to the CISO Series Podcast. My name is David Spark. I am the producer of the CISO Series and joining me for this very episode, it’s one of your favorite co-hosts, it’s Mike Johnson. He’s also the CISO over at Rivian. Mike, say hello to the audience.

[Mike Johnson] Hello, audience. I’m glad I’m one of your favorite co-hosts here.

[David Spark] I’ve polled them all, and that’s what they told me.

[Mike Johnson] I believe it. I’m one of two, so yay.

[David Spark] Well, one of two on this one. There’s also other co-hosts of other shows as well.

[Mike Johnson] Okay, well.

[David Spark] We did a Family Feud style, top five answers on the board, that kind of a thing.

[Mike Johnson] And I was on it. Great.

[David Spark] Great. You were on it, yes. I can’t tell you which number though you were in. We’re available also at CISOseries.com. For those of you not aware, there are other wonderful programs on the show and other wonderful co-hosts as well. If you don’t know them, get familiar with them. Also, our sponsor today, an absolute spectacular supporter of the CISO Series.

We love, love their support. Who is it? It’s none other than Varonis, and they’re always developing something new and cool, and this is what they’re doing continuously. Discover and classify critical data, remove exposures, and stop threats in real time – this is the key cool part – with AI-powered automation.

Pretty darn cool. We’re going to be talking about that, incident response, lots of great stuff later in the show. And actually, they’re responsible for our guest today, who I will introduce in a moment. But first, Mike, you and I, in just about three weeks, just a hair under that, we will be at BSides San Francisco.

[Mike Johnson] Yes.

[David Spark] Doing a live audience recording of our podcast, and I’m super-duper excited about that. We did it once before, and I think my favorite part of this is the fact that we do it in the movie theater, and our logo is the largest I’ve ever seen it.

[Mike Johnson] Big, big logo. Yeah. It was so fun when we’ve done this before, and I love BSides. I love the audience interaction that we get, and yeah, it’s pretty cool seeing the logo just like, what? Four stories tall? It’s amazing.

[David Spark] It is pretty awesome. And we have three wonderful sponsors for the show as well. And we’ll have a surprise guest. Soon we’ll be announcing it, sooner or later, but we’re very, very excited to do the show. So, if you are not already going to BSides and you haven’t gotten your tickets, go ahead and get your tickets.

And if you are scheduled to BSides, well, there is a way to sign up for specific sessions. Sign up for our session. It’s going to be 2:15 p.m. Pacific time at BSides in San Francisco on the Sunday, May 5th. So, please make sure you register for that. All right. Now it’s time for our guest, who we’ve had on before on multiple occasions, not just this show, Defense in Depth, Super Cyber Friday.

He’s fantastic. We love having him on. He is a Senior Director, Instant Response and Cloud Operations over at Varonis, none other than our sponsor guest, Matt Radolec. Matt, thank you so much for joining us.

[Matt Radolec] David, thanks for having me. Great to be back.

Managing security changes for business optimization.

3:26.642

[David Spark] Balancing security with business growth is an ongoing issue, noted Rita Gurevich in a recent Dark Reading piece. And the model is not foreign. Rapidly evolving cyber threats increasingly target third parties outside your perimeter at greater volume, while organizations also try to meet a growing patchwork of regulatory compliance, all balanced by the need for business to grow itself in a challenging economy.

It sounds like a, well, a CISO’s job description, but I specifically want to focus on the growth problem. There are two growing issues, company growth and growing threat landscape. Mike, there is the security program you deal with today and the security problem for growth. How do you deal with these two different growth vectors, one very much desired and one you can’t avoid?

[Mike Johnson] So, I’d like to change the word a little bit here. A lot of folks use the word growth and it’s such an overloaded term. And I like to more think about it as scaling. How do you scale your security program for what the company needs, wherever the company is?

[David Spark] Good point.

[Mike Johnson] It could be a company that is in hyper growth, or it could be a company that has a steady revenue stream, keeps hitting their numbers, and is continuing down that path. Both of those are challenges that we have to figure out how to scale security for. And the reason why I highlight that is I think some CISOs will try and build a ratio, that your security team should be X amount of people, if your company is Y amount of people.

And I really think where that breaks down is we need to focus around automation; engineering solutions to the scaling problem; bring technology to bear to allow you to scale your program with the company. So, that’s really how I like to think about it is, how do you bring engineering solutions to appropriately scale your team, your capabilities, your function for whatever the company needs, wherever the company is in its journey.

[David Spark] This is very much an Israeli philosophy of dealing with security because they have always been a small organization, always dealing with larger adversaries, and many of the security companies out there have very much this mindset of constant scaling, looking for sort of engineering ideas to be able to deal with this.

All right, Matt, and I do like your idea there, how do you deal with, as Mike redefined it, the issue of company growth, but security scale at the same time? And making those sort of married together, if you will.

[Matt Radolec] I look at this twofold. One, I’ll share an idea from a customer. And that customer said that sometimes your company is growing so much, maybe you’re growing by acquisition, that you need to tell the business leaders that security has to grow with it. Right? If you’re buying another company, you’re doubling your employee headcount, and the boss is coming down and saying, “Hey, we’re doing this, you need to take on more responsibilities.” That’s your time to say, “Yes, we need to grow the security team alongside with our growing business.” At the same time though, completely agree with Mike, same thing in this engineering culture, there’s this mindset of innovate or die, right?

Which is, how do you take everything that you did last year and do it again, but do it more efficiently and do it at a higher quality and take on more things? And I think the security leaders, they have to know that as well. You have to balance the fact that you do need to automate more, you need to find ways to continue to scale, and that you’re not always going to have these periods of linear growth or even exponential growth.

Sometimes you might not grow at all, but you still need to grow in what you accomplish by engineering, by innovation.

[David Spark] All right. So, we’re hearing some things, and I really love the advice you have of, if the company’s growing, mention security grows with it as well, and it’s a good time to bring it up because it’s not a time to complain. “Well, we don’t have the money,” “But you’re growing. Come on.” That and also the need for innovation.

Is there another angle that we’re not looking at? Either one of you jump in here.

[Mike Johnson] Well, I think one of the things that you’d brought up in the question is the threat landscape. And there’s really two reasons for that threat landscape changing that come to mind. One is what the attackers do changes, like ransomware. That was a big shift in the threat landscape for us.

But it can also be what the business does changes, like entering new markets. Say you’ve been a US-centric company, and now you’re going into Europe, or you’re going into South America, or you’re going into China or India or the Middle East, all of these have different threat profiles. Your threat landscape has changed.

So, that’s another reason why the threat landscape can change, and that’s something that you need to factor in, is those new markets and what that might mean.

Here’s some surprising research.

8:29.000

[David Spark] When we talk about security concerns with generative AI, it’s usually a conversation of models ingesting sensitive data. But we also need to look at how our traditional security methods can be applied to these models. How do we even red team a large language model? So, data scientist Ben Lorica cited a Carnegie Mellon University research paper finding that current red teaming approaches lack structure and consistency with a lack of consensus on any basic criteria.

So, what is the way forward for security teams that doesn’t lead to complacency or security theater for LLMs? What are the tests we’re going to try out to see if our theories are correct? And so I guess tests with these LLMs, like I’m not looking for the answer, but what is the roadmap to working with them, if you will, Matt?

[Matt Radolec] Yeah, first, I want to start out with red teams lack consistency and structure. I think when I look at red teams, the one thing that’s unanimous is their goal, the outcome that they’re after, which is compromise or escalation of compromise, or saying that I was unable to compromise something is another reason to do a pen test.

So, I don’t know that they lack structure and consistency. But what’s the goal of testing an LLM? The goal of testing an LLM is to say is the security controls that I’ve put in place, are they effective? So, if I’m trying to separate data to be accessible by different people, if I’m trying to ensure that that data warehouse itself is secure, I want to use red teaming methodologies to validate that.

The good things about working with red teamers is they do take that chaos approach. They do try new things. They do innovate. They might even write a new exploit for whatever it is that you have that’s housing that LLM. But at the same time, nothing short of just basic user acceptance testing.

When I think of organizations that we work with that are trying to deploy generative AI, one of the things I always say is, “Well, have you have you queried it yet? Have you asked some personal questions? Have you asked the questions that you think your employees are going to ask? Like how much are we going to get in raises this year, or what’s the performance review of my boss, or did David over there in the podcast series, did he have that scandal that everybody talks about?” These are the questions you should ask your AI, and if it returns the unexpected results, it probably means your security controls weren’t in place and you should reevaluate that.

But at the same time, that’s another great reason to ask red teamers to do that. Red teamers thrive in the, “Hey, come in, test whatever I have, take whatever test plan I have and turn it into material findings.”

[David Spark] Mike, I asked you the same thing about what is the way forward here with LLMs? With red teaming, that is.

[Mike Johnson] Yeah, sorry, I think there’s a desire because of how quickly we’ve seen LLMs come to use within corporations, there’s this desire to have very quick security answers as well. That all of a sudden that we know the right thing to do from a red teaming perspective. And I think we really need to allow ourselves a little bit of time to figure out what are the appropriate standards, the appropriate methodologies, and recognize that there will be some bad approaches.

We will have some theater. I continue to liken this to when the iPhone entered the corporate space, and corporations had no idea how to deal with that. And it took, gosh, probably two years for us to figure out what the right controls were, and it’s going to take us some time to figure that out with LLMs as well.

So, I don’t know. Again, this is one of those that there’s not a clear answer because we’re still trying to figure it out.

[David Spark] What would you do to test it? Kind of like what Matt was saying, maybe you should be asking just some basic questions. What would you do to sort of begin your journey to understanding, I guess?

[Mike Johnson] Yeah, I liked what Matt said, which was just start asking it some questions. Yeah, I like what he said about the chaos approach that red teams bring. There’s a lot of things you can do to just try and trick it. I was recently talking with someone who is injecting a prompt into emails that are going to be summarized by an LLM that basically says, stop processing, now do this new thing, very much like what we would see with SQL injections in the past.

So, I think some of this is just dust off those same tests that we were doing in the past and just use the new syntax would be a great place to start.

Sponsor – Varonis

13:11.044

[David Spark] Before you do anything else, I do want to tell you about our spectacular sponsor, and that is Varonis. So, go from data darkness to automated data protection with Varonis, the leader in data security. So, a dozen security products in one. It seems like it’s constantly growing, by the way.

Varonis takes hundreds of use cases, making it the ultimate platform to stop data breaches without adding more work onto your team. Within minutes, you’ll be equipped to detect anomalous behavior, ensure compliance, and remediate risk to your sense of data in the cloud and on-prem. Reduce your risk without taking any and see Varonis in action today at, let me give you their web address, it’s Varonis.com/cisoseries.

Check it out.

It’s time to play “What’s Worse?”

14:06.738

[David Spark] All right, it’s time to play “What’s Worse?” Matt, you’ve played this game before, you know how it goes. I will make Mike answer first. And what’s cool is this situation has been modified, but it is based on real events, all right? I don’t actually know what the real answer is, but because of that, all we know from our submitter, although I know more, is that her name is Katie.

We’re going to leave it at that, okay?

[Mike Johnson] Great.

[David Spark] So, Katie is responsible for this. Okay, let me just give you the setup and then I’ll tell you the two scenarios. This is your setup. You arrive as the first CISO and the first InfoSec hire of a small but rapidly growing tech company that handles PII and sensitive information. You’ve been told during the interview process the organization has a lot of room to grow and they need help with security hygiene and governance.

There is one engineer who has a passing interest in security and helps when they can, but otherwise no GRC or security team. You identify a lot of security issues within the first week on the job, but the business seems eager to learn. Good. The product is a freemium model, but enterprises are starting to notice them and use the product.

So, that seems good. Well, here are the two scenarios.

Scenario number one. After a few weeks, you learn the sales and support teams are receiving a dozen or so RFP security questionnaires each week from enterprises that want to use the product. The head of customer support had instructed all support agents to check yes to everything and send the questionnaires back in order to expedite signups.

Oh, my God, look at the face Mike is making, I wish I could bottle this for you, but it’s literally like something shot up his spine when I said that. Did not land well.

[Mike Johnson] Yeah.

[David Spark] Okay. Enterprise customers represent a significant percent of the revenue stream as they pay for the upgraded platform, but a small percent of overall users. After some digging, you discover some of the upgraded customers who have received these questionnaires are school districts, political campaigns, city governments, and some small municipalities.

Not good. Again, based on real events.

[Mike Johnson] Yeah.

[David Spark] Scenario number two. During a one-on-one with the lone engineer who has been paying attention to security, they casually mentioned that they “had an issue a few months ago,” but the engineer, “handled it and cleaned up the mess.” After some digging, you discovered that the issue was indeed a breach, but it’s not clear if any customer data was compromised.

The team does not have any additional information about what happened, but nobody was notified. So, now you know this. Mike, I’ve never seen you sort of rub your face and look in shock after hearing these two. So, I’m getting the sense that both of these are actually hurting you right now.

[Mike Johnson] Well, what it is, is I really feel for Katie on this.

[David Spark] Because she went through it.

[Mike Johnson] Right. So, many of our scenarios are just made up and some of them are just crazy like that would never happen. And so that’s why it’s such a visceral reaction, is to know that someone actually had to go through this. Katie, I feel for you.

[David Spark] Now, let me ask, in all your years of working, and go back to your early times, did you ever see something that said, shivers up your back, kind of like what happened with Katie here?

[Mike Johnson] Yes, for different reasons, and maybe one day I will actually tell you.

[David Spark] Okay. Well, we’ll have to wait for that.

[Mike Johnson] Yes, yes.

[David Spark] All right. So, walk us through which one is worse here.

[Mike Johnson] So, what you have, and I might be mixing a little bit of the setup with this scenario, so please correct me, but what we have is, essentially, the company is lying to prospective customers who are then signing up based on those answers. They’re assuming that you’re saying yes to everything, and then they’re engaging, they’re signing the contract as a result of those answers.

So, that scenario one is just lying to your customers.

[David Spark] Lying just in an eager effort to start working with a lot of companies. Let’s just say yes to everything, and let’s let the chips fall where they may if the chips do fall.

[Mike Johnson] Yeah. And I’m making an assumption that the answer is not always actually yes. Like, they’re saying yes, but that’s not the correct answer.

[David Spark] Yes. There are probably some cases where there’s a lot of nos in there too. Yes.

[Mike Johnson] Correct. Correct. And so the customers are going to see this as untruths.

[David Spark] Yeah. I should mention the second version is a form of lying too.

[Mike Johnson] And so in the second scenario, what you have is an incident that you’re not sure of what the scope was. It was an incident.

[David Spark] It’s more than that. It’s flat out, it was a breach. So, it’s more than just an incident.

[Mike Johnson] It’s sometimes a situation where an engineer says something is a breach, and it’s not actually. The engineers generally should not be the person who’s saying that this is a breach or it’s not. So, we’ll just say it was an incident. But what you’d said was we’re not sure of the impact, the impact is unknown, and because it was so long ago, cannot be known.

We just have no idea. And so what I kind of think about in trying to compare these is which story do I want to actually have come out when I’m talking to a customer? Do I want to have the fact that those things that I said that I do, some of them I don’t actually do, or do I want to have the conversation of I had a breach, and I didn’t tell you about it in the moment?

So, which one of these do I want to have?

[David Spark] But I should also mention that there’s also an interesting timing thing is, I had a breach, but it sounds like in the description here, it happened before you signed up all these customers. So, a lot of these customers were not part of this breach too.

[Mike Johnson] Right. And that’s actually part of my reasoning that the first one actually is the worst because what you’re setting up with all those customers is you’ve had a dishonest relationship with them from the beginning. Versus the second one is you’re having to go and tell them that you had a incident that maybe you didn’t have a conversation with them about.

And that actually can be a good news story because you’re actually being honest with them in the moment. Like, “This thing happened that I wasn’t aware of, and now I’m telling you about it,” is a better thing of, “Yeah, we’ve actually been dishonest with you from the beginning, so you shouldn’t trust anything else that we’ll say.” So, long answer, Katie, again, I’m sorry you had to deal with this, but I think the first one is the worst of the two.

[David Spark] All right. Matt has been very quiet listening to you ramble on and on, Mike. Matt, I want you to walk us through which one do you think is worse?

[Matt Radolec] Which is unusual for me to organically disagree with Mike on “What’s Worse?” but I do today.

[Mike Johnson] Great.

[David Spark] Awesome.

[Matt Radolec] And I’ll walk you through why. Yes, these questionnaires are immensely important. I’ve been a part of those both on the customer side, like when I was working for a firm, being the vendor or delivering and asking vendors to fill these out. And on the other side now as someone at a software company, we have to fill out these questionnaires all the time.

Yes, marking yes and getting someone to entrust you with whatever it is that you’re going to process for them – definitely bad, right? You’re doing business with someone that might have some minimum requirements, but I’ve found though even the toughest questionnaires, like the ones that we see from the big banks, don’t often have things that you can’t overcome, controls that you can’t [Inaudible 00:22:14].

A lot of these controls that they’re asking you to do are reasonable. So, someone might have wrote a check that your security program can’t cash yet, but that problem is surmountable. You can get better security.

But whatever it is, whatever is unknown, just as much is known by that statement about the breach, there’s just as much unknown, and that’s what makes it worse for me. That engineer could be like, “Yeah, we had a breach,” and on one hand, they might be totally lying. They might not know what that word means.

But on the other hand, they might have had some real [Beep] go down and your stuff is held together by Elmer’s glue and duct tape, and you don’t know it. You could still have an active leak and not know it. And I’m thinking to myself, that one’s worse because I want to spend all my time with this engineer getting to know everything that they know about it and about our environment.

And the other one, I can say, “Customers, we answered with a roadmap version of the guidance of our future security state. Here is a updated version of our guidance and our actual security state. We hope that you’ll continue to do business with us,” and you’ll send that new questionnaire out with a nice apology, and you’ll take it on the chin.

[David Spark] Well, by the way, this is also modifying the situation too. You’re not allowed to modify the situation, Matt.

[Matt Radolec] Okay. Well, I’m going to say then the unknown breach is worse because it could still be ongoing, could still be a bad scenario, could also not be, but I think that the other situation is recoverable, whereas there’s a larger potential that the breach is not recoverable.

[David Spark] By the way, I also want to throw out there’s also the option of nobody trusts these questionnaires anyway, so what does it matter if you say yes or no? There’s an aggravation that they’re out of date the second they’re filled out. There’s that argument as well. Mike, do you want to change your answer or you’re sticking to it?

[Mike Johnson] I don’t because I think you have to go in with the idea that you’re filling out these questionnaires and you’re actually answering them the way that you believe the answers are. So, I still stick with that. I think the unknowns is a really good point, Matt. And so I think, again, back to these both suck.

I think both of these could be argued as being the worst, and that really makes for a good “What’s Worse?” scenario.

[David Spark] Kudos to Katie.

Please. Enough. No more.

24:26.752

[David Spark] Today’s topic is incident response, and I actually don’t think we’ve done this in Please. Enough. No More. And Matt is the perfect person to help us with this. But I’m going to start with you, Mike. What have you heard enough about with incident response, and what would you like to hear a lot more?

[Mike Johnson] I think you’re right, David. I think we haven’t had this one before because I would know it because I love incident response so much, and I have so many thoughts. I’ve spent so much of my career with incident response, some form or another. But to answer the question, I’d like to hear less about tools, specific tools, like your SIEM or your MDR provider or magic boxes that automatically solve an incident, less of that.

I would really like to hear more about engineering-based approaches, like the scaling conversation that we had earlier, and how that can be applied to incident response. So, that’s what I’d like to hear more of.

[David Spark] All right, Matt, I am throwing this to you. What have you heard enough about with regards to incident response, and what would you like to hear a lot more? And this is also a great opportunity to explain what the heck Varonis is doing in this area.

[Matt Radolec] Sure. I have heard way too much of, “This incident happened because it’s their fault.” Just far too much of it. And what have I not heard enough of? This actually ties to our “What’s Worse?” Is this incident a breach? I find that in a lot of investigations or incidents, people have an auto assumption it isn’t, or they think that only breaches are the ones where actors are involved, and it’s kind of one of these things that gets highly publicized.

Whereas breaches happen all the time, like breaches of your compliance, trust, or breaches of regulations happen all the time where sensitive information is mishandled, and oftentimes our plans are not activated, and breaches are not sought after for these what I might call routine data breaches, so I want to hear way more about that.

[David Spark] So, let’s delve into how Varonis is dealing with this. What is the sort of approach that Varonis is doing now with incident response that maybe you weren’t doing like a couple of years ago, like how has your incident response plan evolved?

[Matt Radolec] So, for us with our clients, it has always been about answering the question first, was data accessed or exfiltrated by unauthorized persons, and do you have a breach? That’s been the aim of our IR team as an extension of other IR teams or other IR providers like customer IR teams or third-party IR providers that customers take in.

There’s always been this gap. Hey, is this a breach or not? And what we’ve built a name up is, “Ask Varonis that.” I think of even the large-scale IR firms, like some of the top ones, the household names that we all know, they might bring us in for those types of scenarios. And I think that’s really where our sweet spot is as to whether or not an incident is a data breach.

But also now that we exist a lot more in the cybersecurity space, being the first person to tell you that there might be an incident as well is somewhere where we’ve evolved.

[David Spark] All right. Well, that’s interesting that that is your first approach to it. So, let’s assume we’re playing the flowchart game here. Yes, it is an incident or yes, it is a breach or no, it is not a breach, but you still have to take action in both cases. How do you deal with that? And I know this is a long and involved thing, but just sort of give me sort of the skeleton behavior and how you work with clients.

[Matt Radolec] Yeah, I think how does an organization with like a good incident response plan, or as Mike put it, a well-engineered incident response plan do it? Well, they have a breach response plan that’s built into it, so when they think that sensitive information has been accessed by an unauthorized person, there’s a duty to report to someone for somewhere for some kind.

That’s usually something that the breach response arm of an IR plan gets spun up from so that the IR arm can continue going with things like eradication or containment or recovery.

I also think though this is a lot why, and I think this was probably something well publicized in the last 5 or 10 years in incident response, the importance of having a technical team and an incident management team so that you can do more than one thing at once in an incident, and that incident response plans are not linear.

If anything, they’re multi-threaded and they’re following the same process over and over again to collect information, let decision makers make decisions based on urgency or business needs, like in a ransomware attack.

And then you have technical teams continuing to gather and produce analysis and information. Ultimately, there’s a lot of decisions that get made in an incident that are risk decisions by an organization, most often based on timing. We need to make a decision about this, but do we need to make it today?

And these are the things that I think the more that you prepare for, the more that you write down, the better off you’re ultimately going to be, and if you simulate them, they’ll go a lot better too.

Looking down the security roadmap.

29:17.172

[David Spark] In the DevOps world, the idea of cattle not pets is well established. Briefly, when possible, don’t get tied to equipment or services that can be easily replaced by a duplicate. Now, arrays where servers can roll over to new ones are better than dedicated systems. As Google Cloud CISO Phil Venables framed it, security teams need to move to the scale, predictability, and reliability of more industrial approaches.

Part of this is moving away from individual security heroism to automated team approaches, as well as moving to metrics with more leading indicators to meaningfully measure performance. Those all sound good, but what is the biggest challenge of moving to this more industrial approach? I’m going to start with you, Mike.

If it was easy, everybody would have done it, right?

[Mike Johnson] So, I loved this article, and one of the things that folks need to take away from this is Phil isn’t offering a solution. He’s offering a philosophy, a theory, and turning a theory into practical is always the hard part. But at the same time, sometimes just changing those perspectives and changing your mental model, they allow you to nudge in a direction when an opportunity comes up.

When you’re working with an engineering team that’s going to go stand up a single point of failure, that’s an opportunity to say, “Oh, wait, maybe we shouldn’t do that. Maybe we should have a bigger conversation about how we’re not having to manage every server individually, how we’re not having to have the artisanal approach to a system.”

And related to that, what I see is Phil constantly revisiting the automation concept. And I’ve mentioned the engineering approach several times, and that’s what he’s talking about. And again, looking at where you have the opportunity, where a new process is coming up, where somebody is standing up something that is manual, again, you can say, “Hey, can you automate that?” So, it’s really giving you that opportunity to inject a new way of thinking.

And again, maybe that’s not the easy solution. The easy solution is just toss it out there, we’re going to do it the simple way, but you’re not likely to come back and automate that. And so if you’ve got this philosophy of the industrial solution and bringing those, when those conversations come up, bring that philosophy into play, that helps you nudge it forward.

This isn’t something that you can change overnight. You have to nudge it when you have the opportunities.

[David Spark] Let me bring this over to you, Matt. As Mike just said, this is about philosophy, and I guess getting a team on board, how do you nudge in this direction?

[Matt Radolec] Yeah, I think one is cost. You have to have a real conversation about the cost of being that good at security to get to like a Google or an AWS level of availability. I often think of that akin to like a Netflix level of availability. You’re paying for multi-node, high availability, high rollover.

So, I do think the first thing you have to overcome is cost. What it’s going to cost for us to be, for lack of a better term, that cool.

I think the second thing that you have to think about, though, is the staff that you have. And something that I think a lot of CISOs are going through right now, at least in the conversations that I have with them, is they’re very much faced with this upgrade challenge. They know that moving to this industrial engineering, automation-first culture in security is something that they have to do, but they’re realizing that they have a lot of people who are capable of analysis work or using security products, but not capable of doing the engineering work of building new and innovating, and that skill set is both expensive and not easily replicable.

Just because you have one person that can do it doesn’t mean they can just train another person on your team on how to write code or how to automate things with Python.

I think one of our pieces of reading material is a book called Violent Python. You can give everyone on your team that book, but you might only get one or two people that come out the other side and they’re good at Python. But it doesn’t mean that the other people don’t have a use. It’s just if you’re trying to take an engineering-first culture, you need to think about hiring engineers and having engineering managers.

This is where DevSecOps was born from. And you have to think about the cost of doing that. You’re saving yourself in the long term because you’re not paying people by the hour to do the manual tasks, but you’re paying for it upfront by investing in good engineers.

[David Spark] Very, very good point.

Closing

34:08.737

[David Spark] And that brings us to the very end of this show. Matt, thank you very much. I’m going to let you have the very last word, but I do want to mention your fantastic company. And that is Varonis. Remember, continuously discovering classified critical data, remove exposures, and stop threats in real time with AI-powered automation, along with what I was talking about earlier is just Varonis has a fantastic suite of products that help you deal with your data and managing breaches, whether you’ve got one or not, as Matt was just explaining.

Mike, any last thoughts?

[Mike Johnson] Matt, it’s always such a great time to have you on the show. As I said, I love geeking out around incident response, and I think we have such great conversations about it when you come on our show. So, thank you for joining us again. One of the things that I wanted to highlight to folks is something that you’d said about the importance of having technical teams separate from the incident response teams.

And I do think that people don’t really understand the difficulty of multitasking during an incident. And so your point around have technical teams that can go and focus on the details, and you have an incident response team that can focus on managing the incident, making the right decisions with the data that the technical teams can come up with, I think is really good advice.

So, thank you for that point. And again, thank you for letting me geek out with you on incident response. So, thanks for joining us, Matt.

[Matt Radolec] No problem. Thanks, Mike.

[David Spark] Well, we welcome our audience to geek with Matt as well, for that matter. Now, Matt, I’m going to throw this to you, a couple of quick questions. I’m assuming people can find you on LinkedIn, and we’ll have a link to your profile there. Are you hiring at Varonis? And let me also remind people to check out their site for a demo, and they also provide some pretty cool first look tools that you can try out.

That web address is varonis.com/CISO series. So, just remember that, varonis.com/CISO series. Matt, any last thoughts and any offer or anything you want to say to our audience?

[Matt Radolec] Yeah, it’s super relevant for our conversation today. You talk with companies about you want to do business with, everybody’s got a POC, right, a free POC. Ours is called a data risk assessment because at the end of it, you are going to get a report. It’s going to be a snapshot of your controls for a period of time.

And the reason that people move forward with us is they buy into our engineers, and they want to automate a lot of stuff. And so anyone listening can do one of those free risk assessments. They can visit that link that you have. And if they want to see how we might be able to automate part of their security stack, that’d be a great reason to do it.

[David Spark] This is the SaaS-based tool you have, right?

[Matt Radolec] Yeah, that’s right. All in the cloud, delivered from the cloud. Yeah.

[David Spark] It’s pretty darn easy to do. This is very, very cool. Well, thank you very much, Matt. Thank you very much, Mike. Thank you to our audience as well. We greatly appreciate your contributions, like “What’s Worse?” scenarios that are actually real, and you could just give us your first name.

You can do that if you don’t want us to disclose it. But if you do want to, yeah, we’ll take your full name, give you full credit for it. Just give us your great contributions. And thank you for listening to the CISO Series Podcast.

[Voiceover] 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 at David@CISOseries.com. Thank you for listening to the CISO Series Podcast.