Security Confidential S5 E7 Dennis Underwood

Manoj Tandon:
Hello everyone, and welcome to another episode of Dark Rhino Security Confidential. Tonight, we are honored to have Dennis Underwood join us.

Dennis is a fantastic human being, but in addition to being a fantastic human being, he’s in Pittsburgh, which gives him bonus points because that’s where we’re at. Also, he is an entrepreneur, a veteran, an expert in cryptography, and a cybersecurity leader. He also happens to be the CEO of Cyber Crucible.

He is kind enough to join us today and enlighten us on many topics that are going to be of interest to you folks in the world of cybersecurity. Dennis, thank you for being on the show.

Dennis Underwood:
Thank you for having me, Manoj. I really like this.

Manoj Tandon:
Dennis, one of the things that I’d love to start off with is that you’re a veteran. At Dark Rhino, we have a lot of veterans in our organization, and a lot of our listeners are veterans.

One of the questions that comes up is, as they are transitioning from military life to civilian life, especially if they’re looking for a career in cyber, what’s the guidance on how they should go about doing that?

Dennis Underwood:
Yeah, that’s a great question. I should say right out of the gate that my MOS, or specialty, when I was in the military was actually artillery. So there was nothing “cybery,” or signals intelligence, or anything like that at all. It was totally combat arms, which is not easily transferable.

I wasn’t good enough to be like the Punisher or a SEAL Team guy. I was just a normal grunt. I couldn’t go be an assassin, and I didn’t have any directly transferable skills.

Honestly, what I ended up doing was getting into cyber. It is a great place to be because if you’re the normal IT person, you have to memorize that Active Directory playbook and come out with all of that knowledge. With cyber, your goal isn’t to memorize pages 44 through 46. Your goal is to break it, to do things they say don’t do, which is a lot easier to do in your spare time.

So I love cyber because you can do that. You’re going to have to research on your own, so just get in the habit of doing that. None of us gets where we are by just doing the eight-to-five.

During your off-hours at garrison or wherever, go ahead and research. I’ll tell you a cool story. When I was deployed to Iraq during Operation Iraqi Freedom in 2003—

Manoj Tandon:
Oh, so you were there? How long?

Dennis Underwood:
A little over a year—like 13 months or something like that. I was actually in-country.

I was doing combat missions and convoy missions, which arguably might not be combat, just driving around and stuff like that. In between missions, I would have my SANS books with me. I would always take my SANS books in the Humvee. I’d bring them out, and they’d be right next to maybe ammo or whatever else. I didn’t want my skills to atrophy.

I realized something interesting. The glue on all my SANS books was melting because of the massive heat in the desert.

Manoj Tandon:
What was the temperature out there?

Dennis Underwood:
Like 130, sometimes 150, depending on whether it was inside the Humvee.

So chapters of the book would actually fall out, and the desert wind was always blowing. You’d actually lose things. It might be a chapter on how to manage a Cisco router properly as part of your SANS certification, and it would blow away.

There were always Iraqis around who would hang out. Some wanted candy or whatever, and some were probably just keeping tabs on you. It took me way too long to realize that the pages flying away looked like classified data or mission data because they were full of technical material like firewall rules.

When I got back home and started getting my lab going and transitioning out, I could actually tell what chapters I was missing. I’d be like, “I forget how to do that,” and then look and realize, “Oh, that chapter is somewhere in Iraq.”

So that’s a cool story about how you should train.

Manoj Tandon:
And so your training in cyber, you did on your own? The military didn’t give you that toolset?

Dennis Underwood:
No. Actually, when I got back, I transitioned into a telecommunications job. It turns out the military’s version of that, at the time, was stringing telephone lines and climbing telephone poles and things like that. So I still didn’t hit the mark.

That was in 2005, so things are different now. But I was like, “I’m going to get into cyber before I leave,” and then they put me up on a telephone pole and I was like, “That is not cyber.”

