TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    News

    Defensive Security Podcast – Malware, Hacking, Cyber Security & Infosec

    Defensive Security is a weekly information security podcast which reviews recent high profile cyber security breaches, data breaches, malware infections and intrusions to identify lessons that we can learn and apply to the organizations we protect.

    Advertise
    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    Defensive Security Podcast Episode 280 Sep 23, 2024
    Show notes In this episode of the Defensive Security Podcast, hosts Jerry Bell and Andrew Kellett delve into key cybersecurity topics. They discuss a recent statement by CISA director Jen Easterly on holding software manufacturers accountable for product defects rather than vulnerabilities, and the need for derogatory names for threat actors to deter cybercrime. The episode also covers Disney’s decision to ditch Slack following a data breach, and the impact of valid account misuse in critical infrastructure attacks. Additionally, they explore new tough cyber regulations in the EU under NIS2, and a Google security flaw from a Black Hat presentation concerning dependency confusion in Apache Airflow. The hosts share their thoughts on industry responses, regulations, and how enterprises can improve their security posture. 00:00 Introduction and Podcast Setup 00:59 First Story: CISA Boss on Insecure Software 03:26 Debate on Software Security Responsibility 11:12 Open Source Software Challenges 15:20 Cloud Imposter Vulnerability 22:22 Disney’s Data Breach and Slack 27:37 Slack Data Breach Concerns 29:26 Critical Infrastructure Vulnerabilities 35:21 EU’s New Cyber Regulations 43:42 Global Regulatory Challenges 48:42 Conclusion and Sign-Off

    Links:

    • https://www.theregister.com/2024/09/20/cisa_sloppy_vendors_cybercrime_villains/
    • https://www.tenable.com/blog/cloudimposer-executing-code-on-millions-of-google-servers-with-a-single-malicious-package
    • https://www.cnbc.com/2024/09/19/disney-to-ditch-slack-after-july-data-breach-.html
    • https://www.cybersecuritydive.com/news/cisa-critical-infrastructure-attacks/727225/
    • https://www.cnbc.com/amp/2024/09/20/eu-nis-2-what-tough-new-cyber-regulations-mean-for-big-business.html

    Defensive Security Podcast Episode 279 Sep 18, 2024
    Show notes

    In Episode 279 of the Defensive Security Podcast, Jerry Bell and Andrew Kalat discuss the latest cybersecurity news and issues. Stories include Transportation for London requiring in-person password resets after a security incident, Google’s new ‘air-gapped’ backup service, the impact of a rogue ‘Whois’ server, and the ongoing ramifications of the Moveit breach. The episode also explores workforce challenges in cybersecurity, such as the gap between the number of professionals and the actual needs of organizations, and discusses the trend of just-in-time talent versus long-term training and development. Links: https://www.bleepingcomputer.com/news/security/tfl-requires-in-person-password-resets-for-30-000-employees-after-hack/ https://www.securityweek.com/google-introduces-air-gapped-backup-vault-to-thwart-ransomware/ https://arstechnica.com/security/2024/09/rogue-whois-server-gives-researcher-superpowers-no-one-should-ever-have/ https://www.cybersecuritydive.com/news/global-cyber-workforce-flatlines-isc2/726667/ https://www.cybersecuritydive.com/news/moveit-wisconsin-medicare/726441/ Transcript: Jerry: [00:00:00] Here we go. Today is Sunday, September 15th, 2024. And this is episode 279 of the defensive security podcast. My name is Jerry Bell and joining me today as always is Mr. Andrew Kalat. Andrew: Good evening, Jerry. Happy Sunday to you. Jerry: Happy Sunday, just a reminder that the thoughts and opinions we express on the show are ours do not represent those of our employers or. Andrew: present, or future. Jerry: for those of us who have employers, that is not that I’m bitter or anything. It’s, Andrew: It’s, I envy your lack of a job. I don’t envy your lack of a paycheck. So that is the conflict. Jerry: It’s very interesting times right now for me. Andrew: Indeed. Jerry: All right. So our first story today comes from bleeping computer. And the title here is TFL, which is transportation for London requires in person, password [00:01:00] resets for 30, 000 employees. So those of you who may not be aware transportation for London had suffered what I guess would has been described as a nebulous security incident. They haven’t really pushed out a lot of information about what happened. They have said that it does not affect customers. But it apparently does impact some back office systems that did take off certain parts of their services offline, like I think. They couldn’t issue refunds. And there were a few other transportation related things that were broken as a result. But I think in the aftermath of trying to make sure that they’ve evicted the bad guy who, by the way, apparently has been arrested. Andrew: That’s rare. Somebody actually got arrested. Jerry: yeah. And not only that, but apparently it was somebody local. Andrew: Oops. Jerry: In in the country which may or may not be associated with an unknown named [00:02:00] threat actor, by the way, that was involved in some other ransomware attacks. Andrew: Kids don’t hack in your own backyard. Jerry: That’s right. Make sure you don’t have extradition treaties with where you’re attacking. So what I thought was most interesting was the, their, the approach here to getting back up and going they, they had disabled. So TFL had disabled the access for all of their employees and the requiring their employees to show up at a designated site to prove their identity in order to regain access. This isn’t the first. Organization that’s done this, but it is something that I suspect a lot of organizations don’t think about the logistics of, in the aftermath of a big hack. And if you’re a large company spread out all over the place, the logistics of that could be pretty daunting. Andrew: Yeah. It’s wild to me that they want in person. [00:03:00] Verification of 30, 000 employees. But given the nature of their company and business, I’m guessing they’re all very centrally located. Used to going to physical offices, but man, can you imagine if you were a remote employee and you don’t have any office anywhere near you, how would you handle that? I’m not, I’m probably not going to get on a plane to go get my password re enabled. Jerry: Exactly. Andrew: You know what it did, remind me of though is, remember back PGP and PGP key signing? Jerry: Oh, the key parties. Yes. Andrew: Yes. Where, You basically, it’s a web of trust and people you trust could verify and sign another key. Like at a key signing party, because we were fun back then, that’s what nerds used to do. And then that’s how you had the circle trust. So maybe they could do something similar where verified employee could verify another employee, then you’ve got the whole insider threat issue, et cetera. Yeah. It just reminded me of, Jerry: No, nobody trusts Bob’s. Andrew: [00:04:00] It’s true. Your friend, Bob, how many times has he been in prison? Most recently, like where Rwanda? I think I heard, Jerry: He’s got the frequent visitor card. Andrew: but yet has some of the best stories. Jerry: He does, he definitely does. so apparently they make reference to a similar incident that happened at Dick’s sporting goods. I will emphasize the sporting goods. They had a similar issue and that is a nationwide retailer here in the U S at least, I don’t know if they’re they’re outside of the U S and so that really wouldn’t be possible, with transportation for London. I assume that most of the people associated with it are local or. Or within a reasonable driving distance or commuting distances, the case may be. But in the situation with a retailer, a nationwide retailer, I think they had to go with virtual in person. So they basically had zoom meetings [00:05:00] with employees and I assume had them show like pictures of their government ID and so on. So the logistics of that is interesting. And. It isn’t really something I’ve spent a lot of time thinking about. And but I know in the aftermath of a big attack like this, establishing, trust and certainty and who has access to your network would be super important. So I think it’s I think it’s worth. Putting into your game plan, Andrew: Yeah, it is. It is a wild one. And what do you trust? Especially in the age of, deep fakes and easily convincing AI copies of other employees. And I don’t know, it’s an interesting one. Jerry: right? Andrew: Ciao. Jerry: our next, yeah, it was it was certainly a an unfolding story, which I don’t think is over yet based on everything I’m reading. Andrew: I did see one quote in here that made me chuckle, which is this is a quote from the transport [00:06:00] agency added on their employee hub. Some customers may ask questions about the security of our network and their data. First and foremost, we must reassure that our network is safe. Okay, define safe. That’s just us being Safe ish. Jerry: safe ish, safe now, Andrew: Safe, safe y. It resembles something that is sometimes called appropriately safe. Based, based on the criteria that we came up with, it’s completely safe. Jerry: which I’m sure is true because they they had also had a clop. Ransomware infection, I guess a couple of months prior to this. So Andrew: What do you use for clop? Is that like a cream? Is that like a, how is that treated typically? Jerry: every time I hear clap, I, it takes me back to the Monty Python, the coconut horse trotting. That’s what I think about when I hear the word clap, Andrew: That’s fair. Jerry: [00:07:00] which is oddly appropriate given that this is in the UK, which is where where Monty Python hails from. Andrew: I thought you say where they have coconuts. Jerry: Only if they’re if they’re transported by swallows. Andrew: You youngins will just have to go. Jerry: Gotta go watch that movie. Alright, it’s worth it. I, by the way, I remember making my son, both my sons watch it, and they protested. And now, I think they’ve each seen it like 30 or 40 times, Andrew: so when you say process, did you like have to duct tape them to a chair and like pry their eyes open and do a whole, yeah, train spotting situation? Jerry: I think they thought it was like an actual movie about the Holy Grail. Andrew: Which, why would they be opposed to that? That could also be interesting. Jerry: I don’t know. Andrew: Indiana Jones did a fine movie on it. Jerry: It’s true. But it, that does not hold a candle to [00:08:00] the Monty Python Holy Grail movie. Let’s just be Andrew: We, we learned a lot. We learned about facing the peril. We learned that Camelot is a silly place. And we learned how to end a movie when you don’t have a better plan. Again, way off topic, but you young’uns will just have to go discover. Do you, Jerry: So back on topic, our next story comes from security week. And the title here is Google introduces air gapped backup vault to thwart ransomware. And I’m going to put quotes as they do over air gapped because as they describe it, it is logically air gapped, not. Actually air gap. So what, and by the way I don’t necessarily mean to take away from the utility of the solution that they’re offering here, but calling it air gap, I think is maybe a little bit of a misnomer. So they are offering Google they being [00:09:00] Google are offering a service where you as a Google cloud customer can store data. Backups to a storage service that does not appear as part of your cloud account. It’s part of a Google managed project that is transparent to your account. So if somebody were to take over your account, for example or to compromise systems within your account, they actually wouldn’t be able to do anything with that backup which I think is a pretty smart the one thing that I was wondering, obviously that you are not necessarily protected in the case that Google’s cloud itself becomes the victim of something bad, but that is, is a kind of a theoretical issue at this point. But the one that concerns me a bit is what happens as we have seen in some other. [00:10:00] There was a, I’m forgetting the name at the moment that there was a company whose AWS account at the time was basically deleted and they had all of their data, all of their backups in their cloud account and they had it, split across different availability zones and it, it didn’t matter because they were, the actor actually deleted everything in their account and I believe they actually deleted the account itself. And I do wonder the same thing, if your account were to be taken over would that backup persist? Would you have the ability after the fact to, to prove to Google who you were and be able to resurrect that. I, Andrew: Do you mean the one that happened accidentally that Google did with that Australian pension fund or like a bad actor getting in and deleting it? Jerry: Bad actor that got Andrew: Gotcha. Yep. Jerry: There was a it was a GitHub competitor, Andrew: Yes. Jerry: [00:11:00] can’t remember the name. It was Andrew: I will look at, Jerry: several years ago. Yeah, I do think, and I’ve said this, I say this an increasing amount. I do think we are. On the cusp of, much more aggressive, what I’ll call cloud native attacks where adversaries are actually attacking, not just the workloads in the cloud, but actually, the cloud resources themselves, the cloud accounts and whatnot. So I think as time goes on, things like this are going to become much more important and questions like what I just asked, I think are going to become Increasingly important to Andrew: yeah it’s, interesting that it makes sense, first of all to make sure that my, if I’ve got a bad actor or ransom or whatever, that’s out there deleting things, I don’t want it to just delete my backups, which is something we’ve always talked about is it could be a weakness in your automated systems. If they’ve got full admin rights into your cloud environment, what stops them from going [00:12:00] after your backups? So that makes sense. It is interesting how strong that quote unquote logical air gapping is. It makes me wonder a little, somebody should probably test it, but I’m surprised this wasn’t offered before, honestly. It also makes me think, remember the days when we used to back up the tape and send those tapes off site to underground storage facilities? And Jerry: And half the time the tapes would fall off the truck Andrew: right. Jerry: built spilled out under the freeway. Yes, Andrew: And you never test restoring them, and then when you do need to restore them, it’s gonna take 43 months and half of them are bad. It was a weird time. Jerry: recall the tapes and the tapes will come back in a locked box and there’ll be tapes missing. Andrew: Right. Jerry: It was just Like the grand old days. I like, I, I don’t know why we don’t still do that. Andrew: I won’t go on the, we’re old rant, but boy, it makes me feel old. But this makes sense. Like what I’m also curious about, I haven’t looked into this is, how many versions of backups do you [00:13:00] have? Because the other thing I think about is you’ve got ransomware. And it automatically backs up how many iterations in, or am I just backing up encrypted data I can’t restore because it’s encrypted. The backup system doesn’t know the difference. It’s just backing up an iterative change. So that’s something else to think about is okay, how many snapshots back can I go? Because that starts to get expensive, but if I’m just like automatically backing up my encrypted data. Oops, it’s interesting and I like the concept and it’s meant to fight one particular source of pain, which is, ransomware, deleting your backups. Jerry: Yeah. I really liked the concept too. I think things like this are going to become increasingly important as this time goes on. Happy to see things like this starting to emerge, Andrew: Indeed. Jerry: but now, again, it comes back to making sure that it is actually working. Andrew: Yeah. And testing like a restore and [00:14:00] do the assumptions you have work. And that’s one thing not to go off on a bit of a side rant that I see a lot is organizations don’t have enough time built into their. IT or security schedules to actually test these things. They just Oh, we think it’s going to work. And the first time they tested is during a crisis, which is a terrible idea. You want to be able to test like when you’re not in crisis mode and see how well this stuff works. Jerry: Absolutely. Our next story comes from Ars Technica and the title is rogue. Who is server gives researchers superpowers. No one should ever have. Andrew: This one was crazy. Jerry: Yeah. So there’s a company called Watchtower of course, is all things tech. Now it isn’t spelled correctly. I won’t hold that against them. One of their researchers found during their stay at Black hat that the dot Moby top level domain had recently changed the location of its, who is [00:15:00] server. So previously it was a domain hosted on a dot net top level domain, but apparently over some time in the recent past, they moved that to unsurprisingly a name hosted on the dot Moby TLD. And I guess through probably some bit of, corporate cost savings or missteps don’t know. They let that domain, they let the dot net version of that domain expire, which is problematic. And so this person realized that registered the domain and then actually started seeing legitimate requests, who is requests coming in. And then they set up a, who is server and. Found that they would have had the opportunity to do quite a few bad things, like creating TLS certificates [00:16:00] for for domains, because VeriSign and others were still pointing their who is to the old. net. So they hadn’t, completely switched over from the NET domain to the MOBI domain, and as a result chaos ensued and it’s really hard to put bounds on how bad this could be, right? There’s, when you, they go through quite a few different situations that this could be. This could have allowed, for example, intercepting email and, lots of different telemetry based attacks. But I don’t even know that we have a good handle on the art of the possible when something like t…

    Full show notes at the publisher

    Defensive Security Podcast Episode 278 Sep 09, 2024
    Show notes

    In episode 278 of the Defensive Security Podcast, Jerry Bell and Andrew Kalat discuss various recent cybersecurity topics. The episode starts with light-hearted banter about vacations before diving into the main topics. Key discussions include a new vulnerability in YubiKey that requires sophisticated physical attacks, resulting in a low overall risk but sparking debate about hardware firmware updates for security keys. Another key topic is Verkada being fined for CAN-SPAM Act violations and lack of proper security measures, including exposing 150,000 live camera feeds. The hosts also explore reports showing diverging trends in security budgets and spending, with some organizations reducing budgets while overall industry spending increases. They highlight the need for effective use of security products and potential over-reliance on third-party services. The episode also delves into the growing threat of deepfake scams targeting businesses, emphasizing the need for robust authentication policies and awareness training to mitigate risks. Finally, the hosts reflect on the broader challenges of balancing security needs with budget constraints in an evolving threat landscape. Links: https://www.bleepingcomputer.com/news/security/new-eucleak-attack-lets-threat-actors-clone-yubikey-fido-keys/https://www.bleepingcomputer.com/news/security/verkada-to-pay-295-million-for-alleged-can-spam-act-violations/https://www.cybersecuritydive.com/news/iran-cyberattacks-us-critical-infrastructure/725877/https://www.theregister.com/2024/09/05/security_spending_boom_slowing/ vs https://www.cybersecuritydive.com/news/infosec-spending-surge-gartner/726081/ https://www.cybersecuritydive.com/news/deepfake-scam-businesses-finance-threat/726043/ Transcript Jerry: All right, here we go. Today is Saturday, September 7th, 2024. And this is episode 278 of the defensive security podcast. And my name is Jerry Bell. And joining me today as always is Mr. Andrew Kalat. Andrew: Good evening. Jerry, how are you? Kind sir. Jerry: Doing fantastic. How are you? Andrew: I’m great. Just got back from a little vacation, which was lovely. Saw a lot of Canada, saw some whales, saw some trains. It was Jerry: Did you see any moose? Andrew: Oddly we did not see a single moose, which was a bummer. We crossed from Toronto to Vancouver on a train and didn’t see a single moose. I saw a metric crap ton of ducks though. I couldn’t believe literally in the thousands. I don’t know why. Jerry: The geese are ducks. Cause Andrew: We saw a Jerry: geese are pretty scary. Andrew: We were sealed away from them, so we were protected. Jerry: I don’t know. Andrew: hard to Jerry: I don’t know. I w I wouldn’t I wouldn’t bet my life on that. Andrew: But yeah, we saw a decent chunk of gooses, but mostly ducks. Jerry: Good deal. Andrew: Indeed. I’m good. Now, catching back up on work. Jerry: And you’re back. Andrew: And you are apparently the Southern Command Center. Jerry: I am for another another day or two. Andrew: Nice. Never sucks to be at the beach. Jerry: It definitely does not. No, no bad days at the beach. Andrew: Nice. Jerry: All right. A reminder before we get started that the thoughts and opinions we express in the show are ours and do not represent those of our employers. Andrew: Past, present, or future. Jerry: That’s right. So our first topic or first story from today comes from bleeping computer. And this one was a bit of a, Oh, what’s the best, a bit controversial, best way to say it, controversial on on the social media sites over the past week. And the title is new leak. I’m not even going to try to pronounce that attack. Let’s threat actors, clone, Yubikey, Fido keys. Andrew: Shut down the internet. Shut Jerry: Shut it down, just throw away your Yubikeys, it’s over. Andrew: And apparently it can happen from 12 miles away with trivial equipment, right? Jerry: No, actually, they the bad actor here actually has to steal it and it takes some pretty sophisticated knowledge and equipment. But apparently the equipment they allege are about, costs about 11, 000. However, the the YubiKey actually has to be disassembled, like they actually have to take the protective cover, protective covering off, and they have to instrument it and, and then they’re able to leverage a vulnerability in an Infineon chip that’s contained in these YubiKeys to extract the private key. And so it’s not a, it’s not a trivial attack. You have to lose physical possession of the token for some period of time. But if you were, The victim of this, it is possible for someone, some adversary, who was willing to put in the time and effort could clone your key unbeknownst to you, and then find a way to reconstitute Packaging and slide it back into your drawer, and you would be none the wiser. Andrew: All seriousness, I think this has a very low likelihood of impacting the average listener to our show or the average person who cares about such things. But if you’re a very high profile target and, some sort of state intelligence service wanted to kidnap you and steal your YubiKey and then gain access to things before those sorts of permissions got revoked in some way, shape or form, I guess that could be viable, but this doesn’t seem like something that would happen to the average person. Jerry: Oh, a hundred percent. And I still think, despite some of the the initial banter about this, you’re much better off using. I’m sure there are definitely certain use cases where you would be concerned about this, but for the average person, I think, like you said, it’s it’s really not a big deal. So this does impact the YubiKey 5 series. And I think also the HSM 2 up through that was released, I think it was in May of 2024. The challenge is that you can’t actually update firmware on Yubikeys. That was a security decision. Andrew: yeah, that seems like a wise security decision if you ask me. Jerry: Yeah, it’s, I have observed quite a few people who who are now trying to find alternate. Security keys because they’ve been that they feel a little dejected by the fact that you can’t update the firmware on them. But I think it’s important to understand that. That actually is a very important security function, right? The ability to not muck with the firmware on these keys is very important. Andrew: right, otherwise a piece of malware could be doing that too. Jerry: Exactly. Andrew: Which not be all that happy Jerry: No. Sad in fact. Andrew: get the sort of knee jerk reaction to, I want to be able to update this to patch for flaws and such, but keep in mind that everything like that can be used by a bad actor just as easily, if not more easily. Be careful what you wish for. Jerry: Yeah. Now what’s interesting is this All of the hoopla around this is about Yubikeys, but the chip, the Infineon chip is actually used by multiple different types of security products, including some EFI. So the secure boot which, I guess at this point, it’s got his own problems already. And then I believe even after, since this particular article has been written, that there are some other. Actual security keys, similar to YubiKeys that have been identified as also using this Infineon chip. So almost certainly going to be vulnerable in the same way Andrew: But I guess, nothing to really panic about. But boy, this got a lot of press. A lot of social media traction. Jerry: it really did. So anyway, I thought it was important to discuss because again, for most people, this is really not a big deal. YubiKey themselves rated the vulnerability as a A CVSS score of 4. 9 to give you an idea. And I think that, that seems right to me. Andrew: Did it get a mascot? Jerry: It did not get a mascot. There was some attempts some valiant attempts made. Andrew: What about a jingle? Jerry: I haven’t seen a jingle yet either, but it did get a name Andrew: All right Jerry: and it has a website. So Andrew: geez. Okay, so mild panic then. If it’s got a name and a website, that equals mild panic. But got a mascot and a jingle, I’m full on panic. Jerry: that, what else are you going to, what are you going to do? If it’s got a jingle, you gotta panic. Andrew: what the tough part is, this is probably like getting traction, perhaps at executive levels who may not have the time or the knowledge to dig into the details and that they’re probably freaking out in certain C suites, but Jerry: Yeah. Andrew: send them our show. Tell them these two random guys on the internet said not to freak out. Jerry: Yeah. I can’t put anything on the internet. That’s not true. That’s right. But, I was I was thinking it’s been a while since YubiKey or UBI has released a new version of the YubiKey. So Andrew: So maybe this is driving an upgrade cycle. Maybe Jerry: maybe Andrew: it themselves. get people to buy new keys. Is that what you’re saying? Jerry, Jerry: it could be just like how the antivirus companies are releasing all the viruses. Yes. That’s right. Andrew: that’s some smart thinking right there. That is, know what? That’s the kind of cutting edge analysis you get on this Jerry: Thought leadership right there. Andrew: man. to get out on this. All right, here’s the plan. Let’s spend 20 years making a company and then break our main thing. So people to buy new things. Jerry: It’s a good idea. It’s solid. I don’t see any any faults in this plan. Andrew: Hey, how’s that working out for CrowdStrike? Jerry: We’ll find out soon. Andrew: Indeed. Jerry: All right. The next story comes from bleeping computer and title is Verkada to pay 2. 95 million for alleged CAN SPAM Act violations. So for those of you, not in the U. S. CAN SPAM was a law passed a couple of years ago, probably more than a couple of years ago at this point, that Unlike you, what you might expect does actually a permit spam in under certain particular circumstances. It requires, for example, an unsubscribe link, which this company didn’t do. Verkata, by the way, creates security cameras. There were two big issues, not related here. First one is that their marketing team did what marketing teams do. They went wild with the with their prospect, people who enter, who expressed interest in the cameras, they started spamming the crap out of them without any way to opt out. And so that was actually the genesis of the 2. 95 million fine. But on the other side, the company had been running around saying that they’re. Cameras are super secure and they are HIPAA compliant and they meet privacy shield requirements and a few other things. And at the same time they got hacked and lost. Quite a lot of data, some sensitive data, actually video feeds from sensitive places like mental institutions and whatnot things, the kinds of video that you would not want to to have exposed. So in addition to that roughly 3 million fine for spamming, they also have now to appoint a and pay for. A security overseer for the next 30, sorry, 20 years. And I think they have to report any data breaches to the financial or the federal trade commission within 10 days or you face additional sanctions. So I thought this one was interesting because we’re starting to see a definite trend. At least in the U. of the government holding companies to account when they make what I’ll call false claims about the, in, in the aftermath, in retrospect, false claims about the security capabilities of their offerings. And so I thought this is interesting. It was really important for people to understand that, if you are going to make those claims, you better not have a problem like this because you’re going to end up in the crosshairs Andrew: Yes, this wasn’t the SEC. So this didn’t matter if they were public or not. This was the FTC, the Federal Trade Commission. So that’s interesting. Some people would say if I’m not public, I don’t have to worry as much about this sort of liability, but guess what? Jerry: you do. Andrew: Looking at the details, 150, 000 live camera feeds were exposed. That’s impressive. And it looks like they didn’t know about the breach until AWS flags is a precious activity. Jerry: Yeah. Andrew: So kudos to AWS, but man, Jerry: It’s not a good look. Andrew: how would you like to be like that security overseer? How would you like that job? Just, working for the FTC, waiting for companies to come tell you stuff that they screwed up on. Jerry: Don’t know. It. Could be could be good. Could be bad. Andrew: Yeah. It’s. It’s interesting because the other thing that’s called out here is that Verkada did not implement basic security measures on its products, such as demanding the use of complex passwords, encrypting customer data at rest, implementing secure network control. So the complex passwords, it’s a little unclear to me if they mean this within their own environment or their customers. Requiring to use complex passwords, which gets back into that whole snowflake conversation we were having on previous episode of how much is a company liable for a customer’s poor use of their security features that are offered. Now, the other aspects here are obviously not, they’re very much for Cata’s choices and how they ran their environment and set up their, it and production environments and such, but doesn’t make me wonder are we going to see more things pushed on ensuring that. These companies are ensuring their customers are being somewhat safe with the use of the tooling. Jerry: Yeah. I don’t know exactly where this particular issue sits, but I will say broadly speaking, I think the expectation is that as a, Technology provider, whether that’s a service provider or some kind of piece of technology, if you’re going to assert that it’s no quote secure, the expectation is that you have some sort of guardrails on them that feed, for example, mandatory multi factor authentication or mandatory password complexity, and if you don’t, and lots of customers, lots of your customers end up getting hosed because they’re using bad passwords, obviously they have a problem, but I think what. And what we’re seeing increasingly is that you as the provider also have a problem, despite the fact that it’s based on the choices of the cost of your customers. Look, we can debate whether that’s the right approach or not, but I think that is in fact, what is happening. Andrew: Yeah. Makes sense. Got to be careful with what you say. If you allege you’ve got good security, at least your marketing and sales people are. And you don’t, and you get bit, there are consequences. Jerry: Yeah. Yeah, absolutely. All right. The the next story comes from cyber security dive and the title here is Iran linked actors, ramping up cyber attacks on us critical infrastructure. And I, There’s not a whole lot of technical Gorpy detail in here, but they do make reference to a number of different threat actor names like Pioneer Kitten. And I’m always fascinated by the names that emerge with these threat actors, but it was more that the targets of these attacks are actual security products. So they’re Cisco firewalls, F5s, Palo Altos that are being attacked by these threat actors in a couple of different ways. This one particular threat actors asserted to be associated with Iran and what they’re doing is they’re facilitating initial compromise, and apparently one of the ways they’re doing this is through exploitation of vulnerabilities in the security products, and then they’re using that access to basically sell that access to ransomware actors, and then taking a cut of any proceeds that those. Ransomware actors end up getting. I think it’s an interesting approach because again they’re asserting that this is, this threat actor is associated with the the Iran Republican Guard IRA or IRG Who apparently is really in it for the money and not for other, other uses like data destruction or intellectual property theft and whatnot. Andrew: Iran is a heavily sanctioned country, much like North Korea. They’re probably seeking hard capital. it makes sense. I, as I’ve often stated on this program I’m very skepti…

    Full show notes at the publisher

    Defensive Security Podcast Episode 277 Aug 26, 2024
    Show notes

    In this episode, Jerry Bell and Andrew Kalat discuss various topics in the cybersecurity landscape, including the influence of cyber insurance on risk reduction for companies and how insurers offer guidance to lower risks. They touch upon the potential challenges with cybersecurity maturity in organizations and the consultant effect. The episode also goes into detail about issues surrounding kernel-level access of security tools, implications of a CrowdStrike outage, and upcoming changes by Microsoft to address these issues. They recount a case about a North Korean operation involving a laptop farm to gain employment in U.S. companies, posing major security concerns. The discussion highlights the pitfalls of relying on end-of-life software, especially in M&A scenarios, and how this could be a significant vulnerability. Lastly, they explore the massive data breaches from Snowflake and the shared security responsibilities between service providers and customers, emphasizing the importance of multi-factor authentication and proper security management. Links: https://www.cybersecuritydive.com/news/insurance-cyber-risk-reduction/724852/ https://arstechnica.com/information-technology/2024/08/crowdstrike-unhappy-with-shady-commentary-from-competitors-after-outage/ https://www.cnbc.com/2024/08/23/microsoft-plans-september-cybersecurity-event-after-crowdstrike-outage.html https://arstechnica.com/security/2024/08/nashville-man-arrested-for-running-laptop-farm-to-get-jobs-for-north-koreans/ https://www.darkreading.com/vulnerabilities-threats/why-end-of-life-for-applications-is-beginning-of-life-for-hackers https://www.cybersecuritydive.com/news/snowflake-security-responsibility-customers/724994/ Transcript: Jerry: Here we go. Today is Saturday, August 24th, and this is episode 277 of the defensive security podcast. My name is Jerry Bell and joining me today as always is Mr. Andrew Kalat. Andrew: Good evening, my good sir Jerry. How are you? Jerry: I am awesome. How are you? Andrew: I’m good. I’m good. I’m getting ready for a little bit of a vacation coming up next week So a little bit of senioritis. If I’m starting to check out on the show, you’ll know why Jerry: Congrats and earned. I know. Andrew: Thank you, but otherwise doing great and happy to be here as always Jerry: Good. Good deal. All right. Just a reminder that the thoughts and opinions we express on this show are ours and do not represent anyone else or including employers, cats, relatives, you name it. Andrew: various sentient plants Jerry: Exactly. Okay. So jumping into some stories today. First one comes from cybersecuritydive. com, which by the way, has a lot of surprisingly good content. Andrew: Yeah, I have enjoyed a lot of what they write. We’ve a couple good stories there Jerry: Yeah. Yeah. So the title here is insurance coverage drives cyber risk reduction for companies, researchers say that the gist of this story is that there were two recent studies done or reports released one from a company called Omeda and another one from Forrester, which I think we all know and love. And I’ll summarize it and say that they’re both reports indicate that companies which have cyber insurance tend to be better at quote, reducing risk more likely detect, respond, and recover from data breaches and malicious attacks compared to organizations without coverage. So I thought that was a little interesting. On the other hand it to me feels like a bit of availability bias, so by that, what I mean is if you go and take a survey of people who go to the gym and work out at the gym on their diet, you will probably will find out that Eat a healthier diet than the public at large. Andrew: But I go. Jerry: you just go. Andrew: I, look, Jerry: I’m not saying, I’m not saying everybody, right? Andrew: least I show up, right? And I’ve been told showing up is half the battle. Jerry: It is half the battle, that’s right. Knowing is the other half. Then doing is the other half. Andrew: I will say, speaking of G. I. Joe quotes, I thought catching on fire was going to be a far bigger problem in my life than it turned out to be. Jerry: That and quicksand. Andrew: I, we were Lot about that as children of Jerry: quick, quicksand. Andrew: Heh. Jerry: QuickSand was, I, I lived in fear of QuickSand, but it turns out it’s really not that big of a concern. Andrew: For as much as I heard stop drop and roll done it Jerry: Yet. Andrew: That’s true. The day is young. Anyway back to your story. I think you’re right I will also say having worked with a number of these companies do interestingly have their own towards trying to keep you from getting hacks. They have to pay out So they do push certain things like and I’ve seen myself and I won’t say it You know, it doesn’t matter where, when, but if you have things like one of the well known EDR tools well deployed, they might cut you a rate on or a break on your rates. Because they have their actuarial table saying, Hey, if you’re using certain bits of technology that lowers your risk of usually ransomware, right? So they Jerry: Sure. Andrew: seems to me, my opinion is that these insurance companies feel that some of the well known EDR brands in a Windows environment It is very effective or decently effective at stopping ransomware, therefore they’re less likely to pay out, therefore they lower your rates. So there might be some of that too. They do to give companies guidance on what they see across their industry to reduce risk. Jerry: I think that, that makes sense. I’ll say, on, on one hand, like I was saying before, I think companies that buy cyber insurance are probably maybe more mature, more invested in, protecting their environment than others. But I think that there’s also this consultant effect when when you want to drive change and whether whatever kind of change that is, reorganizing revamping your security program, justifying additional expenses for anything outside guidance, typically Carries a lot more weight than something that comes from internal. Andrew: Sad but Jerry: and so I think, yeah, anybody who’s been in the industry for a long time or really any amount of time knows that, especially this is a, the CISO trick, right? When you come into a new organization as a CISO, the first thing you do is you go off and you hire a, a big name consultant. You burn a half a million bucks on a consulting engagement. And at that point, it’s not you telling the company, Hey, we’ve got to spend a bunch of money to improve our security program. It’s some, hard to argue with independent third party who is making that assessment. And to some extent you argue with that at your own peril, right? Because now it’s it’s a, it’s an assessment that becomes exhibit a, if something goes wrong and which is, both a blessing and a curse. But my experience is it certainly helps a lot. And I think that this cyber insurance and their somewhat prescriptive guidance and expectations around the kinds of controls and technologies you need to have in place is a very similar kind of thing, right? If you’re engaging with them, they’re going to be opinionated on what you should and shouldn’t be doing and and then like a consulting engagement. It’s a third party giving you that guidance. And so I think that tends to carry a lot more weight. Andrew: Agreed on all points. The only caveat I would say to that is sometimes these recommendations that come from some insurance companies are not customized typically to your particular risk environment or situation. They are very broad approaches to reducing risk across many different types of environments with many different types of risk profiles. Technology stacks and all that sort of stuff. So they’re very somewhat generic recommendations, I think. Jerry: I think you’re probably right. In any event, it’s I thought it was I thought it was quite interesting. Certainly having that insurance can help. I will tell you in my time as a CISO in dealing with customers and to some extent business partners, there was a I would say a growing expectation that you have to have cyber insurance. Actually, I experienced firsthand quite a few customers actually writing into contracts. That you have now, I don’t know how far and wide that permeates the industry, but I think it’s probably becoming a lot more common these days because, companies have this interdependence and so it’s not necessarily just like a cloud service provider where that kind of thing can manifest, look at over the, what now, 12, 13 years we’ve been doing the show. How many times have we talked about a company like, let’s say, Target or Home Depot getting hacked as a result of something happening with one of their suppliers? And so I think, as time goes on, we’re going to see that becoming kind of table stakes to, to have these business relationships, especially with larger and more mature companies. Andrew: Why do you think that is, what do you think that the third party is assuming that you will get from that insurance? Just so you have the ability to recover from an incident and sustain As a going concern or that they assume that if you have insurance, it’s coming with requirements that level up the maturity of your program or what value do you think that third party sees in their business partner having cyber insurance? Jerry: That’s a great question. I think it’s both, actually. I think there is this, naive view that if, if something bad were to happen this insurance would, provide that buffer. It would make sure that, the company didn’t go out of business, but the reality is that, especially, if you look at some of the really large hacks. can happen with relatively small organizations who are, I would say fairly highly leveraged, at least in terms of their insurance policy. So yeah, it’s great. They may have a 5 million insurance policy, but if they hit if they’re, let’s say a, a hundred million dollar company and they get hit with a, 50 million in breach fees, their 5 million in insurance coverage, isn’t really going to go very far. So I don’t know that it’s extraordinarily useful in terms of protecting customers from harm. I think there’s a facade that it provides. And I also think it does give some, at least a segment of, roles at companies gives them this warm, fuzzy feeling that somebody else is looking over their shoulders. In that respect, it’s not different than like a sock to or an ISO, SOA or what have you. Andrew: I wonder if there’s some sort of implied, Hey, you’ve ransomware you can recover faster. The other thing I think about is the perverse incentive. So when we look at an insurance in general, it’s to shift risk. It’s to shift Jerry: I Andrew: risk to a third party. So is there the risk that a executive committee will say, Hey, we don’t need to invest in much in cybersecurity because we have insurance if something bad happens. Jerry: mean, I would love to sit here and say no, that’s that would never happen. But I don’t think it happens that every organization, but I definitely expect it happens more than it should. Andrew: Yeah, it’s interesting. It’s interesting interplay of competing priorities. When you start to introduce these sorts of things and how what sort of behavioral economics comes into play Jerry: Yeah, absolutely. All right. Anyway, go go talk to your insurance carrier and it might might help you with your internal program and justify additional improvements to your program. Our next story comes from Ars Technica and the title here is Crowdstrike. Unhappy with shady commentary from competitors after outage Andrew: I’m shocked. I say shocked Jerry: Totally surprised by this so we’ve talked about this Several times and i’m sure we’ll talk about it several more times CrowdStrike obviously had a pretty devastating Snafu With one of its products that caused probably the largest single meltdown of I. T. in history and a lot of their competitors have been capitalizing on that outage. And so now this story is talking about in the wake of some of the back and forth tit for tat. mudslinging that’s been going on. I think they call out Sentinel one in particular. CrowdStrike is, I think, getting a little peeved at how their competitors are behaving, basically saying, hey, this could have happened to anybody. And I think there’s a lot of differing opinions in the industry based on my experience and exposure to different, to, the industry. I don’t think everybody’s on that bus. I think there’s a lot of people who think that, no, this really would be a lot less likely with other companies. Although it is interesting that SentinelOne is, is one, I think one of the more aggressive mudslingers, but they also, by the way, as far as I can tell, do use they do access windows The kernel. And in fact, the next story we have actually talks directly about that. Andrew: Yep they do and this goes back to something that I’ve I don’t have expertise in so I’m just dancing around and pontificating at something I can’t be authoritative on but I think what I keep seeing is that most security tooling feel that they need to be in the Windows kernel to be effective on the way Windows is architected today. it’s interesting when they talk about they being various competitors of CrowdStrike talk about safer methodologies, whatever that means, and I think somewhat that implies perhaps not operating at the kernel level. However, safer in terms of not causing an outage per se, but are they as effective at spotting and stopping malware? I don’t know. I, my assumption is there’s always some sort of trade off. If we’ve got most of the industry wanting to operate at the kernel level, and we’ve got another story that talks about this a little bit, and Microsoft themselves is talking about maybe we can find ways to make this effective. seems to me as not a, not having worked at those companies that, but Operating at the kernel level allows these security tools to be more resilient against malware trying to shut them down, and in theory be faster and more effective, and if they are operating at the user level or in user space, the implication that I’m getting from these articles is malware could Shut down the anti malware tool and do whatever it wants to do. And that appears to be harder at the kernel level. That it’s better able to protect itself and spot things at a deeper level in the operating system. I don’t know if that’s true, but it seems to be most of these companies operate that way. And in fact, there was even an implication we talked about it on a previous show. From Alex Stamos, who’s the newly appointed CSO over at or c SSO or cso, one of the two over at Sentel Jerry: CTO. CTO. Andrew: Now it says Chief Information Security Officer in this particular Jerry: Oh, okay. Andrew: Alright. Anyway, he talked about, Hey, we’ll back outta using the kernel if all of our competitors will as well. there’s clearly some advantage to being there. And I don’t know that anybody really wants to talk about that. Jerry: I think there’s, I think there, that we are talking about this as if it’s like one, monolithic choice of, you’re either there or you’re not there. Andrew: Yeah. Jerry: that’s probably not the right way to think about it. I suspect that there’s the nuances that there are certain kinds of functions that you don’t need to perform in the kernel. And as an example, you don’t need to, parse your file, your definition files in the kernel. You could do that in user mode and then. pull it into the kernel module. I suspect that there’s some of that. It certainly adds a lot of complexity and I’m not going to argue that, but I think that’s where, I don’t know if, I don’t know anything about SentinelOne and their technology, but I’m going to guess what, when they say, when they’re trying to throw rocks at CrowdStrike, I think what they’re probably saying is we do. more things outside of outside of the kernel. But like you said, if they were to completely move out of the…

    Full show notes at the publisher

    Defensive Security Podcast Episode 276 Aug 16, 2024
    Show notes

    Check out the latest Defensive Security Podcast Ep. 276! From cow milking robots held ransom to why IT folks dread patching, Jerry Bell and Andrew Kalat cover it all. Tune in and stay informed on the latest in cybersecurity! Summary: In episode 276 of the Defensive Security Podcast, hosts Jerry Bell and Andrew Kalat delve into a variety of security topics including a ransomware attack on a Swedish farm’s milking machine leading to the tragic death of a cow, issues with patch management in IT industries, and an alarming new wormable IPv6 vulnerability patch from Microsoft. The episode also covers a fascinating study on the exposure and exploitation of AWS credentials left in public places, highlighting the urgency of automating patching and establishing robust credential management systems. The hosts engage listeners with a mix of humor and in-depth technical discussions aimed at shedding light on critical cybersecurity challenges. 00:00 Introduction and Casual Banter01:14 Milking Robot Ransomware Incident04:47 Patch Management Challenges05:41 CrowdStrike Outage and Patching Strategies08:24 The Importance of Regular Maintenance and Automation15:01 Technical Debt and Ownership Issues18:57 Vulnerability Management and Exploitation25:55 Prioritizing Vulnerability Patching26:14 AWS Credentials Left in Public: A Case Study29:06 The Speed of Credential Exploitation31:05 Container Image Vulnerabilities37:07 Teaching Secure Development Practices40:02 Microsoft’s IPv6 Security Bug43:29 Podcast Wrap-Up and Social Media Plugs-tokens-in-popular-projects/ Links: https://securityaffairs.com/166839/cyber-crime/cow-milking-robot-hacked.html https://www.theregister.com/2024/07/25/patch_management_study/ https://www.cybersecuritydive.com/news/misguided-lessons-crowdstrike-outage/723991/ https://cybenari.com/2024/08/whats-the-worst-place-to-leave-your-secrets/ https://www.theregister.com/2024/08/14/august_patch_tuesday_ipv6/ Transcript: Jerry: Today is Thursday, August 15th, 2024. And this is episode 276 of the defensive security podcast. My name is Jerry Bell and joining me tonight as always is Mr. Andrew Kalat. Andrew: Good evening, Jerry. Once again, from your southern compound, I see. Jerry: Once again, in the final time for a two whole weeks, and then I’ll be back. Andrew: Alright hopefully next time you come back, you’ll have yet another hurricane to dodge. Jerry: God, I hope not. Andrew: How are you, sir? Jerry: I’m doing great. It’s a, it’s been a great couple of weeks and I’m looking forward to going home for a little bit and then then coming back. How are you? Andrew: I’m good, man. It’s getting towards the end of summer. forward to a fall trip coming up pretty soon, and just cruising along. Livin the dream. Jerry: We will make up for last week’s banter about storms and just get into some stories. But first a reminder that the thoughts and opinions we express are those of us and not our employers. Andrew: Indeed. Which is important because they would probably fire me. You’ve tried. Jerry: I would yeah. So the the first story we have tonight is very Moving. Andrew: I got some beef with these people. Jerry: Great. Very moving. This one comes from security affairs and the title is crooks took control of a cow milking robot, causing the death of a cow. Now, I will tell you that the headline is much more salacious than the actual story that the. When I saw the headline, I thought, oh my God, somebody hacked a robot and it somehow kill the cow, but no, that’s not actually what happened, Andrew: Now, also, let’s just say up front, the death of a cow is terrible, and we are not making light of that. But we are gonna milk this story for a little while. Jerry: that’s very true. Andrew: I’m almost out of cow puns. Jerry: Thank God for that. So, what happened here is this farm in Sweden had their milking machine, I guess is a milking machine ransomware and the farmer noticed that he was no longer able to manage the system, contacted the support for that system. And they said, no, you’ve been ransomware. Actually, the milking machine itself apparently was pretty trivial to get back up and running, but apparently what was lost in the attack was important health information about the cows, including when some of the cows were inseminated. And because of that, they didn’t know that one of the pregnant cows was supposed to have given birth, but actually hadn’t. And so it. What had turned out to be the case is that the cow’s fetus, unfortunately passed away inside the cow and the farmer didn’t know it until they found the cow laying lethargic in it stall, and they called a vet. And unfortunately, at that point it was too late to save the cow. This is an unfortunate situation where a ransomware attack did cause a fatality. Andrew: Yeah, and I think in the interest of accuracy, I think it was in Switzerland, Jerry: Is it switzerland? Okay. I knew it started with a S W. Andrew: That’s fair. You’re close. It’s Europe. Jerry: It’s all up there. Andrew: But yeah, I guess in this theory that if they had a better tracking date when the cow had been inseminated, they would have known that the cow was in distress with labor and could have done something more proactively to save cow and potentially the calf. And unfortunately, because I didn’t have that data, because it was in this ransomwared milking robot machine we ended up with a dead cow and a dead calf. Jerry: So not without grilling the farmer too much. I was I was thinking, that, Andrew: Wow! Jerry: I’m sorry. I was thinking that, they clearly had an ability to recover. And what they thought was the important aspect of that machine’s operation, which was milking, they were able to get that back up and running pretty quickly. But it seemed to me like they were unaware that this other information was in kind tied to that same system. I don’t fully understand. Seems like it’s a little more complicated than I’m, than I’ve got it envisioned in my mind. But very clearly they hadn’t thought through all the the potential harm. A good lesson, I think for us all. Andrew: I feel like we’ve butchered this story. Jerry: The the next story we have for today comes from register. com and the title is patch management still seemingly abysmal because no one wants the job can’t stop laughing. All right. Andrew: A cow died! That’s tragic! Jerry: I’m laughing at your terrible attempts at humor. Andrew: I couldn’t work leather in there. I tried. I kept trying to come up with a leather pun. Jerry: We appreciate your efforts. So anyhow. This next story talks about the challenge that we as an IT industry have with patching. And basically that it is a very boring task that not a lot of people who are in IT actually want to do. And so it, it highlights the importance again of automation and. This in the complimentary story which is titled misguided lessons from CrowdStrike outage could be disastrous from cybersecurity dive. I put these two together for a reason because one of the, one of the. I think takeaways from the recent CrowdStrike disaster is we need to go slower with patching and updates and perhaps not rely on automatic updates. And these 2 articles really point out the folly in that. Number 1, this. Article from the register is pointing out that relying on manual patching is a losing proposition because really nobody wants to do it and it doesn’t scale. It’s, it’s already, it’s IT operations is already a crap job in many instances, and then trying to expect people to to do things manually is a problem. The second article points out the security issues that come along with Adopting that strategy, which is, you’re exposing your environment unduly unnecessarily. And in fact the improvements in. Your security posture and the let the reduction in likelihood of some kind of an attack far outweigh the remote possibility of what happened. Like we saw with CrowdStrike. Now there is a kind of an asterisk at the bottom. They point out the importance of doing staged deployments of patches, which I think is one of the central lessons of the, at least for my Perspective, one of the central lessons of the CrowdStrike disaster is that go fast, but stage it. Andrew: yeah it’s an interesting problem that we’re struggling with here, which is how many times have we saved our own butts without knowing it by automate or rapidly patching? It’s very difficult to prove that negative. And so it’s very difficult to. Weigh the pros and cons empirical data showing where automatic patching or rapid patching solved a problem or avoided a problem versus when patching broke something. Cause all we know about is when it breaks, like when a Microsoft patch rolls out and breaks and that sort of thing. And it’s one of those things where it has to be perfect every time is the feeling from a lot of folks. And if it, if every time we have a problem, we break some of that trust. It hurts the credibility of auto patching or, rapidly patching. The other thing that comes to mind is I would love to get more IT folks and technical operations folks and SREs and DevOps folks, with the concept of patching as just part of regular maintenance. That is, just built into their process. A lot of times it feels like a patch is an interrupt driven or toil type work that they have to stop what they’re doing to go work on this. Where, in my mind, at least the way I look at it from a risk manager perspective, unless something’s on fire or is a known RCE or known exploited, certain criteria. I’m good. Hey, take patch on a monthly cadence and just catch everything up on that monthly cadence, whatever it is. I can work within that cadence. If I’ve got something that I think is a higher priority, we can try to interrupt that or drive a different cadence to get that patched or mitigated in some way. But the problem often is that, Okay. Every one of these patches seems to be like a one off action if you’re not doing automatic patching in some way, that is very Cognitively dissonant with what a lot of these teams are doing and I don’t know how to get Across very well that you will always have to patch it was all this will never stop So you have to plan for it. You have to build time for that. You have to build Automation and cycles for that and around it and it’ll be a lot less painful It’s it feels like pushing the rock up the hill on that one. Jerry: One of my observations was an impediment to fast patching is the reluctance for downtime and, or the potential impacts from downtime. And I think that dovetails with what you just said, in part, that concern stems from the way we design our IT systems and our IT environments. If we design them in a way that they’re not patchable without interrupting operations, then my view is we’ve not been successful in designing the environment to meet the business. And that’s something that, that I tried hard to drive and just thinks in some aspects I was successful and others I was not. But I think that is one of the real key things that, that we as a it leader or security leaders really need to be imparting in the teams is that when we’re designing things, it needs to be, Maintainable as a, not as a, like you described it as an interrupt, but as an, in the normal course of business without heroic efforts, it has to be maintainable. You have to be able to patch, you have to be able to take the system down. You can’t say that gosh, this system is so important. Like we can’t, we take it down. We’re going to lose millions of dollars ever. Like we can’t take it down. Not a good, it’s not a good look. You didn’t design it right. Andrew: That system is gonna go down. Is it gonna be on your schedule or not? The other thing I think about with patching is not just vulnerability management But you know Let’s say you don’t patch and suddenly you’ve got a very urgent Vulnerability that does need to be patched and your four major versions and three sub versions behind now you have this massive uplift That’s probably going to be far more disruptive to get that security patch applied, as opposed to if you’re staying relatively current, n minus one or n minus two, it’s much less disruptive get that up to date. Not to mention all of the end of life and end of support issues that come with running really old software. And don’t even know what vulnerabilities might be running out there, but just keeping things current as a matter of course, I believe. It makes dealing with emergency patches much, much easier. all these things take time and resources away from what is perceived to be higher value activities. So it’s constantly a resource battle. Jerry: And there was like, there was a quote related to what you just said in, at the end of this article, it said I think it mostly comes down to quote, I think it mostly comes down to technical debt. You explained it’s very, it’s a very unsexy thing to work on. Nobody wants to do it and everyone feels like it should be automated, but nobody wants to take responsibility for doing it. You added the net effect is that nothing gets done and people stay in the state of technical debt. Where they’re not able to prioritize it. Andrew: That’s not a great place to be. Jerry: No, there wasn’t another interesting quote that I often see thrown around and it has to do with the percent of patches. And so the, I’ll just give the quote towards the beginning of the article. Patching is still notoriously difficult for us to principal analyst. Andrew Hewitt told the register. Hewitt, who specializes in it ops said that while organizations strive for a 97 99 percent patch rate, they typically only managed to successfully fix between 75 and 85 percent of issues in their software. I’m left wondering, what does that mean? Andrew: Yeah, like in what time frame? In what? I don’t know. I feel like what he’s talking about maybe is They only have the ability to automatically patch up to 85 percent of the deployed software in their environment. Jerry: That could be, it’s a little ambiguous. Andrew: It is. And from my perspective, there’s actually a couple different things where we’re talking about here, and we’re not being very specific. We’re talking about I. T. Operations are talking about corporate I. T. Solutions and systems and servers. For an IT house, I work in a software shop, so we’ve got the whole software side of this equation, too, for the code we’re writing and keeping all that stuff up to date, which is a whole other complicated problem that, some of which I think would be inappropriate for me to talk about, but, so there’s, it’s doubly difficult, I think, if you’re a software dev shop to keep all of your components and dependencies and containers and all that stuff up to date. Jerry: Absolutely. Absolutely. I will also say that A couple of other random thoughts on my part, this, in my view, gets harder or gets more complicated, the larger in larger organizations, because you end up having these kind of siloed functions where responsibility for patching isn’t necessarily clear, whereas in a smaller shop. You may have an IT function who’s responsible end to end for everything, but in large organizations, oftentimes you’ll have a platform engineering team or who’s responsible for, let’s say, operating systems. And then you may have a, that, that team is a service provider for other other parts of the business. And those other parts of the business may not have a full appreciation for what they’re responsible for from an application perspective, and especially in larger companies where, they’re want to reduce head count and cut costs, the, those application type people in my, my experience, as well as the platform team are are ripe targets for reductions. And when that happens. You end up in this kind of a weird spot of having systems and no clear owner on who’s actually responsible. You may even know that you have to patch it, but you may not know whose job it is. Andrew: Yeah, absolutely. In my perfect world,…

    Full show notes at the publisher

    Defensive Security Podcast Episode 275 Aug 08, 2024
    Show notes

    Links: https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf https://www.theregister.com/2024/08/05/crowdstrike_is_not_at_all/ https://www.theverge.com/2024/8/6/24214371/microsoft-delta-letter-crowdstrike-response-comments https://www.linkedin.com/posts/alexstamos_why-crowdstrikes-baffling-bsod-disaster-activity-7224046054076243969-1An8?utm_source=combined_share_message&utm_medium=ios_app https://www.linkedin.com/posts/choff_why-crowdstrikes-baffling-bsod-disaster-activity-7224078879445958658-ymuc?utm_source=combined_share_message&utm_medium=member_ios https://www.securityweek.com/thousands-of-devices-wiped-remotely-following-mobile-guardian-hack/ https://www.bleepingcomputer.com/news/security/stackexchange-abused-to-spread-malicious-pypi-packages-as-answers/ https://www.bleepingcomputer.com/news/security/hunters-international-ransomware-gang-targets-it-workers-with-new-sharprhino-malware/ Transcript: Jerry: Today is Wednesday, August 7th, 2024. And this is episode 275 of the Defensive Security Podcast. My name is Jerry Bell and joining me tonight as always is Mr. Andrew Kalat. Andrew: Good evening, Jerry. How are you? Good, sir. Jerry: I am amazing. It is blistering hot at the beach, but it’s awesome. Andrew: recording from your southern compound. Jerry: I am. Andrew: Nice. Jerry: Yeah, Bell Estate South. Andrew: And Debbie was not an issue. Jerry: Debbie not here. We got probably 45 minutes worth of rain. Andrew: Yeah, it seems, at this point, in real time, stalled out over South Carolina Jerry: Yeah, it looks several feet of rain hitting like Savannah and That is nuts. But no, it was not a big issue here. I was pretty worried. I packed up all my Milwaukee batteries with lights and whatnot in preparation for the worst got extra tranquilizer for my dog who hates storms. But no, it’s been absolutely amazing here. Andrew: So you took the tranks instead? Is that what I’m hearing? Jerry: Absolutely. You gotta sleep somehow. Andrew: That’s fair. I’m glad it was a non event, at least for your little neck of the Jerry: Yeah, it was Nice you could actually see some of the storm clouds off in the distance. And that was the best way to watch a hurricane is when it’s far away. Andrew: That’s true. That A few I’ve been through. Stuck on islands, but Jerry: Yeah, that’s right. since I’ve been here, I have been in the building for two hurricanes, and the building’s been hit by three tornadoes. And then there was also a unsuccessful base jump. Andrew: So we’re saying you are cursed. Is that what we’re saying? Jerry: am the human equivalent to a plastic flamingo. which attracts tornadoes for those who don’t know. Anyway. Yeah. Andrew: after that meteorological update, Jerry: Yeah. just a reminder that the thoughts and opinions we express on the show are ours and do not represent those of our employers past, present, or future. Andrew: maybe even our Jerry: Or our pets. my pet is licking me right now and she says, nope, it’s not her opinion. Andrew: fair, Jerry: Okay I would say that this is going to be a CrowdStrike heavy episode. Andrew: three weeks in a row. Jerry: Yeah, it continues to get more and more interesting. Obviously the main event itself is largely behind us and now we are in the lawyer up phase of the party. Andrew: the blamestorming Jerry: blamestorming has indeed begun. The first topic we have to talk about here is the actual formal full root cause analysis was released yesterday by CrowdStrike and it is a 12 page long document. It has lots of marketing fluff in it. And only I would say a little bit of substance. I don’t think there’s anything that is remarkably telling or revolutionary in the document, but it does indicate technically what went wrong. And it gives some indications of the, potential improvements for their quality assurance, which I think is where a lot of this went wrong. So the, I’m not going to go through the details in uber technical specificity, but the net is that this channel file update is for this inter process communication agent, for lack of a better term, I’ll call it. And that agent, expects configuration files that have 20 parameters, but through some unfortunate bad planningtheir test harness actually was Marking the 21st as a catch all, as an asterisk. It was effectively being marked as not used. And so in this particular update, they actually started using it, and that ended up causing their parser to perform what ultimately ended up being an out of bounds read. Because that parser wasn’t set up to actually read it. And so when that read attempted to happen in kernel space, it tried to access memory. It wasn’t allowed to access, wasn’t allocated. And that caused the blue screen. And because the same thing happened every time it booted up. You just had this endless boot loop until that particular file got removed. I think the more substantive issue, and that’s the kind of thing that can happen, Andrew: So let me restate that to make The application was expecting. a file that had 21 fields in it, and it got a file with 20. Jerry: Yes. Andrew: And where it went to read that 21st, it wasn’t allowed to read, and the way that systems protect themselves to do a kernel panic and shut down if you’re trying to read something you’re not allowed to Jerry: Yes. Andrew: If you’re in Jerry: Windows basically says something is horrifically wrong. This should not happen. Andrew: If I went by that criteria, I’d shut down every day. Jerry: And so if that were to happen in user space, the application that performed that read would crash. But when it happens in kernel space, Windows attempts to protect itself and it blue screens. And so the challenge is that testing harness was built assuming that 21st parameter was always set up as a catch all and so effectively was being ignored. And I think there were really two issues here. One was they didn’t have a very thorough, their testing harness obviously wasn’t, Properly designed, but then they also did not have staged deployments. Like they, what they have a process where once it goes through that test harness and passes it, it goes out far and wide. There is no staged, deployment ring concept that you have in, let’s say, Microsoft Windows updates and whatnot. And because of that, it, it blasted out. Everybody implicitly trusted CrowdStrike updates and those got applied to pretty much as, fast as they were delivered and the rest is now history. Andrew: I think it’s a very complicated series of events that led to this. And I think just reacting to a lot of the zeitgeist in the social media world around this, there’s a lot of angry finger pointing some of which is probably well warranted, but it’s interesting to see how the inner chain came together. And going back to another area I know a little bit about is like aviation incident investigation and things like when space shuttles explode or fall apart, I’ve read a lot of books on those and that sort of thing. Anyway, it’s interesting how there’s very rarely one root cause is where I’m going with this. Usually series of events, an air chain that led to this situation. If one of these situations have been slightly different, this would have been caught and all the Swiss cheese holes lined up just right this situation to happen, not absolving or apologizing for it. It’s just interesting how complex these situations truly are. Compared to how a lot of people will knee jerk their opinions on things, usually based on their own bias around what they care about. Jerry: When I was reading it, it reminded me of the show. I think you’ve probably watched it too called engineering disasters. And the history or the learning in each one of those episodes that a sequence of disconnected things all lined up in just the right way. for that disaster to happen. Andrew: right. Jerry: And I think that is definitely what happened here. Andrew: For everybody involved, but there’s a part of me that finds these things fascinating to watch play out. Jerry: I still think, for me, what is most, troublesome, because this is not unprecedented, right? Obviously the amount of systems that were impacted, is unprecedented, but that’s probably more a function of how interconnected and dependent we are on computers than any point in time. But what’s interesting is that this sort of thing has happened in the past, right? This has happened with Symantec and McAfee and Microsoft probably about five or six different times and several others that I’m probably missing. But one of the things that, distinguishes this from those is that those were much less impactful because they did stage rollouts. And so when it happened, it was devastating to the people who were among the first, the canaries that they had the problem. But this is a different thing. I think that the fundamental Coding and architecture errors are hard to foresee. They’re easy to see in hindsight, right? this is like the signal and the noise thing. The failure is easy to identify after the fact, because it’s obvious. Like you can’t, duh, it’s so obvious that this was going to happen, but it’s only obvious after the fact. Andrew: Certainly. Jerry: weren’t looking at it beforehand and saying, Oh, we’re just going to accept the risk. They just, it wasn’t in their mind. And so, that part I find less, obviously it is the thing that caused it, but what I find most problematic is the fact that they hadn’t adopted what I would call the industry standard practice of the tiered rollouts. Andrew: I’m sure that was an intentional decision. I obviously don’t know for sure. I have no idea about decisions that go on a cross track. I’ve never worked there. However, those in their mind, I would imagine a value in not doing, in Jerry: sure, Andrew: So dig, if you will, the picture, they are using these sensors, not just to stop things, but also together these sensors are reporting back to CrowdStrike all the time about potentially malicious or confirm malicious activity. And then they use that data to shotgun this out. And this is basically a reject expression. They were trying to get out to the world about something they thought was malicious. they’re. Go to market strategy is to stop breaches specifically around ransomware. So their business model is really geared towards a ransomware. That’s in my opinion, they’re, I’m not speaking for them. It’s just my read of it. And they care greatly about stopping ransomware and windows environments. So they know that ransomware spreads quickly and rapidly, and I’m sure. In their mind that the value of getting these updates out as quickly as possible to as many sensors as possible a valuable thing to do. So let’s say they know about a new attack type and they pick it up at one customer and they start staging this and they stage it to 10 percent of the customers and 30 percent of the customers and then 50 percent of the customers. Meanwhile, you’re at a customer who hasn’t gotten staged yet and you get hit by it. Are you happy with their staged deployment at that point? No. End. So I’m just playing devil’s advocate a little bit on, it probably was an intentional decision to not do staged rollouts. It’s not like they just were unaware of that concept. I think they felt that there was value in updating as rapidly as they possibly could to as many sensors as they could. Jerry: Likely, I would say that is definitely the proof is in the pudding, right? That is exactly what they were doing. Andrew: A, in hindsight, it’s a bad decision, but it might not have been a bad decision at the time. Inputs as to why they made that call, I guess is what I’m saying. Jerry: I’m sure there is. And by the way, I’m not advocating for, something like what with Microsoft where the rollout happens over the course of days or weeks, I’m more talking about. Hours that, potentially in my mind, at least is a happy medium where you could conceivably have canaries that go an hour before the rest of the world, right? So yeah, you miss an hour. And I’m sure that potentially exposes some number of customers and maybe this is such a rare thing that one hour difference is something that their customers feel important, to accept the risk on. I don’t know. it’s a fair question. Andrew: They are saying in their root cause analysis that one of the things they will do as part of the mitigation is provide customers more control over the deployment of rapid release content updates. So to me that means maybe choose when and where rapid release content updates are deployed is what they’re saying. Like they want to go down that path of, hey, if you want to be as safe as possible from ignoring operational risk, or I should say, minimizing your concern about operational risk, deploy as quick as you can. If you are concerned about operational risk, here’s these tools, right? But the trade off you might be More exposed to malware risk. Jerry: Correct. And, from a customer perspective, it does give you the opportunity to do your own soak testing. But I think you probably also, again, depending on your risk tolerance and size of your environment and exposure and whatnot, would do well to do your own sort of testing. Before you push it out far and wide. But again, that takes resources. It takes time. It takes people, it takes labor. And if it drops on,after work, right before a long weekend, are you going to, you’re going to have the appetite to do that? Andrew: and how consistent is your fleet? Are you on the same patch level? Are you in the same build? Are you on the same hardware? There’s a whole lot of things that are coming to play. And if you’re only testing on a couple of examples, Jerry: Yeah. Andrew: yeah, I don’t disagree. I know I’m being a little contrarian on this. It’s more a matter of, again, people are saying things like, if you only just, and I’m like think that through a little, and you’re going to find out that there’s still holes in your planning and that you may have to accept some risk for the benefit of the tool. And have a way to solve that for you. There’s no perfect answer. It’s you’ve got to figure out that trade off for your own organization. Jerry: Yeah, I think that’s fair. The other, again, I don’t know a whole lot about their release pipeline process, but it, I find it fascinating that they clearly don’t as part of their release process, verify that it doesn’t blue screen a system like there, there’s a very different distinction between, this. channel file update causes CrowdStrike to crash or for it to not detect things and then require a subsequent update. to fix it versus the agent is now creating an unbootable situation. And it seems like there’s a very utilitarian, very specific set of tests. And I think deterministic tests that they could put in line in their release pipeline when you deploy it onto. X number of different windows systems. Does it crash? And if it doesn’t, then you release it with the assumption that if it’s not a catastrophic problem, any other problem could be fixed with an update. Andrew: Yeah. Or if it’s not crashing on the largest deployed population set example, any crashes you have will be limited to relative small percentage of systems. Jerry: All right. So anyway, it’s an interesting read. Um, there’s obviously I think it’s 12 or 13 pages long, a lot more technical details about the actual nature of the crash and whatnot. So I invite you to read it if you’re interested in that sort of thing. Moving on to the next story, which is related, this one I’ll take a step back and say for those of you who aren’t aware, there’s a bit of a war of words between Delta Airlines CrowdStrike and Microsoft. So Delta CEO, Ed Bastian is very famously now said that this outage has cost Delta Airlines about half a billion us dollars in losses and that he feels compelled on behalf of his customers and shareholders and employees to try to recoup some of those losses. And so he’s sign…

    Full show notes at the publisher

    Defensive Security Podcast Episode 274 Aug 02, 2024
    Show notes

    https://www.bleepingcomputer.com/news/security/over-3-000-github-accounts-used-by-malware-distribution-service/https://blog.knowbe4.com/how-a-north-korean-fake-it-worker-tried-to-infiltrate-ushttps://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/https://www.darkreading.com/cybersecurity-operations/crowdstrike-outage-losses-estimated-staggering-54b https://cdn.prod.website-files.com/64b69422439318309c9f1e44/66a24d5478783782964c1f6f_CrowdStrikes%20Impact%20on%20the%20Fortune%20500_%202024%20_Parametrix%20Analysis.pdfhttps://www.darkreading.com/vulnerabilities-threats/unexpected-lessons-learned-from-the-crowdstrike-event Summary: Episode 274: Malware on GitHub, North Korean Developer Scam & Secure Boot Failures In this episode of the Defensive Security Podcast, hosts Jerry Bell and Andrew Kalat discuss several notable security stories and issues. They start with a malware distribution service that leverages compromised GitHub accounts and WordPress sites. They then cover a security warning from KnowBe4 about hiring a supposed North Korean agent as a senior developer. They dive into the significance of two separate vulnerable firmware signing keys affecting over 500 hardware models. Lastly, they explore the massive financial impact of the recent CrowdStrike outage, with losses estimated at $5.4 billion. Throughout the episode, the hosts provide insights, potential solutions, and share personal experiences related to these cybersecurity challenges. 00:00 Introduction and Casual Banter 00:30 Funemployment and Retirement Reflections 01:54 Disclaimer and First Story Introduction 02:17 Malware Distribution via GitHub 04:24 WordPress Security Issues 8:09 North Korean Developer Incident 14:36 Lessons Learned and Recommendations 23:27 Secure Boot Vulnerabilities 29:19 Cloud Providers and Firmware Security 30:47 The Epidemic of Leaked Keys on GitHub 33:35 Challenges in Development and Security Practices 35:36 CrowdStrike Outage and Its Financial Impact 39:16 Legal and Technical Implications of the Outage 57:33 Concluding Thoughts and Future Plans Transcript: Episode 274 274=== jerry: [00:00:00] Today is Wednesday, July 31st, 2024. And this is episode 274 of the defensive security podcast. My name is Jerry Bell and joining me tonight as always is Mr. Andrew Kalat. Andrew: Good evening, Jerry. How are you? My good sir. jerry: So good. It hurts. How are you? Andrew: I’m doing good. it’s Wednesday, which is halfway through the week. So I can’t complain too much. jerry: It’s just another day to me though. Andrew: I, how are you enjoying your funemployment? jerry: It is awesome. funny story, when my dad retired, he told me something sad. He said, one of the things that you don’t realize is that the weekend starts losing its appeal, Andrew: Because every day is the weekend. jerry: because it’s just another day and, holidays are just another day. jerry: There’s not really something to look forward to when you’re working. You typically look forward to the weekend. It’s just another day. I am finding that to be true. I’m going to be [00:01:00] spending some time coming up down at the beach, which will be a whole different experience, not having to work and actually be at the beach, which will be cool. Andrew: So you don’t have to wrap your laptop in plastic when you take it surfing with you anymore. jerry: That is very true. No more conference calls while out on the boogie board. Andrew: I will say the random appearance of sharks behind you on your zoom sessions will be missed. Andrew: Of course, we’ll have to find a way to bring that back. I live in jealousy of your funemployment. I will just say that. But not that you didn’t work your ass off and earned it, right? This is 25 years of blood, sweat, and tears given to this industry to get you to this point. So you earned it jerry: I’m going to have to be responsible again at some point, but I am having fun in the meantime. Andrew: as well. You should jerry: before we get into the stories for today I just want to remind everybody that the thoughts and [00:02:00] opinions we express on the show are ours and do not represent anybody else, including employers cats, farm animals, spouses children, et cetera, et cetera. Andrew: there’s that one Lama in Belarus though, that agrees 100 percent with what we have to say. jerry: Very true. Getting into the stories, we have one from bleeping computer and this one is titled over 3000 GitHub accounts used by malware distribution service. I thought this one was particularly interesting and notable. There is a malware distribution as a service that leverages both, let’s call them fake or contrived GitHub accounts, as well as compromised WordPress sites. jerry: And the, what they’re effectively leveraging is the brand reputation of GitHub. And so they have a fairly complicated setup of driving. [00:03:00] Victims through watering hole attacks and SEO type lures to get people to these sites and they have different templates that entice people to download these encrypted zip files that are hosted on GitHub. jerry: And what they’re taking advantage of is two things. Number one, people generally think that GitHub is a reputable place. To find files. And so you’re. Level of concern goes down when you download something that you think is coming from a reputable place. And I think the other, perhaps more problematic angle from my perspective, at least is GitHub is something that most companies allow access to. jerry: it is something that, by design, many companies, not all, encourage their employees to interact with GitHub. And so you really can’t block it. [00:04:00] And or at least it’s more difficult to block it. And because it’s one kind of amorphous. Thing you, you don’t have the ability to granularly say you can go to this aspect or this part of GitHub and not this other part of GitHub. Andrew: Yeah. I agree at all points. It’s absolutely leveraging and abusing the reputation of GitHub to get this malware out there and it’s effective. Using WordPress doesn’t surprise me, just about every day I see some other plugin has a massive vulnerability. So I’m not blaming WordPress, I’m blaming their plugin ecosystem as being highly toxic in the original sense. jerry: I know that WordPress has a lot of detractors, especially in the security community, but It’s over 50 percent of the entire internet. Websites runs WordPress, right? That is pretty impressive. Andrew: There’s something to be said for The amount of coverage or the amount of instances out [00:05:00] there equals how many bad guys are poking at you. So if you’re not widely deployed, you’re probably also not getting widely tested. So there is absolutely some of that aspect of, Hey, if you’re a well used tool, you’re likely to have more security problems. Andrew: So statistically that makes sense, but it’s not a bad tool. Don’t get me wrong. It’s a super useful tool. It’s just amazing how often I see advisories about. Really nasty exploits on various plugins for WordPress. jerry: Yeah. the barrier to entry for plugin development is incredibly low and there are just an absolute ton of them. There’s many thousands. So it isn’t surprising. Andrew: People who are running WordPress sites are not super technical admins. They’re usually marketing folks or content generation folks. So, when they’re looking for, Hey, I need something that makes a pretty picture, do something like this in WordPress, they probably aren’t looking at with the same level of technical rigor you and I might. jerry: I will tell you in in prior [00:06:00] jobs where we had customers hosted on our infrastructure, this was a big problem because, customers would walk away, right? There’s it’s so easy to set up. It’s so easy to set up a WordPress instance, which is by the way, like that’s part of its value proposition, but it’s also part of, I think it’s I think it contributes to the low ongoing attachment or ongoing care and feeding of it. jerry: It’s so easy to set up and then just walk away from and it’s a big problem. I think that the WordPress team themselves have done a pretty good job of mitigating the issues to the extent they can. Most of the, most of it auto updates these days. Andrew: Yeah. jerry: More to go, right? Andrew: what’s interesting to me is the way you describe that often sounds like the same problems we have with SaaS and cloud in general. It’s so easy to set up and walk away from and not manage it well. That we lead to all sorts of similar problems. This story is more about [00:07:00] GitHub and I agree with all your points. Andrew: I just went down my WordPress rant rabbit hole, but yeah, I get it. GitHub is an interesting one. And I don’t have a lot of good solves for that one. jerry: No, it’s It is not a, it’s not an easily solvable issue. I think this is one of those one of those cases where education will help certainly, proper end point detection, I should say end point protection. Will help being able to identify that somebody has downloaded and run something that is potentially malicious on their device. jerry: But beyond that, unless you’re willing to take that leap and not not permit people to access GitHub, it’s hard to defend against. So by the way, if the industry as a whole decided, Hey, this is too risky, the bad guys would just move somewhere else. Andrew: Yeah, absolutely. They’re leveraging whatever has a good solid reputation that has a sort of functionality. It’s not GitHub’s fault. And I think you’re right. If it [00:08:00] wasn’t GitHub, it’d be somebody else that serves the same purpose. function. It’s their victim of their own success in that sense. jerry: 100%. So the the next story we have comes from the know b4 blog. Know B4 is. I think a fairly well known security education company. They are not without controversy in my my experience. I think they’re the ones that offer the the ransomware guarantee or warranty, if I’m not mistaken. jerry: But this story is not about that. The story is about how they hired a North Korean, allegedly as a senior developer. So they they did what I would describe as a public service announcement describing how they had been duped by purportedly a North Korean, government agent who was trying to infiltrate their [00:09:00] company. jerry: It’s a little unclear exactly what their mission was. But the story basically is that a this company was trying to hire a senior developer. They went through the interview process. They selected what they believed was the best candidate. They performed all their normal interviews, background checks and whatnot. jerry: Then they made an offer. The offer was accepted. They dispatched a laptop to this person. And then suddenly that. Laptop was observed attempting to install malware. And that is what really set off the series of events that alerted them to what was going on. So in the end analysis, the the person they hired was again, somebody allegedly from North Korea. jerry: They had used a stolen identity of a legitimate person in the U S. They [00:10:00] altered a photo, and it’s a little unclear to me exactly in what ways they show before and after of how the photo was altered, but it’s not entirely clear to me if that was the photo of the identity, the person whose identity they stole or somebody else that aspect isn’t clear to me, the laptop was sent to what they call an IT A laptop shipping mill, I think is what they call it. jerry: Basically. It’s a place that will set these laptops up either on a network to allow access, low remote access from overseas, or they will send them out I think in this instance, it was allowing remote access in. So the the bad actor was apparently in North Korea, VPNing into the laptop and then connecting from the laptop, which I guess was located in California and accessing the company’s networks. jerry: When KnowBe4’s security [00:11:00] team identified that there was malicious activity going on. They tried to contact this. Very new employee, and the new employee said, I can’t talk right now. I, I’m trying to, I’m trying to debug something, but I’ve got a personal or family issue going on. And so over the course of a couple of hours, the security team decided to isolate the laptop, and then things started to fall apart, and they realized exactly what happened. jerry: It’s not entirely clear to me, by the way, from reading the article exactly how they stitched together that this person was a North Korean agent. That. That is not part of the at least the stories that I have read. But it’s interesting because this resonated with me personally. I worked for a large multinational company for a very long time. Andrew: And you’re a North Korean agent. jerry: And I yes, that’s, that is true. Sorry, everybody had to find out that way. And anyhow, Andrew: Didn’t they all know? Is that breaking news? jerry: [00:12:00] I think it might be for some, Andrew: Oh you’re a very nice North Korean agent. jerry: I try to be Andrew: Yeah. Andrew: Anyway. Yeah. It’s a crazy story. I, Sent this to some of my friends in HR and they’re like, what this happens? Yeah, it happens. So that tells me there’s some awareness interestingly according to The timeline that no before published their sock was on it. They Detected the users activity Suspicious activity began at 9 55 p. Andrew: m. And by 10 20 p. m 25 minutes later. They’re like, nope shut me down. jerry: yeah. But by all accounts, they did a great job. Andrew: Yeah, and the SOC person was suspicious enough. And also the North Korean angle. It looks like, before we reached out to the FBI in Mandiant. And so it’s probably coming from one of those two who are saying, that this was a North Korean thing. Andrew: Although from the story as well, it looks like this may not necessarily be malicious in terms of state sponsored. malicious [00:13:00] activity so much as it might’ve been just a way to earn legitimate money sent back to North Korea to fund whatever, as they say, at least according to what they quote in their blog post, the FBI was saying, sometimes this is just straight up people working in sanctioned countries, getting around the sanctions and doing legitimate work. Andrew: Or, but this guy immediately started, Loading malware, which is not great. jerry: Yeah. And realistically, if he hadn’t started loading malware, who, I don’t know if it would have been very easy to detect that this was going on. Andrew: sure. So a lot of lessons learned though. A lot of takeaways. jerry: Yeah. I, anyway I was saying that this is, this, It hit home for me because I have had similar, not with, foreign agents, North Korean agents or age, people in embargoed countries, but I have had experience with people falsifying who they [00:14:00] are when they get hired and it’s difficult to do, especially in these remote working. jerry: Environments. I’m not saying that it can’t also be done in a face to face type environment, but I think that it is. Easier to pull off in, in today’s remote working environment. I’m still, by the way, a big proponent of remote working. Don’t misunderstand in any way. But I do understand this one. jerry: I I can definitely sympathize someday. I will tell some funny stories about experiences I’ve. I’ve had, so there were, they did call out some tips and recommendations as a result of this. Again, this was intended to be a public service announcement. So they wanted to describe the, the event and what they learned from it. jerry: So their tips to prevent were scan your remote devices and make sure no one remotes into these. So I think that was [00:15:00] really, addressing how the person was connecting remotely into the laptop. But that’s how, by the way, that’s not a even if you were to not permit VNC or remote desktop or things like that, it’s not a guarantee because there are plenty of cheap ass network KVMs, right? jerry: So just be aware of that. Next one is better…

    Full show notes at the publisher

    Defensive Security Podcast Episode 273 Jul 24, 2024
    Show notes

    The Joe Sullivan Verdict – Unfair? – Which Part? (cybertheory.io) Fujitsu Details Non-Ransomware Cyberattack (webpronews.com) 5 Key Questions CISOs Must Ask Themselves About Their Cybersecurity Strategy (thehackernews.com) Sizable Chunk of SEC Charges Vs. SolarWinds Dismissed (darkreading.com) CrowdStrike CEO apologizes for crashing IT systems around the world, details fix | CSO Online Summary: Cybersecurity Updates: Uber’s Legal Trouble, SolarWinds SEC Outcome, and CrowdStrike Outage In Episode 273 of the Defensive Security Podcast, Jerry Bell and Andrew Kalat discuss recent quiet weeks in cybersecurity and correct the record on Uber’s CISO conviction. They delve into essential questions CISOs should consider about their cybersecurity strategies, including budget justification and risk reporting. The episode highlights the significant impact of CrowdStrike’s recent updates causing massive system crashes and explores the court’s decision to dismiss several SEC charges against SolarWinds. The hosts provide insights into navigating cybersecurity complexities and emphasize the importance of effective communication and collaboration within organizations. 00:00 Introduction and Banter01:52 Correction on Uber’s CISO Conviction04:07 Recommendations for CISOs09:28 Fujitsu’s Non-Ransomware Cyber Attack12:13 Key Questions for CISOs32:47 Corporate Puffery and SEC Charges33:15 Internal vs External Communications33:52 SolarWinds Security Assessment36:36 CrowdStrike CEO Apologizes37:16 Global IT Systems Crash37:57 CrowdStrike’s Kernel-Level Issues40:55 Industry Reactions and Lessons42:58 Balancing Security and Risk49:26 CrowdStrike’s Future and Market Impact 01:03:46 Conclusion and Final Thoughts Transcript: defensive_security_podcast_episode_273 === jerry: [00:00:00] All right, here we go. Today is Sunday, July 21st, 2024, and this is episode 273 of the Defensive Security Podcast. My name is Jerry Bell, and joining me tonight as always is Mr. Andrew Kalat. Andy: Good evening, Jerry. I’m not sure why we’re bothering to do a show. Nothing’s happened in the past couple of weeks. Andy: It’s been really quiet. jerry: Last week was very quiet. Andy: Yeah, sometimes You just need a couple quiet weeks. jerry: Yeah. Yeah, nothing going on so before we get into the stories a reminder that the thoughts and opinions We express on this podcast do not represent andrew’s employers Andy: Or your potential future employers jerry: or my potential future employers Andy: as you’re currently quote enjoying more time with family end quote jerry: Yes, which by the way Is highly recommended if you can do it. Andy: You’re big thumbs up of being an unemployed bum. jerry: It’s been amazing. Absolutely [00:01:00] amazing. I I forgot what living was like. jerry: I’ll say it that way. Andy: Having watched your career from next door ish, not a far, but not too close. I think you earned it. I think you absolutely earned some downtime. My friend, you’ve worked your ass off. jerry: Thank you. Thank you. It’s been fun. Andy: And I’ve seen your many floral picks. I don’t, I’m not saying that you’re an orchid hoarder, but some of us are concerned. jerry: I actually think that may be a fair characterization. I’m not aware of any 12 step programs for for this disorder here. Andy: There’s a TV show called hoarders where they go into people’s houses who are hoarders and try to help them. I look forward to your episode. jerry: I yes, I won’t say anymore. Won’t say anymore. So before we get into the new stories, I did want to correct the record on something we talked about on the last episode [00:02:00] regarding. Uber’s CISO that had been criminally convicted. Richard Bejtlich on infosec. exchange actually pointed out to us that it was not failure to report the breach that was the problem. It was a few other issues, which is what Mr. Sullivan had actually been convicted of. So I’m going to stick a story into the show notes. That has a very very extensive write up about the issues and that is from cybertheory. io. And in essence, I would distill it down as saying again, I guess he was convicted so it’s not alleged. He was convicted of obstruction of an official government investigation. He was convicted of obstructing the ongoing FTC investigation about the 2013 slash 2014 breach, [00:03:00] which had been disclosed previously. jerry: The FTC was rooting through their business and were asking questions and unfortunately apparently Mr. Sullivan did not provide the information related to this breach in response to open questions. And then furthermore, he was he was convicted of what I’ll summarize as concealment. jerry: He was concealing the fact that there was a felony. And the felony was not something that he had done. The felony was that Uber had been hacked by someone and was being extorted. But because, he had been asked directly, Hey, have you had any, any issues like this? jerry: And he said, no, that becomes a concealment, an additional concealment charge. And so the jury convicted him on both of those charges, not on failure to disclose a breach. Andy: Yeah, it’s we went down the wrong path on that one. We were a little, we put out some bad info. [00:04:00] We were wrong. jerry: So I’m correcting the record and I certainly appreciate Richard for for getting us back on the right track there. jerry: This article, by the way, does have a couple of interesting recommendations that I’ll just throw out there. One of them is hopefully these are fairly obvious. Do not actively conceal information about security incidents or ransomware payments, even if you’re directed to do so by your management. Andy: Yeah. I think, let’s put it out for a second. If you’re in that situation, what do you do? Resign? jerry: Yes. Or do you, Andy: yeah, I think that’s, jerry: I mean you either resign or you have to become a whistleblower. Andy: Yeah, that’s true. Your career has probably ended there at that company either way. Most likely. But it’s better than going to jail. jerry: It’s a lot better than going to jail. I think what I saw is he Sullivan is up for four to eight years in prison, depending on how he’s sentenced. Andy: Feds don’t like it when you lie to them. They really don’t like it. jerry: No, they don’t. Next recommendation is if you’re, if your company’s under investigation, get help and potentially [00:05:00] that means getting your own personal legal representation to help you understand what reporting obligations you may have for any open information requests. And I say that because. In this instance, Sullivan had confirmed with the CEO of Uber at the time about what they were going to disclose and not disclose and the CEO signed off on it. And he also went to the chief privacy lawyer, who by the way, was the person who was managing the FTC investigation and the chief privacy lawyer also signed off on it. Like the joke goes, the HR is not, it’s not your friend. Your legal team may also not be your friend. At some point if you’re in a legally precarious position, you may need your own council, which is crappy. Andy: That is crazy. How much is that going to cost? And wow, that’s it. I don’t [00:06:00] one more reason to think long and hard before accepting a role as CISO at a public company. jerry: Yeah, this, by the way I’m skipping over all sorts of good stuff in this story. So I invite everybody to read it. And it’s a pretty long read. jerry: It, it talks about the differences between the Directors of companies and officers of companies and the different obligations and duties they have related to shareholders and customers and employees and whatnot. And what was very interesting. The point they were making is that CISOs don’t have that kind of a responsibility, right? jerry: They don’t, they’re not corporate officers in the same way. And so what they, what, when you read the article, and I apologize for not sending it to you. I just realized, when you read the article it was very clear that there The author here was pointing out that the government and I suspect with, at the behest of Uber, was really specifically [00:07:00] going after Sullivan, right? jerry: Because in exchange for testimony, people got immunity in order to testify against Sullivan. And that kind of went all up and down, including You know, it’s some of the lawyers. So I, by the way, I think he clearly had some bad judgment here. But, also, he wasn’t the only one. This was a a family affair, but he’s the one who’s really taken taken the beating. Next recommendation was paying a ransom in return for a promise to delete copies of data, not disclosed data does not relieve your responsibility to report the issue in many global laws and regulations. jerry: So just because you’ve gotten an assurance that the, after you’ve paid a ransom that the data has been destroyed, you still in, in almost all cases are going to have a responsibility to report. And, one of the things the the author here says is you really should let everybody know, there’s vehicles to [00:08:00] inform at least in the U S CISA and the FBI, and I’m sure there’s similar agencies in different countries. To help insulate yourself do not alter data or logs to conceal a breach or other crime. That seems pretty self evident, but I think the implication is that. jerry: That’s what happened here. And then also lastly, do not create documents that, contain false information. Andy: Shocking. jerry: Yes. So again, not, nothing in there that is like earth shattering but it’s a good reminder, Andy: yeah. And I, I don’t know if but our good friend Bob actually got out of the South American prison he’s been in for a while, and I heard from him, and he’s doing well, he’s got three new tattoos and lost two fingers, but otherwise he’s doing well. He was telling me that he once worked for a CISO that actually fabricated evidence for an internal auditor. Andy: And thought it was a fun [00:09:00] game Andy: and how he had a tough time knowing how to handle that. jerry: And the ethics of how to disclose that, right? Andy: Especially because as he described it, it was a very powerful CISO who had a reputation for retaliatory behavior to those who did not bow before him. Damn. So jerry: yeah, Bob has all the best stories. Andy: He does. He does. I look forward to hearing more about his South American prison stint. jerry: All right. Our next story today comes from web pro news. com. And the title here is Fujitsu details, non ransomware cyber attack. It feels like it’s been so long since we’ve talked about something that wasn’t ransomware. Andy: I feel like these bad guys just, lost a good ransomware opportunity. jerry: Clearly they did. So there’s not a huge amount of details. But basically Fujitsu was the victim of some sort of [00:10:00] data exfiltrating worm that crawled through their network. They haven’t published any details about who or how, or, why, what was taken, but was, what was most interesting to me is that, the industry right now is very taken by ransomware or, more pedestrian hacks of things to mine cryptocurrency or send spam or, do those sorts of things. jerry: It’s been a while since I’ve. I can think of the last time we actually had a, like a a destructive or, something whose job was not. To be immediately obvious that it’s in your environment. Andy: Yeah. If I had to, again, the details are very sketchy, but if I had to guess, maybe this was some sort of corporate espionage or some sort of, it appears the way they described it, which again, the details are sparse. Andy: It was low and slow and very quiet [00:11:00] trying to spread throughout their environment. It didn’t get very far. They said, what, 49 systems? 49. And they had a lot of interesting, you caveats of it didn’t get to our cloud this and it didn’t do that. So there’s a lot of things that didn’t do. Andy: They didn’t tell us much about what I did do. But if I had to guess, maybe some sort of corporate espionage. Yeah, maybe that’s, or just random script kitties being like, you can never always attribute motivation. So I’ll say jerry: this way, intellectual property theft, the motivations for that, I guess this is an exercise left to the reader, but. jerry: They did say that data was exfiltrated successfully. They didn’t say what data but I, my guess is, they were after some sort of intellectual property theft. The reason for bringing this up is not that this has a whole lot of actionable information, but more that, that there are other threats out there still, it’s not all, it’s not all ransomware and web shells and that sort of stuff.[00:12:00] Andy: Indeed, but to be fair that is majority of it. Protect your cybers. You know what helps? A solid EDR. It’s a little foreshadowing for a future story. jerry: We’ll get there. We’ll get there. All right. The next story comes from thehackernews. com and the title here is five key questions CISOs must ask themselves about their cybersecurity strategy. Andy: Apparently, we need to add a sixth one, which is, Am I going to go to jail? jerry: So the key questions here, number one, how do I justify my cyber security? Actually, you know what, I’m going to back up for a second, because there were a couple of other salient data points in here. And the first one was they pointed out that only 5 percent of CISOs report directly to the CEO , then two thirds of CISOs are two or more levels below the CEO in the reporting chain. And that, those two facts indicate a potential lack of high level influence to [00:13:00] use their words. I will tell you the placement of the CISO in an organization isn’t necessarily an indicator of how much power they have. Somebody who reports to the CEO is going to be more influential for sure, but there are lots of different organizational designs especially when you go into larger companies. Andy: Sure. I would say also if they’re highly regulated, that CISO has a lot of inherent authority because of the regulations that are being enforced upon that organization. So by external third parties. jerry: The Ponemon or Pokemon Institute found that only 37 percent of organizations think they effectively utilize their CISOs expertise. jerry: I kind of wonder who are they asking that? Are they asking the CISOs or are they asking, I, anyway I am curious about the [00:14:00] methodology behind that study. It doesn’t necessarily surprise me. Just moving somebody up in a different, into a different place in the organization doesn’t necessarily mean that they’re going to more fully use the talents of or expertise of a CISO. Andy: Yeah. If it’s anything in most organizations, it’s. They delegate to that CISO, not like what the assumption, is that the boards of the executive teams would be asking deep cyber questions of the CISO, which is an odd expectation. jerry: It is an odd expectation. And similar related to what you’re saying, gartner finds that there are only 10 percent of boards. that have a dedicated cybersecurity committee overseen by a board member. Andy: The way I would look at it, both of those stats is more, how much influence does CISO have on the company operating in a less risky or more risky methodology, right? Andy: It’s not about leveraging their expertise. It’s about how influential are they to [00:15:00] guide the company away from risk and what those trade offs are. jerry: It also comes down to what the company’s value. This is a financial risk management. And Andy: the flip side is I think a lot of executives think of CISOs as constantly calling for the skies falling to get better budgets and build their empire and more people. And as this is a black hole of money we’re throwing money into that we can’t, which this article goes into, we can’t justify it. Andy: We can’t prove the ROI on. jerry: Yes, exactly. So the the key questions to ask yourself is number one, how do I justify my cybersecurity budget? And that is a I think that’s a perennial challenge that anybody in security leade…

    Full show notes at the publisher

    Defensive Security Podcast Episode 272 Jul 11, 2024
    Show notes

    Links: https://www.darkreading.com/cybersecurity-operations/a-cisos-guide-to-avoiding-jail-after-a-breach https://www.csoonline.com/article/2512955/us-supreme-court-ruling-will-likely-cause-cyber-regulation-chaos.html/ https://sansec.io/research/polyfill-supply-chain-attack https://www.securityweek.com/over-380k-hosts-still-referencing-malicious-polyfill-domain-censys/ https://www.tenable.com/blog/how-the-regresshion-vulnerability-could-impact-your-cloud-environment Transcript=== [00:00:00] jerry: All right. Here we go. Today is Sunday, July 7th, 2024, and this is episode 272 of the defensive security podcast. My name is Jerry Bell and joining me tonight as always is Mr. Andrew Kalat. Andrew: Good evening, Jerry. This is a newly reestablished record twice in a week or jerry: twice in a week. I can’t believe it. Andrew: I know. Awesome. Yeah. You just had to, quit that crappy job of yours that provided income for your family and pets and you know everything else but now that you’re unemployed house But now that you’re an unemployed bum. jerry: Yeah, I can podcast all I want 24 7 I think i’m gonna become an influencer like i’m gonna just be live all the time now Andrew: you could I really I look forward to you asking me to subscribe and hit that notify button. jerry: That’s right. Hit that subscribe button Andrew: Like leave a rating and a comment jerry: like and subscribe All [00:01:00] right getting with the program we’re we’re getting back into our normal rhythm. As per normal, we’ve got a couple of stories to talk about. The first one comes from Dark Rating and the title is, A CISO’s Guide to Avoiding Jail After a Breach. Andrew: Before we get there. Andrew: I want to throw out the disclaimer that thoughts and opinions do not reflect any of our employers, past, present, or future. jerry: That’s a great point. Or, my cats. Andrew: Unlike you, I have to worry about getting fired. jerry: I still have a boss. She can fire me. Andrew: That’s called divorce, sir. But true. jerry: Yeah. Andrew: Anyway, back to your story. jerry: Anyway, yeah. CISO’s Guide to Avoiding Jail After a Breach. So this is this is following on a upcoming talk at, I think it’s Black Hat talking about how CISOs can try to insulate themselves from the [00:02:00] potential legal harms or legal perils that can arise as a result of their jobs. It’ll be interesting to see what’s actually in that talk, because the article itself, in my estimation, despite what the title says, doesn’t actually give you a lot of actionable information on, How to avoid jail. They do they do a quote Mr. Sullivan, who was the CISO for Uber. jerry: And they give a little bit of background and how it’s interesting that he he is, now a convicted felon. Although I think that’s still working its way through the the appeals process. Though he previously was appointed to a cybersecurity board by president Obama. jerry: And before that he was a federal prosecutor. And in fact, as the article points out, he was one of the process, he was the prosecutor who prosecuted the first DMCA case, which I thought was quite interesting. You didn’t know that about him, but what’s interesting is this article at least is based a lot on [00:03:00] interviews with him and including recommendations on things like communicating with your your board and your executive leadership team. But I’m assuming that He had done that at Uber. Andrew: Yeah, this is such a tough one for me, and it makes, I think a lot of good people make references in the article. I want to shy away from being a CISO if there’s this sort of potential personal liability. When, there’s a lot of factors that come into play about why a company might be breached that aren’t always within the control of the CISO, whether it be budget, whether it be focus, whether it be company priorities, and you have an active adversary who is looking for any possible way to get into your environment. Andrew: So what becomes the benchmark of what constitutes a breach? Negligence up to the point of going to jail is the one that [00:04:00] I’ve struggled with so much and I think those who haven’t really worked in the field much can very easily just point to mistakes that are made, but they don’t necessarily understand the complexity of what goes in to that chain of events and chain of decisions that led to that situation. Andrew: Every job I’ve been in where we were making serious decisions about cybersecurity was a budgetary trade off and a priority trade off and a existential threat to the company if we don’t do X, Y, and Z. Coming from five or six different organizations at the same time coming up to that CFO or the CEO and they have to make hard calls about where that those resources go and those priorities go to keep people employed. And you pair that with a very hostile, third party intentionally trying to breach you it’s a tough situation and I don’t think any of us knows what the rules look like. At this point to keep yourself out of [00:05:00] trouble. You’ve been in this position, not in the, going to jail part, but that this threat was much more meaningful to you in your last role than it is to me. jerry: It is very uncomfortable. I’ll tell you when when the Uber CISO got got charged and the CISO of SolarWinds got charged, that’s It’s an uncomfortable feeling an exposed feeling. In criminal law, there’s this concept of strict liability. jerry: And strict liability basically means, it means the thing happened. And because the thing happened and you are responsible for the thing, it doesn’t matter that, there, there’s no mitigating factors. Your your state of mind, your motivations, , none of that matters in a strict liability case. jerry: And to some extent, it feels like that in this instance, I don’t think it really is, although, when you’re a CISO sometimes that thought can cross your mind. Now in the article, they actually point out that, though the CISO is the [00:06:00] lightning rod when things go wrong. It is not just the CISO that is responsible for, what went wrong. jerry: As they describe it, it takes a community and the results of that community are, as we’ve now seen or is alleged is, being pinned on a particular individual. And I, I think and I know from having read the Uber case I’ve not. I’m not so familiar with the SolarWinds case although I’m obviously familiar with what happened in SolarWinds case, with Uber, it was a situation where they they had a a, basically a data breach and the allegation was that the ad, the adversary was trying to hold it for ransom and they They successfully negotiated having that, at least this is my understanding of how the case went they negotiated a payment through [00:07:00] the bug bounty program to the adversaries, perhaps, maybe adversaries isn’t the right word allegedly deleted the data and because of that, they didn’t report the breach. jerry: And so it was really, the failure to report that breach which the government was coming after him for, basically being deceptive to investors. And it’s not necessarily that he was malicious or what have you, but no, basically my layman’s rate is he was defrauding jerry: investors by withholding information about a breach that he was obligated to report. So that’s a tough situation. And what concerns me is that this is somebody who was a federal prosecutor so I had I had plenty of competent legal counsel surrounding me. jerry: And that was a good thing. It felt good. And I’m quite certain he did too, further he himself [00:08:00] was a prosecutor. And so I have a hard time accepting, and maybe it’s just very naive of me. I’d have a hard time accepting that, He was actually trying to misrepresent things or hide things. jerry: I guess that’s where I’m at on this one. It feels bad and the article points out that, because of this, one of the, one of the whispers as they describe it in the industry is that it’s forcing people who are qualified for the role and understand the perils that they face to shy away from taking that role. jerry: And that then leads to people who are maybe not as qualified taking the role and then obviously not doing as good of a job. And therefore actually, the net effect is a weaker security posture. Andrew: Yeah. I think one thing that you can, if we try to get some advice out of this or try to give some advice out of this, and the one thing they mentioned in For lack of a better [00:09:00] term, tie some other people in the organization to the same decision, right? Andrew: Make sure that your board is aware and your executives are aware and that you’re not the only one holding the risk bag at the end of the day that, if you have to own the risk yourself, then you need to have formal control. Now, in this case, we’re talking about. In theory, he got in trouble because he didn’t notify the SEC and it was a public company, it was material breach. Andrew: And, so stockholders weren’t informed more so than he was negligent in his cybersecurity duties in terms of technical controls and audits and that sort of thing. However, that feels the way things are going. We hear more and more calls for hold companies accountable directly and legally with risk of jail for breaches. Andrew: And this, there’s a lot of nuance here that’s not exactly what happened here. But I find that very troubling and [00:10:00] obviously, I have a bias because I’m in the industry and I would be at risk of that potentially. But I just don’t think it’s that simple. There’s no CISO that has that much control over an environment that they should be solely responsible for taking the fall if a breach were to happen, although that does happen all the time, but it’s one thing to lose your job is another thing to go to jail. jerry: Yeah. And I think that the author here points out that at least as Mr. Sullivan describes it, he feels like he was put forward by Uber as a sacrificial lamb. I guess what I don’t really understand was how much better would it have been for him if, He had done a more effective job at, creating what I’ll loosely call co conspirators within the company. jerry: I think what they’re trying to say is that you as a CISO should go to the board, to your CEO, to whoever, and articulate the risk, [00:11:00] not with the intention of them again, becoming co conspirators, but of them saying, gosh, now I know about it I don’t want to go to jail. I’m going to reallocate the money or do what, do whatever is required in order to address the particular risk. Now, I think in this instance, it wasn’t like a, we have to go spend more money on security. It was more, Hey, we had this issue. Do we disclose it or not? jerry: And I think, that’s a slight, maybe a slightly different take, I would assume by the way, just again, having played in this pool he didn’t make that decision alone. Andrew: Sure. Part of me, and this maybe is not exactly apples to apples, but I think about a lawyer advising an executive on the legality of something that executive can take that advice or reject that advice, a CISO advising a company on the legality or outcome or [00:12:00] risk of a decision. They don’t always make that decision. They’re somewhat beholden to their leadership on which way the company wants to go. jerry: There was a an unwritten aspect to this that I wanted to discuss a bit. And that is the subtext of all of this, I think, is going to create an adversarial relationship between the CISO and the CISO’s employer, because it feels to me like what the government would have preferred is for the CISO to to run to the government and say, Hey, my employer isn’t acting ethically. jerry: Necessarily saying that’s what happened in Uber’s case or any of these cases, but I think that’s what the government is trying to push. Now, granted there’s a not so gray line, beyond which you have an ethical duty to to rat on your employer. jerry: You can imagine all sorts of situations not [00:13:00] even in the realm of security where, you would be obligated to go and and report them. But it feels to me they’re trying to lower that bar. Andrew: Yeah, I can see that. Unfortunately this is probably going to be messy to get sorted out. And it’s going to take a lot of case law and it’s going to take a lot of precedence. That makes me nervous. If I were offered a CISO opportunity at a public company, I’d probably think real long and hard about it, about passing on it or trying to assure some level of security to avoid this problem. jerry: Our next story throws some throw some sand in the gears there. This one comes from CSO online and the title here is US Supreme Court ruling will likely cause cyber Regulation chaos. jerry: And so unless you’ve been living under a rock or perhaps just not in the U S you’re probably aware that the Supreme Court, I guess it was last [00:14:00] week, overturned what has been called or referred to as the Chevron deference doctrine. And the name comes from the oil company Chevron, and it stems back from a 1984 so 40-year-old ruling by the Supreme Court that basically I, I’ll sum summarize it to say that ambiguous laws passed by Congress can be interpreted by regulators like the FCC, the FDA, the SEC and so on. In the U S at least a lot of regulations are very high level. It’ll say something, I’m going to make it pick a stupid example. It’ll have that will say, use a strong authentication . And then it’ll be up to a regulator to say strong authentication means that you use multi factor authentication. jerry: That isn’t SMS based. jerry: That initial ruling was intended to establish that courts aren’t experts [00:15:00] in all matters of law. jerry: And by default courts should be deferring to these regulators. And that has stood the test of time for quite a long time. And now it was overturned in in this session of the Supreme whatever you want to think about the sensibility of it. jerry: I think the challenge that we now have is going to be a have made the joke on social media that right now the most promising career opportunities has got to be trial lawyers, because there’s going to be all manner of court cases, challenging different regulations which, in the past were, pretty well established as following regulations set by the executive branch in the U. S. But now as this article points out, things ranging from the SEC’s requirements around data breach [00:16:00] notifications to the Graham Leach Bliley Act of 1999. jerry: There’s a broad range in the security space of regulations, which, are likely to be challenged in court because the prescription behind those laws basically don’t cover the way they’re currently being enacted. And so we should assume that they will, these will be challenged in court and given the Supreme Court’s ruling, the established prescription coming out of the executive branch is no longer to be deferred to. jerry: And it’s unclear at this point, by the way, how courts are going to pick up their new mantle of responsibility and interpreting these things because, judges aren’t experts in security. So I think that’s why they’re calling it chaos right now, because we don’t really know what’s going to happen. For the longterm, think things will normalize. Andrew: Yeah. Businesses hate uncertainty. jerry: [00:17:00] Yes. Andrew: And for good or ill, businesses can have a huge impact on government legislation. So I think this will get sorted out eventually, but I think you’re right. I think what we counted on, or at least tried to work around or With these regulatory agencies and understand these rules have now all changed, and I think you’re right. Andrew: There’s going to be probably a ton of. of these rules that have the force of law being challenged now in court. And I think ultimately Congress has probably the reins to fix this if they want, but I think that’s another interesting problem. If SCOTUS is saying, look, You regulatory agencies are taking the power of law in your own hands and we don’t like that. Andrew: S…

    Full show notes at the publisher

    Defensive Security Podcast Episode 271 Jul 03, 2024
    Show notes

    Previous 1 7 8 9 10 11 21 Next

    Related Podcasts

    Inside Strategic Coach: Connecting Entrepreneurs With What Really Matters

    1

    Inside Strategic Coach: Connecting Entrepreneurs With What Really Matters Business
    WSJ Your Money Briefing

    2

    WSJ Your Money Briefing Business
    FORTUNE Unfiltered with Aaron Task

    3

    FORTUNE Unfiltered with Aaron Task Business
    FORTUNE OnStage Presents: The Most Powerful Women

    4

    FORTUNE OnStage Presents: The Most Powerful Women Business
    Slate Money

    5

    Slate Money Business
    In The Dark – The New Yorker

    6

    In The Dark – The New Yorker Business News
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights