Speaker 1: Welcome to the Cyber Risk Management Podcast. Our mission is to help executives thrive as cyber risk managers. Your hosts are Kip Boyle, virtual chief information security officer at Cyber Risk Opportunities and Jake Bernstein, partner at the law firm of K&L Gates. Visit them cr-map.com and klgates.com.

Jake: Hey, Kip. What are we going to talk about today on episode 121 of the Cyber Risk Management Podcast?

Kip: Today's going to be a fun one because what we're going to do is revisit one of my favorite shows from years gone by, Myth Busters. And we're going to identify some common but very much not correct beliefs in the world of cybersecurity, cyber risk management, these well worn but absolutely wrong ideas that are just floating around out there and causing senior decision-makers to make poor decisions. And we don't want that. So I think this is going to be fun. I think we're going to help people.

Jake: Yeah. No, I think this is going to be good. And I want to say that we don't really know how many we'll get through. We have a whole bunch and we'll see what happens. So that's part of the fun.

Kip: It's funny. We're not a mature industry compared to accounting. Accountants were pressing marks into clay tablets with their styluses thousands of years ago, and they've got it all figured out. But there's still so much, I don't know, voodoo, black magic? I don't know. There's just all these misperceptions and false beliefs. I just... It's crazy. But I'm so glad we're rounding them all up and we're going to do something about them today.

Jake: Yeah, or at least some. At least some of them, were rounding up.

Kip: Some, as many as we can. So with that introduction out of the way, why don't you kick it off? What's myth number one-

Jake: All right.

Kip: ... that we want to bust?

Jake: For this one, this one is one that's been bothering me. And shout out to a guy named Troy Fine on LinkedIn. Definitely worth a follow. He's been really active on trying to fight this myth. And it is that SOC 2 reports are certifications and that you often see... Actually, I just saw it recently in doing some due diligence, that a company had reported that it was SOC 2-certified. You also see this, "I am NIST-certified." That's actually one of my favorites because it has literally no meaning, S SP 800-53-compliant or 800-53-certified is also common.

Kip: That's awful.

Jake: And what we want to say is that well, one, as you know, Kip, words matter. I'm all about the definitions here and there. But none of these things are accurate. And so let's talk about these. Let's take the easiest ones first, and I'm going to save SOC 2 for the-

Kip: Sure.

Jake: ... for last because I think it's the most complicated to talk about. But NIST-certified, SP 800-53-compliant or certified, those are easy to bust because NIST is the National Institute of Standards and Technology. They don't have any certifications. They don't do any certifying. They're not a certifying body. And even more so, just saying you're... And I really, you've seen someone say, "NIST-certified," right?

Kip: Oh, yeah.

Jake: You've seen that. I've seen that.

Kip: Oh, yeah.

Jake: And I think what they... Okay, so if we're being charitable, NIST-certified has literally no meaning. What they probably meant was that they are NIST Cybersecurity Framework-certified. However, Kip-

Kip: That's not.

Jake: Can you get certified with Cybersecurity Framework?

Kip: Well, not from NIST. I'm sure there's somebody out there that will for a fee confer upon you some sort of a private certification. I just don't have any doubt about that. But as far as-

Jake: That's probably true. But those are not worth much.

Kip: No, they're not. And as far as being NIST-certified, well, I suppose it would make sense somehow if NIST published one thing. If there was only one thing that NIST published-

Jake: But that doesn't happen.

Kip: No, NIST has... NIST-certified, well, I don't know. Does that mean that your gasoline pumps at your service station are guaranteed to dispense one gallon of gas-

Jake: There is an example.

Kip: ... no matter what temperature is?

Jake: That's right. There's an example where things do get certified, but that's very specific. What's-

Kip: Yeah. And that's NIST, right? NIST says what is a gallon.

Jake: It is what is NIST. They do all that stuff. But let's talk about 800-53-

Kip: Sure.

Jake: ... because I think this one is even more common. Everyone, for those who don't know, Special Publication 800-53 which is currently in revision 5 is, oh gosh, 400 pages I want to say.