Manoj Tandon:
How did you—because you have an illustrious past and got the attention of the NSA or probably some other three-letter agencies—how did that come about?

Dennis Underwood:
Again, the good thing about cyber is you’re paid to break stuff, or you’re getting ready to be paid to break stuff.

What happened was I had gone back to school. I was actually in graduate school at the time down at UNC Charlotte. At the time, it was great because all the banks would hire from there. Bank of America needs a lot of crypto.

There was an unbreakable malware situation—a botnet, a peer-to-peer botnet. It was one of Conficker’s cousins, I guess. The news story was that researchers at this university and from the FBI said this thing was unbreakable and no one could get a handle on it.

So I said, “Well, that’s great because I’m training to be a cyber guy.” I pivoted my lab over. I figured out a weakness in their cryptography and their peer-to-peer algorithm that basically said only the boss can really tell me what to do.

So I did a whole bunch of work, math, and protocol analysis, and then I came up with an Independence Day-style attack on this peer-to-peer botnet that just collapsed the whole thing on itself.

What happened next was really interesting. This is the power of being that dark horse researcher on your own. I got proof-of-concept code and demonstrated that I could actually have the malware destroy itself.

So the dean called someone, and next thing I know, two guys flew in—said they were from NORAD. For all the military folks out there, you know what that is. They flew in the same day, apparently on a private jet. I don’t think US Airways would do that.

That really got their attention. It got messy, though, because the dean was trying to maneuver me out of making any money. He was trying to sell it to the government while also taking it from me.

At the same time, another professor at the university was on a global anti-botnet email alias. He was emailing thousands of researchers all over the world saying, “Hey, we have a guy here who found a vulnerability in the peer-to-peer algorithm,” and he gave enough detail that, while negotiations were happening, I was watching the bad guys dynamically patch their code to fix the vulnerability.

Within that 24-hour period, my code was useless, but I didn’t tell anyone.

So I finally did this whole dramatic thing where I was like, “No one gets it, then I delete the code!” No one knew it was useless at that point because this researcher had essentially emailed the Russians and said, “Hey, here’s your vulnerability. You should probably patch this.”

So anyway, that got the attention of some folks, at least the people who flew in.

Manoj Tandon:
And I’m sure that vulnerability would have been worth millions of dollars on the black market.

Dennis Underwood:
As a plucky researcher, you don’t really think about the business side at that point in life.

Apparently—and this is from an article, not personal experience—but what I read was that in the US, if you want to find a zero-day vulnerability, the going rate is about three million dollars.

Manoj Tandon:
That’s a nice little vacation.

Dennis Underwood:
Yeah, it is. It’s a nice little vacation at a lot of Motel 6s after that happens. If you’re ever identified, you better be in a non-extraditable country.

Manoj Tandon:
Start learning Spanish, or whatever you’ve got to do to disappear into the rainforest and never pick up a mobile device again. That’s incredible.

Part of what you’re speaking to is also innovation, which is a great story. Nobody told you this was not possible to do.

Dennis Underwood:
Yeah, absolutely. That’s why I love telling anyone who’s looking to get into it: pick up a book, pick up 13 books, and just start researching. Just start doing things that they say you can’t do. That’s the best way to become a researcher.

I will say that for someone who’s looking to be a SOC analyst—an entry-level position looking at logs—go ahead and get your vendor certification. I definitely would say, if I hadn’t been able to get enough consulting work to feed the family and pay the bills, I would have had to be smart about it and get a vendor cert for security.

But I took the longer road and said, “Let me figure out how to do something more interesting.”

Manoj Tandon:
And we’re very glad you did. Audience, as you guys will hear in a minute, Dennis has done some interesting things with ransomware.

Let’s transition to that for a second. Ransomware is in the news everywhere, every day. Someone’s getting hit, and it seems like no matter how much awareness is being generated, there’s still this idea that it’s something that happens to other people and won’t happen to our company.

There’s also the myth, “Well, we’re in the cloud, so security is Microsoft’s problem, Google’s problem, Amazon’s problem. Why do I care about this?” We see that myth all the time.

