Podcast: Play in new window | Download | Embed

Subscribe: RSS

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.

1. 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 skeptical of the veracity of some of these attribution reports. It’s tough to know how accurate they are because there’s no way to check easily. Somebody says it’s so and okay, based on what and how do you know and how certain are you and how do you know it’s not another actor trying to look like that actor? So I’m always quite skeptical. I’m just cautious about buying into this, but boy, is this such a focus of the industry of trying to attribute a certain actor and it’s interesting.

It makes for good fodder for conversation. And, at the executive suite, I think they like to know that, but I’ve said a few times, and I’ll probably say a few more times. As a defender, I don’t know that I care. I think I care about the TTPs. I think I care about the typical tactics and the typical techniques and typical approaches, but it’s coming from Iran or Billy down the street, really change my job too much, I just need to know what they’re up to and what I need to defend against. That’s not the point of your story. I know I just went off on a rant.

Jerry: I will say, so back to why I thought this was interesting when I, back when I was working. I had observed quite a few especially smaller organizations getting compromised and ransomware as a result of running older, vulnerable the edge protection devices like Cisco’s and Palo Alto’s and whatnot.

And it. It seemed to help in the spirit of quickly identifying or investigating the breach to understand what they were likely doing. And so if example, if you’re you’re Palo Alto firewall gets compromised while they’re You know, the first thing to look for is evidence that somebody’s trying to move laterally and deploy ransomware because that’s probably what’s going on.

But I’m broadly speaking, I’m with you, like you’ve got a, you have to be threat actor agnostic. You need to defend your environment regardless of who’s trying to get in. But I think, what I am. Really trying to impart in here is that I think as an industry and maybe not more sophisticated companies, but broadly speaking I think as an industry, we do a pretty bad job of maintaining certain really Key pieces of our infrastructure, like those firewalls, like I for whatever reason, I don’t know why, like we’ve, I have observed small companies keeping like their workstations patched and, their servers patched, but for whatever reason, It’s really common for their firewalls to be end of life.

Andrew: Yeah, it’s, I think there’s a lot of costs or a lot of reasons. I think cost is one, I think interruption of business and downtime perceptions of patching network gear is another, I think in general, network gear is not thought about as something needs to be patched very often, unlike general purpose computers. But I agree it’s a problem and we’ve seen, it goes Absent flows, and we get troughs and peaks of how often we see these sorts of devices have problems like this. And it seems like lately we’ve had a big spike in remote access VPN type technologies having pretty serious vulnerabilities. And what’s always scares me, what I think about is, okay, you’re 28 patches behind and something serious pops. That’s so much more disruptive to patch up than if you were on a more current patch level and you’ve got to Deploy a patch to fix a serious vulnerability So it’s there’s a hygiene aspect of keeping up to date on this stuff that I think makes your life easier in a crisis

And but also to your point It’s also very interesting that These types of actors get initial access and then broker that out and sell that and we’re not catching them at the initial access phase They can dwell without much notice You So that’s another interesting problem that we should get better at.

Jerry: Yeah. I think in part, it’s because the, these even well instrumented organizations don’t. They’re instrumented, especially at the edge to look for how best to describe it, to look for malicious things that are transiting through the firewall and not necessarily attacking the firewall.

I’m not saying that well, but And that my, my experience was a lot of these technologies don’t have unto themselves, things like EDR type capabilities to tell you that something is going horribly wrong on the firewall itself.

Blind to that.

Andrew: Yeah. Or they have log events that are obscure enough that your SIM wouldn’t know how to make heads or tails of it without custom alerting and. Yeah, when somebody is breaching something through some sort of vulnerability, how it reacts is highly unpredictable, hence it’s a vulnerability, hence it’s doing something it wasn’t designed to do. So it’s not that simple. We usually have to look for some sort of second order impact or or movement, like you mentioned, lateral movement to deploy ransomware to detect that intrusion often, sadly.

Jerry: Yes, indeed. All right, moving on to our next story, this one comes from the register and the title is security boom is over with over a third of CISOs reporting flat or falling budgets.

Andrew: Back it up. Let’s go home.

Jerry: Yeah, it was fun while it lasted which, by the way, I normally we don’t talk about that sort of thing, but I thought it was very interesting because it’s contrasted with another story from cybersecurity dive, which is titled InfoSpec spending to hit a three year growth peak, reaching 212 billion next year.

So the registered story is based on a survey from INs and the cybersecurity dive story is based on a report from Gartner.

Andrew: Which I’m assuming is also based on a survey from Gartner

Jerry: Yes,

Andrew: list of customers and whatnot.

Jerry: Now, when I was first contemplating this, because look, I, I’m pretty involved socially and I see a lot of people struggling to get work in the security industry right now. And we don’t have a story about it, but the US government recently announced that it’s going to Put a bunch of money into training people up to be cybersecurity workers, because there’s this, dearth of unfilled security jobs.

At the same time, we got a lot of people who can’t find work in the security industry. So I think that’s a, it’s an interesting dichotomy. And then, which kind of aligns with. The story from the register, but is antithetical or in opposition to the Gardner report. Now it occurred to me though, that they’re actually maybe saying the same thing.

Or at least they’re not mutually exclusive. I think what the IANS report is saying is that in general security budgets, budget growth is slowing some places it started to stop. And in some places it’s even starting to go down, particularly as it Pertains to hiring new people. And the Gartner report is really talking about industry spending.

So how much are you, how much are companies spending on security products and services? And it occurs to me that when you put those two things together, you have less money to spend, but the money that you do have, you’re spending on third party services and software means that you have less money To grow your team.

Andrew: Oh, CapEx versus OpEx. Although, gone to SaaS, so it’s all OpEx now these

Jerry: It’s not a lot of packs. Yeah. But I think, I, so what, one

Andrew: I could be

Jerry: of the concerns I had is a, as a CISO is, when you buy a thing, whether it’s a SAS thing or on prem thing, You actually have to do stuff with it. Like you have to have, it’s it’s an obligation. You’ve adopted a puppy. You have to care for and feed that puppy. And in the worst case, look at what happened to Target like many years ago now, probably almost a decade ago,

When they got hacked and all of the logs that indicated they had been hacked was like sitting there, but nobody was looking at them.

And so I’m concerned that as an industry, we’re becoming very enamored with technology and less so on the ability to actually use that technology. Now that’s a, maybe a naive and uninformed view, but that’s the benefit I give to the show.

Andrew: It’s fair. No, I, of my strong principles in the teams I run is try to develop mastery over your tools. to understand what’s normal, what isn’t normal, tinker with them, get to know them, play with them, know how to interpret what they’re saying. The challenge with that is you need a lot of free time and you need a lot of initiative and self starting mindset to go do that. And if you’re being pulled a thousand different directions, it’s hard. So you’re very reliant on the tool, raising the alarm, not sensing something is a little off based on familiarity with the tool or the environment or the situation. So I do think we’re also recovering still, or Adjusting to a higher interest rate environment.

I think when we were in zero interest rate environments, at least in the U. S., a lot of tech companies hired a ton of people. And so we’ve seen the slow motion layoff wave for the last year or so, or two years, as a lot of these companies. Probably overhired and with interest rates going up part of the goal those higher interest rates is basically slow down, industry growth and spending and make money more expensive and it’s working like companies slowing down. A little bit, and so they’re slowly laying off here and there and adjusting. And I wonder if that’s part of it to a lot of this is a number of companies with their budgets, taking a little bit of a pause as they’re adjusting, or their staffing levels come down a little bit, or. What not? The other thing that this reminded me of while I’m ranting on this is this consolidation push, which happens about every 5 to 10 years that I’m seeing. And then reference it a bit in one of these articles. Consolidation around certain tools or certain vendors and trying to do functionality in one, one particular solution for one particular vendor seems to be hot right now with executives. I don’t like about that is typically what will happen is a given solution or tool will be very good in one area. And then to gather and grab some of that consolidation money and increase their footprint, they’ll start expanding into other areas. But typically the offerings in those other areas are substandard.

They’re not great. They’re certainly not, of breed.

Jerry: Almost checkbox, right?

Andrew: Exactly. They are a checkbox coverage Of that other bit of functionality and usually sucks compared to the best of breed out there. But what is it’s enough to convince an executive. They don’t need a separate tool that they can gain efficiencies in that consolidation.

But I think we end up with of substandard tools. Then in these, offshoot areas that these other tools are growing into. Now they may get better over time, but typically I think that nuance is lost we are pushing to consolidate of, yeah, it says it does this, but how well does it do it in this other area?

That wasn’t the core purpose. We bought this particular tool or vendor to cover. I think some of that may be going on too. I see, I hear a lot of that push right now to consolidate and get down to less vendors and simpler platforms, but I think you risk losing some functionality and capability when you do that

Jerry: And I think that’s been a long term IT trend that is now crossing over into the security world. If you look at companies like HP and Oracle and IBM and others, they have a lot, they have a few best of breed things and they have a whole lot of checkbox crap and they’re, their sales tactic is to, convince company executives that look, you don’t have to go everywhere.

You can get everything here,

