[01:13] There’s No Trust in the Industry

Rachael: We've got Dr. Richard Ford. He's the chief technology officer, a Praetorian, and it’s his third time on the podcast.

Eric: Episode 10 in November of 2018, that was on Rethinking Digital Trust. Then Episode 38, The Future of Trust in July of 2019. We're talking about a great topic today where there's no trust in the industry.

Rachael: Why has it been so long, Richard? Did we lose your number? Did you lose our number? What happened? Have you just been busy?

Richard: It has been a bit busy, but also time is doing strange things in this day soup that we live in. I'm a little bit confused about whether it's Christmas or Easter right now.

Rachael: It sure is, but I'm glad you're back. We're glad to talk to you because this is the highlight of my month right here. I could think of a better way to end it.

Eric: We're going to get this out pretty quickly, so our listeners can learn about it while we're in the midst of the problem.

Rachael: The big topic, as we were talking about, is what Dr. Richard Ford wrote. He's written a dark reading byline article and numerous blog posts and other things on this topic.

Eric: Patents, you name it.

Rachael: Patents, it's 45, 60, I don't know, a lot of patents and all the things. But he is going to help us break down Log4j aka Log4Shell and all the goodness that comes with that.

Log4Shell Is a Big Beast

Rachael: This is a big beast. We talk about beasts in insecurity, but this is a big beast of a zero-day event.

Richard: Probably the worst in my career, certainly the worst in the last 10 years or so, it's pretty bad.

Eric: Why do you say that?

Richard: You don't need access through the machine. You can do it remotely with no account. It's a simple text-based attack, so you don't need to be a rocket scientist to make it do anything. It's not like I have to defeat H.G. Adler, just thought I'd throw that in there for you. It isn’t like I have to defeat some terribly esoteric defense. Literally, we have reports of people renaming their phone to a specific string. So you don't need access. It's a fairly simple string-based attack.

Once you understand it, it's pretty easy to make it go. The worst of it is that you can scan for it and it's hard to scan for it reliably remotely. That just makes everything more difficult. There's only one way to know for sure that you're safe. That's to look at your actual source code to do a software bill of materials. Then make sure you don't have a vulnerable version of Log4j anywhere in your ecosystem.

Eric: If you're a vendor, you can do that because you own the source code. But if you are a consumer of products, whether consumer-grade or enterprise-grade, you, obviously, don't have access to the source code. So the best you can do is look at every vendor you deal with. I'm a Mac user.

A Service Side Problem

Eric: If you're running a Mac, you've got to literally go to Microsoft and understand the Microsoft platform, Adobe for the PDFs and all the tools you're using. Ensure that the vendor has either updated you; well, first created an update and then automatically updated you. Or you've got to update your software to protect yourself.

Richard: Mostly fair. So this is much more of a service-side problem than a client-side problem. There are some examples of things that run locally that potentially are vulnerable. But the ones that we're scared about are the ones that are in the cloud. Those ones right now that are the most at risk, those are the ones that are most targetable.

Eric: Because they're accessible?

Richard: Because they're accessible, and because typically an endpoint isn't usually using something like Log4j, which is a logging component. This is much more of an enterprise software, enterprise server. So like VMware Horizon, or think about all those SaaS products that are hanging out in the cloud. But it's not to say that there aren't things in your house that could potentially be vulnerable.

I think about embedded systems, some smart televisions, some of the smart homes. But the real big risk is all that enterprise SaaS stuff. Even there, you'd say it's easy for the vendor. The vendors can look at the source code. A lot of times, even pretty good vendors aren't aware of everything that's in the cloud. So one of the big challenges that we have is there's a statistic about 30% of your IT assets you're not aware of.

A Vulnerable Version of Log4Shell

Richard: 95% of all docker containers have a life span of less than a week. It's such a moving target that even for a pretty good defender, it's hard to know where all your stuff is.

Eric: Especially if the cloud-accessible systems are vulnerable.

Richard: This is one of the nasty things about this, remember I said, it was a string. I just have to get a special string into a vulnerable server. That doesn't mean I have to connect to that server. I could connect to the web server or the web server could push that thing through Kafka. Kafka could pick it up in another backend server, and if anything, anywhere in that whole chain uses Log4j, a vulnerable version of Log4j for logging, I'm about to own your infrastructure.

