Episode Transcript
[00:00:14] Speaker A: Welcome to the security Serengeti. We're your hosts, David Schwiniger and Matthew Keener. Stop what you're doing and go and immediately follow us on twitter as at serengeti sec. We have a disturbing mean paucity of followers.
[00:00:27] Speaker B: So we're here today to talk about some recent news and headlines and hopefully provide some insight and analysis and practical application that you can take back to the office and use that to help protect your organization.
[00:00:39] Speaker A: The views and opinions expressed in this podcast are ours and ours alone and do not reflect the views or opinions of our employers.
[00:00:46] Speaker B: And listen to this is time better spent than watching the phantom menace.
[00:00:51] Speaker A: And everybody just craps on the phantom menace.
[00:00:54] Speaker B: All right, for good reason.
[00:00:57] Speaker A: Our first article today is from bleeping computer. It's actually not the first one we found. We found one somewhere else. But I realized that the article from that other place, which will link in the show notes, was just summarizing the bleeping computer article, getting those views from somebody else's hard work. So I wanted to call out the original article here. This is about ransomware gang urges victims customers to demand a ransomware payment. And this has started off with, well, I don't know if it started off with them, but the first major gang to get noticed doing this was the Klopp ransomware gang. They have started reaching out to the victim's customers and notifying them that the victim was breached and that the customer's data is at risk of exposure. I don't know if we should really call Klopp a ransomware gang anymore since they were behind the Excelion breaches recently, which is not ransomware.
[00:01:47] Speaker B: You want to call them a boutique attacker.
[00:01:50] Speaker A: You know, I heard that there were people that said that malware was really nicely done, but this is just a further evolution of attacker methods. Like ransomware started off by just encrypting the data and asking for payment. Then they took the data and threatened to release it unless you paid. Now they're adding the social component that we're going to tell your customers, we're going to tell the journalists if you don't pay. I'm almost curious what's next.
[00:02:20] Speaker B: It's just like any other business. They're evolving their capabilities or their market offering or pivot or however you want to put it, saying. All right, well, this made some money. We're seeing decreased revenues are here. Let's expand into this area, which is related, and get additional revenue that way.
[00:02:41] Speaker A: So next would be social media advertising campaigns.
Your company has been compromised on the walls of the people movers in the airports. That's where I want to see it.
[00:02:53] Speaker B: Well, actually, you know, what I'm thinking is targeted advertising.
They link that into, well, third party cookies are having some challenges lately, but some other third party advertising says, oh, if this, this and this about you, then you're probably caught up in this data breach. So let's ensure that the next ad you see is saying, hey, you should contact this company because your data is going to be exposed unless you convince them to pay for it.
[00:03:21] Speaker A: Yeah, and I definitely put a note down here. I think the next step for them, too, is if they haven't already, I think they have in some cases already started doing this, but it hasn't reached wider acceptance yet. But they're going to start asking for separate ransoms from each of those customers, especially if it's embarrassing information.
[00:03:36] Speaker B: Yeah, I think this kind of relates to that conversation we had around Acceleron a couple of weeks ago and that law firm that got breached.
Yeah.
And in the article that we're referencing here also talks about a chain of psychotherapist organizations in Finland, I think, that were breached and they were threatening the customers were releasing their therapy sessions.
[00:04:09] Speaker A: Yeah, that would be very painful, I have to imagine.
[00:04:14] Speaker B: Oh, yeah, for sure.
[00:04:16] Speaker A: So are all ransomware gangs doing this? And if they're not, how long do you think it'll be until they are?
[00:04:22] Speaker B: Well, it depends on whether it turns out to be a tried and true method for increasing revenue, I think. So. It's kind of like testing the waters, almost. Say, is this method going to be successful? The more successful this method is, the more gangs you'll see pile onto this.
[00:04:39] Speaker A: Are they sharing the information, though? I have to wonder if each one's going to have to try and test it out themselves and see if it improves their income or if they're actually going to share and talk between each other. Like, you'll never believe this one weird trick.
[00:04:52] Speaker B: I don't know.
They have malware as a service and all these other nefarious activities as a service. So I wonder if some enterprising attacker out there is going to start doing seminars and stuff like that and saying, oh, well, we learned this here and that here. And here's how you're more successful with your attacks, is by combining this and that.
[00:05:18] Speaker A: And, I don't know, breach advertising as a service. It's part of your component. You get to choose your malware from your ransomware gang. You can choose the entry vector. What group is going to distribute your malware for you. And then you can choose how to advertise that you successfully breach the company.
[00:05:35] Speaker B: Actually, this might be a lucrative realm for like an attack broker, if you will, to say, hey, you want to run an attack?
These guys make the best dropper. These guys have the best social engineering, these guys have the best ransomware infrastructure. And kind of saying, all right, I'll be the middleman for you and I'll bring all these pieces together for you into unified attack platform, kind of saying, I'm going to pull together best of breed, or maybe you could even have a menu option. Here's five potential fishing vendors to use. Here's five different payload options. And you just kind of like click through and say, all right, check out. And you check out your bundle. Maybe you get a discount for certain bundles together.
[00:06:25] Speaker A: Yeah. Value added reseller for malware. I like it.
[00:06:27] Speaker B: Exactly.
[00:06:29] Speaker A: Let's go ahead and get our name registered and get us into that.
[00:06:34] Speaker B: All right.
[00:06:35] Speaker A: Now this is something I thought of, and this may be dumb, and I apologize for bringing it up if it is, but I'm wondering how long now until the first lawsuit from a customer, let's say for someone with a psychotherapy session suing the doctor or the hospital, saying that they should have paid the ransom to ensure their stuff was kept private because they had a responsibility to keep their data private, I think that's.
[00:06:59] Speaker B: Going to determine where the negligence is determined to fall out. Were they negligent in allowing to get out in the first place and then even more negligent than to fail to pay.
So this is probably something that will end up being worked out in the courts over time would be my guess. And you're getting some precedents here for how this is going to flush out.
[00:07:22] Speaker A: Yeah, I can especially see it for the health care industry. That's definitely the side where people tend to be a little more protective about their data, although it'll be really interesting, especially for some of these multinational countries where the US has fairly stringent regulations against doing things like paying bribes and against using corporate money for executive welfare, shall we say. But maybe some of those executives expect better treatment. And it might be interesting to see if there's more of a reputational hit to certain corporations where they're willing to pay more or willing to fight to keep that stuff out of the public eye.
[00:08:02] Speaker B: Yeah, it's another item in the risk calculation.
[00:08:07] Speaker A: Do we pay bribes? Well, we should be, we should take more care to make sure our systems are secure.
[00:08:12] Speaker B: Let's see what the lawyers have to say. If they have that written down in the policy somewhere. It is our corporate policy to pay bribes.
[00:08:20] Speaker A: But you see those stories come out. They don't come out every year, but it's often enough that executives get these kinds of perks or whatever that the company ended up paying for somehow that you kind of feel like people somewhere know where was. Oh, I was listening to a podcast about doing business in China. That's what I was listening to. I don't remember what podcast it was, but they were talking about how in China, the corruption is just extremely widespread and everybody's being paid off all the time. And if you're in the communist party or any of the leadership like, you expect to be paid off. And the way that american and other western countries deal with it is they just give giant lump sums of money to their chinese subsidiary partner, and then that way, they don't know about it. They just know that we paid our chinese partner this amount of money. We don't know what it went for.
[00:09:09] Speaker B: Plausible deniability for a slush fund.
[00:09:12] Speaker A: Yeah, but there's got to be tons and tons of things like that that companies are just paying into. They've got a private jet and they've got a party fund or, I'm sorry, social fund or something like that. You just hear about this stuff often enough that you know it's there.
[00:09:28] Speaker B: Right. And it could be that they kind of put this in standard terminology. So it depends on the DDoS mitigation vendor. They may say you were covered for x, and anything above x, you have to pay for ongoing attack mitigation or something like that. So you have to say that, all right, we're only willing to pay x amount of money for DDoS mitigation before. We're simply fine with being offline for x number of days or something like that. So they may also have something in their policy which says, in case of ransomware, we will pay up to x amount of dollars or be willing to pay up to x amount of dollars for the attacker to get that data back. But of course, with the increased use of cyber insurance, which is really why all these local municipalities in America were getting hit, is because virtually all those were insured and the insurance companies were willing to pay those off. So you may hit a small municipality who doesn't have much funds in and of themselves, but their insurance companies got deep pockets, so they'll pay that.
[00:10:55] Speaker A: Yeah. And a leaked article I found said that the average ransomware Payup went up almost three times, from 115,000 in 2019 to 312,000 in 2020. So yeah. They're still making money. They're still getting those payouts.
[00:11:10] Speaker B: That's crazy. And I assume that's just the ransomware. So we're not even talking about these additional fees on top of that. Because at this point we're kind of getting to the point where every attack. Every ransomware attack is like a three fee circus. Yeah.
[00:11:25] Speaker A: They should come with itemized receipts.
[00:11:28] Speaker B: Decryption pay not to release. And then the victims pay not to release. The victims. Customers pay not to release.
[00:11:34] Speaker A: Why get paid once when you can get paid three times?
[00:11:37] Speaker B: Exactly.
[00:11:39] Speaker A: Is there anyone else that we can hit with this? Related to this?
Bet you could get third party too. I don't know if that counts as customer. But like provider and third party people. Partners. Can we get paid four times? Five times?
[00:11:54] Speaker B: Well. It depends on the data that you end up getting out of there. If you get multiple different types of data. Possibly you could itemize that out.
But all this stuff also can run afoul of the US government because if whoever you're attacked by is a sanctioned organization. The US says well you can't actually give them any money at all because they're sanctioned and that's federal crime.
[00:12:22] Speaker A: Terrorists.
[00:12:23] Speaker B: Right. Right. Exactly. If they're on that list.
So that runs into a whole other bunch of problems.
[00:12:30] Speaker A: How does a company know if they're on that list necessarily? Attribution is not an exact science.
[00:12:37] Speaker B: I guess they'd have to rely on who the attacker says they are.
[00:12:41] Speaker A: I guess them politely.
[00:12:44] Speaker B: Hey.
[00:12:44] Speaker A: Are you guys iranian? No. Awesome. All right. Here you go. Here's your check.
[00:12:51] Speaker B: No. We're from Brooklyn. It's okay.
[00:12:55] Speaker A: My final thought kind of on this in terms of points of discussion is when does ransomware become so ubiquitous that you can just start ignoring it? Just thinking about the excelion breach. I know that they said that something like 60 companies were affected and yeah. You can go and you can look them up. But I don't know any of them offhand. There's nothing that. It's just so much back when target was breached. I don't even know how many years ago that was. It was a lot. It's Covid time. Time doesn't matter. But there was a lot of talk about like would this be the one where a company finally goes under and security is taken seriously? And security was taken more seriously. But it didn't really have much of an impact. The stock dropped a bit. Stock bounced back. And now we're at the point where they're so common that it's not even affecting stock anymore.
[00:13:43] Speaker B: Yeah, it's kind of like ransomware is going to get to the point where it's like a commodity malware.
My, my thoughts on this is I'm not an operating system programmer, but the OS developers, Microsoft, Apple, people doing the Linux open source stuff. There's got to be something you have to do at the operating system level. So that's ubiquitous in order to do something about this ransomware because until we get to that point where the ransomware is just not effective anymore as a method, then this is going to keep going because it makes money.
They're not interested in fame. So not reporting on it or ignoring it doesn't matter.
They don't care if it's not reported that they got this level of, or these number of companies or this much money from whoever they attacked. So simply not reporting it. Which listening to different security folks are like, well, this is so ubiquitous now. Like you said that I'm not even a talk about it anymore because it happens every day, multiple times a day. It's just background noise now.
[00:14:59] Speaker A: Yeah.
[00:15:02] Speaker B: So I really think the operating system vendors need to step up if this is ever going to come to a stop.
[00:15:07] Speaker A: You'd almost think that there are certain alterations, like if you edit so many files in a certain period of time, like the operating system freezes file editing for a period of time or. I don't know.
[00:15:19] Speaker B: Yeah, that's what I'm saying. There's got to be somebody, I mean, way smarter than me, obviously these software companies that can figure this out. I know. I asked Microsoft this question a year or two ago and the Microsoft guy said, oh, well, we've got really good backup stuff.
[00:15:40] Speaker A: You can back up the encrypted files. Helpful.
[00:15:42] Speaker B: Yeah, good job.
[00:15:44] Speaker A: Actually, speaking on the Microsoft subject, I just discovered the other day that there's like yet another source of alerts in Microsoft, that they just keep rolling out new alert sources and trying to find them in Microsoft in the Office 365 environment is kind of a pain. They've got like five or six different places for alerts to be.
[00:16:02] Speaker B: Well, at least they're generating alerts, but.
[00:16:04] Speaker A: They'Re not telling us about them.
It's a secret. All right, so why does this matter? This matters because this is going to be additional pressure during and after an incident beforehand. Your pressure came from regulators for reporting. Your pressure came from your own executives. Your pressure came from potential journalists reaching out to you. But now if you've got victim or customers of yours who are being directly reached out to by the threat actor, and they're going to be pushing them to go talk to you about it.
This is going to be a lot more pain and suffering for the legal and comms team.
[00:16:41] Speaker B: I was just going to say on that point. I was just thinking, reading through the article, it sounded like those emails were much more targeted to specific individuals. Imagine if they sent that note to everybody.
You could end up, if the breach is large enough, you could end up with actual people at your building out front with a sign or something.
[00:17:03] Speaker A: Yeah, or a Twitter storm. Your customer relations team, like saturating your system with tickets, calling your help desk.
[00:17:12] Speaker B: Yeah. This could easily lead to second and third order effects we haven't even thought of yet, just based on how the customers respond to those notifications from the attackers. Like you said, their entire help desk could be, or customer support line could be completely disrupted or non functional effectively because so many people are contacting them about the incident.
[00:17:39] Speaker A: I would also bet that this is going to mean more victims are going to pay and therefore that's going to lead to more ransomware because it's going to become more profitable.
[00:17:46] Speaker B: Right.
[00:17:47] Speaker A: What should you do about it? It's pretty simple. There's not much you can do about it immediately other than make sure that this is included in your tabletops. Make sure this is included in your incident response plan. Make sure that you have talked to legal. Make sure you talk to your communications department and figured out, all right, what happens if we start getting these in? Do we need to staff up? Do we need to post a message sooner and let people know that we know about it, not to contact us? Just be prepared for that pressure and game it out and figure out exactly what you're going to say beforehand.
[00:18:19] Speaker B: And if you do have a customer support line, consider the option to add a menu item in there or something that actually diverts them from talking to a person with a script or something. And make sure that your customer support reps on your phones are aware of the talking points that you want them to know. Should a customer call in about this.
[00:18:39] Speaker A: Particular thing, one thing you would consider as well, including maybe in that script or on your site, is justification on why the ransom shouldn't be paid. If you're planning on not paying it, this is actually kind of an opportunity for your company to set like a moral stance. Not that companies are moral, they're the opposite in many ways, but there's a chance for you to look good for you to know, oh, but paying ransom gives money to the bad guys, and we would never do that, yeah, it's.
[00:19:07] Speaker B: Kind of like Apple taking a stance on privacy.
I mean, it's not the exact same thing, but you get where I'm coming from. They're saying that this is something that we think is important and we're doing this for what we believe are moral, I suppose would probably be the closest word to use there for that.
[00:19:33] Speaker A: And you mentioned an interesting point about the second and third order effects, because for most breaches, many consumers and customers don't find out or care about whether there's a breach or not. Like target was big, Home Depot was big, but nowadays they're so common, most people don't find out about it. So what happens this time when all your customers are being emailed personally to say that you've got breached, you may have trouble retaining them as customers.
[00:19:59] Speaker B: Right. Because before they get the standard letter, hey, you've got credit protection. Congratulations.
[00:20:08] Speaker A: If you even got that.
[00:20:10] Speaker B: Yeah.
All right.
[00:20:12] Speaker A: Well, that's all I have to say about that article. We'll put a link in the show notes course. And I'll also link those other two articles, both the one that we originally found and the linked one about ransomware payouts. Second fun, one we have today is from CSO online. And it is experts fear that Biden's cybersecurity executive order will repeat mistakes of the past. This one's a little different than the other one. We don't have any kind of direct, here's what you should do. But we just kind of wanted to talk a little bit about how the government approaches cybersecurity and how know tell their contractors and other people how to do it. So as the summary, there have been some recent rumors that Biden is going to be releasing nearly a dozen executive orders in response to the SolarWinds hack. In case you've been living under a rock, the solar winds hack is, of course, where somebody, ostensibly a russian actor, did a supply chain compromise. They got into SolarWinds and then they pushed the malware out to everywhere that SolarWinds had an installed base. They didn't compromise everybody. They pick and chose their specific targets and then compromised those targets. So according to the draft order seen by reporters, it's going to require government contractors to do a couple of things. Number one is report attacks on their network and software similar to GDPR. Encrypt data at rest use two factor auth on secure build systems. Keep those secure build systems inaccessible from the Internet. Track the identity of users on the secure build systems, and they're going to have to create a software bill of materials that breaks down the pieces of code in the software product that was not particularly detailed, but I am imagining it's something like what are the packages used in here so you can kind of track like, oh, it uses this open source package that has a bug and needs to be patched. I know back from my days in doing vulnerability management that was frequently a pain where you would not know that something needed to be patched unless the vendor released a patch for it.
[00:22:13] Speaker B: Well, that runs into the additional problem of that recent name eludes me at the moment. But the package update vulnerability, if you will, in the way that software packages are updating internally where they would rather than look to an internal package update repository, they'd go out to the Internet and get what should be ostensibly an internal only package update from the Internet which contained malware or could contain malware. And there were huge organizations that ran afoul of this particular risk, if you will, or vulnerability based on the way their update process worked.
[00:23:04] Speaker A: It's like a larger version of a DLL search order hijacking for malware where. Yeah, it expects to go to this place first and if you can sub your malware in there. Interesting. All right, before we dive into discussion, there were some concerns raised by people who saw draft versions and they interviewed a couple of people and each person had their one concern, they're going to harp on a big one, was not enough focus on cloud. And reading through those above, it really does not seem like it's very forward looking, but we'll talk about that in a minute. Second concern, these are all things that have been tried before, concerns about the reporting time being too short. I think they said 72 hours and nothing around intruders already in the network. So that's kind of the summary and I kind of want to go through those concerns each one by one.
I have a fun quote from the article I'm going to read at the end once we get all the way to the end, I think so the first discussion point is 72 hours too short to report. I think right now in GDPR is 72 hours. And one of the experts in the article quoted said that they believe this is going to lead to a lot of false positives being reported up and kind of a general clouding of the reporting as there's just so much stuff being pushed upwards.
[00:24:17] Speaker B: It depends on who's doing the reporting. I know years ago in the DoD these exact same conversations came up about reporting just up through the regular reporting channel. It's about compromises and the time between identifying the compromise or the incident and then reporting it up, the farther up the chain you got in the higher levels of the chain, they would look down and say, well, you have to report what you obviously know is a compromise. There's no doubt that it's a compromise. And they couldn't wrap their minds around the fact that it's really hard to say with absolute certainty within a real short period of time that this was in fact a compromise and have the decent amount of details to report up. So some organizations would just say, for instance, if you give us a 72 hours window like they're suggesting here, we're not going to tick off that 72 hours point that the compromise may have happened five days ago. Well, we're not going to say 72 hours until we declare that this is an event or an incident. So you could have a week of investigative time and then have a declaration point and say, okay, here's the declaration point. Now we have three days. So it depends on how this is written as to when that clock is actually going to start. And smarter organizations will kind of be able to play around with that and probably be able to sidestep it if the language is not very distinct or very exacting in the executive order.
[00:26:00] Speaker A: That's been my experience in the past is we don't really worry about the reporting requirements. We just take a lot of care not to say incident or breach or confirmed because as soon as somebody says we've been hacked or whatever your local vernacular version of that is, then the countdown starts. So, yeah, I'm not too worried about that one.
I don't think that's a real concern, except maybe among people that aren't as, I mean, and frankly, even the declaration involves legal.
You bring the lawyers in first or as soon as you think that it may be something reportable.
[00:26:39] Speaker B: Right. And hopefully that's spelled out in your IR plan or your communications plan.
[00:26:45] Speaker A: Yeah, that's funny. You would think at this point in time at least all the multinationals have it because they've had to deal with GDPR. But a lot of us only companies probably haven't had to deal with reporting unless they're in New York or California. Are those the only two states that require reporting? I don't remember.
[00:27:04] Speaker B: Well, Virginia just came out with one as well.
[00:27:06] Speaker A: I imagine it's probably different than California and New York, of course.
I mean, at some point in the near future pretty much everybody's going to have to do this. You might as well get out of it, get in your IR plan. Figure out what you're going to do.
[00:27:20] Speaker B: One of the things that I think is interesting about this concern they're pushing this down to the contractors is there's a vast difference in the size and organizational capabilities of the contractors. The government has. There are probably several smaller contractors that what they're trying to push on them is really outside their capabilities.
[00:27:46] Speaker A: Yeah, anytime you push new requirements down and there's not accompanying funding, they're going to have to take that funding from somewhere and do something to accommodate it.
[00:27:56] Speaker B: Not that I feel bad for government contractors, I'm sure.
[00:27:59] Speaker A: Well, that just means they get to increase their prices another 10%. Yeah.
[00:28:02] Speaker B: I was going to say hammer is now going to be $700 versus five.
So the savings is passed on to you, or, I mean, lack of savings is passed on to you.
[00:28:14] Speaker A: So just because these things have been tried before doesn't necessarily make them wrong either. In terms of the expert was saying, like, we've tried this before and it hasn't worked in the past. And I think the security industry as a general kind of has a problem with that. I work in IR. I do a lot of IR stuff. And to be honest, I think that about 90% of my job would go away if companies could do the basics. I couldn't tell you how many times I've had to respond to something where something was exposed on the Internet that wasn't supposed to be, or somebody clicked on a link that was obviously not from the company or just misconfigurations and mistakes. And that's got to be 90% of my workload.
[00:28:58] Speaker B: Well, I mean, that's what you and I have talked about before, how cybersecurity is mostly the hidden factory of it, where if it did everything exactly correctly, security would have a much smaller role or much less work to do.
I'm not trying to say that it is horrible or they don't try to do their best and do their jobs. A lot of this stuff is hard to do.
[00:29:26] Speaker A: Yeah. It's extremely complex environment and systems upon systems upon systems. Just the order of complexity is ridiculous.
[00:29:34] Speaker B: I get that.
[00:29:35] Speaker A: Right.
[00:29:35] Speaker B: And security isn't their number one purpose or function. Making money is, well, providing value to the organization. So the organization can make money.
[00:29:46] Speaker A: Yeah. Step two, question mark. Question mark, question mark. Step three, profit. I get it. So I am curious why these things are not already part of the government contractor requirements. I mean, some of them, obviously, keeping extra track of the security build servers are a direct response to the solar winds. But some of the other ones, like tracking the identity of users on the systems. I was a government contractor. I'm pretty sure we had to do that, like, a decade ago.
[00:30:13] Speaker B: Yeah, they have logging requirements, but that makes me think about how he says that cloud is not mentioned in here. I wonder if it's not mentioned in here because that is part of the whole Jedi contract or something that Microsoft was awarded because the government's going to. That the Microsoft build them. That Jedi cloud. I forget what Jedi stands for now.
[00:30:37] Speaker A: Oh, that's why we're doing Star wars references at the beginning.
[00:30:39] Speaker B: I see it's all full circle.
[00:30:44] Speaker A: Data encryption at rest as well. Data encryption is fine. I think that we should encrypt data. That certainly helps if somebody gets into the system via backdoor or something. I mean, like, a literal kind of comes at it sideways and the data is encrypted. But if they're breaking into the system via the normal methods, that doesn't help at all.
[00:31:05] Speaker B: Right.
[00:31:05] Speaker A: I don't know.
[00:31:06] Speaker B: They're going to compromise account that's got access to the keys to decrypt the data anyway.
[00:31:10] Speaker A: Yeah, or they're getting in through the web app, and if you pull the data up through the web app, it's unencrypted because the web app has to use it.
[00:31:17] Speaker B: Right.
[00:31:19] Speaker A: That's always been kind of a weird thing to me to talk about. You have to encrypt it at rest so the bad guy can't get to it.
[00:31:25] Speaker B: That's a fundamental misunderstanding of the purpose for data at rest encryption.
[00:31:33] Speaker A: All right, so is government top down direction the right way to handle this?
I actually don't know the answer. This isn't like a pre made question where I already have the answer ready to go, because I was trying to think of if there was a better way to do it, kind of in a capitalistic way or some more organic way, rather than the government being like, bam, bam, bam, you need to do these things.
[00:31:58] Speaker B: Well, I think centralized direction, though, is fined for policy. That's why you do policy at the organizational level. But really what you want is the ability for different parts of the organization to do things differently and possibly do it better. I'd say what you want is that baseline policy that says, here's generally what you have to do without getting too specific about it, and then facilitate the sharing of different perspectives on how different parts of the organization are doing this, especially when you're talking about an organization as huge as the United States government. Because if DoD does it one way and Department of Energy does it a different way, and if you have good lines of communication between those two organizations to share how they're getting it done, it could be that they will actually learn from each other and the government entirely will benefit from that because you'll be able to percolate up those better concepts or those better ways of doing different things versus saying, this is the way everyone's going to do it. And your uniformity is, I mean, it's a government. So you're probably talking about uniform mediocrity at best, not necessarily uniformity of excellence.
[00:33:27] Speaker A: I don't know. I was more thinking in terms of almost like an insurance driven, where you require all of the government contractors to have cyber insurance. And then the insurers, we talked about this the other week, how they would have kind of a broader view into what works, what doesn't, who's getting breached and who's not getting breached and what kind of controls they're running, and then kind of use that as a monetary benefit for them to be like, hey, we have these things and our insurance is cheaper. Although I guess it probably still wouldn't be cheap enough to cover the cost of. Although, I guess, you know, because we're talking about, like, if you do it right, you need less security. They can save money that way. Do it like, more. Try, hit it. Hit the company's pocketbooks.
[00:34:10] Speaker B: Well, that can work in the private sector, in the government sector.
I think that's almost a non starter, to be honest with you. Because the government is out of the CIA, they are more concerned with confidentiality, so they don't want anything getting out ever at all, versus being able to get by with transferring risks should something happen.
But one thing I did want to mention that you were talking about with all these things have been tried and failed before is like, it made me think of the OASP top ten.
Just because there are a lot of challenges with the implementation of those top ten doesn't mean that the echo execution of those, if done correctly, isn't going to raise the bar on how well your code is secure overall. So just because these are standard recommendations or whatever that haven't worked in the past doesn't mean they aren't still good recommendations.
[00:35:13] Speaker A: Yeah, it's just like we're talking about with it. It's in the implementation.
We know how to secure networks.
It's the actual application we really struggle with.
[00:35:23] Speaker B: But one of the other problems with this coming down from the White House, though, is that's really pie in the sky kind of thinking versus actual tactical implementation for people who understand that it's practice versus theory.
[00:35:39] Speaker A: Yeah, I know. I just did something about what I'd do if I was in charge, and I think there's two big things that I would do if I were up there. And they're actually focused diametrically opposite of each other. Number one, I would be focusing kind of government research efforts and government organization efforts, kind of how they have released standards and they do some research and nist releases a whole bunch of standards and incident response documentation, stuff like that. I would really focus on trying to figure out how to help customers do those basic things. Not customers. Companies and contractors do those basic things. There's a reason that we haven't been able to get software inventory right, and that's because it's really hard and it's really complicated.
This kind of seems to me like kind of that kind of basic research to bring up that security poverty line level, providing tools, free tools from the government, maybe, or working with a commercial partner, and the government provides some of the research funding and maybe some of the smart people at NSA or somewhere to solve some of those basic problems and then commercialize it. I mean, they've done that a bunch in the past with DARPA. Second, they should be really getting ahead of the current trends. Things like AI, machine learning, cloud containerization, stuff like that. Stuff that is for a lot of companies is still, unfortunately kind of pie in the sky, or they're just kind of getting started on moving stuff to the cloud and they're just doing a lift and shift right now. We need to kind of get ahead of that stuff and not try to refight, because, again, the stuff they're releasing, a lot of, it's refighting the same battles we've been fighting, and they've been doing poorly at it. I don't think that a new executive order from on high is going to suddenly change that. We're not fighting that battle.
[00:37:18] Speaker B: Well, the incentives are not there for them to really solve these problems, though, because regardless of how much failure they endure or happens to them, there is no real downside.
[00:37:31] Speaker A: Maybe that's the answer. Maybe there needs to be a severe financial downside.
[00:37:34] Speaker B: If they get hacked to the government.
[00:37:37] Speaker A: No, like the contractors and stuff like that. If a contractor gets hacked, then their contract price, something happens to what they're getting. Of course, that'll just encourage them to hide it and conceal it.
[00:37:49] Speaker B: Well, there's really the relationship between contractors and government make them almost another wing of the government.
A lot of the reason the government does some of the things they do is to ensure that the stock prices of the tvent contractors remain high. So you're not going to see them punishing them in those ways.
[00:38:15] Speaker A: How does this matter to you? Well, unless you're a government contractor, it probably doesn't matter at all. But if you're a government contractor, you can look forward to a whole bunch of new requirements dropping down under your head over the next couple of months. So in terms of what you should do about it, really, you should start planning for those changes now. Start looking at. I mean, we don't know exactly what the changes are going to be, but there's going to be some coming up, so keep your out. Not much to do on this one. All right, I wanted to finish up with one quote that David pointed out to me that I think is just absolutely the bee's knees. So this is a very, very last paragraph of the article. The quote is, when solar winds happened, we got a call set up with Sisa. They canceled our call because they were in the throes of being compromised themselves. Then the Department of Energy called Sisa saying, we need help. Sisa said, we can't help right now. We're busy with our own problems and now you guys are in charge of coming up with a solution. Quote is from Kareem Hajazi, founder and CEO of Prevailion, a cyber intel company.
And that is an interesting problem. If the person who's supposed to be responding is busy with responding to their own, it sounds like they don't have a great system for helping out the rest of the government there.
[00:39:27] Speaker B: Well, I think really it kind of comes down to how they're structured then, because you'd think that it would be almost like Mandiant saying, oh, we got compromised, so we can't provide IR services to other companies, we're using our own consulting services to solve our own problems.
[00:39:49] Speaker A: I mean, that's what happened, right? That's not the response they gave, but they were compromised in solar winds. They're the ones who found it and broke it and they still turned around and sold their services.
[00:39:58] Speaker B: Exactly. So what I'm saying is that their response efforts to their own problems were not taken away from their consulting capabilities.
[00:40:09] Speaker A: Shouldn't have been, at least, shouldn't have been.
[00:40:11] Speaker B: Right. So if Cisa is going to play that kind of role within the government, then they can't be diverting the resources they're using to supposedly protect the rest of the government, to protect themselves.
[00:40:25] Speaker A: All right, well, that looks like that's all the articles we have today. Thank you for joining us. Follow us at serengetisack on Twitter and subscribe on your favorite podcast app. And in the very near future, that should include Apple as well. Apple finally fixed the issues with their submission. We got it submitted, and hopefully it'll be popping up in Apple very shortly.