Andrew: and it works, which is helpful because our show has a couple of best read episodes and a bunch of checkbox episodes, so I’m. glad that’s acceptable to the industry. The other thing that I pulled out of one of these articles, I think it was the register one. I’m going to quote it. Quote, an encouraging sign also is that security spending as a proportion of the overall IT budget is on the rise up from 8.

6 percent in 2020 to 13. 2 percent this year. This trend looks set to continue, Kowalski opined, but still security spending was typically less than 1 percent of the revenue of those I always find that interesting. And I know what’s going to happen is a lot of CISOs and CFOs are going to look at that and go that’s what I should spend. 13. 2%. That’s my target.

Jerry: Yep.

Andrew: Regardless of their circumstance or their situation, companies love to try to measure against the averages around them and use, in theory, wisdom of crowds to measure what they should be spending on security.

Jerry: Yeah. That is the normal benchmark. That’s the normal playbook for you, whether you’re a CIO or CISO coming into a company, like that’s the gold standard is benchmarking your competition.

Andrew: It’s safest. It’s easiest. It’s an easy button. It’s, you can’t get criticized if you’re doing what’s average for the industry.

Jerry: Right,

Andrew: I think that’s a bit of a shortcut, a bit of a easy button, naive way to look at it. Like you don’t like your risk tolerance and your environment and your situation is very different from your competitor

Jerry: yeah, it

Andrew: got

Jerry: assumes text to text parity and lots of other

Andrew: Right.

Jerry: that are almost certainly not the case.

Andrew: So just something I pulled out just to riff on for a minute there that I worry about that being used as. Now the flip side is if you’re well below 13. 2 percent of your, your IT budget, you can go use this as evidence to, to fight for more budget.

Jerry: That’s certainly true. You’re not gonna get it in this market. It is I think if we take a big step back, The reality that we find ourselves in is that there’s a lot of pressure on spending, and I certainly felt it as a ciso. And I think that many people in that role feel the same and is born out in the in the ions report that, we’re being asked as an industry to do more.

With either the same or with less, the threat landscape is certainly not getting any better. It’s getting worse at a faster pace as we often talk about here. And from a, a personal liability standpoint, I think it’s also getting, At least in the U. S. getting more complex companies in their officers and their executives are now starting to be personally held liable in certain, edge case instances.

And so that’s there’s a lot of, I think, really fundamental changes afoot. But if you look at the big contour. There is an expectation of driving efficiency. And I think that what, just going back to my time as a CISO, it’s difficult for an organization to commit to hiring a person.

It’s easier for an organization to commit to spend, to signing a contract that lasts a year or two years, because, you can You know how much it’s going to cost. You can choose to not renew it. You can perhaps get out of the contract in, in the middle of it. And so that I think drives some of what has is being borne out in the Gartner report that we are starting to see companies trading off people for services, but as we’ve talked about in the past I still think that Especially if you talk, even like managed security services, I think it’s very difficult to take commodity services and have them be really effective in absence of some kind of an abstraction layer.

Like you, I think that. The place that we have to get to is in industries, figuring out how to optimally run vended services and our internal it I’m struggling with the right way to convey it, but I think we’ve got a long way to go, but my, Big concern is that we’re going to overshoot the mark, like that, that the, we’re going to cut too far

Andrew: Sure.

Jerry: and as security leaders, we’re going to end up getting exposed.

And as we started to see, that the employee, our employers are probably not going to have our backs.

Andrew: and the indicators you’ve cut too far are usually very lagging indicators that you’re not going to know right away. And it’s very difficult to know until you do a post mortem after a massive breach, why? And often those decisions make sense in the moment. And it’s a very tough job justifying a security ROI, which goes back to, Hey, what’s the average of the industry doing? Okay. That must be safe.

Jerry: I think even. I think even that is is a little perilous because, it’s, I guess it’s one thing if you feel like you’ve got all your bases covered and, you’re trying to decide if you want to, take the next step of maturity or what have you. But most companies have a big risk register.

And I always worry that those risk registers are gonna be exhibit A.

Andrew: Jerry, if it’s on the risk register, nobody can attack it.

Jerry: True.

Andrew: rule.

Jerry: I forgot about that. I’m sorry. You’re right.

Andrew: It’s out of bounds. If it’s.

Jerry: It’s out of bounds.

Andrew: No, you’re right. What’s worse having it on a risk register or not knowing your risk, I think is the first step.

Jerry: I completely agree. I guess my, my, my point was it’s hard. I think it’s very difficult, especially in some kind of a, litigation or regulatory situation to be able to justify having gnarly looking things on a risk register at the same time you’re cutting your budget. That’s my that was my point.

Andrew: Yeah, that’s fair. But just to play devil’s advocate as a CFO or a CEO. Hey, like I’m trying to keep my company afloat. I can’t just throw money at security.

Jerry: It’s certainly true. And I guess that kind of comes back to the risk tolerance, which, I guess I think one of the one of the things that’s really important. Problems that we have is what is, what does it mean to have a risk tolerance, right? Because

Andrew: Yeah.

Jerry: there seems to be like this

Andrew: And is it well understood and truly internalized by the executives making that decision?

Jerry: correct. And so in the past, okay like I, I’ve accepted a risk and no, gosh, something bad happened that. The thing that I accepted was exploited and we had a breach and, we got our hands slapped or we got some negative press. And then you move on, but now it’s okay.

And you’re going to get personally sued or perhaps go to jail or like that it’s the dynamics I think are changing. a bit. And so the, this concept of accepting the risk, I think is starting to take on a different flavor than it has in the past. And it’s probably candidly overdue. Because look, as society marches on and becomes more and more online and digital and reliant on, on on your Personal records and personal data, the sensitivity and the harm that can come from that information being stolen or maliciously used is it’s becoming much more perilous for the.

The people whose data that is exposed. And so it makes sense. But I’m not sure that we’ve broadly speaking, embraced that yet.

Andrew: No, it’s I agree. Problem. There’s always has been a tough problem and it’s constantly evolving and you go back to, okay, then what’s the framework I can use? What’s the standards I could measure against. How often are those finding the last set of problems? It’s. constantly see these sorts of approaches come into play that, whether it’s PCI, just as an example of, yeah, we’re completely PCI secure. Great. You still got hacked, right? We’re following the NIST cybersecurity framework. Okay, but how well? And there’s so much complexity.

It’s not easy. It’s really tough. getting the basics right is really tough. So it’s, I don’t know. It’s a tough problem. I, probably we should start caveating this show with the advice in the show is for entertainment purposes only so we don’t get sued.

Jerry: That’s a good point. It’s a very good point. Anyhow, but time marches on technically, the risk marches on and then the next story is a good example Of that. And this one also comes from cybersecurity dive. And the title is deep, fake scams, escalate hitting more than half of businesses.

Andrew: That was an amazing segue, by the way.

Jerry: I’m trying like I’m

Andrew: was, that’s years of work

Jerry: Right there. I’m done. Like I,

Andrew: Almost professional.

Jerry: yeah, a couple, like I say, just a few hundred more episodes and I’ll actually know what I’m doing here.

Andrew: Anyway

Jerry: It’s not been all that long that the CEO, the CFO, CEO, business email compromise concept has emerged. It started off probably 10, 10 ish, 15 years ago where, the CFO would send an urgent email to their accounting team saying I need you to wire a bunch of money to to this business email.

Bank because we’re buying a company and super secret. You can’t talk to anybody about it, but you know what, you got to do it immediately. And those for a period of time were pretty effective. And we it’s a community we adapted a bit. We built some processes and it still happens by the way, like companies are still falling victim to fairly unsophisticated attacks.

But, one of the things we said was like, you got to make sure that you know who you’re talking to. Is that email really from your CFO? And then that, that morphed into deepfake audio calls where the CEO, somebody would alter their voice. So it sounded like the CFO and for a period of time that was that was somewhat effective.

And now the next iteration of that is deepfake video where the CFO is getting onto a Webex or a zoom meeting with you. And. They’re face to face asking you to to transfer money and

Andrew: interactive video.

Jerry: right.

Andrew: Yeah, wild.

Jerry: And that’s what this is about. They’re saying that they interviewed a bunch of not IT or security people, they interviewed finance people.

And they said that of the 1500 people they interviewed, they said 85 percent view, this is an existential threat. They identified that about Roughly half of companies have I’ve been targeted and then of those that have been targeted, about 43 percent have fallen victim, which is a big number.

I don’t know how well that extrapolates out. Obviously they didn’t interview every company in the world, but still that seems like a big number. And when you tie that, by the way the Gartner report that we just talked about, the headline on that report was actually quite interesting. Because it, it said Gartner forecasts, I’m sorry, wrong headline.

Gartner predicts that by 27, 2027, so Three years from now, 70 percent of cyberattacks will involve generative AI.

Andrew: That’s wild. My toothbrush now has gender of AI, so sure, but

Jerry: I think what they’re, I think what they’re, I think what they’re saying is, it’s going to be things like this where they’re they’re using generative AI to create phishing lures and to create deep fakes and whatnot. So I don’t know that,