So it's not just the front end, it's all the different places this goes. There's a piece of messaging that I want to get out because people don't understand this. There are all these scanners that people have put out for Log4j. None of them are super reliable. A lot of them just change one header in the HTTP request, and if you don't get a pingback, you go, "Oh, you don't have Log4j. You don't have Log4Shell vulnerability." That's not true.

We've seen examples now scanning, where we'll send the exploit. 12 hours later, we get a pingback because there was a batch job that picked up this log and imported it into elastic. Then, it got exported from elastic into some overlap system and bam, that system was vulnerable, and we got that one. We didn't get the front-end system. We got it much later. It's crazy.

[08:41] Log4Shell, Colonial Pipeline, and Ransomware

Eric: Just to baseline quickly for our listeners, this is a Java logging library that's commonly used.

Richard: It's ubiquitous in the Java world, and it's a good library. I've used it. That's the definition of common because I don't write much Java. If I've used it, it must be pretty common.

Eric: Rachael, you're director of communications. You deal with The Wall Street Journal, The Washington Post, you deal with all the publications out there. All the periodicals, you deal with the news, everybody all the time. I consider you an expert in this topic. Is there more written about Log4j, Log4Shell, or Colonial Pipeline and Ransomware? Based on your expertise and opinion, what's out there? What does the common person know more about?

Rachael: Honestly, the Colonial Pipeline because everybody understands being without gas.

Eric: Which one would you say is more commonly understood and known?

Rachael: Versus Log4j?

Eric: Yes.

Rachael: Everything. Unless you're in the industry or really following it, you wouldn't necessarily be poking on Log4j like you would the others. As a consumer, you can understand it in terms of broad-based interest in being able to grasp a concept. We can grasp the concept of not having gas, but with a lot of things, these zero to vulnerabilities until it impacts you personally. You have a hard time wrapping your head around it in terms of a more broad-based audience.

If my iPhone, or if I was playing Minecraft and all of a sudden stopped working for me because of Log4j, as a layperson, I would understand it better. But when you read this stuff, sometimes it feels dense.

Dealing With Log4Shell Forever

Eric: Yes, or just so distant from something I control or deal with. I'm going to switch back to our expert here, Dr. Richard Ford. Dr. Ford, which one do you think has a more serious potential consequence from sabotage or espionage or theft of information?

Richard: We'll be dealing with this Log4j, Log4Shell forever because it's very deep in people's clouds. It's not even necessarily exposed on the front end. So my prediction is that this is one of these phones that will hang around for quite a long time. We'll find it in interesting and subtle places. I was shocked at, actually, how little coverage it got.

Eric: I always do.

Richard: We stood up in a war room once we figured this thing out. So Praetorian, we do a lot of offensive penetration testing work in the commercial world. We do security assessments, red teaming, that whole gamut of very high-end bespoke services. What we did is we weaponized this thing in a couple of hours, once it was announced. We're like, "Oh, my. Good Lord, this thing is awful." Then, we started working with our customers. I got to brag about this because it was a beautiful thing. We, for free, started scanning our customer's ecosystems.

Because when do you need friends? It's when you're in the trenches. This isn't the time to go, "Okay. Stroke me a check for X, and let's do it." The team buckled down over the weekend and lived on pizza and Mountain Dew, just banging out Log4j scans. The number of people that we got would cause you physical pain.

Comparing Log4Shell to Ransomware

Eric: Right, and that's why we're doing this show. Because I don't think people understand, and comparing Log4j, Log4Shell to Ransomware is probably not a good comparison. But maybe comparing it to Eternal Blow, the tool set or something. It has a better likelihood of damaging or creating damage, negative consequences.

Richard: Log4Shell potentially gives you an access, and then it remains to be seen what's done with access.

Eric: But once you have access, you have a lot of options.