And the third thing is, “Well, we’re protected at the endpoints. We’ve got what we need. We’re good here.”

Setting the stage, this is coming from a lot of the work that we do in the small-to-medium business space. I can’t speak to the enterprise, but we’re certainly seeing these kinds of myths propagate in the SMB space.

So the question to you as a real expert is: why is it that companies can’t get their act together with ransomware?

Dennis Underwood:
Yes, it’s really interesting. Coming from when I went to the NSA, I ended up doing some operations, but there was also a lot of threat hunting I did.

One thing I had seen before going there that made me more jaded was that the bad guys seem to always have access. Every time I found something, it would be, “Oh look, they were there for six months.”

What I think we’re seeing is that economics are a lot of the drivers for the behavior change. They always have access. They’re getting into big places and small places.

One thing about the behavior change is that there’s so much data out there that’s been stolen. Look at the T-Mobile breach, Accenture, the State Department—it just never stops.

What’s happened is that the data has devalued because there’s just so much of it. It’s the whole game of: if everybody has a pile of diamonds in their backyard, then diamonds would not be worth as much.

So what happened was that when you have the ransomware variable, all of a sudden the value of your access goes way up. You’re not only dealing with ambiguous data breach costs to the company, but with ransomware, you’re removing the data and you’re also removing the revenue-generating ability of the business.

Now you’re not just making the security guys upset. Now all of a sudden the CFO is calling because QuickBooks or whatever accounting software they’re using just went straight down.

So it’s a very costly exercise. It’s no longer dependent on the value of stolen data because there’s tons of data out there on the dark web. What’s happening now is it’s directly tied to the revenue and assets that the business has.

We have spies now that have turned into essentially sappers or bombers. Now they’re blowing things up inside the business instead of just sitting there and slurping out data.

Manoj Tandon:
Why is this problem so difficult to get under control from a business perspective? I’d love for you to address this in the context of an executive, because an executive is thinking, “My IT guy is the greatest person on earth and they’ve always got everything under control,” and yet they get shafted.

Dennis Underwood:
Yeah, and there’s this myth that somehow these security teams aren’t doing their job or aren’t competent. I’ll go in and see these very tired groups of people before or after an attack, and I’m like, “These guys are busting their butts.” It’s never that they just throw caution to the wind. They’re always trying their hardest.

What I’ve found from a business standpoint is that the attackers are exploiting the timing and the tooling. We actually have a document that goes through seven questions to ask the ransomware vendor if they come to you. It’s a pretty sad set of questions.

When the CIO is in the boardroom trying to defend what just happened, the defenses seem to fail because either they’re missing it, or it takes three months for the vendor to catch up and actually let you find it. With ransomware, you don’t have three months. It’s an immediate business-impacting event.

Either the defenses are too slow, or maybe the SOC analyst doesn’t have the skills to know how to dive into all that data and doesn’t have the time. That’s a problem for businesses.

The ransomware might take 15 minutes to position and go. You don’t have three months to try to find that.

The second thing I see is that beyond evasion, we’re actually seeing a zero-trust issue in a different sense. Not only are we protecting, but the attackers have system or domain admin. I can’t even trust the system I’m on. The hackers have totally taken it over.

So we’re seeing that this is a resilience issue. Everyone talks about zero-trust from a “make sure the one user is the right user” standpoint. But is it really the Windows kernel telling me to do this, or is it lying to me? Is it a hacker telling me?

That’s a problem when you can’t trust the system you’re on at all. That’s more like SolarWinds. Those guys upped their own privileges. SolarWinds, Kaseya, before that ConnectWise—they’re all at high privilege. They’re all normally whitelisted, so it’s a great place for a hacker to be. They can run amok with whatever they want to do.

I loved Kaseya from a security guy standpoint, because before Kaseya, I never actually got to respond in an environment where the antivirus and EDRs were fully working. They were always degraded or disabled because the hacker had nuked them. With Kaseya, all the tools were working at full capacity.