Kip: Yeah, it's huge.

Jake: It's huge. And it's a control catalog. It's a very useful tool. It's a very useful tool. But I don't think it even... One, I'm not even sure it's possible to implement all the controls.

Kip: No, that would be ridiculous. That would be a 10.

Jake: That would be, yes.

Kip: You'd be a 10 on our scale of 0 to 10, where 9 and 10 are excessive.

Jake: Yes. Actually, that might be an 11, Kip. Honestly.

Kip: It probably busts the scale.

Jake: It busts the scale. So you cannot be 800-53 anything.

Kip: Just no.

Jake: SP 800-53 is a catalog of controls that you can use to build a very reasonable cybersecurity program, but it is not something that you can be certified or compliant with. That's just not its function.

Kip: You can use it. You can say, "Hey, we..."

Jake: You can use it.

Kip: "We use it as a guide for our program," because a lot of people don't know how to use 800-53. And I've actually taught lessons in my online training courses about how to use 800-53. It's an amazing resource because it just contains so much really insightful ideas about how to do stuff. I talk a lot in my... when I give the example about how do you destroy data. And by looking at the 800-53 data destruction control, their template control, you can just see all kinds of different enhancements to the control that you might want to make. It's great because you can dial in the amount of security you need.

Jake: Yep. Okay, let's talk about SOC 2.

Kip: Yeah, the bane of our existence in some ways.

Jake: In some ways. First of all, SOC stands for service organization controls. And it's really a CPA, a certified public accountant auditing mechanism.

Kip: It was built by the AI CPA, the American Institute of CPAs.

Jake: Yup. And this is where it gets a little confusing. And I think this one is more understandable because you can get, you can buy a SOC 2 attestation report. That's an audit. And it does have more meaning than... For example, NIST-certified literally means nothing. But having a SOC 2 attestation report, it does say something.

Kip: Right.

Jake: The problem now-

Kip: It's an independent attestation.

Jake: It is. The problem is that SOC 2, and this is not... And just to be clear, I'm not going to spend this episode criticizing SOC 2. If we want to do that, we can totally record a separate episode on the-

Kip: Easily, there's so many myths in there.

Jake: Right, the utility or lack thereof of a SOC 2. But the thing about SOC 2 is that the way to think about it is it's a test, and you do get to write. You, the person taking the test, in a sense, actually in a very real sense, gets to decide what questions are in the test, right?

Kip: Yep.

Jake: And then what happens is that you invite a third-party auditor, usually a CPA firm-

Kip: One that you pay for.

Jake: ... one that you pay for, to come in and basically verify.

Kip: Test your controls.

Jake: Test your controls. And all they're doing is testing whether those controls are present and as you say they are. They do not, and I think this is super important, the SOC 2 auditing firm does not make any determination that they are the right controls, that they are the best controls, that they are reasonable controls, that they're even necessarily fit for whatever purpose you think you have.

Kip: That's so funny, I was thinking about that.

Jake: All they do is, and this isn't... Like I said, it does have value, but all they do is say, "You, client, say you have these controls. We're going to check to make sure you actually have these controls." That's it.

Kip: That's that.

Jake: And what it is, it is an attestation report from the auditor. And that's what it says. "You said you have these controls. We looked. We say you do have these controls." It is not a certification. A certification like the CISSP or one of the IAPP privacy certifications or any number of technical certifications. Those are different. Those are third party-controlled credentialing systems. And if you pass and get certified, then you have met that third party's control framework. An example is ISO 27001.

Kip: Yeah, or PCI.

Jake: Or PCI DSS, yes. But ISO 27001 is the only cybersecurity certification that is widely recognized that I would say. I don't think... I suppose it's possible, Kip, that you and I don't know of any other ones and that they do exist, but I certainly can't think of any true certifications for organizations related to cybersecurity other than the ISO certifications.