Richard: You do have a lot of options. But if you're a bad guy, when something like Log4Shell comes out, what do you do? You don't pick one person and do something horrible to them, because you know that it's like this Cyber Monday of vulnerabilities. You’d want to get in there quickly before Tuesday hits and all those discounts go away. So you compromise as many people as you possibly can. You go resident and maybe I'll come back and do something bad to you later. That's my fear.

Eric: You gain entrance on a wide scale. Then you kick back and think about, "Now, how do I triage and what do I need to do?"

Richard: Or, "How do I make the most money, or how do I exert the most force?"

Eric: If you're on the good guy, good people side, you're a white hat hacker. You're an IT defender, InfoSec professional, whatever, what's your recommendation? What do you do? I've got all these systems, I don't even know about 30% of them based on your data, which I would agree with. Some places are a lot worse than 30%, what do you do?

An Attacker Centric View

Eric: What should we do, and what do we do? They're different answers. First of all, the time to figure this stuff out isn't when it's raining cats. There are things that you should be doing on those sunny days when the sky isn't falling.

Richard: We should pivot and talk about that at some point in our time together. Why do you deal with this specific vulnerability? You do the best you can. So you take an attacker-centric view because you know what the attacker's playbook is going to be. You make certain that none of your assets are trivially vulnerable for that attacker-centric playbook. So you use the scanners that are out there and you make certain those things blocked as triage.

Then you can delve down deeper into your system. If you develop your own software and you've got good asset inventory, then the only real way to deal with this is to patch or to get onto a patched version. Of course, that was a bit of a mess, because there were a few different patches that came out from Apache Software Foundation. We finally got, I think 217 is the current. That appears to have solved this issue. 216 and 215 had issues that were still exploitable.

Eric: The vendor community is going to be working on this for a while. But if you're in the InfoSec world, you're going to be patching your systems for a while?

Richard: So let's not give the industry a D-. I'd say it's more of a B-.

Eric: I totally disagree, but we'll go with you because you're the doctor.

Trying to Be the Good Folks

Richard: We did see a pretty swift response from quite a few vendors moving to the newer version. I know a lot of folks who worked that weekend trying to protect their customers, not just us. We were out there trying to be the good folks, but all those people who had vulnerable services were trying to get a patch through and test it and into production for customers. It was a real fire drill.

The place where we didn't do so well as an industry is, we've been the clearest about communicating the limitations of some of the medications. Or the limitations of the scanners that people have been putting out there. And the only real way to be sure is to just get rid of this exploitable version from all of your boxes. Just let it go.

Eric: Which is difficult. If I'm a CEO or a board member, Rachael and I are on the board of company X. We're going into the holidays here. We want to kick back and relax. We're tired. Do we know that our organization, our company is okay, and everything's going to be good going into the holidays? What are we being told?

Richard: You have to take a more risk management approach, probably a risk annihilation.

Eric: Which we're great at, in this industry. Risk and prioritization of assets and data, we're so good at.

Richard: We're number one, totally. But you have to view this from a risk management standpoint. You have to do some forward planning, you have to figure out what your attack surface is. That's a real problem for many companies.

[17:10] Shocking but Not Surprising

Richard: Again, that's a, "Don't do it when it's raining," sort of day. It is inexcusable. It's shocking, but not surprising that we're so bad at drinking our assets as an industry. I was looking at my home router, and I'm like, "Why do I have 12 devices on my home router?" After a little bit of back and forth with my wife and then actually after scanning the two devices, I couldn't figure out. I could account for the 12 devices and that's in my home.

Eric: I've got 39.

Richard: But you know what I mean. Why do I have that speaker? That thing's on the wifi, I guess it should be talking to my RAM. Now, imagine in the cloud where anybody with a credit card can spin something up and put it into your environment. It's pretty bad. One of the big takeaways from this is you need to know where your stuff is. There are tools that do that. Attack surface management, that's something that we do and something I'm keen on. But I'm not keen on it because we do it; we do it because it helps customers.

Eric: Because we should do it. I want to go back to Rachael, the board member. What question are you going to ask of Dr. Richard Ford? You're head of IT going into the holidays to know if you have a problem or not here?

Rachael: As a board member, I guess, wearing my hat where I read a lot of news coverage is. We're vulnerable during the holidays when people are out of the office. That makes us a prime candidate to be further attacked.