Andrew: sense.

Jerry: I don’t know that like they’re going to, I don’t think that they’re predicting that LLMs are going to start coming up with novel ways of hacking into your pal about the firewall, though, maybe that happens.

I don’t know. I think it’s more like coming up with creative ways to execute kind of old style attacks.

Andrew: You won’t have the badly translated poor English messages any longer.

Jerry: That’s true.

Andrew: in proper American English. It’ll sound normal and appropriate and you won’t have that trigger of, weird verbiage that sounds like a non native English speaker, which is usually a good tell. So that’s one thing that’ll make it a little harder for sure.

Jerry: So there was a report published in May. Yeah. By the, in this article makes reference to this report by the big four accounting firms, including Deloitte, that said that by 2027 fraud losses from generative AI, they expect to reach 40 billion. It’s

Andrew: That’s wild. And honestly don’t know the answer to this, and I probably should, and I feel bad that I don’t know this, but in a personal Fraud case. Let’s say somebody scams you into transferring money with Zelle, for instance, like a personal fraud, your personal homeowner’s insurance and your bank.

I’m like, no, sorry, we’re not covering that. You authorized that transaction. Yeah, you were scammed. It was and for us in the industry, we’re looking at that was a, that was basically stealing money. But right now Those banks and vendors and such are like, no, sorry, you were, you authorized it.

It’s an authorized transaction. We don’t own the liability. I wonder if that’s the case with cyber insurance. If you fell for, or were a victim, I shouldn’t say fall for, because that makes it sound like you’re at fault. If you were a victim of this sort of scam. Would there be coverage or would it be the same sort of story of no, you authorized it.

This is an authorized transaction. I don’t know. I really don’t.

Jerry: a good question. I I wonder if it would fall into I’m not a, not an insurance expert. But I do wonder if it would fall into more like errors and omission,

Andrew: Could be.

Jerry: Than cyber insurance, but I don’t know. That’s a, it’s a good question. Very good question.

Andrew: dozen or so listeners might know.

Jerry: Yeah. Hit us up. Let us know if you know the answer to that. So in any event, I. Now, this is certainly a rapidly evolving area. I know that there are a lot of people who are very bearish on generative AI, and there’s some valid ish reasons for that, but I don’t think it’s going away. The fact that you may not think it has a lot of utility and then it is unsustainable from a ecological perspective.

All that stuff can be true and it doesn’t go away. So I think that’s probably where we’re at and certainly from a, from the perspective of adversaries, I think we’re on what is likely to be a dramatic uptick in using this technology in adversarial fashion.

Andrew: Have some decent advice, which is the same thing I would ask you, which is educate your finance teams, your executive teams about the risk. Show them examples. Show, give them If there’s one thing to take away, it’s look for that sense of urgency. That’s what’s usually very common in these scams and it’s very effective psychologically, but if you can get them to understand, if someone is pushing you for a sense of urgency, be suspicious. the other thing is have processes that cannot be deviated from, which inquire, require. people to authorize and following a process. So if somebody is asking you to deviate from the process, that should be a red flag. And I think those are very common techniques that happen with these scams. So I think that’s a key. And I do think because there’s only a small number of people who can control finances in a company, can go a long way. It’s not like you’re trying to broadly target your entire population against, phishing attacks. You’re trying to get a few people control the purse strings know about this and be wary of this and be wise.

Now the flip side is it adds. It adds friction, right? You’re saying, if you have your boss legitimately coming to you and saying, I need you to do this. And you say, no, because our policy is X, Y, Z. That’s a little uncomfortable. That’s probably going to slow business down, but it’s one of the only ways probably to protect yourself against these types of scams.

Jerry: absolutely. Absolutely. I’m concerned about what other ways we’ll see this materialize.

Andrew: I actually am not here. This has been a deep scam

Jerry: You’re just an, you’re just an LLM.

Andrew: This is actually one of my cats and probably doing a better job than I can do.

Jerry: I I think. I was about to say that

Andrew: Look, hey, results, I’m results oriented. The show got done. Speaking of, where’s Betty? Stop hopping up on my desk. We’re not in video yet. But soon, we might be.

Jerry: getting close.

Andrew: random cats wandering through the shot.

Jerry: Yeah, it’ll be deep fake video.

We’ll be like we’ll pick different celebrities to portray us, but it’ll be okay.

Andrew: Ugh. What is happening? have no idea.

Jerry: Anyway I think this is one area to watch. I, I. I certainly think this particular area, like you said, there are some definite ways that we can avoid losses, but I am also concerned about ways that we maybe haven’t even thought of or seen exploited yet, for more broad consumption in, in, in other types of roles, for example, a lot of Organizations, even the ones, by the way, that work in person meet virtually.

And how long will it be before we start reading about you people sliding in adversary, sliding in and portraying someone and, stealing intellectual property or,

Andrew: And

Before the Zooms, the Google Meets, and the WebExes of the world offer an enhanced package with anti deepfake for a small, multi thousand dollar per month fee?

Jerry: Hey, there you go. We should patent that.

Andrew: We should.

Jerry: Brilliant.

Andrew: You know it’s coming. You know it is. It’s gotta be. It’s inevitable.

Jerry: Yeah. And it’ll be it’ll be LLM, generative AI based. Yeah. Two. So

Probably with some blockchain and cloud thrown in, I’m guessing.

Andrew: How could it not be?

Jerry: I don’t know.

Andrew: It’s a table stakes.

Jerry: We’ve I think we’ve hit terminal altitude and now we’re headed back down. So I I think that’s it for today. I certainly appreciate everybody’s time and attention.

Hopefully you found this interesting. If you like the show, give us some love on your favorite podcast app. We definitely like that. It helps other people find the show. If you. didn’t like it, you can also give us a positive rating because that still works. Like you, you don’t have to give us a bad rating.

You could give us a good rating and then just not listen again. That works too.

Andrew: It’ll encourage us to get even better.

Jerry: That’s right. Absolutely.

Andrew: We’re

Jerry: So you,

Andrew: positive reinforcement here.

Jerry: Not negative reinforcement, positive. All right. You can follow the show on our website at www. defensivesecurity. org. You can follow us on, you can download the podcast on just about every podcast platform there is out there now. I don’t know that we’ve missed any, although if we had, love to hear about it.

You can follow Mr. Callot on the social media at where

Andrew: I’m both on X, formerly known as Twitter, and InfoSec. Exchange, Jerry’s fine Mastodon service at LERG, L E R G, which someday I will explain, but not today.

Jerry: which is by the way, the best the very best in social media. So you can find, follow me on infosecular. exchange at. At Jerry at InfoSec that exchange. And with that, we bid you adieu. Have a great week, everybody.

Andrew: See you later. Bye bye.

Podcast: Play in new window | Download | Embed

Subscribe: RSS

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 signaled that he’s going to be suing.

both CrowdStrike and Microsoft. And we’ve talked about this a little bit in previous shows, but now CrowdStrike and Microsoft have separately responded to those legal threats. I don’t think they’ve actually materialized as filed lawsuits yet, but the first one is from the register and the title is CrowdStrike Unhappy About Delta’s Litigation Threat Claims Airline Refused Free On Site Help.

So this particular story is about a open letter that one of CrowdStrike’s lawyers sent to the legal counsel that Delta retained. And I think that legal counsel is pretty some fairly high profile legal team that was involved in in prior high profile cases. In this, I’ll summarize this letter is basically saying, you, Delta should be, cautious about what you ask for.

And by the way, if you are going to proceed with this, we would expect you to retain a certain set of information that we think will be useful in this litigation. And there was one quote, I think summarizes the whole thing very well. And it says, Should Delta pursue this path, meaning the lawsuit, Delta will have to explain to the public, its shareholders, and ultimately a jury, why CrowdStrike took responsibility for its actions swiftly, transparently, constructively, while Delta did not.

Now, there is an interesting adjunct to this that both Microsoft and CrowdStrike had offered assistance to Delta. And in the industry, there’s lots of, armchair quarterbacking about how Silly that is, because what would they really be able to do, right? Like in this particular instance, you need hands and feet going and sitting in front of computers to do the thing, to get the systems back up.

And so what were either CrowdStrike or Microsoft, really going to do? And I think that’s a fair characterization, but It’s not highlighted in this particular letter, but Delta, to both Microsoft and CrowdStrike basically said, no we’re good.

We don’t need your help. And so now both CrowdStrike and Microsoft are throwing that back in their face saying, if it was so horrible, why? Why didn’t you accept our offer of help? But I think that does beg the question, what help could they really have been? And I actually don’t have an answer for that.

Andrew: it’s interesting because these lawyers for CrowdStrike and Microsoft also go into this whole, and this is clearly for public, and posturing

Jerry: Oh yeah.

Andrew: lawsuits, but saying, Hey, what you Delta clearly were different in the way you approach this and your competitors. So what’s up with your organization that makes you different?

When why didn’t you want our help? What were you hiding? And, implying that. dirty laundry would come out on Delta’s side, and they’ve got skeletons in the closet that, Microsoft and CrowdStrike are aware of, that they are brandishing of, hey, if you want to drag us into court. You’re not going to come out of this unscathed, which I’m sure this was going to come up great during negotiations for renewal on CrowdStrike with Delta. I’m sure that sales team is really happy right now.