Kip: Yeah. Well, I think that's an incredibly popular one with a broad scope because it's an information security management system, so it covers everything that organization does to identify and manage cyber risk. PCI DSS is very, very technical, very specific for the most part, very specific and scoped. It's only going to apply to cardholder data. And if you can somehow wrangle all your card older data into a single system, that's all you're testing, is that system. So it's not quite as broad as in coverage.

Jake: And you are right. There are other ones out there that haven't been finalized yet, like CMMC, that class.

Kip: I think one of the big differences though is that with SOC 2, management is choosing the controls that is going to be tested. ISO 27001, PCI DSS, CMMC, management doesn't choose the controls.

Jake: That's true, yep.

Kip: Controls are set for them by somebody else who doesn't have any skin in the game. I think that's a big, big difference.

Jake: Agreed. Okay, I think we've busted this myth. Why don't we move on?

Kip: Okay. But if we're going to bust the myth, I think we do need to say whether or not there's something to it. There is some value in a SOC 2. There really is. I'm guiding two customers through a SOC 2 attestation right now. We're in the pre-phase where they're selecting controls and they're writing their control statements and they're gathering their evidence and so forth. So we're in this early preparation stage. And I think if you do it well, actually, a SOC 2 can be an amazingly helpful thing to have. But-

Jake: I see what you want us to say. Yes, I totally agree. I think the difficulty is that there have been SOC 2 farms.

Kip: Oh, absolutely,

Jake: That will just offer a SOC 2. And-

Kip: How fast can you do it?

Jake: How fast can you do it? And really, what you need to remember is look at the attestation, see what was actually examined and audited.

Kip: I had a salesperson one time practically say to me, he hedged and he chose his words carefully, but essentially what he's saying was, "If I cut a check right now, will you go find us a SOC 2 report because I have a deal to close?"

Jake: Yup. So it becomes a checkbox item, right?

Kip: Yeah, it really does.

Jake: And that's where you can get into trouble. Okay.

Kip: Yep.

Jake: Myth busted with a whole lot of caveats because it is complicated.

Kip: Yeah, okay.

Jake: What's myth number two here?

Kip: Okay. This myth is around senior decision-makers in, I don't know, state of denial, ignorance. I don't know how to exactly describe this, but it's like when somebody says, "Well, I don't store or process any personal data so we don't really have any cyber risks to manage." And there's a variant on this, which is, "My data isn't worth anything."

Jake: Albeit...

Kip: Yeah, right.

Jake: Yeah, no. So this one I think is fairly straightforward. And I suppose we can blame... The reason for this myth I think is not totally, it's not unfounded. It comes from the idea that what gets... Well, at least historically, what got all the press was data breaches, credit cards, personal health information, customer and consumer records. And there is a temptation. If you do some self-examination and think, and you're like, "Okay, I don't have any of that. The most I have is some personnel, HR-type stuff."

Kip: Right. "I've got payroll data."

Jake: "I've got some payroll data." But there's a lot of businesses that don't process or store large amounts of personal data or credit card information, stuff like that. And I think the temptation historically was to say, "Well, we always hear about these data breaches. Hackers are clearly wanting this data. My data isn't worth anything because it's not personal data, therefore I don't have any cyber risks." Why don't you bust that myth, Kip?

Kip: Yeah. I bust this myth actually pretty frequently. I'd say once or twice a month. I'm talking with a prospective customer and they say some variant of this. Often, they're in the manufacturing space or they are in some kind of business, like maybe real estate. Commercial real estate, I think, is a good example. Not personal real estate, but commercial real estate where they don't really routinely handle personal information. And so they look around, they're like, "Why would anybody attack me?" And they completely overlook the fact that their business depends on their ability to control their systems. That if their systems become out of control, that it's going to have a massive and immediate negative impact on their ability to serve their customers. And of course, I'm talking about ransomware and things like that.

