In the same breath as a vendor will try to sell you a zero trust solution, they will also implicitly ask for your trust about their pitch. No one wants to come off in a bad light, but why do vendors risk losing trust by going for a “perfect pitch?”

This week’s episode is hosted by me, David Spark, producer of CISO Series and Dan Walsh, CISO, Datavant. 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

Full Transcript

Intro 

0:00.000 

[Voiceover] Best advice for a CISO, go! 

[Rob Allen] Listen to the CISO Series Podcast. Tell other CISOs, spread the word. 

[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 it’s so awesome. I’m thrilled to announce we have a guest co-host today who you probably know his voice very well because he’s been on many times before.

It is the CISO for Datavant, none other than Dan Walsh. Dan, thank you so much for joining us.

[Dan Walsh] It’s great to be here today, David. 

[David Spark] Awesome. And by the way, for those of you who are not aware, Rob at the beginning, who I’ll introduce in just a moment, he mentioned the CISO Series, and you can find the CISO Series over at CISOseries.com. Kind of easy to find there. Also, if you type CISO Series in Google, it’ll take you to CISOseries.com as well.

You’ll get there. Today’s episode is sponsored by ThreatLocker. You know them as the Zero Trust Endpoint Protection Platform. Well, we’ve got something new to tell you about – Defense Against Configurations. Pretty darn cool. That’s coming up later in the show.

But first, Dan, you brought up something off-recording just moments ago, talking about that you’re going into and many other CISOs are going into budgeting season, and I was interested to know, what should vendors know about when you go into that? Because my thinking is they just want to hammer you at this time.

What should they know? 

[Dan Walsh] Yeah, so while the vendors are going into, a lot of them are going into year end, right, and they’re trying to get that last sale before close, I think what they need to know from a CISO point of view is we’re evaluating how our current vendors are doing, how the current tools that we have are doing.

We’re evaluating feature creep, so like when you purchase something on a multi-year deal or even on a one-year deal, presumably that company is developing new features and how do those feature overlap with other vendors or tools in your portfolio? And so, I think the big thing is to really come at it from a value proposition, like here’s how we can add value, without necessarily increasing the price, and lead with value and not pricing because if the value’s there, then the CISOs will pay the price.

[David Spark] Very, very good point. Good tip. All right, let’s get into today’s episode. Thrilled he’s back. He gives me a hard time. We love him regardless. And he gave us a great plug at the very beginning of the show, but yet you’re already listening to the CISO Series.

It’s none other than the chief product officer over at ThreatLocker, our sponsored guest, Rob Allen. Rob, thank you for joining us again. 

[Rob Allen] Most welcome, Dave. Great to be here. 

Why has this topic suddenly become the center of attention? 

2:44.953 

[David Spark] What’s your backup when EDR fails? The Register recently reported that at least a dozen ransomware games are now routinely using kernel-level EDR killers before deploying their payloads. Techniques range from abusing legitimate but vulnerable drivers to disable endpoint detection to targeting specific vendors using hard-coded lists to disable kernel hooks.

This sparked a conversation on the cybersecurity subreddit that EDR is mitigated. Does network telemetry remain the ultimate truth-teller in cybersecurity? No matter how stealthy the malware, post-breach activity like lateral movement, command and control, and exfiltration must traverse network, threat actors can’t execute these attacks without generating network telemetry.

So, I’ll ask you, Dan, first. If ransomware crews can routinely disable your primary detection layer, EDR, what’s your backup plan? 

[Dan Walsh] Well, I don’t know if routine is maybe the right way to describe it, but the fact that it is a very real threat.

[David Spark] Good point. It is a real threat. Yeah, it’s not like it’s happening… Because if it was routine, then there’d be no point for having an EDR. [Laughter] 

[Dan Walsh] Right. But I think beyond that, I think that’s there’s a couple things. I think one, defense in depth is more than just like a catchphrase or a slogan. These EDR bypasses are real and so they’re no longer theoretical. So, what that means is like we have to layer technical controls and so if one fails, we don’t have a complete total disaster.

I do think network telemetry is extraordinarily critical, but obviously now it’s not necessarily sufficient on its own. And so what does that mean? Well, it means we have to look at some of the other layers that are at play here. So, things like identity, right?

What’s your IAM game? What kind of IAM events or are there any MFA bypasses that are occurring? What about any sort of Kerberos anomalies, if that’s in play? And then I think, what about resilience-oriented controls? So, things like immutable backups, rapid restore capability, so even if detection fails, we can recover and be successful with that.

And then I think the other thing is you have to harden your EDR. It’s not a set it and forget it as much as we would like that to be. And so where there’s vulnerable drivers, making sure that you’re blocking those, and you’re having multiple endpoint layers where you’re having maybe application allow lists or something like that.

So, I think those are some of the things that you can do. Again, with security, it’s never set it and forget it, and I think just making sure that security leaders and security operators keep that at the forefront of their mind. 

[David Spark] So, I’m going to toss this to you, Rob, pretty much kind of the same question. I mean, EDR has failed before, but like in anything in cybersecurity, all security defenses at one time do fail, and that’s why we have defense in depth as well.

What are the other mitigation points you think for when EDR essentially can be bypassed? 

[Rob Allen] Well, first of all, just to absolutely agree with everything Dan said. I mean, really, I couldn’t have put it better myself. Layered security is important, and the other part about layers is layers should be different. They shouldn’t be the same type of layers.

We’ve spoken to organizations and I know of organizations that have layers of EDRs, for example, fundamentally all looking for the same known bad things and very often falling over each other when they do actually find them. So, different types of layers.

So, one thing that we espouse is both detection, but also controls. So, as Dan mentioned, allow listing. Allow listing is a perfect example of a control that’s blocking things from running that shouldn’t be allowed to run. Combine that with detection, so if somebody’s trying to run something they shouldn’t be able to run, you get alerted about it, and that’s a really good example of a well-balanced security posture, well-balanced security stack.

So, that, as I said, basically everything that Dan said makes perfect sense.

But there are other ways that EDRs can fail. So, obviously this is one example where they’re actually going after the EDRs to try and stop them and shut them down. There are other ways that detection can fail. So, zero days, things that have never been seen before.

They’re also ways that EDRs fail, but they’re failing to detect the bad things because one of the problems with detection is you pretty much need to know all of the bad things in order to be able to block them. So, again, that’s another method of, I suppose you could call it EDR failure.

It’s just bypassing an EDR because it doesn’t know that this thing is bad. So, how can it block it? So, again, it comes back to why layers are super important when it comes to protection. 

Will we really ever achieve zero trust?

7:30.000 

[David Spark] “Leave if it makes too much sense.” That’s the Marwari saying Raghav Dinesh of IBM recently shared on LinkedIn, arguing that when vendor pitches feel too perfect, you’ve found your red flag. He outlined the psychology of influence in cybersecurity sales.

You probably know the techniques, even if you can’t name them. The 90% true pitch, charisma masking contradictions, and the breathless claim that ‘I fought for you,’ with no proof to back it up. Why don’t we apply ‘zero trust’ to vendor pitches? A vendor who can’t explain their solution’s limitations,” by the way, we hear this all the time from CISOs that they want to know a solutions limitations, “but vendor who can’t explain their solution’s limitations probably doesn’t understand them either.

We all have seen our fair share of vendor red flags, but what are the questions we should be asking?” and I’ll ask you, Rob, “And should every vendor be prepared to answer them?” And I’m going to just say, give you kudos first, before you even answer, Rob.

You’ve been good at dealing with some of the super-tough questions that I’ve seen CISOs throw your way. 

[Rob Allen] Well, I was going to also say, thank you for throwing the question that beats up on vendors to the vendor. 

[David Spark] I’m throwing it to you first. No, but no, I’m giving you kudos because I have seen you handle really, really tough questions very well. And the thing is, no one product can do it all, right? 

[Rob Allen] Well, as we just discussed, as we said a moment ago, no one approach is the only true successful approach. 

[David Spark] Right.

[Rob Allen] It requires different solutions, it requires different approaches. So, it’s detection, it’s protection, it’s, and we may speak about this a little bit later, it’s configuration. Ensuring that your configurations are straight and correct is a large part of it as well.

I mean, it is a really good point about if a vendor doesn’t understand their own limitations, then that’s a problem. Because realistically, if you don’t understand your limitations, then fundamentally the bad guys are going to figure out your limitations and they’re going to exploit those limitations.

So, absolutely. And again, look, a lot of it’s about knowing where potential weak spots are. 

I mean, one of the things that gives me great joy is we often have customers of ours who are subjected to penetration tests, and that is incredibly valuable information for us to get back. I actually, I got a message from a very good customer yesterday, basically saying, “This organization had been subjected to a penetration test, and the penetration testers were amazed that this was the only environment that they weren’t actually able to drop and execute the things that they were trying to do.” So, that kind of feedback is incredibly useful and incredibly valuable, but to be honest, what’s even more useful and more valuable is when they actually say to us, “Hey, look, we found this way in.

We managed to get around the protections that you’re offering by doing X, Y, and Z.” That kind of information from our perspective is absolutely gold because it tells us the holes that we need to fill. But yeah, it’s an absolutely valid point that if the vendor themselves doesn’t understand the limitations and the approach of the products that they have, then it is a pretty big red flag.

[David Spark] That is a pretty big red flag, but I would also throw out, and this is what we heard from CSOs, and I’ll toss to you, Dan, on this is admitting to your limitations is the thing that actually builds trust, not the fact that you can do it all.

Would you agree with that, Dan? 

[Dan Walsh] 100%. I mean, we just got done talking about defense in depth has to be more than a slogan, and that applies to tools because not one tool is going to cover every layer, every domain, every aspect of the program. So, I think a really good vendor understands where their tool is strong and what other strong tools it can be a complement with.

So, yeah, I mean, there’s no such thing as a silver bullet, and I think admitting that and then having a critical understanding of how your product fits into the rest of what the security team and the CISO are trying to deal with makes you a trusted partner, not just someone who’s trying to sell some software.

Sponsor – Threatlocker 

11:43.921 

[David Spark] Before I go on any further, let me tell you about something brand new from ThreatLocker, and that’s Defense against Configurations. It delivers clear visibility into system risks by continuously scanning endpoints. 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 and 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 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, go to threatlocker.com/CISO. Now add that /CISO so they know that you heard about them from the CISO series. Remember, threatlocker.com/CISO. 

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

13:12.319 

[David Spark] All right, both of you have played this game many times before, so I’m just going to throw it. I throw it to Dan first. Here’s the scenario. It comes from Ozren Bogovac of Generac, and here’s the setup and I’ll give you the two “What’s Worse?” scenarios.

The setup is you’re a CISO of a global company. You find out that different business units like marketing and engineering have created their own cloud subscriptions for sandbox use. Some have security tools, some do not. Now a few hosts are already compromised, and the teams act surprised and unaware of the risks.

Here are your two scenarios. Scenario number one, you pause all new cloud provisioning and tell the teams that they must stop and go back to deploy the required security tools. This upsets the business and puts security in the middle of friction, okay?

Or scenario two, you let the teams continue to provision but ask them to submit mitigation plans. The problem is they have not been replying to your emails or attending your meetings. Dan, which one is worse? 

[Dan Walsh] Probably number two. 

[David Spark] And why is that? 

[Dan Walsh] Well, I think one of the questions that wasn’t answered, one of the pieces of context that was missing was like what is the data that is actually being compromised? 

[David Spark] Oh, yeah. Well, let’s just assume there’s some sensitive data in there. 

[Dan Walsh] So, if it’s sensitive data, I would say number two is worse. 

[David Spark] Yes. So, number one, creating the friction and making everyone angry with you is not worse? 

[Dan Walsh] Not when it comes to the sensitive data, I don’t think. Especially, look, I think data is trust, right? And if customers are putting their data with you and it’s also along with their trust, that’s really the mission of the company in a lot of ways.

And so I think that is one place where I think it’s okay for security to have a little friction. 

[David Spark] All right. But the second scenario where they’re ignoring you flat out, this isn’t working. 

[Dan Walsh] Yeah, that’s not working at all. Because again, especially if there’s regulatory implications, like let’s say you’re violating GDPR or you’re violating HIPAA in a very bad way, timing is everything and addressing this swiftly and in a responsible manner is everything.

[David Spark] All right. I throw this to you, Rob. Do you agree or disagree which scenario is worse? 

[Rob Allen] Once again, I wholeheartedly agree. Dan has pretty much laid it out. What I would say is they’re not replying, they’re not responding. Screw those guys. 

[David Spark] [Laughter] 

[Rob Allen] I mean, that’s just rude apart from anything else. But again, for all the reasons Dan outlined, even leaving aside potential violations of things like HIPAA and GDPR, the fact is, I mean, first and foremost, you probably shouldn’t allow people to spin up random things in random pieces of the cloud.

[David Spark] Well, they were initially in sandbox environments that essentially, like in Jurassic Park, they found a way. 

[Rob Allen] Again, they didn’t reply, they didn’t communicate. Screw those guys. Deploy the tools, apply security. 

[David Spark] So, it looks like you’re going to get friction in any case. 

[Rob Allen] Well, probably. But if they complain, then just say you should have answered my emails. You should have replied when I contacted you beforehand. 

[David Spark] But the way you’re playing this, scenario one and two are going to become equal because you’re going to infuriate the business. 

[Dan Walsh] I always do it with a smile, David. Just do it with a smile. And by the way, by the way, brakes on a car cause friction as well, and we all like brakes, so. 

[Rob Allen] Agreed. 

Please, enough! No, more! 

16:51.253 

[David Spark] Today’s topic is configuration management. So, Dan, I’m going to ask you the simple question of what have you heard enough about with configuration management and what would you like to hear a lot more? 

[Dan Walsh] So, one, and this is like grumpy Dan. 

[David Spark] Our favorite Dan, by the way. [Laughter] 

[Dan Walsh] I feel like grumpy Dan would say every time my team notices a gap with a new tool that we buy, their response is like, “Well, you didn’t configure it right.” And my response to that is, “Well, we need a little more guidance because you just sold us this amazing tool, so illuminate us in the ways of configuration.” So, I think that’s one that I’m just tired of hearing about.

I think what I would like to hear more of, and I think this is where AI and all the promises and hopes and dreams that people have in that, can really help assess and evaluate how should an organization configure something given their context, their environment, what’s important to them?

And I think vendors leaning into that to make their tool more effective and more governable and more manageable is something that I think has a lot of opportunity. 

[David Spark] All right. I throw the same question to you, Rob. And I know, by the way, ThreatLocker is most recently playing into the configuration management game. What have you heard enough about with configuration management and what would you like to hear a lot more?

[Rob Allen] Well, Dan actually made a really good point. There’s a couple of ways of looking at this. So, configuration of tools is absolutely an important aspect to be considered. So, again, there’s no point in selling a tool to somebody and they have no idea how to use it, and they don’t configure it properly, and then they get breached as a result of that.

So, our assistance and handholding in setting up tools is extremely important, but there’s also general configurations, shall we say, within an environment, things that can be exploited or exploitable. I was actually in Brazil recently at a Gartner event and one of the slides that the Gartner gentleman had was that 61% of security leaders have suffered a breach because of failed or misconfigured controls in the last 12 months, 61% in the last 12 months because of failed or misconfigured controls.

So, one of the things that we’ve recently announced is a tool called DAC, Defense Against Configurations, and it’s basically running a series of checks. I think at this point it’s about 100 checks, ultimately it would be about 170 checks on every machine that has a ThreatLocker agent installed on it.

Checking for common misconfigurations, things that could be done differently, things that could be done better, mapping it against various frameworks. So, we mentioned GDPR, we mentioned HIPAA. It’s not always an easy thing to say, “Well, look, okay, we tick this box,” but do you really tick that box?

The likelihood is on some machines or part of your environment, you may not. You may think you do, but you may not. So, that’s what Defense Against Configurations gives you. It’s an actual check to make sure that the controls and the configurations that you think you have in place are actually in place on every asset within your environment.

[David Spark] So, let me try to understand this tool a little bit better. What is it you’re asking the tool and how does the tool actually know, I guess is my question. 

[Rob Allen] Well, I mean, fundamentally we’re running on machines so we can check the configuration of those machines. So, is, RDP allowed from the internet, for example, is an example of a very basic check. If it is, is it encrypted? That kind of thing.

But as I said, there’s 170 different checks, things like can MSHTA run on a machine? I mean, that’s something that we’ve seen commonly exploited. I mean, another thing that’s been quite publicly exploited recently is Microsoft’s Quick Assist. So, Quick Assist is something that’s built into Windows, but it’s something that attackers are leveraging because they know it’s built into Windows.

So, quite a number of the social engineering attacks that are being perpetrated at the moment, they will ring up, “I’m from the IT department, I want you to open up Quick Assist and pop in this password for me or pop in this code for me.” Again, your average user isn’t necessarily prepared for that.

The fact that they’re just running Quick Assist, something that’s built into Windows, is not going to set off any alarm bells or triggers, but it could very easily give an attacker access to an environment. 

So, again, these are just example of things that could be configured better that maybe you want to block Quick Assist out of the box. Obviously, it’s something that you can do with allow listing. But as I said, that’s one or two examples. There’s 170 different checks, they’re mapped against different compliance frameworks.

So, it basically tests those things that you may be saying you do, but you don’t actually know if you’re doing. 

[David Spark] Now, I don’t know if this is in version one or planned for version two, version three, but Dan alluded to hoping AI could guide us the right way. Now, you could ask the obvious questions of is this hard drive encrypted or whatever, certain things like that that are known, but if you don’t know what new attacks are and new configurations needed to deal with those attacks, maybe others are dealing with them, is there a way to learn from the community to advise others as well?

[Rob Allen] Well, as I said, a lot of what we’re doing with these checks is mapping them against various frameworks. So, obviously frameworks are updated over time, they’re changed, new recommendations, I suppose, come along. But yeah, it’s not just frameworks, it’s obviously things that we are aware of as well.

[David Spark] Well, it could also be threat intelligence too as well. 

[Rob Allen] Correct. And as I said, the likes of Quick Assist, the likes of blocking MSHTA to stop HTA files, which again are a very common method of attack these days, those are things that I suppose we know about that we can fix so we can suggest solutions to it.

So, look, you can set up a policy, here’s a community policy. Just click and download and it’ll be applied to your environment straight away. So, it’s not only about telling you where the holes are, it’s also about explaining why these holes are important and how you fix them, how you can have a solution to them.

Now, they may not always be ThreatLocker-related solutions, might not be something you can fix with a policy within ThreatLocker, but at least we’ll tell you what it is, why it’s important, and how you can fix it. 

Are we creating more problems? 

23:01.709 

[David Spark] “Car buyers get to see a window sticker when making purchase decisions. Software buyers could benefit from their own ‘window sticker.'” And this was what Adam Isles recently explored in a blog post for Lawfare. “Can we create crash test ratings for code?

The proposed quote sticker would combine process attestations like threat modeling, pentesting, and security feature inventories into a single view. But this sounds suspiciously like what SBOMs, Software Bill of Materials, and security questionnaires were supposed to deliver, and we all know how well those work out with point-in-time assessments.

So, Dan, I’ll ask you, is there any way that this could be anything other than just another layer of compliance theater? And who’s going to analyze all this data when CISOs are already drowning in vendor documentation? I mean, it sounds great. We’d love a sticker.

How easy is this to pull off? 

[Dan Walsh] Yeah, I mean, everyone loves stickers. I think that it’s…

[David Spark] Even kids, I would say. Even kids, yeah. I like stickers. No, but I would say, yeah, I think it’s the exact same downfall of an SBOM. And what I would say is car stickers are great. They sort of tell you what the features are, but they don’t necessarily tell you how resilient the car’s going to be, and most people are trading in cars inside of five years.

And so a lot of these technologies, some of them are lasting for decades, and I would also say that there aren’t active things that are popping up every day trying to destroy the car. So, I think that analogy falls a bit short because of the nature of technology, how it evolves, the nature of the threat environment, new vulnerabilities.

So, I think it’s a much more complex scenario, but I do like the intention of it. 

[David Spark] Yeah, I mean, I think that goes back to SBOMs, Rob. I mean, everyone loves the idea of it. It’s just the execution, isn’t it? 

[Rob Allen] I have a confession to make, David.

[David Spark] That is? 

[Rob Allen] I’d never heard of an SBOM. 

[David Spark] Really? Okay. A man as smart as you. 

[Rob Allen] I mean, it sounds fun. It’s like, I mean, I like it as a phrase or a word, but I had never heard of an SBOM before. 

[David Spark] Well, it’s essentially this idea of the window stickers, software bill of materials. The idea is when you buy software, you would see not just like ingredients on a package of any good, you would see the materials that are in it, the food stuff that’s in it, and it’s…

[Dan Walsh] The software components, yeah. 

[David Spark] Yeah, and it’s required. 

[Rob Allen] Yeah, absolutely. Can I just say as well, by the way, the phrase “compliance theater,” I think is tremendous. I mean, I think there’s a big opportunity there for somebody who wants to go and take it, which is to actually do compliance theater, GDPR on masse or something, I think would be really, really cool as well.

So, yeah, anyway, that’s somebody’s million dollar idea. Go take it, run with it. But yeah, I thought compliance theater was excellent as well. But no, again, it’s a valid point. I mean, one of the things that we struggle with and one of the things we have to do is we have questionnaires coming out the wazoo from various organizations effectively ticking boxes, can you do this?

Can you help with that? Can you do this? And it is something that is a constant challenge from the vendor perspective as well. So, yeah. 

One thing I would say, by the way, and again, the more observant of the listeners may have noticed that I’m not actually from this part of the world, I was never familiar with window stickers until quite recently. And one thing that I noticed on window stickers in the USA, correct me if I’m wrong here, but the one thing they don’t have on them is the price, and that would strike me as being a pretty important detail.

[David Spark] Don’t they have the price? I think they have the MSRP on there.

[Rob Allen] Maybe I’ve been going to the wrong garages because any ones I’ve been to, the one thing that is noticeably missing from window stickers here is prices. But anyway, I digress. Yeah, it’s a valid point and something that certainly could be improved upon.

And again, one thing that we’re trying to do is we’re trying to build repositories of all the information, all the questions that people are going to ask. So, rather than having a hundred different questionnaires and trying to fill them out a hundred different ways, just having all that information available to our people enables them to better answer people’s questions.

Closing 

27:27.664

[David Spark] Well, that brings us to the very end of the show. A huge thanks to our sponsor, and that would be ThreatLocker. Remember, to learn about their great new tool, Defense Against Configurations, go to their website, threatlocker.com/CISO. Remember, add that /CISO because that’s the way you let them know that you heard about them from the CISO Series.

Again, that’s threatlocker.com/CISO. And a huge thanks to both of you, Rob Allen and Dan Walsh for joining us. Let me ask you first, Dan, are you hiring over there at Datavant? 

[Dan Walsh] We are. We’re looking for some cloud security application security folks. So, head on over to the Datavant Careers page and please apply. 

[David Spark] And Rob Allen, as I know you’ve said before, ThreatLocker is never not hiring. Is that true? 

[Rob Allen] 100% correct. We are never not hiring. 

[David Spark] Yes, and it’s almost all in Orlando, correct? 

[Rob Allen] Mostly in Orlando. Yeah, we’ve got operations in Dublin, in Ireland, in Dubai, in the Middle East, and also in, I believe, Brisbane in Australia, and we’re hiring pretty much everywhere. Yeah, pretty much worldwide, but headquartered here in Orlando.

[David Spark] Well, I was at their Zero Trust World event, many of the employees there, and it seems like a super fun place to work. 

[Rob Allen] It certainly is. 

[David Spark] Well, thank you very much, Rob. Thank you very much, Dan. And to our audience, we greatly appreciate your contributions and 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 Cyber Security 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.