¶ Introduction and Episode Overview
Alright. Here we go. Today is Sunday, 07/07/2024, and this is episode 272 of the defensive practiced. My name is Jerry bell and joining me tonight as always is mister Andrew Ke. Good evening, Jerry. This is is a newly established record twice soon in a week or twice in a week. I can't believe it. I know. Awesome. Yeah You just had to quit that crappy job yours, provided income for your family and pets and
You know, everything else. But now that you're unemployed house, but now that you're unemployed bum. Yeah. I can podcast all I want 20 47II think I'm gonna become an influencer, like, I'm
¶ CISO's Guide to Avoiding Jail After a Breach
gonna just be live all the time, though. You could. I really... I look forward to you asking me to subscribe and hit that notify button. That's right. Hit that subscribe button. Like leave a rating in a comment? Like and subscribe. Alright. Getting with the program, we're we're getting back into our normal rhythms is per normal. We've got a couple of Thor to talk about the first 1 comes from dark rating and the title is a Cis guide to avoiding jail after a breach.
Before we get there. I wanna throw out the disclaimer. That thoughts and being not reflect any of our employers. Crash president or future. That's a great point or my cats. Unlike you, I have to worry about getting fired I still have a boss. Mid? That's called divorce sir. Well, but true. Yeah. Hey, back to your story. Anyway. Yeah. Cecil guide to avoiding Jail after a breach.
So this is this is following on a upcoming talk at, I think it's Black at talking about how Cis can try to ins themselves from the potential legal harms or legal peril 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 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, quote mister Sullivan, who was the Cis for Uber, 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, and before that he was a federal prosecutor. And in fact, as the article points out, he was 1 of the pre... He was the prosecutor who prosecuted the first the Mca
case. Which I thought was quite interesting. He didn't know that about him. But what's interesting is this article at least is based a lot on interviews with him. And including the
¶ Challenges and Complexities of the CISO Role
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. Yeah. This is such a tough 1 for me. And it makes I think a lot of good people and they references in the article wanna shy away from him, being a Cs. So if there's this sort of potential personal liability on the table.
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 Cis, whether it'd be budget, whether it be focused, whether it'd be company priorities, and you have an active adversary who is looking for any possible way to get into your environment. So what becomes the benchmark of what constitutes negligence up to the point of going to jail is the 1 that I've struggle 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 of events and chain of decisions that led to that situation.
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 5 or 6 different organizations at the same tunnel, 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 trouble. You've bet in this position, not in the going to jail part, and the that. This threat was much more meaningful to you in your last role than it is to me.
Is very uncomfortable. I'll tell you when when the Uber Cis got got charged and the Cis of Solar winds got charged that this an uncomfortable feeling an exposed feeling in criminal law there's this concept of strict liability. And strict liability basically means the thing happened. And because the thing happened, and you are responsible for the thing. It doesn't matter that there's no mitigating factors. Your your state of mind, your motivations, none of that matters in a strict liability case.
And to some extent, it feels like that in this instance, I don't think it really is, but although when you are cs so, sometimes, that thought can crush your mind. Now, in the article, they actually point out that though the Cis is the lightning rod when things go wrong, It is not just the Cis that is responsible for what went wrong. If they describe it, it takes so community, and the results of that community are as we've now seen or is alleged is being pinned on a particular
individual. And III think in I know from having read the Uber case. I've not not so familiar with the solar Winds case. Although I've, obviously familiar with what happened in solar Winds case. With Uber, it was a situation where they they had a a basically a data breach, and the allegation was that the 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 the case went. They negotiated a payment through
the bug bounty program. To the adversaries perhaps maybe ever series in the right word, allegedly deleted the data and because of that they didn't report the breach. 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 so it's not necessarily that he was malicious or what have you, but Now, basically, my Layman's read is, he was def distraught investors by withholding information about a breach that he was obligated to report. So that's a tough situation What concerns me is that this is a somebody who was a federal prosecutor. So like, I had I had plenty of competent legal counsel surrounding me. And that was a good thing. It felt good. And I'm quite certain He did do. Further, he himself was a prosecutor.
And so I have a hard time accepting, and maybe it's just very naive of me. I have a hard time accepting that he was actually trying to represent things or hide things. I guess that's where I'm at
on this It feels bad. And the article points out that because of this, 1 of the 1 of the whispers they describe it in the industry is that it's forcing people who are, you know qualified for the role and understand the peril that they face to shy away from taking that role, and that then leads to people who are maybe not as qualified, taking the role, and then obviously, not doing is good of a job, and therefore, actually, the net effect is a weaker security posture.
Yeah. Well, I think 1 thing that you can... If we try to get some advice on this, or try to give some advice out this. And the 1 thing they mentioned in the article is for a lack of a better term, tyson some other people in the organization to the same decision. Right? Make sure that your board is aware and your executives are aware and that you're not the only 1 holding the wrist bag at the end of the day.
That if you have to own the risk yourself, then you need to have former control Now in this case, we're talking about theory, he got trouble because he didn't notified the Sec and has was a public company was material breach and so stockholders weren't informed more so than he was ne 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. And this there's all new ones here. That's not exactly what happened here, but I find that very troubling and obviously, I have a bias because I'm in the industry and I would, you know, be at risk of that potentially. But I just don't think it's that simple. There's no Ce that has that much control over an environment that they should be solely responsible for taking the fall of a breach would to happen. Although that does happen all the time.
But it's 1 thing to lose your job something to go to jail. Yeah. And I think that the the author here points out that, at least as mister Sullivan describes that he feels like he was put forward by Uber as a official 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 C conspirators.
Sure with within the company. I think what they're trying to say is that you as a c social go to the board to your Ceo, do whoever and articulate the risk, not with the intention of them again, becoming coke conspirators, but of them saying, gosh now I know about it. I don't wanna go a jail. I'm gonna real you, the the money or do what do whatever is required in order to address the particular risk. Now I think in this instance 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? And I think that's a 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. Sure. Pardon of me, this is maybe is not exactly apples to apples, but I think about a lawyer advising get executive on the legal legality of something. That executive can take that advice or reject that advice.
Ce advising a company on the legality or outcome or risk of a decision. They'd always make that decision. I they there's someone be behold that their leadership on which way the company wants to go. There was a an unwritten aspect of this that I wanted to discuss a bit. And that is the sub of all of this, I think is going to create an ever serial relationship between the Cis and the Cis employer.
Because it feels to me like what the government would have preferred is for the Cis to to run the government and say hey, my employer isn't acting ethically. The show saying that's what happened in Uber case any of these cases, but I think that's what the government is trying to push. Now granted, there's a not so great line. Beyond which you have an ethical duty to
to write on your employer. You can imagine all sorts of situations, not even in in the realm of security where you would it'd be obligated to go and and report them. But it feels to me they're trying to
¶ US Supreme Court Ruling and Its Impact on Cyber Regulation
lower that bar. Yeah. I could see that. Unfortunately, this is probably gonna be messy to get sorted out, and it's gonna take a lot of case law. Is gonna take a lot of precedence that makes me nervous if I were offered a Seesaw opportunity a public company. I'd probably think real long an art about about passing on it or trying to assure some level of security to avoid this problem. Our next story throws some throw some sand in the gears there. This 1 comes from Cs online.
And the title here is Us supreme Court ruling will likely cause cyber regulation chaos. And so unless you've been living under Iraq or perhaps just not in the Us. You're you're probably aware that the Supreme Court, I guess it was last week. Overturned what has been called or referred to as the chevron defer doctrine.
The name comes from the the oil company Chevron, and it stems back from a 19 84, know, 40 year old ruling by the Supreme Court that, basically, I'll some summarize to say that ambiguous laws passed by congress can be interpreted by regulators like the Sec, the Fda the Scc and so on. In in the Us, at least, a lot of regulations are very high level. It'll say something... I'm gonna make it
make pick a stupid example. It'll, you, that will say uses this for authentication, and then it'll be up to a regulator to you say strong authentication means that you use multi factor authentication that isn't an Sms based. That initial ruling was intended to establish that courts aren't experts in all matters of law spite default courts should be deferring to these regulators.
And that has stood to test the time for c a long time, and now it was overturned in this session of the Supreme Court, whatever you wanna think about the the sen of it. 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 gonna be all manner of court cases challenging different regulations, which in the past were pretty well establishes following regulations set by the executive branch in the Us. But now as this article points out, things ranging from the the Scc requirements around the data breach notifications to the Gram Leach B act of 19 99.
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 the the 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, you know, deferred
to. And I... It's unclear. At this point by the way, how courts are going to pick up their new mantle of responsibility in interpreting these things because judges aren't experts in security. So I think that's why they're calling at chaos right now, because we don't really know what's gonna happen. For the long term, I think things will normalize. Yeah. Businesses hate uncertainty. Yes. And for good old businesses can have a huge impact on government legislation. Listen.
I think this will get sorted out of eventually. But Think you're right. I think what we counted on are at least tried to work around work with these regulatory agencies, and understand these rules have now all changed. And, I think you're right, There's gonna be probably a ton of of these rules that have the force of law being challenged down in court. And I think ultimately Congress has probably the range to fix this if they want, but I think that's another
interesting problem. If Scott is saying look, you regulatory agencies are taking the power of law in your own hands and we like that. So Power of law comes from congress and elected officials of Congress. Then Congress, you need to do a better job of defining these rules specifically. That presents its own set of interesting challenges because how well will they do that? And we've seen a lot of well attention laws, especially in very complex areas.
Have their own set of problems because of all of the trade offs and problems that go into the legislative light of work in congress causing issues. So it will be very interesting. This could have a lot of wide ranging impacts. And again your point, I'm not getting anywhere near whether they should or shouldn't have done this, but I think the intent was you una elected regulators shouldn't make law. Congress should make law. Okay? But that's easier said than done.
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. Not Not the executive branch. And that's what that's where I think if you read the majority opinion, that's basically to sum up. That's what they're saying. I I think the the challenges that when the constitution was written like there was it was a much much simpler tie.
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 my concur that this throws a lot of accepted precedent around our industry into question. Right. But at 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.
Sure. Yeah. Did the Sec made this law in essence could would be his argument and based on this particular ruling by Scot, that was an inappropriate ruling and earning inappropriate law, 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 get convicted and please politely pound sand.
Do think the... I do think this supreme court opinion did say something along the lines of if it doesn't overturn previously held court
¶ Polyfill.io Issue: A Modern Supply Chain Attack?
people are do their day in court. So if he has an avenue for appeal, that's how the justice system works. This this is hot off the presses. I think I think the echoes are still circling the earth, will 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 on this periodically. Okay. The next 1 comes from Sand Sack, and I... There's actually 2 stories.
1 from Sand 1 from the Security week, and this is regarding the Poly fill dot io issue. I'm hesitant to call it a supply chain attack. But I guess this is what everybody is calling it. Come on and get on the bandwagon again. No. I know. If you wanna be an influencer man, you gotta use the influencer language. Feel... It makes me feel dirty to call it a supply chain attack. So what What makes you so comfortable calling in a supply chain attack? I know. I don't know. I... That's a
good question. And I answer is I I don't really know. It just feels wrong. Did your mother talk to you a lot about supply chain attacks? No. Dude that's... Maybe that's the problem. 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 over? What's your not tree over why aren't you returning it over, Jerry? Don't even know where this is going. Ed light up at the last 2 stories man. Beat a downer.
Poly fill is a is a Javascript library that, many organizations included in their own website it does overs simplifying it it enables some types of more advanced functions or newer functions of modern and web browsers to work in older version 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, a remote document hosted on in this instance, poly fill dot I. 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. Correct. It's telling the web browser to go
get the code Right. Directly. What happened back in February was I don't fully understand what pre this, but the maintain of the poly filled dot j s library in the poly fill dot io o domain was sold to, Chinese company. And that company then started using They alt... Basically, they altered the Java script library to all alternatively, depending on where you're located and other factors. Either serve you malware or serve you, spam, ads, so on.
So you're saying they're are not hot singles in my area ready to meet me? I'm surprising, but they probably are usually. Carry. They can all be using Poly. Anyhow, there there were... Depending on who you believe somewhere ranging from 100000 websites that were including this Poly filled dot io o code to tens of millions as p by cloudflare. So, at this point, by the way, the the issue is somewhat mitigated. I'll come back to why I say somewhat mitigated.
The the poly filled that I owe 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, you know, still pointing to Javascript a code that's hosted by somebody else although presumably, companies like Cloudflare and Aka aquaman and fast are probably more trustworthy than funnel in China. Yeah. You know.
Because they actually came out and denied any malicious intent in crying foul on this whole thing too. Which was interesting. Yes. But people have done, a, you know, pretty good job and in fact, this the sand report pretty thorough examination of what was being served up, and, you know, you can very clearly see it. It's serving up some domain lookalike, like, I I find it hilarious dash any analytics com, which is supposed to look like Google analytics dot 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, 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 probably worth having your threat until teams, take a look at this because my guess would be that At some point in the future, the other domains that this organization owns will probably likewise be used to serve up malware. Bold of you to assume that all this have threat intel teams. Fair enough. You do. You just it just may be you. Correct. Me and Google. Right Yes. And my rs says feed of handy blocks penis. That's right.
But, yeah, they seem to have over a wee bit of a history of being up to no good, this particular Chinese developer. 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 p. Maybe I'm old school and it should be about the pasture. I think it's risky as we've seen
many times now. This is not by far the first time this has happened to be including by reference things hosted is part of some kind of an open source program. That's necessarily picking an open source there. I think it happens less often with commercial software. If... We've seen it now happen quite a few times with these open source programs either including things like browser extensions and and whatnot.
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 Poly fill dot Io. We're downloading the Poly code to their own web server, and most likely you would have between a hundred thousand and 10000000 websites serving locally modified code. But then again, nobody updates. Great. Would be affected, but we're running 28 year old versions. So maybe not.
Yeah. But boy, to your point, it gives me a little bit of He 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. I don't do much website development. I don't know if that's common. But as a security guy that makes me go, oh, that's risky. So we don't control that at all. Some
third party does. And we're serving that to our customers or our visitors to come to our website and we just have to trust it.
¶ Understanding Polyfill Confusion and Risks
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 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 way to scramble to find where they're using this, which then goes to. Hey, How good is your software bill of materials or software asset management programs to how quickly can you identify you for using
this? And then there was a lot of confusion when where first came up because there's
¶ Maintaining Open Source Software Health
different sort of kind of styles or or instances of poly fill that somewhere impacted somewhere not, How much of this is, you know, what truly was at risk, and the upside is that that the domain was black hold pretty quick. Edwin, it seems so fragile. Right? You've got this third party code. Hey you don't control. You don't know what's taylor other and you probably have ignored that it's even out there. And forgotten about, especially this is default code.
And that's a whole other egg that drives me a little. Crazy at night is, how do you know what an 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
¶ The Need for Open Source Health Ratings
things like, hey, if there hasn't been an update within 1 year, do we call that? No longer maintained. I don't know. I don't have a good answer. I play around with that idea with my developers and talked about because we wanna make sure that code is well maintained, and third party code that we're using is being, you know, up to date, we don't want end of life code. In general, but I don't know what constitutes end of life in open source anymore.
I I think we will eventually see some sort of health rating for open source projects. And that health rating will be based on
¶ Challenges with Third-Party Code and Security
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, you know, being made and other things like that. But it doesn't necessarily mean a whole lot. Look at what happened with what was it XZA couple. Yeah. You know, That was a very arguably
I won't call it healthy. Right? 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 we look at what happened with open ssl and then open ssh and It's not a guarantee. But I think it would be good to know that, hey, you have code in your environment. That is, you know, by reference, and it was just bought by a company who's known to be a malicious adversary.
And and... So we don't have that... We don't have any way of doing that today. So you want like a restaurant health inspector to show up and be like, alright. Show me your cleanliness Like, so, I think that we will get there. You would able sign in the window. This restaurant slash github repository. Earned a b minus, but has great brisket. Sometimes sometimes she just have to to. Right? Good good brisket is good brisket. I think that's gonna 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. Or have some sort of tooling or third party tool that some sort of software security, suite that scans your code and alert 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 pump this up on their solution. Oh, I'm... I feel quite certain that my Linkedin
The will be lit up with. Mh. People wanting to come on the show to talk about their fancy Ai enabled source could analyze. But it's just 1 more thing Devs said now I have to worry about a security have to worry about it. And this is a competition against developing new features and new functionality and fixing bugs. Is this is now just 1 more input to worry about, which competes priorities, which is why it's not that simple. It's very true. Way back when I was a deceased so...
He... She me 2 weeks ago? Way back. The way I had always characterized it is Using Open source software. It's like adopting a puppy. You can't ignore it. It needs to be cared for. You have to feed it and clean up after it. And walk it and 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 S bomb, and that, of course, will lead to better intelligence on what needs to be updated when it has of vulnerability, and that's certainly goodness. But I think that the end to end process in many organizations needs a lot of work. Yeah. I also think that this is never gonna go away in terms of companies, I think
¶ Vendor Questionnaires and False Urgency
right wrongly or will always be reliant on third party opens our software now. And so we've got it fine... And this is also a relatively rare event that that we're aware of. Of the hundreds or maybe thousands of open source projects that people use regularly. It doesn't happen very often. It's the shark attack. Simply you hear about it every time it happened. And so it's it seems like it happens often. But when
it does happen, it can be spectacular. It's interesting because when leasing things hit, a certain level of press awareness. It also drives a third party risk management engagement, of various vendors to vendors. And in 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?
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 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 doesn't matter. Having come from a service provider. Live that pain. And and I'm sure you you do too. Like, you you have to deal with it both ways.
Who have your own customers who, you want you to answer their questions. But then you have your own supplier if for no other reason than to be able to answer your customer's questions with a straight face. Is that great? You've you gotta go and answer that them. I think 1 of the challenges with that is Where does it in? I'm a supplier to some other company, and I have suppliers and they have suppliers and they have suppliers and they ask. 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 authoritative answer those questions? I don't know. I think it's I think there's a lot of K dance and well it's an appropriate term there. It's executive saying we have to do something, go do something.
What do. And so then the risk management folks so the third party risk manager whoever, do something and then they could point, hey, look, we did something they were waiting for responses back from Bob's budget cloud provider. There's a lot of hand ringing that goes on. I will also say, having worked in certain context, you end up having small suppliers. You may end up with small suppliers who may not know they have to go do
something. 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 of their business focus. In those instances, it could very well be because, like you said, not everybody has a threat cell team that the 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 AAA more robust security program in place. Because I don't 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. 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. I question the effectiveness risk. Yeah. I can agree with that. Yeah. So not to be too cynical about it, but And then I always wonder what are you gonna do? Okay. Let's say let's say you're... How soon could you shift to another provider at? Okay. Let's play this out. Let's say, you ask me and I'm running Bob's budget cloud provider. Do I have poly phil? And I say, I don't know. What are you gonna do? You're you gonna
cancel your contract? Maybe? You're gonna choose to go somebody else. Maybe. It's gonna take time Yeah. It could influence your decision to renew or continue new business or went up, but... I think what you're trying to say and I agree is it doesn't change the facts for that particular situation. Right. And do you want me spend time answering your questions or go fixing the problem? I want you to do both in it. That's their. What do I pay you for? I don't
know. I'm a tough spot. I don't have a really warm fuzzy about these sort of fire drills it gets spun up around big media info tech events. I think they're... I think it's a shark attack, and it's Do you have sharks in your Lagoon? Maybe. I feel like this whole area is very immature. It's a v that in most instances, I think is worse than useless because it does create a false sense of security. I agree. And how do you know I'm not lying to you? When I felt like you're little
for? That's the concern. We're lying and there was a breach like you would you is the customer would cr them in the media or in a lawsuit? Yeah. At the end of the day, it either becomes a breach of contract or a Yeah Know, who a lawyer, but I haven't fully articulated my thoughts on this yet, but there's... It'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 secure events. Yeah. I agree. I
agree. I think there is likely something sensible
¶ The Regression Vulnerability in OpenSSH
as a consumer, 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 wanna turn your pockets inside out and say, III 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. Last story comes from 10. The title is how the regression
vulnerability could impact your cloud environment. So I don't the regression is acutely spelled with the to h capitalized. So regression... This regression vulnerability was a recently discovered the slash disclosed vulnerability and open ssh. I think it was poor versions released between 20 21 and Recently is a couple of weeks or months ago, and can under certain circumstances allow for remote code execution. So bad.
Yeah. Rec... Remote code, execution un authenticated against open s ssh that's open to the world. Correct. But it's not that easy to pull off. 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 10000 authentication attempts and even
¶ Cloud Security Best Practices
with that, you have to understand the exact version of open ssh and information about the platform it's running out like 32, bit 64 bit, etcetera. Yeah. And I think that those tests were the 32 bad, and it's much tougher against the 60 64 because you gotta basically get the right address collision in memory. Is my understanding. Take that with a little great assault. I'd... But that was my understanding. But not impossible. And so the The point of this post
is Open ssh is exposed everywhere. Like it's everywhere. And they point back to cloud, I think they point the cloud for 2 reasons. Reason number 1 is, and I think cloud incentivize this 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 are almost always going to be the open ssh. Unless it's rd p. The not good. And it's much preferred. Are are piece way better. It's a b. There's pictures.
Pictures. That's right. A mouse works. What how 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 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 if you've gotta get in there and patch it right away. You've gotta know that's your responsibility and it's not actually protected by the magic cloud security dust. At least not your cloud. Maybe Bob's budget secure cloud is. I don't know. But that joke didn't work out. But you make interesting point. And 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. The concept of sony 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, I get Ssh port or an Http port H b port. That usually had a lot of steps to go through in and most companies would also make sure that you're hardening it and making sure that really needed to be exposed. But with cloud, and I think you referenced this. It's
exposed by default, most of the time. There there's this there's not this concept of this thick firewall that only the most important things and well vetted and secure things would be exposed to. There is no more quote unquote perimeter. Everything's just opened to the Internet. And that's a way paradigm is hot 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 talked to limited Ac cl and only open the Ports have to, and that sort of thing. But I think it's super easy and super simple for people to just build something and I gotta them get to it. So open s sage and or whatever or literally Rd be, and do what they gotta do. And to your point, yeah, Most of these Images are not pad rolled images. There's something some sort of image that you grab off of some catalog and, spit it up and probably has a bunch
of vulnerable stuff in in. But Ssh we think of as safe. And even security first like only have Ssh open. But this to me speaks more and more to It still matters what your tax surfaces is, and you still shouldn't be exposing stuff, that doesn't need to be exposed to the Internet because you never know it something like this is gonna come along. Even on Quote unquote your safe protocols to be open to the Internet. So the less you have exposed, the less you have to
worry about this. Now I'm not saying that the only thing gets tagged the stuff that's open to the Internet. We know that's true. But it's 1 more hurdle that the bad guy has to get through and it buys you more time to manage stuff If it's not directly exposed as an attack service to a random guy coming
from China. So the the recommendations coming out of this are 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 your 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 taste, limiting access.
They talk about lease privilege, and they talk about that in 2 axes. First seasons 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 un trusted system that then you uses a jumping off point to get deeper into the network. Where you don't have every 1 of your systems with Ssh exposed to the internet. It gives you 1 place to patch it gives you a lot more ability to
focus your monitoring than whatnot. Now, the the other axis they point out is that in the context of cloud providers you can assign access privileges to system. And so if your system, it 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 as 3 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 adversary to get to them. And that's another in my view, a benefit to that relatively interested be concept that doesn't have any of those privileges associated with it.
Yeah. It's a tough sell. I don't think most cloud architects think about it that way at all. You are absolutely right. They don't think about that until they've been breached. And then they do. Yeah. And I can I can authoritative say that given where it came from? It'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. There is a better way. And yep. It's not... No. It's not as convenient.
Not everything that we used to do back in the old days when we were wrote around and dinosaurs was a bad idea. There are certain things that probably are still apt even in today's cloud based world. I think 1 of the 1 of the challenges I've seen is the how best to describe it. The, like, the bastard embracing of 0 trust. In in concept, it's
a great idea. It's a great idea, but like the whole N password guidance that came out a couple years ago where people looked at us said, oh, this I don't need to change my passwords anymore. It does actually say that, but it's in the context of several other things that need
¶ Final Thoughts and Recommendations
to be in place. In in the in in the context of 0 trust that also port certain other things. I think where Z trust starts to break down is when you have vulnerabilities, that allow the bypassing of those trust enforcement points. Right. Yeah. If you can't trust the actual authentication authorization technology involved, To trust dependent upon that. I think the the takeaway for me is you can never get to 0 risk, but you never know when you might have to rapidly patch something really critical.
And are you built to respond quickly? Can you identify quickly? Can you find it quickly and can you patrick quickly? That's question make it. And you can make it harder or easier on yourself? The design joint design choices you make. Can make that harder or easy? Yeah. As well as how you run your teams. 1 thing that I've often tried to instill in the teams that I work with is I can't tell you what vulnerabilities are gonna show up in the next quarter. But I know something's gonna show up.
So you should plan for 10 to 20 percent of your cycles, to be unplanned interrupt driven work driven by security. 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 gonna show up, and I know I'm gonna have asks.
¶ Conclusion and Farewell
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. It's a tough sell. Yeah. Mh They don't always buy into it, but that's my theory I tried to dirt to explain at least and try to get them to buy tune. Sometimes it works. Sometimes it doesn't. Alright. I think I think with that, we'll call it a show. Given the weather gods are fighting us today. Yeah. The And I see that it's starting
to move into my area too. So it'll probably be here as well. So, thank you to everybody for joining us again. Hopefully you found this interesting and helpful. But if you did, tell friend, you can subscribe. And buy something from our sponsor. Today, sponsored by Jerry's Llama. The best llama there are. Alright. I feel like all the podcasts need to need use our code. Jerry's big llama box dot com. Or I'm just gonna stop before this goes completely the author rails.
That that happened about 45 minutes. So just a reminder, you can follow the podcast on our website at defensive security dot org. You can follow le at... Le, LRG on both x slash twitter and info dot exchange slash mastodon. You can follow me on info bad exchange add jerry. And with that, we will talk again next week. Thank you. Have a good weekend everybody them.