Security tools are supposed to do a job. Either they need to alert you, protect you, or remediate an issue. But they don’t always work and that’s why we have breaches. Who’s at fault, the tool or the administrators who configured the tool?
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 (@dspark), the producer of CISO Series, and Geoff Belknap (@geoffbelknap), CISO, LinkedIn. We welcome our guest Kenneth Foster (@Kennethrfoster1), vp of IT governance, risk and compliance at FLEETCOR.
Got feedback? Join the conversation on LinkedIn.
HUGE thanks to our sponsor AppOmni
[David Spark] Security tools are supposed to do a job. Either they need to alert you, protect you, or remediate an issue. But they don’t always work, and that’s why we have breaches. Who’s at fault? The tool or the administrators who configured the tool?
[Voiceover] You’re listening to Defense in Depth.
[David Spark] Welcome to Defense in Depth. My name is David Spark. I am the producer of the CISO Series. And joining me for this very episode is Defense in Depth, it is Geoff Belknap. He’s the CISO of LinkedIn. Geoff, say hello to our friendly audience.
[Geoff Belknap] David, hello, and welcome, audience. Let’s have some fun.
[David Spark] Let’s have some fun. Hey, our sponsor for today’s episode, a phenomenal sponsor of the CISO Series… We love having them on board. It’s AppOmni. It’s time to secure your SaaS data. AppOmni. And we’re going to be talking about securing SaaS data or specifically what controls around Cloud data become throughout this show, but we’ll hear more from AppOmni later in the show. But first, our discussion at hand. On Twitter, Jeremiah Grossman, now at Tenable, asked this question – “In your experience, when security controls should have stopped a breach but didn’t, is it usually because the control isn’t affective or was the control misconfigured/ignored?” His core thought here, he goes on to say, “Do info sec products have an efficacy issue or an implementation issue?” And I think this is a really good discussion because I think it could go probably both ways, Geoff. But he was asking what’s your experience. So, what’s your experience?
[Geoff Belknap] I had to put some thought into this because I just don’t know if there are clear stories of breaches that they had all the controls, and process, and policy, and training they needed but a control or a product failed. And I think the reality is…
[David Spark] Yeah, we don’t usually hear that story.
[Geoff Belknap] No. No, no. And honestly if that was ever the story, you would never stop hearing it because the comms people, the legal people, the investors, they would absolutely be happy to lay the blame at either of these things. So, I think the reality is it’s probably more complicated than this, which is our favorite to get into on the show. So, let’s do it.
[David Spark] And the person we’re going to do it with is none other than the VP of IT governance, risk and compliance over at Fleetcor, Ken Foster. Ken, thank you so much for joining us.
[Ken Foster] Hey, thank you to David and Geoff for having me. I look forward to this discussion. I think it’s always timely when we’re having these, and I look forward to having some fun and having some discussion around this. So, appreciate it.
Why is this relevant?
[David Spark] Fernando Montenegro of Omdia said, “I think it can be both. With a healthy dose of organizational dynamics acting as a catalyst. Too hard to configure/operate becomes unmanaged/unused because no budgets to do so properly.” Interesting take. Karen Worstell of VMware said, “Too often security controls are put in place and are not operationally sustained and regularly verified to be functioning as intended. It is a perfect storm of issues: poor control design, lack of verified implementation, and poor maintenance.” And Joe O’Brien said, “C, both. And D, neither are both possible answers.”
[Geoff Belknap] Indeed.
[David Spark] Which I liked. So, I think this opening sort of confirms both of your comments is this is plenty complicated, isn’t it?
[Geoff Belknap] It sure is, yeah.
[Ken Foster] It is.
[David Spark] Geoff?
[Geoff Belknap] I think complexity is really the enemy of security. The more simple and straightforward your operating environment is the easier it is to implement controls and the easier it for the products that you buy or the things that you build to work. And I think what you would see in most cases where there are breaches… And let’s be honest real quick. There is sort of breach with a capital B, which is the kind of thing everybody hears about and podcasts like this talk about. And there’s breaches with a lower case B, which is like maybe somebody fell for a phish, or someone installed some software they shouldn’t have.
In both of those cases, more likely than not what has happened is you either don’t have enough products… And I’m using products very broadly here to say some controls that you implemented. Or you haven’t implemented comprehensively enough. And I think the thing to keep in mind as we have this conversation is a lot of times people forget that security is inherently horizontal. It is inherently multidisciplinary. And that means we need help from our partners in the rest of the organization, whether it be engineering or an IT organization, to implement security. It doesn’t all happen in security. So, a lot of times when there is a problem it’s because maybe something has failed between security and some partner that needed to do something.
[David Spark] All right, good point. What’s been your experience, Ken? And again taking all these sort of complications into effect here.
[Ken Foster] So, as a guy whose primary job sometimes is to define what that control set is and how we’re supposed to be implementing it and meeting it across the board and looing at what our objectives are, and how our capabilities are going to meet that, I think it’s interesting because if we do a poor job which I think we tend to do in our seats from the security side of throwing over the fence and saying, “We have chosen a tool to meet this control objective…” And we do a poor job of explaining why we need to implement that, and what the ultimate outcome is, and why our stakeholder partners that we’re expecting to implement this follow our control guidance, and understand what they should be doing and what the ultimate outcome is.
I think that’s one of the bigger problems. Because a lot of times we’ve had a whatever is in the news today knee jerk reaction to, “We’ve got a problem we need to go fix, and we’ve identified a gap in our environment. This tool is going to fix it.” And if we don’t do enough up front in due diligence in figuring out what the ultimate goal of that tooling is and how we’re going to implement it, and what that ultimate deliverable is as we roll it out across the environment, all we’ve done is cause confusion, friction, and a lack of people being able to follow along the guidance that we kind of laid out in a rough thing. And what it winds up is is because of that friction, because of that lack of understanding, because of that guidance, we wind up with a poorly implemented tool that may not be accomplishing everything that we need it to do because we didn’t slow down long enough to make a well thought out plan ahead of this.
[David Spark] Let me add to that. You make a really good point there. If it’s poorly put out yet you “have it in place,” you’re getting a false sense of it’s doing its job, right?
[Ken Foster] Well, then you get compliance, right? You get the problem with compliance. “I’ve checked the box.” [Laughs]
[David Spark] Yeah.
[Geoff Belknap] Yeah.
[Ken Foster] “I have checked the box. But have I ultimately moved the needle on security in reducing risk?” I will argue that a lot of things we do for compliance… And hell, that’s my job. It’s been my job the last two companies I’ve been at. And I’ve been a CISO twice doing this, too. It always gets down to the point we’ve checked the box, and that is the bare minimum effort. Bare minimum effort.
[Geoff Belknap] It always comes down to this. It always comes down to when people start with compliance, that’s when you usually fail. If you start with, “We’re going to build a good program that solves our problems and solves problems for the company,” usually you end up with compliance. But when you start there, you usually fail.
[Ken Foster] Geoff, I 100% agree. 100% agree. And I think we need to really adapt the I call it development or the Cloud mentality of a pattern. What is the pattern that we’re going to use to design our control, and how are we going to implement that across the enterprise, and how are we going to set the appropriate measures, and metrics, and reporting that come out of that so that we understand the efficacy of what we are putting in place. And I think a lot of times we go into this with a poor understanding of what that ultimate outcome is and how we’re even going to measure efficacy. So, it’s easy to go, “Well we got popped,” or, “We had a ransomware incident.” And go, “Well, the tools are not affective.” Ultimately the misconfiguration of the tool, or the lack of understanding in how the tool functions, or the ignoring the noise that’s being generated because we didn’t tune that tool correctly causes us to not be as affective with it as we should have been.
What’s going on?
[David Spark] Matthew Gardiner ofRapid7 said, “The configuration /people/process/ease of use were the factors that stood in the way more than just straight core control failure.” Bruno Fonseca of S&P Global said, “In many cases it can be both. But more often than not, it is poorly interpreted controls which leads to misconfiguration by humans.” And lastly, Robert Thompson of Allens said, “All controls need a lot of care and feeding no matter what vendors say.” So, I’m going to back to you, Geoff, again, on this. This also was brought up in the first segment is a lot of times it’s like bad user experience, bad user interface, confusing as to what these controls mean, what they actually do, what risk is it dialing down and protecting me from. And going back to Robert Thompson’s last comment, they all need a lot of care and feeding. And going back to Ken said, it’s like you got to know this stuff. And that also is on the vendor’s part who’s creating the controls to explain what this stuff is.
[Geoff Belknap] These are all great points you made, David. The thing I always keep in mind… I know I sound like a broken record. To be really successful in security you’ve got to be a great communicator and a great storyteller. It is not just when it comes to talking to executives. If you are writing a bunch of controls and standards, and you cannot communicate them well to the people that need to implement them, AKA people don’t know what they mean, you’re going to see odd failures, and it’s going to look just like this. So, when we write expansive control standards and we tell people all the things they need to implement, if the people that need to implement them can’t do that you’re starting off on the wrong foot. I think similarly if your product requires detailed expertise in implementing that product and constant care and feeding, you’re really not offering the kind of protection that an organization needs. There are a lot of times where we over index on trying to do too much in a commercial product or something that we’ve built ourselves, and we fall into this trap of trying to make perfect security. And if it gets too complex and it takes too much effort, again, you’re not doing anyone any favors. So, I think that’s where things start to break down.
[David Spark] Have you had a tool that was so simple to use, so clear to understand… If you can think of that tool, what made it so great, and how did ease of…how was it easy to manage, and what did it do to your risk?
[Geoff Belknap] I’ll give you a great example that’s a little dated at this point, so people, don’t comment on the post and yell at me about this. FireEye. When that first came out in the early 2010’s, it was dead simple to implement. You can implement it in one of two ways – you could just put it in line on your network, and it would just grab all the binaries and detonate them for you. And yes, I know in some cases it wasn’t perfect. But it was a great example of a tool that was very simple to implement, and it very simply did its job, and it gave you a result. You didn’t have to become an expert in reverse engineering. You didn’t have to become a source of threat intelligence. You didn’t have to interpret the results deeply. You could just kind of set it and forget it. That was a great model. That level of interaction is fantastic.
[David Spark] Ken, do you have a similar story?
[Ken Foster] Yeah, I think FireEye is a great point of that and similar tools like that. It had a very clear set of what it’s supposed to do, how it’s going to do that, was fairly simple to configure. And I think we’ve gotten to the point now where we’ve got a lot of tools on the market that they do a lot of things. Which is great. But it’s also bad. They do a lot of things. And it is poorly understood what all those things are going to do in our environment and what all those things are… If I flip switch A, what’s it going to do? If I flip switch B, what is it going to do?
And I flip both of them together and then go down the line and hit switch E, what did I just do, and why do I no longer have traffic flowing on my production environment? And I’m losing revenue, right? And it’s not understanding all those things and how they work together within our environment. It takes a lot of testing. Especially if you’re doing things in-house custom. And it takes time, and it takes time to develop what those expectations and deliverable are. And that is one of the bigger issues I’ve seen with today’s software is they’re trying to boil the ocean so to speak to go back and use the old term. They are offering you all of these things that you could possibly do.
[Geoff Belknap] Here’s a bit of advice I would give you. If you’re listening to this podcast and you’re thinking about building a product or you’re thinking about the products you sell, or you’re an investor, I want you to hear this loud and clear – it is okay to build a point solution. It is okay to build a product that might only be a billion dollar company. It is okay for you not to build a product that does everything under the sun. Those are great solutions. You can focus on how well they work. They can completely solve one thing and one thing only, and I will still absolutely buy that product all day every day. I will not be sad that it doesn’t do 12 other things. There is plenty of room for that.
[Ken Foster] I’m going to second your comment there, Geoff. Build something that you’re really good at. Help me solve a problem, and you understand that problem A to Z. And you can help me. Are there benefits that maybe you can help me actually use maybe one of my other products that I’m already on and make that more successful, and improve my efficacy overall? If you have a good story to sell about that, I don’t need you to also replace that product that was not your core competency.
Sponsor – AppOmni
[David Spark] All right, before we go on any further, I do want to mention our awesome sponsor, AppOmni. Think about the SaaS platforms your organization uses to get vital work done. So, Sales Force, Workday, Microsoft 365, or Google Workspace. Do you know which third party apps are actually connected to them or the data these apps can actually access? After all, the average SaaS environment has more than 40 different third party apps connected into it, and each third party app offers a new data access point to your SaaS platforms. That means a single compromised third party app can give threat actors the “in” they need to access sensitive data stored in your SaaS ecosystem. Not good! But good news for you, AppOmni can help.
With AppOmni you can gain visibility to all third party apps and SaaS to SaaS connections. You’ll have a complete inventory of every third party app in your SaaS ecosystem, and you’ll know when end users have enabled third party apps and the level of data access each app has been granted. See what’s connected to your SaaS platforms and what vulnerability third party apps have actually introduced. Go to their site – visit appomni.com. That’s appomni.com today and request a free risk assessment. Now, a lot of people don’t want to hear this, but seriously you’re going to want to see what they show you. Appomni.com. Ask for that free risk assessment.
What aspects haven’t been considered?
[David Spark] Ian Tibble of Seven Stones Infosec said, “Out of the two options, I find more resonance with the misconfigured option but also say that in prevention there is a widespread vast overestimation about the effectiveness of products.” Dan Holden of BigCommerce said, “If the control does indeed exist, I would wager it’s the latter. I believe this problem has haunted us from the start. It’s hard for a vendor to be an expert on their own products.” And by the way, going to what the latter was of what Jeremiah Grossman said is because the latter being misconfigured right here. So, Ken, going back to what Geoff said at the beginning, is your experience it’s really just something has been misconfigured?
[Ken Foster] I will say that there is a high percentage of that that happens. And it’s not intentional misconfiguration, and it’s not even… I want to say it’s not even folks that just don’t understand the configuration. I agree. I have talked to a lot of companies and think about… I ask them, “Hey, if I set this configuration in your tool, what does that ultimately mean it’s going to do?” They have an answer that’s typically whatever the broadest answer is that’s going to appeal to the most of us that may be interested in buying their product, and they’re trying to meet that broad control, broad configuration. They’re trying, to me, make everybody happy is ultimately what it boils down to. And in reality what we need to have is a good understanding of what my control requirement is. What do I need this tool to do, and does that tool do what I need it to do? And I have sat in way too many engineering and architectural discussions with sales teams talking about their product and listening to people ask questions and go, “Nobody in the room understands what the hell the control objective is.”
[Geoff Belknap] [Laughs] Yeah.
[Ken Foster] And that’s part of the problem. This is where I feel this is a big part of my job. My job is to help them understand what that control objective is. And if I have not explained what the control objective is and I have not made sure that not only the engineering team, architecture team, development team, business team, and leadership understands this from the security side, and everybody understands what our control objective is and how we’re going to meet that, we’re never going to be successful. What’s going to happen is it’s going to get blamed on this piece of tooling that we have bought that it was misconfigured, and that’s why we got breached.
Because that’s the easy button to get out of a little bit of responsibility and to get out of some blame game there. I think we… And I have said this a hundred times. Vendors, and tool developers, and anybody who’s selling me a product needs to be transparent and honest with me. I also need to be transparent and honest with you and give you a clear expectation of what I’m expecting your toolset to do for me. And if I can’t explain that to you, I then hope that your team understands me and my team don’t understand what we’re asking for. And you can help us understand how your tool is going to help us meet a control objective.
[David Spark] That’s a really good point there. Geoff, when you sit down with a vendor and are like, “Okay, we’re ready to…” Or you’re considering buying. Are you clear on your objective, or is something the tool enlightening you on your objective? Or is it sometimes a discovery process? There’s multiple levels here.
[Geoff Belknap] Yeah, I think it could be a lot of those things. The way I would frame this is just misaligned expectations. And I think Dan sort of hits on this a little bit. It’s hard for a vendor to be an expert on their own products. It’s even harder for a vendor sometimes to step back and look at like, “Does this product actually solve a whole suite of problems, or does it solve a niche, a part of the problem?” They’re so busy sometimes when you’re… Especially if you’re in a presales role or an implementation role, you’re so busy focused on making that implementation successful, delivering that product, trying to add value that sometimes the marketing lingo and the customer expectations can really balloon into like, “Oh, this thing is going to solve all my security problems. It’s going to be great.”
And the reality is it may solve a very narrow set of problems that you have. And now you’re expecting it to do something that it didn’t. Without picking out a current product, I’m going to go back to the let’s say CASBs. So, maybe five or ten years ago, everybody was rushing out to get a CASB, a Cloud Accessed Security Broker. And the thought was this was going to prevent you ever from having any DLP or any data loss on your Cloud platforms. You could use SaaS. It would be perfect, and safe, and wonderful. And the reality is it would make it better, and it would make it safer. But it’s definitely not going to prevent you from ever having a loss on a SaaS or an IS platform. Again, that was just peoples’ expectations would just get whipped into a frenzy, and they wouldn’t match the reality of these situations. I think when we talk about an efficacy problem, what we’re probably hinting on is people are expecting way too much.
Whose issue is this?
[David Spark] Jared Atkinson of SpecterOps said, “The question highlights our failure to properly evaluate our security programs.” Aw, so it’s on the buyer. Buyer beware, [Inaudible 00:21:58] Jared goes on to say, “Knowing a control has failed is too low resolution to identify and implement the solution. Is the problem technical, or is it a matter of training?” Which we’ve alluded to here. And @immutablesec, because this was a Twitter question and I don’t know exactly who that person is… But that person said, “It’s because it wasn’t implemented properly, coverage was not complete, or it was expected to protect outside of a defense in depth strategy.” So, this is alluding to a lot of things we’ve already been saying. But if you had all the training in the world you could do this. Going back to your point solution comment, Ken, one of the things I’ve heard from a lot of CISOs is, “Actually I kind of want an everything kind of a solution because I don’t got the time or the money to train all my staff on 20 different point solutions.” So, how much training do you have, and should it be so intuitive that you wouldn’t need any training? What do you think?
[Ken Foster] God, this goes back to one of my least favorite terms out there is that single pane of glass term.
[David Spark] Aw, a popular one to hate on this show.
[Ken Foster] Popular to hate on. It ranks right up there very close to zero trust, but I will… The thing is is training is important. Understanding it. I get from being in a leadership position that you want it to be easy for your team to be able to pick up, be able to be affective, not have to learn a whole bunch of stuff and jump from place to place and do this stuff. But also going back to our…looping back into what we talked about earlier, if you do one or two things very well, don’t pile on a bunch of stuff that you don’t do very well.
I’m not going to name names on vendors, but back in the day there were some…before the Next Gen firewall there were some firewall providers out there that were phenomenal firewalls. Package inspection, just transactional firewall, absolutely excellent tool. Then they started adding in all these other things. IPS, IDS. They started adding in all these bells and whistles. The problem was is they were not best in breed at any of them, but they also did a really poor job of understanding the workload that it put on the rest of what they did as a very basic thing which was firewall. Which ultimately led to failures in the product. Not because the firewall was bad, not because their technology was bad. Because they tried to bolt on a bunch of things that they bought from other companies and kludgly put them on there. And what they wound up doing was making their firewall a bad product.
Because they bolted on things that overloaded it and kept it from doing its job very well. And I am a fan of, like I said, a point solution that does something very well but may help me figure out a solution with my other tooling down there. I don’t need everything. If I could find that magic pill out there that did ten things and did them all great, and limited the understanding that my team needed to be able to have, I’d be all for it. Problem is I haven’t really seen anything yet that does that across the board very well. Soon as you do something very well, one of these startups is going to jump out and say they do it better, so you got to pay attention to it. And you’ve got to figure out if you were doing something real well for too long and also didn’t innovate… So, it’s a double edged sword, right? I’m really good at one thing, and I don’t innovate, and now the next thing that happens to me is I’ve been relegated to an obsolescence because other people have figured out how to do that one thing I do very well but also plug in some stuff. So, you got to constantly be innovating.
You’ve got to constantly be understanding. And we need to be talking to these vendors that we use, talking about problems that we’re seeing in how our environment evolves over time, and how their product can evolve to help us. And we should be having that two-way transparent feedback loop going on because the vendors… If they’re hearing from me, they’re hearing from Geoff, they’re hearing from everybody else I know doing this job and they’re all starting to get that very clear picture, and they’re reacting to that, and they’re adjusting to what they’re hearing from our entire collective network, our entire collective industry, they should be able to adjust to that I would hope and come with a better, more affective product over time.
Am I asking them to solve all my problems at the end of it? Absolutely not. But if they listen to us, and they’re taking everybody’s feedback, and they’re thinking about it smartly, and they’re asking for feedback, we should see overall product improvement. Hell, we ask for our own people to do that. How do we improve our products? How do we improve our customer experience? And if they’re listening to all of us, we should start seeing some really great improvements in the product that they’re selling to us.
[David Spark] Geoff, you were nodding your head a lot. Especially in the middle of Ken’s diatribe right there.
[Geoff Belknap] Yeah, there’s a couple of nuggets in here. But I think the bottom line here is there are a lot of products. There are a lot of problems. And we can only get good at solving so many things. I remember a long time ago I worked for a telecom company, and we used to sell one of everything. And I thought it was fantastic. I remember our customers saying to me, “You can’t be good at all of these.” My first reaction was to be like, “What do you…? How dare you. Of course, we’re amazing at all these.” And I realized like no, we sell everything because we want to sell to everybody. But clearly we’re better at some things than others. The trap that I think a lot of vendors and a lot of buyers fall into is hoping that they only got to buy this one last thing, and they only got to learn this one last thing, and then they’re done. And the reality is it’s just way more complicated than that, and it is never as easy as we’d like it to be.
[David Spark] Very good point. It’s very complicated. It’s not as easy as we’d like it to be. I’d like to wrap on that.
[Geoff Belknap] Security is still very hard.
[Ken Foster] It is.
[David Spark] It is still very hard. That’s why we have a successful show. Hey, let’s pick our favorite quotes and why. Ken, which quote was your favorite, and why?
[Ken Foster] Karen Worstell from VMware, “Too often security controls are put in place that are not operationally sustained, regularly verified, functioning as intended. And it’s a perfect storm of issues – poor control design, lack of verified implantation, and poor maintenance.” I resonate with that because I think that is part of our problem is we didn’t have a good, thought out process of what that control design was, and it causes us an issue with the actual implementation of it down the road.
[David Spark] All right, good quote. Geoff, your favorite and why.
[Geoff Belknap] I’m going to go with Joe O’Brien who said, “The answers don’t necessarily have to be whether it is an efficacy issue or an implementation issue. It could be either C, both, or D, neither, and there are other possible answers.” And the reality is there’s not just two reasons that things fail. While I do think we do need to have a discussion about how affective some of the products we buy are, how they’re implemented… But like we talked about here and I think like some of the other quotes mentioned, people buy things and just don’t implement them. They never get around to it. They spent that money, and they didn’t find the time to implement it. That’s not necessarily the product failing.
[David Spark] How often do you just buy products from Amazon and you don’t actually install, set it up, things like that? We do it all the time.
[Geoff Belknap] It happens all the time. And I think people would really like it to be… I think CFOs especially would really like it to not be the case that you’re spending $100,000 or more on something that you didn’t use. But the reality is… And I don’t want any CFOs to hear me, so I’m going to lower my voice. It happens all the time.
[David Spark] They’re not going to hear it because you whispered it. No way are they going to hear it.
[Geoff Belknap] [Laughs]
[Ken Foster] Shelfware is a real thing.
[David Spark] That’s right.
[Geoff Belknap] Yes.
[David Spark] All right. A huge thanks to our guest, Ken Foster who is the VP of IT governance, risk, and compliance at Fleetcor. You get paid three times because you cover those three things, right?
[Geoff Belknap] [Laughs]
[Ken Foster] Yeah, I wish that was true. And if I can find somebody who will pay me three times I will have a conversation.
[David Spark] All right. If you want to hire him for three times…
[Ken Foster] [Laughs]
[Geoff Belknap] If you want to triple Ken’s salary, you can reach him at ken.com.
[Ken Foster] Yeah.
[David Spark] [Laughs]
[Ken Foster] But I will say the general theme of this, and I used it for my entire career, is bad news doesn’t get better with age. I think we have all talked about that. Because what we’re talking about here is not understanding how to deliver the bad news that what we bought may not have been thought out correctly, and we need to rethink that. So, that bad news doesn’t get better. [Laughs]
[Geoff Belknap] I’m going to steal that saying. Thank you, Ken.
[Ken Foster] [Laughs]
[David Spark] There you go. Hey, I want to say a huge thanks to our sponsor, AppOmni. It’s time to secure your SaaS data. Why don’t you go check them out? Seriously. Go and get that free evaluation of your environment so you see what’s going on rather than being in the dark because it’s better to know what’s going on. Check them out at appomni.com. Any last thoughts, Geoff? Or just everyone keep thinking?
[Geoff Belknap] Everyone keep thinking? Hey, unrelated to this, if you haven’t implemented a FIDO2 authentication scheme for your organization, maybe think about doing that.
[David Spark] All right. Let’s all do that. Why not?
[Geoff Belknap] Let’s please do that.
[David Spark] Let’s improve our authentication. Thank you, everybody. We greatly appreciate your contributions and 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 cyber security. 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 firstname.lastname@example.org. Thank you for listening to Defense in Depth.