I was like, “I finally get to see what SEAL Team Six looks like when they aren’t blindfolded.”

Manoj Tandon:
And I think for our audience, a take-home here would be that zero-trust is not the end-all be-all because, obviously, if you have elevated privileges that are trusted, your zero-trust framework isn’t exactly going to work.

One of the things that we noticed in our telemetry, which spurred a bunch of development on our side, was that at first it was all things like “hackerlaws.exe” or “Ryuk.exe” in terms of ransomware being run. Then we realized that it was actually a pretty quick transition. It wasn’t “hacker.exe” anymore. It was all Windows applications or other privileged applications getting stopped.

We realized what was going on was that even with zero-trust, what do you do when you trust your SharePoint server and the hacker has injected ransomware? Now your SharePoint server is doing SharePoint things but also doing ransomware things.

Zero-trust won’t really help you there because you’re saying, “Oh no, that’s SharePoint. It has access to the ecommerce server.”

That’s very true. And that’s also a case where I’m glad you pointed out that even though Microsoft has great security, just because you’re on their platform is not going to stop this.

Dennis Underwood:
Right. I didn’t touch on the cloud thing at all.

Manoj Tandon:
Please do, because let’s do a little myth-busting on that one.

Dennis Underwood:
First, it’s not a technical problem at all. If you ever follow risk mitigation or risk acceptance in the cloud model, the cloud providers make sure that you’re the one accepting the risk of security. It wouldn’t be good business for it to be anything else.

So it’s not their problem.

We do see where the ransomware is not really targeting the cloud in some super-smart way. What we find is that a lot of times, the Windows libraries they use are made for resilient commercial operations. They’re made to help businesses.

Sometimes the ransomware will run and, depending on which library they use, it will happily connect to that remote server that doesn’t even have a drive letter. It will just go ahead and access it. It doesn’t care that it’s actually inside of a Google Cloud instance.

Attackers will also prepare the environment—“prepare the battlefield,” for the military folks. If we have ransomware that isn’t all that advanced, we’ve seen where they’ll run a script. Say the ransomware could only encrypt things with drive letters A through Z. They’ll actually mount that Dropbox or whatever to a drive letter just to make sure the ransomware hits it.

It’s like you have this supply chain. You have this ransomware developer who is really good at C, C++, or .NET, and then you have this DevOps person who can’t do the coding but knows how to mount that drive in PowerShell to make sure the ransomware hits it too.

We’ve seen that as well, which is actually pretty interesting.

Manoj Tandon:
That should be triggered on big time. There should be some alarm bells going off in your SOC as soon as someone tries to do that.

Dennis Underwood:
It depends on how they’re configured, but these are legitimate things. A user—because they’ve co-opted a user at that point—can do them.

I think I would probably go crazy if you gave me a task like, “Every time a user mounts their cloud instance to a drive letter, I want to know about it and I want you to talk to them and see if it’s really them.” I think I’d last about a week and then lose my hair. It would be ugly.

But yes, if you see cloud instances getting mounted to drive letters, that definitely could trigger something.

The more modern ransomware does a better job of handling that kind of situation.

Manoj Tandon:
The dwell times of ransomware—when they’re prepping the environment—there used to be an old statistic that it was 200-plus days that people were in. What is it currently? Have the advances shortened that dwell time substantially?

Dennis Underwood:
That’s a great question. It really depends, but we have seen this trend where they are taking over automation. It is becoming a bigger play.

Some folks think it’s an elite mastermind running the show, and then I find out it’s really someone marginally useful who just has 20 scripts to run. They know, “Run these scripts and it’ll disable the EDRs or firewall off the XDR.”

The dwell time can be shorter if all the scripts happen to line up. I call it “speed bump security,” because once the script breaks, these people sometimes are stuck and they have to move on.

But also, if they take over the Active Directory server, then I have seen where they will deploy Group Policy to download, install, and run the ransomware on a ton of machines at once. At that point, you don’t really need a lot of dwell time. You have Active Directory doing it for you.