On Top of Log4Shell

Rachael: On top of Log4j, what else should we be worrying about during this time off with people away from the office?

Richard: It's actually interesting, Miss board member. In some ways, the tech's job is harder when people are out of the office because how am I primarily getting it if I'm an attacker? It's primarily fishing. Some of the war stories I could tell you from Praetorian, we have a very high success rate with phishing, and if you have MFA.

Eric: You're red teaming an organization. That's the easiest way to get it. The adversaries have proven that from the data that phishing is highly successful over the years.

Richard: Extremely. But a lot of people in the industry think that because they have multi-factor authentication, they're safe and they're not. Once I'm in your browser, I've got your MFA at that point, generally, because I can either steal your session tokens. There's all kinds of things I can do. Once I am into your browser, I am you.

So with people out for the holidays, in some ways, it makes the job of the attack hard. Nobody's clicking on those phishing emails. But in terms of managing your infrastructure, there's a couple of takeaways, actually. So the hackers take holidays too, that's a definite truth.

Eric: That's to our benefit.

Richard: That's sort of to our benefit. But a lot of the people we want about at the nation's state-level have different holidays than us. You can tell who you're being attacked by going, "Oh, this is a holiday in this part of the world. Suddenly I'm not getting attacked."

The Attackers Take Days Off Too

Eric: Like Chinese New Year may not be a big day to go after the Americans?

Richard: It could be. I don't know why you're picking on China, but yes.

Eric: I'm picking on everything.

Richard: It certainly could be a correlation that it's a little bit quieter on networks for certain kinds of attack on those days. So the attackers take days off too, not always the same ones that we do. But there'll be a lot of scanning. When you think about attacks around Christmas, one of the interesting things is trying to route or own all the electronic gadgets that people all turn on for the first time and put on the internet.

That's an interesting target. It's not commercial, it's very personal. But all those devices become a target. From a corporate network standpoint, the attackers do have a little bit more time because it's usually a skeleton crew. But one of their favorite ways of getting in, which is phishing, has been taken away from them. People just don't do as much email over Christmas.

Eric: I feel like I do more personal, less work. The number of, I call them phishing emails, but it's just really vendors trying to get my business over the holidays here is massively up. I go through email much faster as a result of the volume increase, so I pay less attention. Now, I'm not clicking on things other than the delete button 90% of the time, maybe more. But I do feel that just due to the volume, your guard is probably down a little bit. I'm more careless. Personally, not at work.

A Good Phishing Email

Richard: But a good phishing email will catch you offbeat. Some of the stuff that's out there is really very good. Some of the pretexts that get set up are very good. We have companies. We've got all kinds of tricks that allow us to do what we do.

Eric: So, Rachael, board member, we're now off of a Log4Shell here. It's still a major concern going off the holidays because the adversary does have access. If they've gained access, of course. If you weren't able to patch in time or they gained entry before you patched.

My guess, Dr. Ford, would be that there aren't as many defenders working either. So if a nation state or a determined bad actor really has rule of the roost in many cases. That's the problem we have.

Richard: It can be very bad for people borrowing in. I will say that even today, we are still discovering vulnerable versions of Log4j in people's infrastructure. Even today, just this morning, we had another.

Eric: Well, you said you'd be doing it for the rest of time.

Richard: We'll be using this for a while. If we are using it for a while, media attackers will be using it for a while too. This has been one of the craziest two weeks that I've had in my career.

Eric: That's why it's so serious in your mind.

Richard: Yes, because it's this weird, subtle vulnerability where it's not just the internet-connected things I need to worry about. It's anything that handles data that an attacker can taint, whether that data comes through HTTP or DNS, or, God help you. I might be able to OCR this into your system, which is crazy.

[25:34] Log4Shell Is Not Sexy

Richard: There's some really crazy vulnerability channels. It's not just, "Oh," it's not like Heartbleed, where you know you got to go patch a certain version of TLS. If it's not talking TLS on the internet, it's probably okay.

Eric: Yet, we're treating it. Even Heartbleed had an interesting name, no offense, but Log4Shell is like, eh. It sounds like a Unix app.