Jerry: Oh

Yes.

Andrew: this is wild. I also, and we’ve talked about this before, I don’t know what sort of legal leg Delta really has to stand on.

I guess this is what the court system will explore, but yeah it’s an ugly one. And it was pretty aggressive on both Microsoft and CrowdStrike’s lawyers parts to be like, Delta. Yeah, we screwed up, but you screwed up a lot too.

Jerry: So the Microsoft response. And there’s a similar article from the verge titled Microsoft says Delta ignored Satya Nadella’s offer of CrowdStrike help. And Microsoft similarly wrote a letter to Delta’s lawyers, but this one actually shines a light on a, perhaps a question or line of questioning that I hadn’t thought of before, and it does highlight again that Microsoft obviously did reach out and offer help, and they were told that, no, they Delta have it under control.

And what Microsoft and the reporter on the verge seemed to be insinuating is that the problem for Delta was not actually with windows. Obviously the problem started with CrowdStrike. Causing their window systems blue screen. But what they seem to be asserting is that when that happened, it created downstream problems in their legacy infrastructure, which is not based on windows and that then had to go get fixed.

And that is what took the place. All the time. Now that is an interesting point, although I will say it stains a little bit in contrast to some of the images that we saw of contractors standing up on ladders and airports rebooting. Display terminals, I think well after the, like up to a week after the outage, it’s an interesting point, what Microsoft is asserting here is that Delta has chosen not to modernize its it.

And when this incident happened, because of the fragility of their system, they were able to get their Windows systems back up and running relatively fast, as evidenced by their refusal. the problem they had that took all the time was with their old aging IT infrastructure.

Now it’s an interesting thing because legally, It almost doesn’t matter, because even if that’s true, and the court fines in favor of Delta, the fact that Delta didn’t invest doesn’t necessarily absolve either Microsoft or CrowdStrike of anything.

Andrew: Yeah. And Southwest is still running on the Commodore 64 and they were fine.

Jerry: true.

Andrew: counterpoint,

Jerry: That’s very true.

Andrew: it’s almost do you want the court to, Find what is due diligence and what is appropriate level of I. T. modernization. And you’ve heard this point a couple of times. You don’t think this is ever going to

Jerry: No, this is they’re trying this in the court of public opinion. This is never going to go to trial. This is going to get settled out of court. None of these parties, maybe Microsoft, I don’t know. They may be okay, but certainly CrowdStrike and Delta don’t want.

They don’t want, they’re not going to want it to go through the process of discovery and having all of this shit about them in their it programs and development programs laid bare for the public to see, they’re just not going to want that. So I think it’s going to get settled out of court. And right now this is about PR and damage control and everybody’s trying to make sure that their own we don’t have a story about it, but CrowdStrike’s shareholders have filed a lawsuit against CrowdStrike for for loss of shareholder value.

Andrew: Indeed.

It’s interesting. So I have one other topic on the CrowdStrike thing before I move on, if you’ll indulge me.

Jerry: And I think this is the LinkedIn posts, right? And I’ve got, I’m going to put these links in the show notes for you.

Andrew: Okay. So, Alex Stamos, who’s well known and, was at all sorts of interesting organizations recently joined SentinelOne Now SentinelOne is a direct competitor of CrowdStrike, so keep that in mind. And full disclosure. I happen to use Sentinel 1, so I know it better, but I don’t have any, strong opinions one way or the other, but I just want to be transparent about that. Anyway, so about a week ago, Alex put a post out on LinkedIn talking about this outage. So keep in mind it’s coming from a competitor. And he’s basically alleging it is false to say this could have happened to anybody. It’s clear that CrowdStrike made intentional architectural engineering and process decisions that led to this global catastrophe. All right. And he has a bunch of points, but there’s one specifically that I want to drill into here, which is 0.

4 in his post. And this addresses why are people running a kernel level? And why do they have kernel for these tools? And a lot of people have said, Hey, you shouldn’t do that. You don’t need to do that. You don’t do that on Mac. You don’t do that on other systems. Why are you doing in Windows? Point four, quoting, Additionally, there are models for architecting EDR with minimal kernel access, and the team at Sentinel One is, quote, willing to work with Microsoft on exploring these models, assuming Microsoft holds their own products to the same standards, end quote. So as I think this is a very key point to this entire discussion and this entire debate, because what this is saying, and this goes back to some things that Microsoft 2009, the EU through antitrust settlement Microsoft, who was competing at a, with a security tooling. other vendors to give other vendors the exact same access as Microsoft had to the kernel for the efficacy of their security tooling. So what Microsoft is saying, look, we didn’t have a choice. The government, the EU made us give folks access to this kernel. And what I’m reading here is saying, we also have access to the kernel because we have to compete with Microsoft’s tooling. So if Microsoft is willing to not be in the kernel with their security tooling, we’ll do the same. And that is calling attention, I think, to there’s obviously some benefit to running your security tooling at the kernel level if they’re worried about competing with Microsoft who has kernel access and they wouldn’t

Jerry: When I read that, whole thing is interesting because. It’s coming from a competitor of CrowdStrike. And so I come back to my new favorite legal term, which is corporate puffery,

Andrew: indeed.

Jerry: And I see corporate puffery. Obviously there’s some well founded points in here, but.

I will say that the first point and that fourth point stand in contrast to each other. Because on the one hand, they seem to be saying nobody else is doing it that way. CrowdStrike is standing alone in how they do this. And by the way we look forward to working with Microsoft to figure out how we can also not do it.

Andrew: Right?

Jerry: I don’t know. it’s an interesting point. there is associated video where Alex talks a bit more about his thoughts in depth. I think it fundamentally isn’t wrong. if there is an alternative way to do this, that is safer outside of the kernel and we don’t lose visibility we should be doing that.

Andrew: Yeah. speed. Severity of impact of the agent. There’s multiple things there. And I just think that there’s more at play here than just, we chose to do it because it was easier. I think there’s a competition issue here with Microsoft.

Jerry: Yeah. There was one point in here that I wanted to talk about. I picked up on his second point, which is quote, it is dangerous to claim that any security product could have caused this global outage because you’re telling CEOs, CIOs, and boards around the world that it is highly risky to deploy advanced security products.

In the long run, that makes it the world harder to defend and less secure. in any event so I don’t disagree conceptually. Like we shouldn’t be doing things that make our job harder, but we also shouldn’t be sugarcoating things and telling our senior leadership that, there is no risk

Andrew: The other thing I find interesting about this point that is not ever included in these conversations is the cost of the software.

So I’m making up numbers here. Don’t quote me, but I’m in the right area. Let’s say for the average company, average CrowdStrike agent per host. I, again, I’m making up numbers, but just. Work with me, 50 bucks a head, right? So it’s probably more than that, but let’s just say it’s 50 bucks a unit. What if I offered you a thousand bucks a unit, but I promise you it’ll never crash. Is it worth it to you? I’ve got to apply so many more resources and so much more time and so much more energy to do that extra checking and I’m going to develop slower and I’m going to be behind everybody else, but it’s more stable. Is it worth it to you? There has to be that trade off. There has to be that question of speed versus cost versus stability.

Jerry: So I,

Andrew: And we never

Jerry: yeah I think it just becomes unaffordable, right? It’s not a, do I want it? Do I think it would be, is it necessary? at that price point you’re basically. Probably spending two or three times more than your overall budget just on a single tool, not even including, what it would require to run the tool.

So I think it would be awesome to have, aviation, life safety grade stuff, but it’s really not. It’s not practical, but I guess my,

Andrew: that’s my point. It’s do we acknowledge that ever? That, hey, look, there are folks who develop things that run aircraft, that cost, many multiples of standard software development because of life, grade. I used a good term that I’ve blanked on. That isn’t affordable for the average generic system. But is it then fair to assume that they would have the same stability that highly refined, or however you want to say it, system?

Or are we just deluding ourselves?

Jerry: no I strongly suspect most organizations would not say that it’s worth it to them, right? They would trade off some amount of downtime or the chance of some amount of downtime for. To be able to a, not spend that exorbitant amount of money, and also to have generally a reasonable amount of protection in place, which I think is the implicit or the tacit trade off that we’ve made.

The thing that I guess is concerning to me is that this particular bullet seems to be asserting that, we shouldn’t. Be, upfront about the potential downside, right? I think what Alex and again, I didn’t talk to Alex. I don’t know, Alex, but I think what he’s trying to say is we have a hard enough time as it is.

We have a hard enough time allocating money for security programs as it is. And if we go and we tell our senior leadership team that, hey, not only do we have to spend all this money, but by the way, there’s, a non significant chance that it’s going to cause, a global outage for us because, it happens to everybody.

I think that’s what he’s railing against, but on the other side, I think we, at our own detriment, tell our boards that, there’s no risk in running CrowdStrike or SentinelOne or any other program