And so I have to tell them, "Well, there are people out there who would like to take control of your systems away from you and then charge you a hefty fee to give that control back." And so then we do some negative visualization exercises where I say, "Could you, whatever your business is..." I was talking to a company that catches tuna fish in the South Pacific, processes that at sea, cans it, and delivers it to grocery stores. And I asked them, I said, "Can you do that? Can you do any of that without your computers? Can you actually have a can of tuna show up to be sold at a retail outlet?" And they had to think about it for a moment and they realized they couldn't. There were some things they could do. They could catch the fish, but they can't actually get them to a store in a canned form because they're so computer-dependent. And so tons of cyber risk there.

Jake: Yeah, very much so. I think this one is fairly easy. And I almost hesitated to include it because it feels a little old. That being said, as we both discover on a routine basis, it's only old for those of us who live and breathe this stuff every day.

Kip: Right, yeah.

Jake: It is. It's almost obvious that this is a myth.

Kip: It's still floating around out there like a lot of myths.

Jake: It's still there, yup. No, it very much is. Here's another one. So busted, right? Busted?

Kip: Yep, I think so.

Jake: Here's another one that's in the same vein. And I love this one because, oh my gosh, this one is still so common. And it's something like this. "My business runs in the cloud so my cyber risks are minimal."

Kip: This is a relatively new myth.

Jake: It is relatively new. No, no, this is true.

Kip: It's widespread. It is widespread. And it's fueled by marketing dollars spent by, big surprise, cloud providers. They tout the security that they can provide. They talk all about what the security that you're going to inherit from them. They don't talk all that much in their marketing and their pre-sales about all of the things you have to do once you show up.

Jake: And let's be fair when we say cloud providers, because that encompasses... As everyone is, should be aware at this point, you've got infrastructure as a service, IaaS. That's the raw, one step up from the metal machines. You've got platforms as a service, and then you've got SaaS, software as a service. In my view, this myth is by far promulgated mostly by SaaS and somewhat by the platform as a service. The infrastructure as a service, the underlying, what is it, big three or four cloud service providers, they are pretty good.

Kip: There's two and there's one trying to be a third.

Jake: That's true. I'd say there's three or four-ish.

Kip: Well, there's AWS and Azure, which are well established. And Google desperately wants to be part of the team there, and they're working hard.

Jake: And there are other ones too. A lot of the... Oracle, they have cloud. And there's a lot of private cloud, hybrid cloud providers. In any event, those companies are in a different position because they really push this shared responsibility model. And I think AWS frankly says it best, which is they say something along the lines of, "Look, we take care of security of the cloud. Your responsibility is security in the cloud." And this is a nuance that gets lost a great deal in the SaaS world.

Kip: It's just, yeah. Well, it's just not part of the pre-sales conversation.

Jake: It's not. And the issue too with the SaaS component here is that... Because let's be honest. Most of the time when we're talking to client who say this, we're usually not talking to the SaaS company itself, right?

Kip: Yep.

Jake: We might be. It's possible. But more often than not, we're talking to our non-technology clients who say, "Well, we don't worry because we don't really have, we have no on-prem servers. Everything's in the cloud. We use this series of SaaS programs. It's all good," right?

Kip: Yep.

Jake: And that is the problem, is that the... And what really drives me nuts is when some new SaaS company hangs their entire security hat on the reputation of the underlying infrastructure as a service provider. And it's like everyone knows that the big three or big two plus one, however you want to say it, their physical data centers are locked down. This is a true statement. What drives me insane though is when I see this new, we'll just say some startup, that's like, "Oh, we have..." What is it, level three or level four? "There's some extremely high level of data center security." And it's like, well actually you're just on AWS or Azure, and that shouldn't fill you with a whole lot of confidence when it's part of the marketing game. And why is that, Kip? Why isn't this true?

Kip: Gosh. Well, I like what you said about security of the cloud versus security in the cloud. I think that really captures the essence of why it's a myth that just because you're in the cloud, you have minimal or no cyber risks. Because once you get in there, you've got to configure stuff to match your security posture, to counter the threats that are facing you out there. And one thing about cloud that really gets in the way of that is that everybody is a systems administrator in the cloud because anybody in the cloud can share a file, for example. Well, it used to be when pre-could, if you wanted to do file sharing, you usually had to have a systems administrator set up a server to do file sharing. And they would configure-