Richard: It's not doing it for you? You're not a big fan.

Eric: It's a problem. A lot of the people I talk to, when you look at the news, I don't think people understand the severity of it. The name is part of it, it's not sexy. It's not something that's like, "Oh, well I better care about that."

Rachel: It's not like the media express.

Eric: You worked your ass off for the last two weeks. I got to tell you, I didn't work that hard on it. Our teams did. I didn't have a lot of customers dialing us up and saying, "How exposed are we? Where's the problem? How do you help us?" We normally get that. I would like a lot of my peers and a lot of people I know in the industry, unless they were super technical, they didn't tend to have the same level of concern either. That's a problem.

Richard: I was calling people on Sunday night when I realized how bad this was, just old friends. So not customers, just old friends.

Eric: What'd they say?

Richard: "How have you looked at this? Well, I knew there was something going on. Is it bad?"

Eric: It's like logging, who cares? Nobody cares about logging. It's like backups, not that important.

The Worst Vulnerabilities

Richard: Tuesday morning, I got a lot of thank you calls. It was nice.

Eric: They actually saw the level of severity, but do you think the bulk of the industry sees it that way? You described it as probably one of the worst, if not, the worst vulnerabilities or attacks that you've seen in your career.

Richard: I don't say that because I'm going to make more money. I don't say that because I'm trying to spin it up, I say it because I think it might be true. It's just got all these weird arms and legs that have made it very unpleasant to fix. I can imagine things that would be worth it. They were more hardware-based, because they're just a beast to recover from.

Eric: But have you seen them?

Richard: Yes, we are close with some of the spectrum meltdown things but there were ways around it. The point there is that those things were esoteric. They were hard to exploit.

Eric: Think about the scale, the level of access. We're going to see this down the road. We may not be able to link it back, but we're going to see it with data exfil cash exfil, maybe some espionage sabotage. We'll see different types of downstream consequences. I don't don't even know if we'll be able to link it back in many cases, just my gut.

Rachael: I think people too, though, the other part are people just exhausted. "It's just yet another thing. It'll work out. We'll have enough patches come through. It'll work out. We'll just ride the wave.

A Brutal Industry

Richard: There's a reason there's pretty brutal burnout in our industry. We joke about that as industry insiders, but this is a brutal industry for people just burning out. You are on that hamster wheel of pain. At some point, you get numb and you go, "Yes, it's this remote thing that I can nail with a string. How bad can it be?"

Rachael: It's almost like this thing that we have to live with like we were talking about earlier. You start looking at endemic situations and cyber is like that. It's just this awful thing. I guess people are just getting used to living with it being awful all the time. It's just chock another one on the post of things happening.

Eric: How do we prevent it? It's this small, fundamental piece of code that's ubiquitous, it's everywhere. It is going to stick around for a while. How do we prevent the next one? What could we have done, back in the day to prevent this?

Richard: Static analysis of code can help. The theory is by having everything open source, these things shouldn't happen. I will offer Log4Shells. People are looking at it.

Eric: They're open source when they do happen. A lot of people have been looking at it and using it and the problem is larger.

Richard: Potentially so, yes. This is a really hard problem. A better approach is to say, "What are the things that I need to have taken care of before the next version of something like this happens? So that when this happens, I can react very quickly." Cybersecurity is a game that is not won by the strong, it is a game won by the quick.

A Good Asset Inventory

Eric: What you're saying is regardless of what the exploit is or the vulnerability, if you have a system, if you have an approach when that vulnerability or exploit appears, you will be able to more quickly deal with the environment that you manage?

Richard: Yes. So do you have a good asset inventory? Do you know how to keep the inventory up in real-time? Because you can't do it in spreadsheets in the cloud.

Eric: Or in a crisis?

Richard: Yes, because it represents what the network was maybe some time ago. You need to be automated, you need to be able to look at it like an attacker would look at it. And you need to be able to filter all that noise, because what is the CISO not wanting? The one thing that the CISO does not want is another blinking light.