Andrew: let’s take it back to password managers, right? When somebody has a problem like LastPass did, for instance, We all came out and said, look, don’t throw password managers out.

Jerry: right?

Andrew: Like you’re still better off running a password manager statistically and everything else.

You’re still better off using unique complex passwords on every site. You manage through password manager. It’s still better even with these sorts of circumstances. So I feel that’s a similar conversation. Yeah, there’s a risk, but there’s no zero risk here. You can’t be in business and have zero risk. So got to, I think Alex knows better, frankly, than to try to imply that there’s a zero risk option here. There’s always some trade

Jerry: Yeah I think he’s two, two things. One is he works for a vendor and so he needs to make sure that companies still keep buying XDR software. But I think more broadly, he is hoping that we don’t shoot ourself in the foot by talking our senior leadership team out of allocating money for these important products.

Andrew: fair. And by the way, I don’t know Alex yet. I think I’ve met him once or twice, but I certainly am not trying to, Know what he’s saying. I think there’s a, it’s somewhat disingenuous to say that there’s zero risk in running software like this,

Jerry: All right. So moving on to more exciting things.

Andrew: From security week. The title here is , thousands of devices wiped remotely following mobile guardian hack. So mobile guardian is anMDM solution, mobile device management solution, who focuses on the education sector.

Jerry: they had an incident on August 4th that resulted in some number of their iPads managed through their platform, being deregistered in the process of being deregistered that caused the devices to be wiped. And there’s actually some fairly sad looking pictures of kids in front of stacks of broken iPads, because they’ve been deregistered.

wiped. this particular article doesn’t go into it, but it seems like this company mobile guardian has actually had a run of some security related issues leading up to this one. This one apparently isn’t related to the prior ones, but it does give me.

Concerns about the health of their offering. right now, in fact, they’ve actually got their offering deactivated and any of the systems that are managed by them are currently not functional until they. fix whatever issues they have. I think they took a proactive step of disabling their central management infrastructure.

So that’s rendered the functionality of those devices pretty significantly.

Andrew: Yeah, it’s an interesting attack factor. Somebody gets into your centralized management software and could just wipe all your devices. That’s tough to recover from. Not one I’d thought about before, to be honest, from an MDM

Jerry: Yeah. The it tools have long concerned me where you have central management of your infrastructure. In this particular case, it’s outsourced to a third party company, but we have lots of different flavors, whether that’s like Ansible or salt or Active Directory or many others that serves as a concentration point, like it is a place that an adversary can go in with one, you area cause untold chaos for your organization.

And so it really needs to be well protected. And, in this instance, the country of Singapore was pretty significantly impacted by this. And so they have actually decided to move off of a mobile guardian. Going to guess they won’t be the last one.

Andrew: Yeah, this is an interesting corollary of, is it worth it to have the protection? They’ve decided, nope, it

Jerry: Yeah I think

Andrew: need

Jerry: my guess is they’ll

Move to something else, but

Andrew: I should say not even just the protection, but the manageability. Which yeah, you’re right. They’re going to go to a competitor. I’m sure. But the capabilities offered by the centralized manageability is what can be used against you, which is what you were saying.

Jerry: Yeah,

Andrew: but I don’t know how you’d manage a modern large infrastructure without it. you just got to

Jerry: I don’t think you can, but I also don’t think that many it shops spend enough time thinking about how to protect those orchestration and management platforms. And I also don’t think that we necessarily don’t do enough due diligence on. companies like Mobile Guardian.

And again, I don’t know, this is the first time I’ve ever heard about them. I don’t know anything about them. They could be an absolutely fine company, just having a bad run. I don’t really know, but I think it’s a, to me, a highlight on an issue that I think is going to continue to grow in prominence.

So now on to, the other topic I want to talk about, which is really focused on targeting I. T. people. So the first story is from Bleeping Computer. The title here is Stack Exchange Abused to Spread Malicious PyPy Packages as Answers. And it, again, it’s not a, like a massive attack here, but I thought the technique was super interesting and worth talking about.

There’s a couple of different blockchain platforms, one of them called radium and I forget the name of the other one. Radium doesn’t have any Python modules. And so what the adversary here did was they created some malicious. Repositories in the PiPi repo. And then they created a whole bunch of fake accounts on stack exchange and they started answering questions and they started basically talking up how to use these bogus packages that they.

Uploaded into the PyPy repo and it worked, they got almost 2, 100 downloads.

Andrew: that’s actually really what we’re up to with the show. It’s a long con to start telling people to go install malware once we’ve gotten over 5, 000 episodes out and people trust us. That’s what we’re doing

Jerry: we’ll be there sometime around 2050.

Andrew: but

Jerry: amazing.

Andrew: They’re just, They’re abusing the reputational trust that comes with that platform of valid appropriate answers and Oh yeah, it’s like the easy button to go find an answer and yeah, I trust it. You get some malware, have a nice day.

Jerry: Yeah. So this particular one was, capturing credentials and other sensitive information out of big crypto wallets Telegram and other instant messaging software. And then also information out of browsers. But what I thought was quite interesting was that it was, focused on developers.

It was targeted at developers and As I guess now the former CISO, this causes me a lot of concern, right? That you have a population of developers who are, I would argue what makes an effective developer these days is figuring out how to get efficient answers to your technical problems. you can’t hire developers that know everything, that are completely prescient and omnipotent.

the average IT person is an effective IT person because they know where to go to get the answers to the problems they have. Whether that’s programming, or system administration, or helpdesk, or anything like that. And this worries me. And I think we have to be very cognizant of this trend going forward.

And I think in the near term, we at least have to be incorporating something about this into our security education for developers. But, I think this is probably going to come up more broadly. And that, by the way, dovetails into The other way that it manifests, or has manifested, and I’m sure there’s lots more ways, this one also comes from Bleeping Computer and the title is Ransomware Gain Targets IT Workers with New Sharp Rhino Malware.

And this is more of a watering hole slash

It’s, watering hole, SEO, domain hijacking, where they are purporting to be the angry IP scanner. They’re doing typo squatting or malicious ad buys, trying to divert you. The IT person to a malicious website that they control that looks like the legitimate source of the angry IP scanner for you to download.

And somebody who’s downloading that in the context of an IT or a security person in a company, probably more often than not, has some sort of elevated privileges because they’re probably trying to get that to do some important IT work.

Andrew: Indeed.

Jerry: Between the two, I think we should expect an increase focus on targeting it workers. I think in I think we’ve seen it people being targeted by more sophisticated adversaries for quite some time. What I think is becoming more novel is that this is really becoming a commodity type.

tactic where you’ve got, like lower tier ransomware actors and people trying to steal crypto wallets, actually targeting IT people. So I think we’re almost certainly going to see more and more criminal elements coming in and using these sorts of tactics to try to infiltrate, we know that entry as a service or, that initial entry point into an organization is part of the industrialization of the attack chain where You can, as a ransomware actor or as somebody trying to steal intellectual property, go and buy access.

So you’ve got bad actors who are trying to find ways of Infiltrating companies. And this I think is going to become a much more prominent and effective way in the future, because we, it people hold ourselves in high regard in our ability to not fall for stuff.

Yeah.

Andrew: Believe me, it happens. And the bad guys can keep getting more sophisticated and keep trying different tactics and they start to hit on things that work for a while or, catch certain people at a certain time in a certain set of stressors or certain circumstances that just, it’s, I was curious, going back to the malicious PyPy packages. I do wonder if any static code analysis tools would have picked that up. I don’t know. Maybe I’ll play with that.

Jerry: This is

Andrew: Or that sort of

Jerry: the they were not detected by. Like when the normal anti malware, but I don’t know if they would have been detected by, your aquas and and whatnot.

Andrew: And is it worth running? Having a process of any third party code? That you bring in and scan. I don’t know. I’m just musing out loud here. I honestly don’t know. And I think for a while, wasn’t Google, I think a couple people were trying to do like a safe package repository where, it was vetted and secured.

And I don’t know how well that’s been adopted, but it might be another idea. Don’t just get random stuff, like only go to the safe

Jerry: There’s,

Andrew: But that may slow you

Jerry: yeah.

Andrew: may not be able to answer all the questions you need that way. And, you may not find what you need there.

Jerry: lot, there’s a lot of. focus on supply chain. And I think we’re seeing a lot more focus on supply chain security as it pertains to open source? But my observation is that tends to focus more on Products where we’re, to some extent becoming compelled to care about this, because for example, the U S government has created some, regulatory hoopla where you now have to create S bombs and you have to make attestations about the integrity of your software development practice and whatnot.

So I think. in certain contexts that make sense. But there’s a lot of companies that have a lot of developers that don’t make products for sale or offer services for sale. We have huge numbers of people creating internal applications and whatnot. And I don’t expect, I think it’s a very long time before we see that kind of maturity being applied to purely internal operations.

Andrew: fair. And, these are also expensive sort of things to ask an organization to do it. You’d have to be pretty mature and pretty well staffed and well funded to, to do some of these things too.

Jerry: I definitely agree, but I think we have to be mindful about the ecosystem that we operate our, what I’ll call privileged users in, right? it goes back to that quote, with great power comes great responsibility. If you’re going to have IT people with elevated privileges, they should have to operate within a tighter set of parameters.