Jake: I still do have to request that if I want to do an external file share.

Kip: There you go. There you go, because that's the legacy world of file sharing. Well now, we've got people who can share files just by right-clicking on the file on their computer, and they can share it. But they don't really, they've never been trained to make the security settings. And more often than not, by default, they're just going to turn off all the security and they're going to typically choose "if I possess the link, I can access the file" level of security, which isn't very good. And those links never expire. And so they're floating around forever.

Jake: Not by default.

Kip: No, don't. Not by default.

Jake: That's exactly it.

Kip: And so that's a big problem. And that's why Gartner said years ago and continues to iterate that 99% of cloud security failures are the responsibility of not the cloud provider but the cloud user.

Jake: Yup. And I think, again, we could probably do a whole episode on cloud and what it means, but I have a mug that says, "There is no cloud. It's just someone else's computer."

Kip: That's right.

Jake: And I think we can even go slightly deeper than that, which is these days, it's not just someone else's computer, it's someone else's simulated computer. Because isn't that what a virtual machine is, Kip? It's a simulated computer.

Kip: Yeah. There's real hardware somewhere underneath there. But is that-

Jake: There is somewhere.

Kip: As a cloud user, you have no access to it, right?

Jake: Right.

Kip: And so one of the things I have to talk to customers about these days is that they'll get a data security addendum from a customer of theirs, an insurance company, bank, whatever, and it'll still have language in there saying that when you dispose of your old computers, you have to do a DOD, Department of Defense class data wipe of the hard drives before you dispose of them so that our data doesn't accidentally wind up on eBay.

Okay. Well, you're fighting last decade's war with this. Everyone's in the cloud, and you have no ability. You can't wipe anything in the cloud because you have no access to the underlying hardware. And so we have to come up with alternate approaches like encrypting everything and then destroying the encryption key. That's the modern equivalent of that. Crypto-shredding is one of the terms that I hear people use to describe that approach, but yeah. And if you don't understand this, then there's a gaping hole in your data protection strategy.

Jake: Very much so. I think we've busted-

Kip: By the way, we did talk about this once before. It was episode 77 of our podcast. But since we're on episode 121, I don't expect us to remember everything.

Jake: Well yeah, that's a good point.

Kip: But if you want to go back to episode 77, specifically what we talked about there was that migrating to the cloud means you do have cybersecurity worries. And so we really unpacked this myth, I think, in episode 77.

Jake: Okay. What's the next one, Kip?

Kip: Hackers don't target small businesses, something I hear a lot. And of course the variant there is that cyber criminals only attack large businesses. And this myth is really interesting because it's actually, I think, grounded in a dominant view of businesses where if you're a senior decision-maker and you want to sell something, it's been generally true for a long time that if you can sell your widget to a very large enterprise, then your profit per transaction is going to be really high because you can probably sell them 100 of your widgets because they're a large enterprise and you do one deal. Whereas if you target mid-market or small companies, to sell 100 widgets, you're probably going to have to do 25 deals or 50 deals or 100 deals.

Jake: And each deal has a transaction cost and-

Kip: That's right.

Jake: ... inefficient and all that stuff.

Kip: Yeah, that's right. And so your profitability isn't as good because you've got to do all these separate transactions and deals. And so senior decision-makers who are trying to figure out if they're in target or not take that lens and they say, "Wow, we're too small. Why would a cyber criminal go after us because they're not going to score as well if they tip us over? They're better off just going and trying to tip over a large enterprise because they'll get more reward for the effort that they put into it."
And so I can understand this lens, but what they're not paying attention to and why this is a myth is that every technology Amazon has to terrorize Walmart is in the hands of the cyber criminals, which means they can attack us at scale and the cost per attack is negligible. So they can afford to attack everybody.