If I offer the Richard Ford patented blinking light service to a CISO they're just going to look at me funny and go, "No. I got plenty of blinking lights. We got lots of blinking lights. Some of them even blink on important things, but I'm not dealing with them." We need to de-nice the world for the CISOs to tell them about what really matters. A good example is if I scanned your network, I'm sure I'd find things that were out of date.

But I shouldn't tell you about all of them, I shouldn't fuss you about all of them. I should tell you about the three that are causing you the most pain, that give you the most vulnerability. The ones that I could exploit today, not the ones that are vulnerable to some theoretical vulnerability that I've never seen anybody yet breached by.

The Priority Level

Eric: You started with this as saying you don't need physical access. That's a problem. If you need physical access, I would lower it in the priority level, risk level.

Richard: Your physical access point is very well made. When the storm isn't raging, we have to be taking these preventative steps to understand what our attack surface is and who manages it. Half the time you find a box in your IP space. You're like, "I have no idea who owns this box."

We've dealt with customers in the last 14 days where they're like, "Well, yes. You're hitting this box on our network and yes, we can see it's vulnerable. We don't know whose it is." Well, it's yours, because it's on your network.

Doing a really good job of understanding where everything is helping you because you are not scrambling when you could. Then if you had good software bills and material, you could very quickly run a query against that database and go, "This, this, and this. Those are the boxes I need to shut down," or "Those are the boxes that I need to mitigate."

The challenge, I have nothing but love, affection, and respect anybody who would take the job of CISO right now. You are a crumple zone at the front of the car that takes the impact when something bad happens.

Eric: You don't win. The best you do is crumple well and protect people. There's no upside?

Richard: It's a very difficult job. You can't hire people, you can't retain them when you do hire them. The salaries right now are stupid beyond words, for some of these positions.

[34:23] Vulnerabilities That Are Coming at You

Richard: Then you have these vulnerabilities that are coming at you all the time while you're being told to accelerate the transition to work from home or accelerate digital transformation or whatever it is that is mission-critical.

Eric: Reduce cost or whatever it may be. It's a really hard job, and so nothing but respect.

Richard: I've worked with remote CISOs the last couple of weeks who are just putting in crazy hours. They and their teams, sleeves rolled up trying to bail the ball. So I don't want anything I say to be like, "Oh, we need to do better as a team. We all need to work harder."

That's just not realistic. We need to work smarter and do the things that matter and not just run around and try and pouch for everything.

Rachel: But as we talked about in the past, sometimes people need that impetus to go out. Do these things that they should be doing, like with the whole Colonial Pipeline. Biden got involved and made it a thing and, "Oh crap. We need to do something." But until the bottom falls out, are people going to do half of that inventory? Or are they going to get ahead of it or just think, "We'll be okay?"

Richard: We'll be okay. We'll wait till next time.

Eric: You're so busy, that's what you're saying. You've got to prioritize but you can't get in. Everything's number one.

Rachael: How do you start knocking those off the list if they're all competing with each other?

Richard: You have to have a strategy and then you just have to manage it really well, you can do it.

Doing the Things That Matter Most

Richard: The job of a CISO is about managing resource constraints as much as it is about security and doing the things that matter most. That's one thing that, as an industry, we haven't always done very well. It's explaining to the customer what really matters most, because usually what matters most is what you're trying to sell.

That is such a bad way to do anything. What matters most is the thing that's going to harm your customer most. Even if that's not what you sell, that's what you should focus on. There's so much money floating around the cybersecurity industry. It's very easy for the most important thing to be the widget that I'm selling today.

Eric: That's what I see. I've seen it throughout my whole career. We spend time on buying things as opposed to we've spent a lot of time talking about trust. We need to talk about risk, understanding risk, and we rarely get into a conversation with that. As a product vendor, it's usually, "Here's a list of requirements, which ones do you meet?" It's like, "Well, wait a minute, what are you trying to accomplish? What are you trying to do?" That's really hard for customers because they want to buy products.

Richard: No, that's exactly right. One of the things that we've done as an industry. It just hasn't worked. If we get into feature wars with each other, "I'm going to have more features than Rachael's product has. You can have different colored dots on the map, instead of all the same." We should be focusing on offering cost security value rather than features.

ServiceNow Integration With Log4Shell