Manoj Tandon:
And what is the rate of encryption?

Dennis Underwood:
That’s a great question. It depends on what’s being encrypted and where. The max we’ve seen is around 300 files per second. That can be slower if you have 50 workstations all running through one switch trying to encrypt that remote server, which is a common scenario.

Manoj Tandon:
Is that 300 files per second per core, or just the flat-out limit?

Dennis Underwood:
We did the flat-out limit to make it easy. Now, it’s interesting you say that, because they’ll actually tune the number of threads inside the ransomware variant to do simultaneous encryption. Three hundred was about 30 threads, I think, in what we saw.

If they want to go low and slow, they can reduce that number.

Some early versions of ransomware would make it 100. The problem is—and this is an old sysadmin problem—if you try to do too much on the system or over the network, file corruption starts happening.

If the switch can’t handle those 50 machines all trying to encrypt the servers, file corruption starts happening on the network layer.

So they have to tune it to be fast, but not too fast. It’s like Han Solo: “Fly casual, but not too casual.”

That’s why they like to maneuver to the server sometimes. Once you’re on the server, you might only get 100 files a second remotely, but on the server you can crank that thing all the way up to 11 and really get the ransomware going.

They’ve also done something else recently, and this goes back to why things aren’t stopping this. The defenses will many times come in after the fact.

I always tell business people, “Look, it’s like a bad guy puts on a guard uniform in a bank. He’s going in and out of the safe and taking money out, and then eventually someone says, ‘I don’t think that man is really a security guard for our bank.’ By then, 20% of the money is gone.”

A lot of the defenses are like that, where the behavior analysis only catches on after enough damage is done.

What ends up happening is these things will fire up—and if you have 20 guards all taking money out? Sometimes the ransomware attackers will actually stand up 20, or we’ve seen as high as 50, ransomware samples on each system. And you have 50 systems.

At that point, we calculated at one site that went down—it was over a million files per second being encrypted. It was almost like a DDoS, where all the machines stand up at once and just crush the systems.

So it comes down to this: you have around 100 to 200 milliseconds before damage starts. It has to be automated and you have to react immediately to stop the business downtime.

Manoj Tandon:
That is a great metric. I want the audience to please make a note of it: you have 100 to 200 milliseconds. During the Cold War, we had 30 minutes of flight time from the Soviet Union to the United States. That seems like an eternity compared to 100 to 200 milliseconds. That’s faster than the blink of an eye.

Dennis Underwood:
Yeah. In our own product, for something like 50 samples happening all at once, my developers came to me and said, “Our stuff’s too slow.”

And I said, “Well, we’re an application.”

They said, “You understand that our driver in the kernel is too slow communicating to the service in our Windows application? That data bus on the same system is too slow.”

So they started moving things into the actual driver because they had to get faster and go down to the C level.

Manoj Tandon:
Let’s talk about your company and your product and how you guys are actually tackling this problem. What’s the design behind Cyber Crucible?

Dennis Underwood:
What happened was we had a bunch of SOC automation products, and we still do. We realized that ransomware was just too fast and too destructive.

We literally had a situation where we were calling a person because we got an alert. We were helping them monitor, and it was almost like you’re on your military base and all of a sudden you find that 100 suicide bombers are scattered throughout the base. You can start trying to capture them, but now you have a problem: these guys are detonating as fast as they’re being approached.

I realized there needed to be a different solution. We looked around and realized we actually had a tool that would be able to capture the encryption keys being used by some remote access tools and data breach tools. We pivoted it for ransomware, and we were able to grab the encryption key and then make a bunch of automation to decrypt.

Manoj Tandon:
Oh, that must have been really upsetting to a whole bunch of people.

Dennis Underwood:
I got cussed out. I was Googling translations like, “Okay, what does this mean?”