Jake: So what we're saying really here is that while it is true that the transaction costs for making deals is something, we're not saying it's high or huge or insurmountable, but it's something, the transaction cost of attacking is essentially approaching zero.

Kip: It's like software, right?

Jake: Yeah.

Kip: The first time Microsoft wrote Word and the first copy that they sold, they lost money. Because if it cost them $5 million, making up numbers here, to write Microsoft Word, but then they sold the first copy for 99 bucks, they lost a lot of money. But the marginal cost of selling the next copy is the cost... Well, it used to be the cost of a CD-ROM or a DVD, and now you just have to have a download server. And so yeah, once you open up your hacking operation and you hack the first one, that costs you a lot. But everyone after that, the marginal cost is practically zero.

Jake: Yep, that's right. Okay, so I think that one's busted. And one of the easy ways to say it too, just to really hammer this one home, is let's say I'm a hacker group. I'm a criminal, and I want a million dollars. Do I really care if I hack one large company for a million dollars or 10 small ones for 100,000 when the cost to me of each hack is the same?

Kip: The same.

Jake: It's basically zero. The answer is I don't.

Kip: No.

Jake: Particularly since as things have evolved, it's actually becoming easier for me to successfully attack those small and medium-size businesses.

Kip: Thank you. I was just about to say that, because a small, medium business, as we've said before, has all the security risks of a large enterprise, but they have only a fraction of the budget to do anything about it with. And so they're a much easier target. And that's why I encourage our customers to be hard targets, to be difficult targets, not to be perfectly secure because that's just not reasonable. Okay, one more myth.

Jake: Yeah, one more myth and then I think I'm going to call an audible and do a speed round after this one.

Kip: Okay.

Jake: Now, this one-

Kip: It's number five.

Jake: Yes. This is one of my pet peeves. Tell me, Kip, have you ever gotten a file that says pen test report? And you're like, "Oh, this is going to be exciting. I'm looking forward to reading this." And you open it up and you're like, "Wait a second. Wait a second. This is actually just a vulnerability scan from-"

Kip: Yeah. "This is canned output."

Jake: "... an automated algorithm. This is canned output. This is not..." And you're just like, "Ugh, what's going on?"

Kip: Right.

Jake: And so what is the myth here? Well, it's a misunderstanding. Again, it's very similar to that SOC 2 certification issue that we talked about at the beginning. There is a difference between a penetration test and a vulnerability scan.

Kip: Mm-hmm, correct.

Jake: And there's a big one. And the variant, or I should say a corollary, of this myth is that people believe that they're safe because they, quote, "regularly perform penetration tests". The problem is that they're talking about $2,000, and this is just a number we pulled out, but cheap.

Kip: I've seen this number.

Jake: Inexpensive quote, unquote "pen tests", and they're just not pen tests. So Kip, you actually do... Your company does penetration testing.

Kip: Yeah.

Jake: Why don't you tell our listeners who don't know what the difference is between a penetration test and a vulnerability scan?

Kip: Yeah, sure. So-

Jake: Hold on. And why one should never confuse the two, particularly if it's a question of due diligence or responding to a insurance application or anything of the sort.

Kip: Yeah. I would say that there's so many different ways to characterize the difference, so what I'm about to say is not the exclusively correct way to characterize the difference. This is just how I think of it. But a vulnerability test is really a highly automated thing that you do. You purchase access to a vulnerability scanner. You feed in one or more IP addresses. You might tweak a little bit. You might put in there the target is a Windows machine versus a Linux box or something like that. And then you press the button and then you walk away. And at some point a report pops out, and that's pretty much it. That's the whole exercise.

Now, if you're really good at what you do, you'll actually go through the report. Because it's canned and clinical, it's not contextualized at all. So a high severity vulnerability contextualized might be a medium severity vulnerability or something like that. Now, this is where you start crossing over into a penetration test where the context is very much considered, and I might use a vulnerability scanner or some other automated tool to-

Jake: Always to start a pen test.