Richard: It doesn't matter what my ServiceNow integration necessarily looks like if I can stop you from being breached. You didn't buy me because I integrate well with Jira; you bought me because I can stop you being breached.

Eric: You should want to buy an outcome or a result set, not a bunch of blinking Richard Ford lights in a box?

Richard: I wish more people spoke at that. You are buying an outcome, but usually you're not selecting based on outcome. You're selecting based on features.

Eric: We've done a lot of sales training. One of the things Steve Thompson, famous sales trainer in the industry talks about is, "Are you selling a quarter-inch drill bit or a quarter-inch hole?" It's very basic, but as a salesperson it's like, "Well, we spend so much time selling the drill. But what the customer should want and many times does want, is a quarter-inch hole.

That's why they're buying the drill and the drill bit and everything else. So if I can provide the whole, do you care how I get it done?" But the same thing here, what are you trying to accomplish? What outcome are you trying to accomplish? How do we help you get that? Who cares about the blinky lights?

Richard: What the CISO really wants is to be able to sleep at night. To be able to be on that beach and actually look at the sand as opposed to look at their cell phone and see what the latest.

Eric: Today, the sales guy gets to do that, or gal. The sales people get to hit the beach and sleep because they just sell the widgets. We need to change the industry a little bit.

Who Get the Mission

Richard: We do. It's one of the things that we have in common. From my time at Forcepoint, especially with G2, people got the mission; the government side of the house, they got in the mission. They understood that the job was stopping bad people and allowing good things to happen. That's the nice thing about Praetorian as well. It's a lot of folks who get the mission that we're the watchers on the wall trying to allow you to have a safe, prosperous, and healthy business.

As a whole, sometimes we do drift a little bit on the mission. It's especially bad because this is such a hot space for investment. You can get into cybersecurity for love, which is how we got into it. There wasn't a cybersecurity industry when I started.

Eric: We're fixing problems. This is great. Now we're tired.

Richard: Or you can get into it to make a ton of money.

Eric: You don't even have to be good and you make a ton of money.

Richard: The outcomes for the customer, though, look very different in those two worlds.

Eric: We're coming up on Christmas time at this point. Good luck with Log4j and Log4Shell. I sure hope we make some progress here and our defenders don't work harder than they have to. But I really do hope they protect our businesses, our organizations and our people. That would be my wish.

Rachael: Get a good night's sleep, too. That would be good, too.

Richard: Well, it's been a pleasure. Thank you so much for having me on. It's always fun to hang with you all.

Most Significant Events of Our Time

Eric: It was great, and thank you for educating us. Thank you for educating our listeners. There are a lot of vulnerable systems and organizations out there. We're just going to have to do our best and deal with them as we do. But I hope Richard is wrong that this is not one of the most significant events of our time. I think he's right.

Rachael: In my history of knowing Richard, he's always usually pretty right.

Eric: He's usually spot on. Not only does he know things, he sees things. He knows what's going to happen. That's what makes him such a great guest and person to talk to.

Rachel: 100%.

Rachael: Great to have you, Richard. Hopefully, you can come back again soon. Thank you to the lovely woman on Twitter who did give us a shoutout on the podcast. We greatly appreciate the feedback. For all those folks out there, you can get a fresh new episode every single Tuesday right to your inbox if you hit the subscription button. It's really that easy and you get Eric and Rachael and now, Richard, delivered to you on Tuesday.

About Our Guest

Dr. Richard Ford is the Chief Technology Officer of Praetorian. He has over 25 years of experience in computer security, working with both offensive and defensive technology solutions. During his career, Ford has held positions with Cyren, Forcepoint, Virus Bulletin, IBM Research, and NTT Verio. In addition to work in the private sector, he has also worked in academia, having held an endowed chair in Computer Security.

He worked as Head of the Computer Sciences and Cybersecurity Department at the Florida Institute of Technology. Under his leadership, the University was designated a National Center of Academic Excellence in Cybersecurity Research by the DHS and NSA. He has published numerous papers and holds several patents in the security area. Ford holds a Bachelor’s, Master’s, and D.Phil. in Physics from the University of Oxford.