There are ransomware developers and operators who are very unprofessional, and then there were other ones who were very professional and it was like you and I talking. They had already reverse-engineered my software. They knew how it worked down to the function name. It was just a chat among professionals. They were very calm about it.

What happened during 2020 was essentially an arms race. They were evading and trying different things, and we were red-teaming our own stuff and seeing them do stuff. Of course, Microsoft was introducing bugs for both of us to deal with while that was all going on.

Where we sit now is this: we had this really cool thing that made attackers angry, which was that we could decrypt for you in about five minutes. The attackers hated it.

But then we had some CIOs and CISOs over COVID who were like, “Look, I don’t have a budget right now.” They were frustrated that we would sit there, watch the attack happen, let the whole company go down, and then decrypt in 10 minutes.

They were basically saying, “I’m frustrated that you can’t just stop the burglar from being able to do this.”

So we pivoted. That’s where business rules don’t line up with the geekiness that is our nature. We actually pivoted to make it go super fast.

Now we have this really cool driver. It looks for the things that work for the hackers, including ransomware behaviors, and we can authoritatively stop the ransomware.

Knock on wood, we haven’t been beaten yet.

It actually stops the downtime from happening, even when it’s a trusted application like Kaseya or SolarWinds.

Manoj Tandon:
So you’re shutting down the encryption process completely? You’re not even letting it start on the processor?

Dennis Underwood:
Yeah, our behavioral analytics at this point are fast enough that with our 200-millisecond metric, it has to make decisions very quickly.

Manoj Tandon:
So you’re not going back to the cloud then?

Dennis Underwood:
We tried. The latency is the problem. Even with Amazon Lambdas inside their CDN, the fastest we could get it still caused downtime.

We couldn’t use backups on the system because those get nuked. We couldn’t even have a cache. The attackers found the cache one day and deleted it. They corrupted it, and we were like, “We needed that data.”

Everything is in memory and all in the driver, in kernel space. We have our behavioral models there and we react instantly and suspend the process.

Technically, you could carve it out and grab it. The problem is, as humans, if a SOC gets a call or an email from our automated notification saying, “Hey, someone has system privileges and we just shut down 50 samples of ransomware and froze them in place,” most folks are not in a place emotionally to calmly do a memory carve and start collecting forensics. They’re in four-alarm fire mode.

Manoj Tandon:
That’s incredible technology. And the other side knows what you’re doing. Thus far, they have not been able to break it.

Dennis Underwood:
Not yet. We do see some really crazy attacks, like OAuth attacks and other increasingly interesting things.

Before a wave of attacks, we used to have demos on YouTube. I’ve kind of stopped putting things there. But before a wave of attacks, we’d get DMCA takedowns. I’m assuming it was them.

For instance, when hospitals were hit with Ryuk attacks, three days before the attack we had a DMCA takedown of our Ryuk demo. I went to show the demo one day and it was gone.

Then the Ryuk guys went to town on hospitals. So it seems like they know we’re coming and they’re trying to hide what we can do.

Manoj Tandon:
That means what you’re doing is highly effective.

Dennis Underwood:
I think so. I take it as a good thing.

Manoj Tandon:
And that is a very good thing. A lot of us are very grateful that folks like you are out there trying to make a serious dent in this problem.

One thing I wanted to ask you: every time there is a major ransomware attack that makes the news, we always get some politician on TV who comes on and says whatever nonsense they’re going to say, regardless of the party involved.

But one thing we never hear publicly is that companies need to focus on threat hunting in their environments. I think you would agree: you can’t leave it all to technology; you need humans involved at some point.

Why does that get missed? It seems like the focus is always on the silver bullet: “Just find me that one technology and I’m going to rely on that.” Why not build a great threat-hunting program as part of your corporate environment? That doesn’t have to be 50 people. It can be a very small group of dedicated professionals.

Dennis Underwood:
Absolutely. I always call it like the “chaos monkey.” I like it when it’s an IT admin who is not formally trained, not the expert on Cisco Firepower. You don’t want that person. You want someone who’s just going to poke around like a hacker would and try to find things.