Kip: Yeah, to do some of the work. But I don't just stop when the scanner finish finishes running. We did a pen test recently where we said, "Hey, we're going to simulate an ordinary employee, so please make us an account just like you would make for any employee who's not a systems administrator, doesn't have special privileges. And we're going to remote access into your environment and see what we can do." And I've got a guy on my team who went into this situation, and he worked around a lot of the controls manually to the point where he was able to access all kinds of things that should never have been accessed, that they weren't intending to be accessed based on the way that they had set up the VPN and so forth. And no vulnerability scanner would've found this stuff. No automated vulnerability scan would've found any of these things. And so that's the difference between a real pen test and a vulnerability scan.

Jake: Yeah. And I think a good metaphor here is helpful. A vulnerability scan is a little bit like walking down a row of cars and pulling on the door handles to see if they're locked or unlocked. Whereas a pen test would be going down that row of cars and determining if any of them could be unlocked remotely via a code, and then getting your hands on that code and unlocking the door through the internet. And that's a rough metaphor, but it's a different level of sophistication-

Kip: That's a great word.

Jake: ... and it provides a different level of information back to the person, to the entity being tested. So really, please don't label your vulnerability scans as penetration test reports. They just aren't. And anybody who knows is going to immediately face palm when they see that.

Kip: Yeah. And we don't have time, but I could unpack how we got to this point, but it doesn't really matter.

Jake: Okay.

Kip: Lightning round.

Jake: Lightning round, okay. First, and I'm just going to toss these at you and you can very briefly say yes or no and then why. First, a couple of credential myths.

Kip: All right.

Jake: Here's the first one statement. Password complexity requirements will keep us safe.

Kip: Currently, a myth. Used to be true. That's one of the things about our work is that truisms become false after a while. And these days really, it's just about how long can you make your password and still remember it. And that's why we talk about pass phrases.

Jake: Right, okay. And then here's another. This one's very common these days. Getting MFA log-on codes by text messages is totally safe.

Kip: Same thing. It's a myth but it used to be okay. And the reason why is because there is no security in the text messaging system. It was never designed to be secure. And we're seeing cyber criminals tipping that system over in the sense that they're not destroying it, but that they're actually able to manipulate it and monitor it. And we've seen some really big successful cyber attacks as a result of that.

Jake: Well, and the current advice is even starting to become potentially problematic, which is use one of those very secure app-based authenticators where you get a push notification. The bad guys have started to figure out how to socially engineer their way past push notifications by spamming them. And eventually, someone is going to hit, "Fine, accept." And that's a problem.

Kip: We even have a turn of phrase for that, MFA fatigue.

Jake: MFA fatigue, exactly. Okay, I'm going to save a few for later, but I've got four responsibility myths that are super quick. First one, cybersecurity is too expensive and will always feel like the long, sweaty line at the airport. I like it. I think you wrote that.

Kip: I did, because that's the dominant feeling that I get from a lot of customers when I first encounter them. They know they need some additional cyber protections, but really all they're thinking is that, "Oh my God, we're just going to turn into this process-bound, high overhead operation where we'll lose our agility, we'll die homeless and penniless, we'll have to live in a box under a bridge and nobody will love us."

Jake: Yeah, I see.

Kip: And no, it doesn't have to be that way. Cybersecurity doesn't have to be too expensive, but you have to balance it and it can be balanced. It's just that the balance goes out of balance after a while.

Jake: It does.

Kip: It's like the tires on your car every now and then have to be rebalanced because things change. You ran into a pothole, you change the shape of your wheel a little bit, and now the thing's wiggling and jiggling and you got to take it back and get it balanced.

Jake: Now, this next one is actually really important. Cybersecurity has to be done exactly right or it's not worth doing it all.

Kip: Oh, my little perfectionists out there.

Jake: Yes. And before you answer this one, I just want to say too, that you said, you just used the phrase MFA fatigue. Well, a few years ago we were talking a lot about breach fatigue. And in the security world we used to talk a lot about the perimeter and keeping people out. And then it became this whole, "Well, let's assume a breach." And there just became this nihilistic view. Even within the cybersecurity community, I think at times, about it was impossible. It's an impossible task to keep people out. So why even bother? You're going to get breached. You're going to get... And I think it's even worse out there amongst our customers and our clients. When they see major breaches of huge companies and they just think to themselves, "Well if they can't do it, how can I?"