And whether that’s, the context of what Microsoft used to call their red forest, I forget what they call it these days. I’m getting old. But I think it’s very difficult to combat all of the different ways these things can manifest. And in particular, a lot of companies aren’t going to have the tolerance, to, stop their employees from leveraging open source that way.

But that doesn’t mean that we get to throw up our hands and say it’s just too hard. I think it means that we need to take a different look at how we construct our environment in a way that is more tolerant to the problems that can come from this sort of thing.

Andrew: Yep. I would agree. It makes me think also somewhat similar, like if they’re a high value target, Similar to how executives are a high value target. It’s only a reason they shouldn’t break the rules or have exceptions to the rules because the consequences of them being hacked in some way are so much higher than the average employee.

Jerry: Oh, a hundred percent. Absolutely. All right. That is the show for today. I appreciate everybody’s attention. Thank you for working through my noisy cat and our technical problems. If you like the show, you can find all of our back episodes on our website at defensive security. org. You can also find us on your favorite podcast platform.

I think we’ve got them all now, if I’m not mistaken, pretty much all.

Andrew: Unless there’s ones out there we don’t know about.

Jerry: Yeah,

Andrew: We’ll

Jerry: absolutely. You can follow me on the Fediverse at Jerry at infosec. exchange. You can follow Andy where?

Andrew: Also on the Fediverse at lurg, L E R G, at infosec. exchange. Also, I’m still hanging around the Twitter slash X world. Also at lurg, L E R G.

Jerry: All right. I look forward to talking to everybody again real soon. I hope you have a great week.

Andrew: Thanks everybody.

Jerry: Take care.

Andrew: bye.

Podcast: Play in new window | Download | Embed

Subscribe: RSS

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: So the power of law comes from Congress and elected officials in Congress. Then Congress, you need to do a better job of defining these rules specifically. That presents its [00:18:00] own set of interesting challenges because how well will they do that? And we’ve seen a lot of well intentioned laws, especially in very complex areas, have their own set of problems because of all of the trade offs and problems that go into legislative work in Congress causing issues.

Andrew: So it will be very interesting. This could have a lot of wide ranging impacts. And again, to your point, I’m not getting anywhere near whether they should or shouldn’t have done this, but I think the intent was you unelected regulators shouldn’t make law, Congress should make law. Okay. But that’s easier said than done.

jerry: Yeah. It’s, I think it’s that plus the constitution itself. very directly says that it is up to the judicial branch to interpret laws passed by Congress. Yeah. Yeah. And not the executive branch. And that’s [00:19:00] what, that’s where I think if you read the majority opinion, that’s basically to sum up, that’s what they’re saying.

jerry: I think the, the challenges that when the constitution was written, like there was, it was a much, much simpler time.

Andrew: There’s a lot of interesting arguments about. That you see out there and there’s a lot of very passionate opinions on this. So I’m trying very hard to stay away from the political rhetoric around it and just, I concur that this throws a lot of accepted precedent around our industry into question.

jerry: But, going back to the previous story, I don’t know, again, I’m not a, I’m not an attorney. However, if I were Joe Sullivan, I would feel like I have a new avenue of appeal.

Andrew: Sure. Yeah. Did the SEC made this law in essence could, would be his argument. And based on this particular ruling by SCOTUS [00:20:00] that was an inappropriate ruling and, or an inappropriate law.

Andrew: And therefore his. Obviously I’m not a lawyer because I’m not articulating this like a lawyer, but he could say that’s why I shouldn’t have been trying to convicted and please politely pound sand.

jerry: I do think the, I do think the opinion did say something along the lines of it doesn’t overturn, previously held court cases, people are due their day in court.

jerry: So if he has an avenue for appeal, that’s how the justice system works. This is hot off the presses. I think. I think the echoes are still circling the earth, we’ll be seeing the outcome of this for a while and I don’t think we exactly know what’s going to happen next. Stay tuned and we’ll check in on this periodically.

jerry: Okay. The next one comes from Sansec and there’s actually two stories, one from Sansec and one from security week. And this is [00:21:00] regarding the polyfill. io issue. I’m hesitant to call it a supply chain attack, but I guess that’s what everybody’s calling it.

Andrew: Come on, get on the bandwagon.

jerry: I know, I know.

Andrew: If you want to be an influencer, man, you got to use the influencer language.

jerry: I feel, it makes me feel dirty to call it a supply chain attack. So why what makes you so uncomfortable calling it a supply chain attack? I don’t know. I don’t know. I, that’s a good question. And I, the answer is I don’t really know.

jerry: It just feels wrong.

Andrew: Did your mother talk to you a lot about supply chain attacks?

jerry: See that’s, maybe that’s the problem.

Andrew: Okay. Imagine you’re walking in a desert and you come across a supply chain attack upside down stuck on its back. Do you help it? But you’re not turning it over. Why aren’t you turning it over, Jerry?

jerry: I don’t even know where this is going.

Andrew: I had to lighten it up after the last two stories, man. You were being a downer.

jerry: Polyfill is [00:22:00] a is a JavaScript library that many organizations included in their own website. It does oversimplifying it. It enables some types of more advanced functions or newer functions of modern web browsers to work in older versions of web browsers. And so I don’t fully understand the sanity behind this. I think it’s, maybe this will start to cause some rethink on how this works, but , this JavaScript library is called by reference rather than it being served up by your web server, you are referring to it, as a remote entity remote document hosted on, in this instance, polyfill. io.

Andrew: So instead of the static code living in your. HTML code. You’re saying go get the code snippet from this bot and serve it up.

jerry: Correct. It’s telling the web browser to go get the codes directly. Yeah. What happened [00:23:00] back in February was I don’t fully understand, what precipitated this, but the maintainer of the polyfill. js library in the polyfill. io domain. Was sold to a Chinese company. And that company then started using they all basically, they altered the JavaScript script library to alt, alternatively, depending on where you’re located and other factors either serve you malware or serve you spam ads and so on.

Andrew: So you’re saying there are not hot singles in my area ready to meet me?

jerry: It’s surprising, but there probably are actually.

Andrew: carry on.

jerry: They can’t all be using Polyfil. Anyhow, there, there were, depending on who you believe somewhere ranging from 100, 000 [00:24:00] websites that were including this polyfill. io code to tens of millions as purported by CloudFlare. So at this point, by the way, that the issue is somewhat mitigated.

jerry: I’ll come back to why I say somewhat mitigated that the poly field that IO domain, which was hosting the malicious code has been taken down. Most of the big CDN providers are redirecting to their own local known good copies, but again, they haven’t solved the underlying issue that it’s still pointing to JavaScript code that’s hosted by somebody else. Although, presumably companies like CloudFlare and Akamai and Fastly are probably more trustworthy than, Funnel in China.

Andrew: Yeah yeah, because they actually came out and denied any malicious intent and cried foul on this whole thing too, which was interesting.

jerry: Yes. [00:25:00] But people have done a pretty good job. And in fact, this, the San Sec report gives it pretty good. Pretty thorough examination of what was being served up. And, you can very clearly see it it’s serving up some domain lookalikes, like I find it hilarious, Googie dash any analytics. Com, which is supposed to look like googleanalytics. com. And I suppose if it were in all caps, it would probably look a lot more like that. But the other interesting thing is that these researchers, noticed that the same company also in several other domains, some of which have been also serving up malware.

jerry: And those have also been taken down, but there are also others that aren’t serving, or haven’t been seen serving malware yet and are still active. And so it’s it’s probably worth having your threat Intel teams. Take a look at this because my guess would be that at some point in the future the [00:26:00] other domains that this organization owns will probably likewise be used to serve up a malware.

Andrew: Bold of you to assume that all of us have threat Intel teams.

jerry: Fair enough. You do you just, it just may be you.

Andrew: Correct. Me and Google.

jerry: Yes.

Andrew: And my RSS feed of handy blogs, but yes,

jerry: that’s right,

Andrew: but yeah, they seem to have, oh, a wee bit of a history of being up to no good.

Andrew: This particular Chinese developer.

jerry: Yes, defending against this, I think is pretty, pretty tough beyond what I said on the supply side. I think it’s, I think it’s a bad idea. Maybe I’m a purist. Maybe I’m old school and it should be out the pasture. I think it’s a risky as we’ve seen many times now.

jerry: This is not by far the first time this has happened to be including by reference things [00:27:00] hosted, as part of some kind of an open source program. Not necessarily picking on open source there. I think it happens less often with commercial software. As we’ve seen it now happen quite a few times with these open source programs, either, including things like browser extensions and whatnot.

jerry: I, now having said that, you can imagine a universe where this existed as a just simply and solely a GitHub repo and companies, instead of referring to polyfill. io we’re downloading the polyfill code to their own web server. And most likely you, you would have between a hundred thousand and 10 million websites serving locally, modified code, but then again, nobody updates

Andrew: right? It would be impacted, but we’re running 28 year old versions.

jerry: So maybe not.