Because even with our tools, we have some behavioral analytics where we’re like, “Why is PowerShell doing this?” We can’t whitelist it and we can’t blacklist it, because you need PowerShell to run your business.

All we can do is alert, but it takes a human to come in and say, “Oh yeah, that was Bob, and he does this all the time.” We can whitelist specific commands, but still, some of the commands are the same. We try to remove the hiding places, but it’s never foolproof.

I love the threat-hunting piece.

On the politicians’ and businesses’ side, I feel like they almost need to find a way for people to disclose: “Hey, I make money off your failure. I make money off your pain.” Like, “I run an ambulance network and I love sick people.”

That kind of thing is necessary, but it’s also a conflict of interest sometimes.

In our company, I always tell people, “Look, our goal here is to get you up and running so you can install our software.” We let them know right away: we’re not here to take you to the brink of bankruptcy on forensic analysis and all that stuff.

I think companies are probably familiar that after they’ve been hit, that bill is not cheap.

Manoj Tandon:
It isn’t, no. And I agree with you 100%. The threat hunting and trying to find these guys as they’re moving around and dwelling…

Internally, we’re doing a better job now of making a lot of this raw data available to people, because there are so many folks that just need more data. And if they can get meaningful data, I think they can probably do a good job even if they’re not NSA-trained cryptography chaos monkeys.

Dennis, we’re at the two-minute mark. We’d really like to give you a chance to plug anything that you would like: events, books, appearances, whatever you feel you’d like to make the audience aware of.

Dennis Underwood:
Absolutely.

I’m here in Pittsburgh, so we’re going to B-Sides Pittsburgh, and there are other B-Sides around too. We actually put in for three free presentations. We’ll see how many get accepted.

The first one is on how we reverse-engineered one of the ransomware protocols they use to figure out which key to charge you the most for—basically how they do their inventory management.

The second one is twelve things that a hacker does before they run the ransomware, but after they get in position. They do a lot of preparation.

And the third thing I’m doing is this: I’ve had a heck of a time finding accurate metrics for all the actuaries and risk-management folks on the business side to say, “Here’s what the ransomware is costing and here’s how often.”

As one example, we found a report that was quoted by a couple dozen people. In the original report, they actually forgot a zero in their math, and then it got copy-pasted and used for all kinds of derivative risk analysis. They were off by a factor of 10.

So I’m going to go through some of that during my presentation.

Manoj Tandon:
That’s going to be very valuable data. The only thing I have anecdotally on that is that if you look at the cyber insurance market, it used to be—before ransomware got hot and heavy—that cyber insurance companies kept 60 cents on the dollar as profit on every dollar collected in premiums.

That’s not true anymore. In fact, the payouts have exceeded the premiums, and they’re dipping into their property and casualty funds to pay these, which is why people are seeing 50, 60, even 100 percent increases in cybersecurity insurance costs.

So someone has data somewhere, or it’s getting developed very quickly, but you’re right, it’s not readily available out there.

Dennis Underwood:
Right. And as a risk manager, you can’t go to your CFO and say, “Here is the risk we accept and here’s the risk we have managed,” if your math is wrong.

I guess the same thing is happening to insurance companies. Whenever the insurance company loses money, that tells me the insurance company’s math is not reflective of reality.

Manoj Tandon:
I agree with you completely.

Dennis, we’re at the hour here. I’m going to really request that you come back for a part two. I think we just scratched the surface. If you’re up for it, we’d like to dive in a lot more. I know we’re going to get a lot of interest in this topic. It’s near and dear to a lot of people at this point, and we appreciate you sharing your insights.

Dennis Underwood:
Well, thank you so much for the time. I’m glad I was caffeinated so I could just keep firing.

Manoj Tandon:
You’re awesome. A very enlightening conversation. Thank you, Dennis. I hope you have a great day in sunny Pittsburgh today.

Dennis Underwood:
Thank you so much. Have a good day.