Kip: Right, yeah. They just throw up their hands. And I tell customers too, it's like, "Well, nobody can do perfect security. Nobody can get it exactly right." That's one of the lessons of Edward Snowden, I think, is that the NSA with virtually unlimited resources still could not prevent an Edward Snowden-type breach.

Jake: That's true.

Kip: And so that's why this is a myth, is because we're never going to get it exactly right. And in this day and age, I just keep going back to just become a harder target. That is the bar these days, just become a harder target.

Jake: And at the risk of slowing down the lightning round, and I promise we'll stop here in a moment, it's that you also have to consider that cybersecurity is not a binary thing.

Kip: No.

Jake: It's not a yes or no or 1 or 0. And if you really want to understand why, just consider the hypothetical. Would you rather be down for three weeks or three days? That's what we're talking about here in a lot of situations. Either way, one could say you failed, right?

Kip: Yeah.

Jake: You got hit. Got attacked successfully. But there's a big difference between recovering in three days versus recovering in three weeks.

Kip: Right, absolutely. And so anybody who's out there thinking it's impossible, it's not impossible and it can actually make a big difference for you.

Jake: Yep. Okay, last two for the speed round. Cybersecurity is the IT department's job so I'm relying on them to keep us safe.

Kip: God, I hear that. So awful, and often. And this is a myth. It used to be true again because it used to be that I could just look at the IT folks and say, "Will you please make sure Norton antivirus is on all of our computers and make sure that it stays up to date?" And that was the easy button. And if you did that, you were okay.
Of course, that's not true anymore. That's too simplistic. There really aren't any easy buttons anymore. And so you really can't rely on the IT department to exclusively deal with this. Plus it turns out that, and it's been like this for a long time, we beat the IT team up all the time if systems are unavailable. So they got that A, and the CIA triad totally nailed. They're always keeping things available. But to keep things confidential and high integrity, which is the other two elements of CIA, well those work against availability. And so IT teams tend to default towards more open systems because they're just easier to keep up and running on a day-by-day basis. And so that's the insight there. And if you want to really explore this myth, episode 105 is where we really drilled in deep on the idea that your IT person is not your cybersecurity person.

Jake: Yep, that's right. And last one, a third-party security provider will secure everything, an MSSP.

Kip: Yeah. Well, they'll secure what their tech stack will let them secure, and that's about it.

Jake: That's about it, yeah. And we could probably do a whole episode on that.

Kip: And they are treasure chest for attackers, because if I can get into an MSSP-

Jake: Isn't that the Kaseya issue?

Kip: Yeah.

Jake: Isn't that what that... Yeah.

Kip: Yeah. If I can exploit an MSSP, then I can easily push malware into the environments of all of its customers. And we've seen some awful, awful hacks-

Jake: We did.

Kip: ... related to that.

Jake: Okay, one last note before we wrap up. A major, major myth that we didn't mention because we talked about it way, way back in the midst of time in episode 12, was that compliance with laws and regulations equals minimum viable cybersecurity program. In other words, compliance is security or security is compliance. That is a myth. It's been busted repeatedly. If you'd like to know more, go back and listen to us when, gosh, I was probably recording with AirPods or the built-in microphone. I apologize for my historical person, my historical self. But yeah, episode 12.

Kip: Episode 12. Okay, everybody, I think that's enough myth busting for one episode. Thanks for being here, and we hope that this was helpful. And if you are struggling with any of these myths, they're busted now. Now you know what's really going on. And if you're working with a senior decision-maker that's under the spell of one or more of these myths, we hope that this has given you some insight into how you can explain to them using ordinary language why it's a myth and what the truth of it is. So thanks for being here. We'll see you next time.

Jake: See you next time.