Andrew: Yeah, but boy, to your point, it gives me a little bit of a [00:28:00] heebie jeebies to say that the website that you’re responsible for is dynamically loading content and serving it that you don’t have control over, but that’s perhaps very naive of me.

Andrew: I don’t do much website development. I don’t know if that’s common, but as a security guy, that makes me go, Ooh, that’s risky. So we don’t control that at all. Some third party does. And we’re serving that to our customers or visitors to come to our website and we just have to trust it. Okay. But that probably exists in many other aspects of a modern supply chain or a modern development environment where you just have to trust it and hope that.

Andrew: People are picking up any sort of malicious behavior and reporting it as they did in this case, which is helpful But then it causes everybody to scramble to find where they’re using this which then goes to hey How good is your software building materials or software asset management program to how quickly can you identify you for using this?

Andrew: and then there was a lot of confusion when this first came out because there’s different sort of kind of [00:29:00] styles or Instances of polyfill that some were impacted some were not how much of this is You know, what truly was at risk? And the upside is that the domain was black hole pretty quick. Anyway, it seems so fragile, right? You’ve got this third party code that you don’t control. You don’t know what’s the other end. You probably have ignored that it’s even out there and forgotten about it, especially this is defunct code. And that’s a whole other area that drives me a little crazy at night is how do you know when an open source software is no longer being maintained and is silently or quietly gone end of life and you should be replacing it? I’ve contemplated things like, hey, if there hasn’t been an update within one year, Do we call that no longer maintained?

Andrew: I don’t know. I don’t have a good answer. I play around with that idea with my developers and talking about, because we want to make sure that code is well maintained and third party code that we’re using is being up to date. We don’t want end of life code in general, but I don’t know what [00:30:00] constitutes the end of life in open source anymore.

jerry: I think we will eventually see some sort of health rating for open source projects. And that health rating will be based on like, where are the developers located in the world? How long on average does it take for reported vulnerabilities to get fixed? How frequently are commits and releases of code being made and other things like that. But that doesn’t necessarily mean a whole lot. Look at what happened with, what was it? X Z.

Andrew: Yeah. Yeah.

jerry: That was a very, arguably, won’t call it healthy, right?

jerry: But it was an active project that had a malicious a malicious contributor who found ways of contributing malicious code in ways that were difficult to discern. And then, you look at what happened with open SSL and then open SSH and [00:31:00] it’s not a guarantee, but I think

jerry: it would be good to know that, hey, you have code in your environment that is included by reference and it was just bought by a company who’s known to be a malicious adversary. And we don’t have that. We don’t have any way of doing that today.

Andrew: So you want like a restaurant health inspector to just show up and be like, all right, show me your cleanliness.

jerry: They so I think that we will get there.

Andrew: You want a sign in the window, this restaurant slash get hub repository earned a B minus, but has great brisket.

jerry: Sometimes you just have to risk it. Good, good brisket is good brisket. So I think that’s going to happen, but what that doesn’t solve is the demand side. So that’s. I think part of the supply side, you still have to know to go look for the health score.

Andrew: Or have some sort of tooling or third party tool [00:32:00] that, some sort of software security suite that, scans your code and alerts you on these things in some way, like in theory. And I’m sure by the way, that there’s probably vendors out there that think they do this today and be happy to pimp us on their solution.

jerry: Oh I’m, I feel quite certain that my LinkedIn. DMs will be lit up with people wanting to come on the show to talk about their fancy AI enabled source code analyzer.

Andrew: But it’s just one more thing devs that now have to worry about as security teams have to worry about. And. This is a competition against developing new features and new functionality and fixing bugs is, this is now just one more input to worry about, which competes for priorities, which is why it’s not that simple.

jerry: It’s very true. Way back when I was a CISO.

Andrew: You mean two weeks ago?

jerry: Way back. The way I had always characterized it is using open source software is like adopting a puppy. You can’t ignore it. It needs to be cared for. You have to feed it and clean up after [00:33:00] it and walk it and whatnot. I don’t think that is a common approach. I think we typically consume it as a matter of convenience and assume that it will be good forever. I think we’re getting, we’re starting to get better about developing an inventory of what you have through SBOM. And that of course will lead to better intelligence on what needs to be updated when it has a vulnerability and that’s certainly goodness, but I think that the end to end process in many organizations needs a lot of work.

Andrew: Yeah. I also think that this is never going to go away in terms of companies. I think rightly or wrongly, or we’ll always be reliant on third party open source software now. And so we’ve got to find, and this is also a relatively rare event that we’re aware of the hundreds or maybe thousands of open source projects that people use regularly.

Andrew: This doesn’t happen very [00:34:00] often.

jerry: It’s the Shark attack syndrome, you hear about it every time it happens. And so it’s, it seems like it happens often, but when it does happen, it can be spectacular. .

Andrew: It’s interesting because when these things hit a certain level of press awareness, it also drives a third party risk management engagement of various vendors to vendors and Inevitably, at least in my experience, when we see something like this hit you will inevitably see, if you were a vendor to other businesses, their third party risk management team spinning up questionnaires to their suppliers, hey, are you impacted by this and what’s your plan?

Andrew: Which then drives another sense of urgency and a sense of reaction. That may be false urgency that’s taking your resources away from something that’s more important. But you can’t really ignore it. The urgency goes up when customers are demanding a reaction in this way, whether or not it’s truly your most important risk that you’re working, it doesn’t matter.

jerry: Having come from a service provider, I [00:35:00] lived that pain. And, and I’m sure you, you do too. Like you, you have to deal with it both ways. You have your own customers who you want you to answer their questions, but then you have your own suppliers. If for no other reason than to be able to answer your customer’s questions with a straight face, you’ve got to go and answer them. I think one of the challenges with that is where does it end ? I’m a supplier to some other company and I have suppliers and they have suppliers and they have suppliers and they have turtles all the way down, and If you think about everybody, assuming everybody acted responsibly and they all got their vendor questionnaires out at right away, but how long would it take to actually be able to authoritatively answer those questions?

jerry: I don’t know. I think it’s. I think there’s a lot of kabuki dance, I don’t know if that’s an appropriate term there.

Andrew: It’s executives saying, we have to do something, go do something. [00:36:00]

jerry: That’s true.

Andrew: And so then the risk management folks or third party risk manager or whoever do something and then they could point, Hey, look, we did something.

Andrew: We’re waiting for responses back from Bob’s budget cloud provider.

jerry: There’s a lot of hand wringing that goes on. I will also say having worked, in certain contexts you end up having small suppliers. You may end up with small suppliers who may not know they have to go do something.

jerry: And so your questionnaire may in fact be the thing that prompts them to go take action because their job is to deliver parts. They’re not a traditional service provider. They have some other business focus.

jerry: In those instances, it could very well be because like you said, not everybody has a threat intel team, that you are in fact telling them that they have to worry about something it’s, it doesn’t make it any less annoying though, especially if you have a, a real, a more robust security program in place. Because I don’t [00:37:00] know, in my experience, I’m not sure anything genuinely beneficial has come from those vendor questionnaires other than put potentially, like I said, the occasional you’re telling a supplier who was otherwise unaware.

Andrew: I think it breeds a false sense of security that you’ve got a well managed supply chain and a well managed third party risk management.

Andrew: I question the effectiveness.

jerry: Yeah I can agree with that.

Andrew: So not to be too cynical about it, but, and then I always wonder, what are you going to do? Okay, let’s say. Let’s say you’re, how soon could you shift to another provider? Okay. Let’s play this out. Let’s say you ask me and I’m running Bob’s budget cloud provider.

Andrew: Do I have polyfill? And I say, I don’t know. What are you going to do? You’re going to cancel your contract. Maybe you’re going to choose to go someplace else. Maybe it’s going to take time. Yeah, it could influence your decision to renew or continue new [00:38:00] business or whatnot. But

jerry: it’s, I think what you’re trying to say, and I agree is it doesn’t change the facts for that particular situation.

Andrew: Right yeah. And do you want me to spend time answering your questions or go fixing the problem?

jerry: I want you to do both, dammit. That’s that’s their view. What do I pay you for?

Andrew: I don’t know. I have a tough spot. I don’t have a really warm fuzzy about these sort of fire drills that get spun up around Big media InfoSec events.

Andrew: I think they’re, I think it’s the shark attack and it’s, do you have sharks in your lagoon? Maybe.

jerry: I feel like this whole area is very immature. It’s a veneer that, in most instances, I think is worse than useless because it does create a false sense of security.

Andrew: Yeah, I agree. And how do you know I’m not lying to you when I fill out your little form?

jerry: That’s the concern. We’re lying and there was a breach, like you would, you as the [00:39:00] customer would, crucify them in the media, or in a lawsuit

Andrew: Yeah, at the end of the day, it either becomes a breach of contract or a, I don’t know, I’m not a lawyer, but I haven’t fully articulated my thoughts on this yet. But there’s something I’ve just never really felt was very effective or useful about these sorts of questionnaires that go out around these well publicized security events.

jerry: Yeah, I agree. I agree. I think there is likely something sensible as a consumer.

