On the onset, no one purposefully misconfigures a tool. But over time, it happens. Configuration drift inevitably results in security issues. How are we managing our tools, and when do we know they’re no longer set the way we want them to be?
Check out this post 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 Geoff Belknap. Joining us is our sponsored guest, Rob Allen, chief product officer, ThreatLocker.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, ThreatLocker
Security tip of the week – Tenable
Jump to the full tip here.
To learn more about exposure management, go to tenable.com.
Full Transcript
Intro
0:00.000
[David Spark] On the onset, no one purposefully misconfigures a tool, but over time it happens. Configuration drift inevitably results in security issues. How are we managing tools and when do we know they’re no longer set the way we want them to be?
[Voiceover] You’re listening to Defense in Depth.
[David Spark] Welcome to Defense in Depth. My name is David Spark, I’m the producer of the CISO Series. And joining me as my co-host, one of your favorites, I know he is, it’s none other than Geoff Belknap. Geoff, say hello to the audience.
[Geoff Belknap] I think you mispronounced Michael’s name, but here I am and I’m happy to be…
[David Spark] Geoff is being self-deprecating.
[Geoff Belknap] That’s the only deprecating I know how to do.
[David Spark] People adore you. In fact, we have a feedback form – feedback@CISOseries.com. Let us know how much you love Geoff as a co-host.
[Geoff Belknap] And why Andy is better.
[David Spark] No. I think you said the name Mike earlier too.
[Geoff Belknap] [Laughter] Michael? Mike? Yeah, sorry.
[David Spark] Our sponsor for today’s episode, a phenomenal sponsor of the CISO Series, and that would be ThreatLocker. They have a zero trust platform, and one of the cool new tools on their platform is called Defense Against Configurations. We’re going to learn more about that later today, but also, we’re talking about configurations.
So, let’s get into our topic. Every security professional knows the feeling of setting up a new solution, getting it configured to play nicely with the rest of your environment. And then after a while, it’s no longer as secure as you once had it. As you pointed out, Geoff, these configurations drift over time.
There are rarely clear warning signs, and we don’t have really great visibility into when this is happening. We know this is a problem. Geoff, how can we be more vigilant about this? And this is kind of generally. Just set us up. This is our topic today.
[Geoff Belknap] Well, I think number one, we all acknowledge that as soon as we configure something, it’s perfect forever and we never need to look at it again.
[David Spark] We would love it if there was something that’s set it and forget it. There is not.
[Geoff Belknap] Well, there is. It just requires you to really lean into the forget it part.
[Laughter]
[Geoff Belknap] If that is not your gig, and you would really like a secure environment, I think the most important thing to keep in mind is that unless computers are configuring every one of your devices, which I highly recommend, and even if they are, it is very common that a human will make an unintentional mistake, or a config that you blast out via automation may not be what you expected or may have unintended consequences.
If you want to avoid that, the best thing you can do is get involved in managing your configurations, automating that, and figuring out how to detect anomalies across those configurations. It is one of those things that doesn’t feel like security but is primo security.
[David Spark] And by the way, we hear so many cases of breaches happen because of a misplaced configuration. It’s so unbelievably common.
[Geoff Belknap] There’s also just not just a misplaced configuration, but also three years from now, you might find out that there’s a CDE based on the config that you use that is only triggered in a certain situation. You don’t know what your configs look like, you’re in trouble.
[David Spark] Right. Six months ago, a year ago, it was perfect. Not anymore.
[Geoff Belknap] That’s right.
[David Spark] All right. Helping us out with this discussion actually is our sponsor guest we’ve had on many times before. We adore him. Even if he does abuse me, even if he does give me a hard time, we still love him. He is the chief product officer over at ThreatLocker, none other than Rob Allen.
Rob, thank you so much for joining us.
[Rob Allen] Thank you for having me, David. And can I just say, Geoff, I can’t believe he described you as one of our favorites. I mean, that could literally mean any number of other favorites.
[David Spark] Could be hundreds. Could truly be hundreds.
[Geoff Belknap] Rob, I was just saying you, of all the guests on this show right now, you are in the top five, and I want you to know I mean it.
[David Spark] Top five? [Laughter] There are two other people who are not here right now because there’s only three of us. So, that means there could be two imaginary people be more popular, is that what you’re saying?
[Geoff Belknap] It’s very likely.
[Rob Allen] I was trying to say something nice, Geoff, but…
[Geoff Belknap] And so, what I want to point out, Rob, is that’s just not you, and I want you to be the authentic Rob.
[Rob Allen] [Laughter]
[David Spark] For anyone listening to this show right now, you could not do better getting both Geoff and Rob on the same show together.
[Rob Allen] I appreciate that, David, I think.
[Geoff Belknap] I love you, too.
How would you handle this situation?
4:19.672
[David Spark] Luis Valenzuela of InComm Payments said, “When it comes to security controls, they always have to be onboarded in some sort of consistent programmatic effort that verifies them, confirms them, or audits them regularly.” Good point. “They have a system…” and he went into great detail, but “…where weekly, a team member tests a control randomly, we catch things someone else changed intentionally or not, or false positives that were never documented or waived.”
And Louis Zhang of AIA Australia said, “Configuration drift is inevitable. Change is the norm. The key is to operationalize how you manage it.” And similarly, Louis has a system that sets a baseline, compares it, and evolves it. I didn’t go through it, but there was a long, detailed solution both Luis and Louis had.
So, I’m going to throw it to you, Geoff. Anytime you set it up, you just have to have a system how to manage it. You can’t just set it up, and like you said, forget it and walk away. Like, okay, now that it’s set, what are we going to do a week from now, a month from now, a year from now?
Like, what do you think at that point?
[Geoff Belknap] You are making the point perfectly as well as Luis and Louis did. I think the important part to just keep in mind is it really depends on what kind of configuration you’re doing. There is no exception. If you’re configuring Unix devices, Windows devices, network devices, firewalls, etc., it is essential, especially in a production environment, whether it be productivity production or customer production, to be tracking your config and how that changes over time, for exactly the kinds of things that Luis talks about here.
Which is if something changes, you may not know whether it’s intentional or unintentional, but you should start to develop an idea of whether that change is impactful on your environment or not and be able to walk that all the way back.
If the only way for you to understand whether a bad guy has made a change on your device, or a good guy, so to speak, has made a change on your device is to sit and digest all that and wonder what that setting could be – was it you? Was it somebody else?
That is not a high-performant, very secure, highly reliable environment. That is chaos. Everything beyond that can be simple things like, look, did you know if somebody exposed something to the internet? It would be really good to know when and how that was done.
And there are a bunch of tools, whether it’s just copying the config and loading it into a database or a more sophisticated system that’ll look at what the intent of those changes are that you can leverage here, and it really just depends on what your environment is like.
[David Spark] Rob, I’m going to actually set you up early on this because one of the reasons we’re doing this show is that you also, ThreatLocker, have a tool called DAC, Defense Against Configurations, but I want to step back a few steps from. When you were developing this tool, what were you seeing in environments that said, “This obviously needs to happen”?
[Rob Allen] I can give you one very simple example, which is we also provide a MDR service for our customers, and we came to jokingly refer to the MDR team as the configuration police because probably 90% of the calls that they were making to customer were as a result of misconfigurations.
So, did you know that, as Geoff said, RDP is exposed to the internet on this device, that kind of thing. So, as I said, we jokingly referred to them as the configuration police but obviously, having them calling people every time there’s a misconfiguration was less than optimal.
[David Spark] So, it was literally beating up your support, essentially, it sounds like.
[Rob Allen] Pretty much, pretty much. Making the same calls over and over again to different customers, different organizations, “Hey, this is misconfigured. Hey, that’s misconfigured.” We did build some tooling insofar as we were able to give people advice as to how you can fix the problem, that kind of stuff, but we realized that was obviously not scalable, and it’s not practical for everybody.
I mean, anything that involves human beings is somewhat problematic. I mean, in Louis’s case, I like the idea that we verify things, but the fact that you have a human being checking, auditing, and verifying things is probably less than ideal because the likelihood is that that human being will check the same thing over and over again, or they’ll forget to check something, or they won’t check it properly.
So, that’s why automated testing and checking and reporting is so important.
Does anyone understand what’s going on?
8:32.586
[David Spark] Joan Weiner Levin said, “We like to say that config drift is like weeds in a garden. You only notice when it’s already out of control. Just like you schedule time to weed the garden, you need to stay on top of drift and schedule time to fix it.
Definitely needs automation.” Well, speaking your language right there, Rob. And Fernando Montenegro from Futurum Group said, “I think of this as analogous to driving. Until we get to actual self-driving cars, human driving requires continuous monitoring of speed, distance.
Sure, things like smart cruise control help to alleviate some of these, but it’s still up to the driver to adjust to conditions as needed. So, example, reduce target speed if they change from a highway to a country road. This means that monitoring for drift should be a regular exercise so that things are caught early on.”
All right. Rob, so there’s two things going on here from Joan and Fernando’s comments. One is you notice it when it’s out of control and it needs automation, what Joan said. But Fernando says a human has to be in the loop, and really what I see also from ThreatLocker tools is there’s automation, but there is the opportunity for, and in many cases, the much-needed human in the loop.
Yes?
[Rob Allen] Absolutely. But again, it’s not up to the human to find the things that are wrong. I suppose the human is prompted with ways that things that are wrong can be resolved, or we can certainly point them in the right direction as to advice as to how they can fix a particular misconfiguration or problem.
To the point of it being like weeds in a garden, much like anything else, you’ve got to start somewhere. And even if you know your configurations are not what they should be, or even if you think they are what they should be, having something that is automatically checking to what you attest is the case, is actually the case, is super, super important.
[David Spark] Geoff, what’s been your success in terms of checking your configurations? What’s that mix of human and automation you’ve done? What programs have you set up? And tell me like what’s failed. Like you tried this and this didn’t work.
[Geoff Belknap] Well, I’ve tried a lot of things that didn’t work. I’ll say early in my career when I was allowed to touch keyboards on important pieces of equipment, which was long, long ago, you would make it a habit if I’m going to copy and paste the config of each of these devices, SSH into them.
And that way, I’ll have a notepad on my desktop, and I’ll be able to just sort of peruse these things. And that’s great, but even as you start to get to 5 or 10 devices, that’s too much for you to sort of reconcile across. So, even in a small environment, where you’re doing something simple like just routing people to the internet, it can get very complicated, and while it’s better than nothing, it is not good.
I [Laughter] currently work at a place where we have a few million devices connected to the network. And I can tell you it’d be very, very challenging if I needed to know if RDP was open in a certain place and I had to ask a human.
And so, on our environment, what we do is all of those things go effectively into a database, and they can be queried. And what that allows us to do is if I need to know, hey, we’re chasing a bug or we’re doing a hunt, need to know if this port or that port is open on a subset of devices, within a minute or two, you can get an understanding of what your exposure is to that.
And that’s fantastic. So, if you’re just doing a hunt, very good. And if you want to build automation now on top of that, it becomes very easy because you’ve got it in a database. There’s amazing amounts of detection and anomalies that you can look for just in your configs if you’re treating them like any other kind of telemetry in your environment.
Sponsor – ThreatLocker
12:07.335
[David Spark] Who’s our sponsor this week? Well, our sponsor is Rob’s company. That would be ThreatLocker, and I want to tell you about this tool I referenced at the beginning of the show, Defense Against Configurations or DAC. It delivers clear visibility into system risk by continuously scanning endpoints.
But built directly into the ThreatLocker agent, it identifies misconfigurations, weak firewall rules, risky USB permissions, and default Windows settings that weaken your defenses so you can address them before they’re exploited. Findings are also mapped against compliance frameworks, including NIST, CIS, HIPAA, and ISO 27001 with actionable remediation guidance to simplify security hardening and audit preparation.
The platform updates daily, providing administrators with the most current view of their environment without added performance impact, additional agents, or complex integrations.
By consolidating configuration risks into a single dashboard, ThreatLocker Defense Against Configurations or DAC streamlines compliance, reduces attack surfaces, and strengthens overall security posture. You can see how ThreatLocker makes it easier to secure and maintain a compliant environment.
Go to their website, threatlocker.com. And you know what? Add the /CISO at the end, go to threatlocker.com/CISO. Easiest way for ThreatLocker to know that you heard about us through the CISO Series.
Why does it matter?
13:34.887
[David Spark] Roshni Chattopadhyay, of Microsoft said, “Configuration drift isn’t just a nuisance, it’s a threat factor. I think we all agree with that. Automated drift detection tools can be integrated into the CI/CD pipelines for real-time monitoring, while audit trails and SIEM logging help trace the changes.
Now, to stay adaptive, we need to treat all configurations as code, use modular templates, integrate observability for feedback loops, and maintain human oversight for critical decisions.”
And Gaurav Trivedi, also with Microsoft, said, “Configuration drift is one of the most underestimated risks because it doesn’t announce itself. It creeps in quietly. It only shows up as an outage or a breach. Back when I was with Azure Networking, I suggested we build a WTFC, what the F change, dashboard to show all changes on critical devices in the last 24 hours.
Simply surfacing changes in real time gave us a huge leg up in reducing mystery outages. Perhaps most importantly, build a culture where teams understand drift as a security issue, not just an operations nuisance. In environments that never stop changing, the goal isn’t to freeze configs, it’s to make every change observable, controlled, and reversible.” I like that – observable, controlled, and reversible.
That’s how drift becomes manageable instead of a silent threat.” Geoff, your take on that.
[Geoff Belknap] Yeah, this is unshockingly the dogma that I follow, which is your configs are a part of your telemetry as much as anything else, and if you want to do detection, you cannot do much worse than understanding when things change on your devices.
Sometimes if bad guys have access to them, they will change things outside of expected change windows. That’s a great way to detect it. Sometimes when your good people make silly mistakes, it’s great to know why that was made. Also, I think the other thing that we can’t underscore enough here is that configs are incredibly challenging to understand.
Whether you’re talking about a network device, a security device, or just an endpoint Windows computer, you can’t possibly know all the settings on those things anymore and so understanding what change impacts different features on your machine really requires you to understand the config completely.
[David Spark] Rob, I take this to you. These are just some really good advice, and I just really like the idea of just what changed in the last 24 hours, just so we know what’s going on. Because if you don’t kind of look on a daily basis of what’s happening in terms of changes, a change that made last week, last month, that nobody had insight on, all of a sudden could be the big problem, and you would have to do some massive investigation to know what the frigging hell happened.
Yes? What’s your take?
[Rob Allen] I mean, look, the point is you are far better off knowing about these things before they are exploited and it turns into some sort of breach or cyber attack than after. And the problem is, very often, it is after that these configurations or misconfigurations are discovered because they’ve been used by threat actors.
It is, as Roshni said, a threat factor, very clearly a threat factor. To your point, I suppose, it is useful to know when things change because it can be an indicator of compromise. If firewall ports are open on a machine or that kind of stuff can be an indicator of compromise, but again, it is just good practice to know what things or how things should be set and that they don’t change from that setting.
It is, as I said, it can be an indicator of compromise, but it is just good practice. It is a good idea to know how things should be set and that they continue to be set that way.
[David Spark] Let me ask you a quick question, both of you. Are there common things that drift more than others? We often hear stories about just cloud instances that have their settings just change. I mean, what are the things that are the most common drift issues?
[Geoff Belknap] I think it’s less of a certain type of thing that changes, but it’s a certain type of change, right? So, if you’re running a high-volume change environment, right, any kind of like online production environment, you’re going to have ACLs change, you might have passwords change, you might have logging servers change.
And a lot of times, it will feel like your config script ran and it was fine, no errors, but you might find out later like, oh, you forgot to add the deny at the end of that thing, or you changed it to allow SSH or FTP for just 30 seconds to edit something, but forgot to change it back.
There are things like that that happen all the time that those are the kinds of things that lead to massive breaches where you didn’t intend that change to be permanent, but you didn’t realize nobody went back and changed it. Those are the kind of things that really end up biting you, where you think you know the state but turns out you were wrong.
[Rob Allen] That’s a really good example of where these things can happen. Very often it is somebody making a change for a few minutes to do a particular task, they forget about it, and then move on to something else. I mean, realistically, people are busy, people have a lot of things going on, and if opening SSH or whatever the case may be is something that you need to do for a particular task, you get distracted, you get 50 million Teams messages, people are knocking on your door wanting help with something, and then all of a sudden, you forget that change that you made.
Who’s going to track that? Who’s going to know about that? Who’s going to fix it ultimately? So, yeah, it’s a really good example of the challenges that people face. Sometimes it’s accidental. Sometimes it’s something that somebody deliberately did but just forgot to change back.
[Geoff Belknap] I’ll tell you who will find it for you, the threat actors.
[Rob Allen] Yes. [Laughter]
[Geoff Belknap] They will identify that for you.
[Rob Allen] Very much so.
[Geoff Belknap] Good threat actors are like a red team, but you just don’t get the report at the end.
[David Spark] [Laughter]
[Geoff Belknap] It’s the trade-off.
Security Tip of the Week – Tenable
19:26.054
[Voiceover] It’s time for this week’s security tip. This week’s security tip is brought to you by Tenable, the exposure management company.
[David Spark] If you think about exposure management by picturing lists of vulnerable assets, you risk something vital. Attackers don’t think in lists. They think in paths. Attackers look for the connections between identities, assets, and configurations.
These are the relationships that allow them to move laterally through your environment. For example, a single developer’s laptop with weak credentials might connect to a privileged identity in Active Directory, which in turn has admin access to a cloud storage bucket containing sensitive data.
None of those issues alone may register as critical, but together they form a very clear attack path.
That’s why exposure management isn’t about counting vulnerabilities so much as understanding how systems and people are linked. Using a purpose-built exposure management platform will help you visualize these relationships with attack path mapping and dependency analysis.
They reveal the real business risk, how one small misconfiguration could cascade into a major breach. By shifting your focus from isolated weaknesses to interconnected risk, you will transform exposure management from a patching exercise into a true defense strategy.
[Voiceover] This has been your weekly security tip. To learn more about exposure management, go to tenable.com.
How do I start?
21:10.142
[David Spark] Jared Mendenhall, who’s the CISO over at Armature Systems, said, “Configuration drift comes down to change management – effectively controlling, monitoring, and managing changes as they enter the system. The answer all of us want to give is that every change is documented, tested, and tracked all across systems with alerts in place for any configuration modifications.” Sounds wonderful.
“However, this assumes a certain level of process maturity and control and that the velocity of required changes doesn’t exceed your ability to manage them.” Good point. Is there an issue there, Geoff, with regards to I just can’t keep up with the changes?
[Geoff Belknap] Oh, yeah, absolutely. I also think what we used to consider documented configuration modifications were you’d write a Word doc or a Google doc and write down what you were going to change. That doesn’t mean that’s exactly how it changed because when it’s midnight and you’ve got the one-hour window to make the change and you’re trying to keep everything going, maybe you make a slight modification, and nobody realizes it.
Understanding what’s actually running on the device, what those configs actually do, and then mapping that to an intent so that a human can decide whether that’s good or bad, that is super valuable. And I think if you are an organization that’s doing that, whether you’re building something yourself or using a commercial tool to do that, you are in the top 1%.
That is definitely a high maturity activity.
[David Spark] With the people who are using your new tool, Rob – Defense Against Configurations – how are they managing these better?
[Rob Allen] The thing about configuration drift, it assumes that there is some correct configuration at the very beginning, and that’s not always the case. I’ll give you a very basic example, which is the company I used to work for back home in Ireland.
One of the first things that we did when setting up a new computer for somebody was set them up with local admin rights because software, they needed local admin rights, and that’s a very bad thing and something you shouldn’t be doing. But I mean, theoretically, that was the original and initial configuration on those machines, but it was dumb.
And so, assuming that some state in time, everything was fine, and then you’re drifting from that point is somewhat problematic. So, you’re far better off looking at everything with a fresh eye and saying, well, look, instead of has it changed from user is a local admin to user is a local admin?
No. Is user a local admin a good idea or not? Absolutely not, therefore, it should be changed.
[David Spark] No, you bring a good point. There are two problems happening here. One is they didn’t know what they were doing at the beginning. They made a mistake. And so, it was a problem at the beginning. And then there’s a situation where, like you brought up at the beginning of the show, Geoff, where something that was set correctly, all of a sudden, it’s now a vulnerability because a threat actor has figured out how to exploit it.
And the third is something that was valuable at one time, given the way the environment is changing or given the way the attacks in general are operating, not some specific vulnerability, now it doesn’t work anymore. So, all of these come into play, don’t they, Rob?
[Rob Allen] Absolutely. Which all the more reason as to why effectively a fresh set of eyes, a check to see if, look, we don’t care what you think these things are supposed to or how these things were supposed to be configured. We’re going to check and say, well, hey, you might think it’s okay for – I know, bad example – RDP to be exposed to the internet, but hey, RDP is exposed to the internet here.
Or configuration, as you said, you don’t even know changed. Somebody did it for five minutes or a user is working from home, for example, and it’s not convenient enough for them to work from home. They want to work from their friend’s house, and they open up RDP on their home internet, the internet, and they’re getting a load of failed logons on that machine.
Those kind of configurations, those sort of things that may be outside the reach of normal configuration drift do also need to be checked and resolved if possible.
[David Spark] Excellent.
Closing
25:08.537
[David Spark] Well, that brings us to the portion of the show where I’m going to start with you, Rob, I’ll ask you which of these quotes was your favorite and why?
[Rob Allen] I liked, “Configuration drift isn’t just a nuisance, it’s a threat vector.”
[David Spark] That was Roshni’s comment, yeah.
[Rob Allen] That was Roshni’s comment. I like that. I did also like, “Configuration drift is one of the most underestimated risks,” but we’ll stick with the first one. I’m not going to cheat and take two of them.
[David Spark] Well, okay, so you’re leaning on Roshni’s but giving an honorable mention to Gaurav.
[Rob Allen] Yes, indeed. Yes, indeed.
[David Spark] Okay. He picked two employees at Microsoft.
[Rob Allen] God bless Microsoft. Because [Laughter] where would we be without them?
[David Spark] There we go.
[Rob Allen] But yes, no, leaving that aside. No, I do like, “Configuration drift isn’t just a nuisance, it’s a threat vector.” You could possibly change that not just to be configuration drift, it could be misconfiguration.
[David Spark] Yeah, it could be both. Configuration drift and misconfiguration.
[Geoff Belknap] Well, it’s drift from intent, even if it’s not drift from previous config.
[David Spark] All right, Geoff, your favorite quote and why?
[Geoff Belknap] My two favorite quotes are the ones he stole. So, now that Rob has one-upped me.
[Rob Allen] Sorry.
[Geoff Belknap] Well, I’m going to try not to cheat and just go to the team favorite, but I’m going to go to Louis here from AIA Australia who said, “Configuration drift is inevitable. Change is the norm,” very deeply philosophical, I appreciate Louis.
“The key is to operationalize how you manage it,” and I think that’s how I think about it. You are constantly changing. These are not things you set and forget. You need to understand the config as much as you understand what’s happening in the syslog, as much as what’s happening in the NetFlow.
Baking that into your process, both about how you operate those devices, but how you secure them, is essential.
[David Spark] Very good point, and that brings us to the very end of this episode. Huge thanks to both Rob and Geoff. I do want to mention your company ThreatLocker. Remember, go to threatlocker.com, add the /CISO at the end of it. So, they know we sent you there.
You heard about ThreatLocker and DAC, Defense Against Configurations, from the CISO Series. Geoff, as always, thank you very much. I’m going to say this, Rob, you are still hiring over at ThreatLocker? Always hiring, correct?
[Rob Allen] Yes, always hiring, threatlocker.com/careers.
[David Spark] Look for great opportunities. And very important, in most cases, you need to be in Orlando to do that. So, if you’re listening from Orlando…
[Rob Allen] Most cases, yes.
[David Spark] Most cases.
[Rob Allen] Or even if you’re not in Orlando and you’d like to be in Orlando.
[David Spark] It’s a beautiful place to live. Rob, anything else to add to today’s show or to talk about DAC, Defense Against Configurations?
[Rob Allen] No, I think we’ve pretty much covered it.
[David Spark] Excellent.
[Rob Allen] Thank you for the opportunity.
[David Spark] Go to the website, check it out for yourself. Thank you very much, Rob. Thank you very much, Geoff. And thank you very much to our audience. We greatly – and I mean this, I don’t just say it because I say it every time, but I mean this – we greatly appreciate your contributions.
Keep them coming in. And thank you for listening to Defense in Depth.
[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.