jerry: Yeah. It is helpful to know the situation with your suppliers and how exposed you are, because then your management wants to know, Hey what’s my level of exposure to this thing? And you don’t want to turn your pockets inside out and say, I don’t know. But at the same time, I’m not sure that the way that we’re doing it today is really establishing that level of reliable intelligence. The last story comes from tenable the title is how the regression vulnerability could impact your cloud environment. So the [00:40:00] regression is cutely spelled with the SSH capitalized. So regression, this regression vulnerability was a recently discovered this slash disclosed vulnerability in open SSH.

jerry: I think it was for versions released between 2021 and as recently as a couple of weeks or months ago and can under certain circumstances allow for remote code execution. So kind of bad

Andrew: Yeah remote code execution Unauthenticated against open SSH that’s open to the world.

Andrew: Correct, but It’s not that easy to pull off.

jerry: Correct. There’s a lot of, there’s a lot of caveats and it’s not necessarily the easiest thing to exploit. So I think they say it takes about 10, 000 authentication attempts. And even with that, you have to understand the exact version of OpenSSH and information about the platform it’s running on, like [00:41:00] it’s a 32 bit, 64 bit, et cetera.

Andrew: Yeah. And I think that those tests were, a 32 bit. And it’s much tougher against 64 bit because you’ve got to basically get the right address collision in memory, is my understanding. Take that with a little grain of salt. But that was my understanding.

jerry: But not impossible. And so the point of this post is, OpenSSH is exposed everywhere.

jerry: Like it’s everywhere. And they point back to cloud and I think they point to cloud for two reasons. Reason number one is, in, I think cloud incentivizes or makes it really easy and in some instances, preferable to expose SSH as a way of managing your, your cloud systems. And in those instances, there’s almost always going to be open SSH. Unless it’s RDP, then it’s all good.

Andrew: It’s much preferred.

jerry: RDP is way better.

Andrew: There’s a GUI. There’s pictures.

jerry: There’s pictures. That’s right.

Andrew: A mouse works.

jerry: How [00:42:00] much better could it get? And then the other reason they are picking on cloud providers is that as a consumer, you are provisioning based on images that usually with most cloud providers, You’re provisioning your servers using images provided by the cloud provider. And those images may not be updated as frequently as maybe they should be. And so therefore, when you provision a system, it is quite likely, to come vulnerable right out of the gate. And you’ve got to get in there and patch it right away.

jerry: You’ve got to know that’s your responsibility and it’s not actually protected by the magic cloud security dust.

Andrew: At least, not your cloud. Maybe Bob’s budget secure cloud is, I don’t know, that joke didn’t work out, but you make an interesting point. And I think I was talking to somebody about this and I was trying to make the example that when we started doing this stuff pre cloud, because we’re old. [00:43:00] The concept of something being exposed to the internet was a big deal. Everything was in a data center behind a firewall, typically. And typically if you wanted to expose something to the internet, like an SSH Port or an HTTP port, an HTTPS port, that usually had a lot of steps to go through, and most companies would also make sure that you’re hardening it and making sure that, it really needed to be exposed.

Andrew: But with cloud, and I think you referenced this, it’s exposed by default. Most of the time there’s this, there’s not this concept of this thick firewall that, that only the most important things and well vetted and well secured things would be exposed to the internet. There is no more quote unquote perimeter. Everything’s just open to the internet. And that’s the way the paradigm is taught now with a lot of cloud providers, that there isn’t this concept necessarily of private stuff in the cloud versus public stuff. It’s just. stuff. And yeah they, talk to limited ACLs and only open the ports you have to and that sort of thing.

Andrew: But I think it’s super easy and super simple for people to just build something and I got to [00:44:00] get to it. So open SSH and, or whatever, or literally RDP and do what they got to do. And to your point, yeah, most of these images are not. hand rolled images. There’s something, some sort of image that you grab off of some catalog and spin it up and probably has a bunch of vulnerable stuff in it.

Andrew: But SSH we think of as safe ish. And, even security folks are like only have SSH open. But this to me speaks more and more to, it still matters what your attack service is, and you still shouldn’t be exposing stuff that doesn’t need to be exposed to the internet because you never know when something like this is going to come along even on quote unquote, your safe protocols to be open to the internet.

Andrew: So the less you have exposed, the less you have to worry about this. Now, I’m not saying that the only thing gets attacked is the stuff that’s open to the internet. We know that’s true, but it’s one more. hurdle that the bad guy has to get through. And again, buys you more time to manage stuff if it’s not directly exposed as an attack surface to a random guy coming from [00:45:00] China.

jerry: So the the recommendations coming out of this are a couple. First is making sure that you update, obviously that you update for this vulnerability, patch the vulnerability. Second is that when you are using cloud services and you’re provisioning systems with. A cloud provided image, make sure that you are keeping them patched, even newly provisioned systems are probably missing patches and they need to be patched post haste, limiting access, they talk about least privilege and they talk about that on two axes.

jerry: The first axis is With regard to network access to SSH, not everything should have access to SSH. It is not a bad practice to go back to the bastion host approach on a relatively untrusted system that then you use as a jumping off point to get deeper into the network where you don’t have every one of your systems. SSH exposed to the internet. It gives you [00:46:00] one place to patch. It gives you a lot more ability to focus your monitoring and whatnot. Now the other access they point out is that in the context of cloud providers, you can assign access privileges to systems. And so if your system is compromised it’s going to inherit all the access that you’ve given to it through your cloud provider. And so that could be access to S3 storage buckets or, other cloud resources that may be not directly on the system that was compromised, but because that system was delegated access to other resources they provide basically seamless access for an adversary to get to them. And that’s another, in my view, a benefit to that relatively untrusted bastion host concept that doesn’t have any of those privileges associated with it.

Andrew: Yeah, it’s a tough sell. I don’t think most cloud [00:47:00] architects think about it that way at all.

jerry: You are absolutely right. They don’t think about that until they’ve been breached. And then they do. Yeah. And I can authoritatively say that given where I came from.

Andrew: That’s fair. And part of the goal of this show is to try to take lessons. So you don’t have to learn the hard way.

jerry: There is a better way. And it’s not, no, it’s not as convenient. Not everything that we used to do back in the old days, when we rode around on dinosaurs was a bad idea. There are certain things that, probably are still apt even in today’s cloud based world.

jerry: I think one of the, one of the challenges I’ve seen is the, how best to describe it, the, like the bastardized embracing of zero trust. Again, in concept, it’s a great idea, it’s a great idea, but like the whole NIST password guidance that came out a couple of years ago where people looked at it said, Oh, NIST says I don’t need to change my [00:48:00] passwords anymore. It does actually say that, but it’s in the context of several other things that need to be in place, in, in the context of in the context of zero trust, that also portends certain other things. I think where zero trust starts to break down is when you have vulnerabilities that allow the bypassing of those trust enforcement points.

Andrew: Yeah. If you can’t trust the actual authentication authorization technology involved zero trust dependent upon that. I think the takeaway for me is you can never get to zero risk, but you never know when you might have to rapidly patch something really critical.

Andrew: And are you built to respond quickly? Can you identify quickly? Can you find it quickly? And can you patch it quickly? That’s the question.

jerry: And you can make it harder or easier on yourself. Design choices you make can make that harder or easier.

Andrew: Yeah. As well as how you run your teams. One thing that I’ve often tried to instill in [00:49:00] the teams that I work with is I can’t tell you what vulnerabilities are going to show up in the next quarter, but I know something’s going to show up. So you should plan for 10 to 20 percent of your cycles to be unplanned, interrupt driven work driven by security.

Andrew: And if you don’t, if you’re committing all of your time to things, not security, when I show up, it’s a fire drill, but I know I’m going to show up and I know I’m going to have asks. So plan for them. Even if I can’t tell you what they are, a smart team will reserve that time as an insurance policy, but that’s a tough sell.

Andrew: It’s a tough sell. Yeah. They don’t always buy into it, but that’s my theory. I try to do it, to explain at least and try to get them to buy into. And sometimes it works. Sometimes it doesn’t.

jerry: All right. I think I think with that, we’ll call it a show.

Andrew: Given the weather gods are fighting us today.

jerry: Yeah. I see [00:50:00] that it’s starting to move into my area, so it’ll probably be here as well. So thank you to everybody for joining us again. Hopefully you found this interesting and helpful. If you did tell a friend and subscribe.

Andrew: And buy something from our sponsor today, sponsored by Jerry’s llamas,

jerry: The best llamas there are. All right.

Andrew: I feel like all the podcasts need to need, use our code Jerry’s big llama box. Dot com.

Andrew: I’m just going to stop before this goes completely off the rails.

jerry: That happened about 45 minutes ago.

jerry: So just a reminder, you can follow the podcast on our website at defensive security. org. You can follow Lerg at

Andrew: Lerg L E R G on both x slash Twitter and InfoSec. Exchange slash Mastodon.

jerry: And you can follow me on InfoSec. Exchange at Jerry. And [00:51:00] with that, we will talk again next week. Thank you.

Andrew: Have a great week, everybody.

Andrew: Bye bye.