Greg van der Gaast's advice for CISOs: ‘Stop doing cybersecurity. Start doing business securely.’

Van der Gaast – chief information security officer (CISO), consultant, author, world-famous former hacker and undercover agent – talked with Michael “Roo” Fey, Head of User Lifecycle & Growth at 1Password, on the Random but Memorable podcast about why taking a different approach, especially in a world of increasing security incidents and ballooning budgets, can be a much more effective strategy to reduce both vulnerabilities and cost.

What’s different in Van der Gaast’s approach? It has a lot to do with focusing on quality and process before risk. And repeatedly asking “why” to get at the root of upstream security issues. Read on for the interview highlights, or listen to the full podcast episode.

Editor’s note: This interview has been lightly edited for clarity and brevity. The views and opinions expressed by the interviewee don’t represent the opinions of 1Password.

Michael Fey: What was your journey from undercover hacker for the FBI and Department of Defense (DOD) to cybersecurity consulting?

Greg Van Der Gaast: As a teenager growing up in Holland, I started learning about operating systems and how stuff worked and how you could break stuff and make it do other stuff.

I semi-accidentally hacked into a nuclear weapons facility somewhere overseas – I think three or four weeks after they set up five atomic bombs on the ground. It was quite a hot topic at the time. I just realized what it was, downloaded a bunch of research, and next thing I know – I had moved to the States at this point – it’s like CIA, DIA (Defense Intelligence Agency), and FBI.

I had four suits show up at the door. The first one said he was from the DOD. I invited him in and I told him, “Look, I was living in Holland at the time. This was somewhere over in Asia. I don’t think I’ve broken any U.S. laws. I was worried you guys were from Immigration.”

That’s when suit number four raised his hand and said, “I’m from Immigration.” I was put into the back of a van, taken to a detention facility where, to this day, I still don’t know where it was.

About a week later, more suits came and made me a job offer I couldn’t refuse. I spent the next three years working undercover, getting paid cash by federal agents in underground car parks.

What I do now is at the extreme end of the strategic- and business-focused leadership and root cause big-picture stuff that isn’t on the radar of most security people. Part of my challenge has been that no one’s asking for this because no one knows that these are even valid approaches.

“What I do now is root cause big-picture stuff that isn’t on the radar of most security people."

I think my overall mentality is more one of a problem-solver rather than just a “security person”. I started looking at the bigger picture of, “Well, we’re deploying all these firewalls and database encryption and intrusion prevention systems, all the latest stuff. Are we actually protecting the business? Do we know what data is where and who’s doing what and how these business processes work and what data I should even be seeing over this network that I’m monitoring?”

It dawned on me that everybody else hated process. But I realized that if we’re not consistently implementing, configuring, monitoring, managing any of this stuff, how are we sure we’re not missing anything? I started focusing on “how do I make sure I mature the technical tooling?” I started realizing a lot of these things wouldn’t happen if it weren’t for some root causes elsewhere.

So why don’t we focus more on our IT maturity rather than spending an absolute fortune on security operations? If those decisions are made by other departments, how do I influence change and create a program?

Learning about the business language and about business took me down this journey where security is about risk management – and I think that is completely backwards. We should be like most other industries, like in manufacturing, aviation, oil and gas, healthcare – it’s about quality management.

It’s about having really high quality processes so you don’t have defects that cause issues. We don’t do that. We don’t go upstream. We don’t go holistic. We just constantly detect and respond to the defects being exploited.

That’s brought about this really different approach to security that’s process focused, not about doing IT security, but about going through your business processes and making sure they’re secure.

In other words, stop doing cybersecurity, start doing business securely.

MF: You mentioned other industries that are heavily process oriented and quality focused. When I think about that from a software point of view, my brain says: “We can’t just build a resilient widget because the platform on which that widget rests is constantly shifting."

It’s an apples-to-oranges comparison. Am I thinking about this the wrong way?

GVDG: Every industry – aviation, automotive, transport, oil and gas – focuses on quality management. They focus on addressing the root causes behind problems. I see incident responses like: “Oh, the root cause was that this got exploited.” Why was that exploitable?

“Oh, well, because so-and-so did X.” Okay, why did so-and-so do X? “Oh, because they had this.” But why did they do X without considering the downstream impact? “Oh, because there’s no awareness.” Why? Why? Why?

Toyota has a “five why” system to find a root cause. They ask “why” five times and go five levels deeper. When you address those things, you get this downward curve of issues or defects over time.

If you think about security vulnerabilities, they’re actually quality defects in code, in the configuration of a system, and how a system is built for users. But there is a point at which there is a diminishing return in resolving the root cause of this thing that caused 50% of our issues. Or the second thing that was 30% of our issues. You end up with this level of residual activity where it’s just not worth it to fix the root cause because it’s too expensive or happens so rarely that it’s just not cost-effective.

That is the point at which risk management should start. Because if you look at the number of most vulnerabilities out there today – I’m going to say 98% of them are known defects.

“If you look at the number of most vulnerabilities out there today – I’m going to say 98% of them are known defects."

If we started doing those things, we would reduce our exposure by probably one or two orders of magnitude. That’s really significant. That’s what I’m getting at because we’re at a point where instead of having that downward curve in security, every year we spend more money and every year we have more incidents.

We see new applications all the time that have four-, five-, six-year-old Common Vulnerabilities and Exposures (CVEs) in them. If someone’s using six-year-old code to build a new platform, that’s a process issue. We know how to fix this, but we don’t.

Only once you’ve done all that, should we risk manage residual issues. But we’re not doing the big picture. Very few people in security are bringing that total business lifecycle so that management appreciates the real cost. The reaction I get from CISOs and security leaders usually falls into two camps.

The first is: “Yeah, I get it but please shut up because I like my job security.” We don’t want to fix the problem because it threatens our employment! Really, if you’re the one fixing the problem, you become far more valuable. This is how I’ve grown in my career – not by creating more problems to keep me busier, but by learning to fix bigger problems that create value.

The second reaction, which is quite common, is a problem of structure. It’s: “Yes, Greg, I understand that these process issues somewhere upstream are causing me all this work and it’s costing the business all this money to mitigate and remediate, but I don’t own those things. I don’t own the IT department. I don’t own the engineering function. I don’t own the fact that the salespeople put contract data in this platform. So I can’t do any of that.”

And I think that’s a truth. But now that you’ve identified the problem, you need to influence processes somewhere else to create a structure where you can drive change even though you don’t own it.

Every security issue is a quality issue, but not every quality issue is a security issue – but the root causes can be the same. So, if I fix whatever causes my engineering teams to produce a lot of vulnerabilities in what they develop, quite often I end up with cleaner code. It runs faster, it’s more stable, my customers are happier.

“Every security issue is a quality issue, but not every quality issue is a security issue – but the root causes can be the same."

My AWS compute costs go down dramatically. And you end up saving the business a lot of money because you’re making quality enhancements that go beyond just removing vulnerabilities. They remove other defects, they improve performance, they improve reliability. There’s a lot of benefits and they’re all cumulative and sustainable.

MF: It sounds like you’ve met some resistance when spreading your thesis out in the world. Can you talk about the differences between the companies that are very receptive to this type of approach versus the ones that aren’t?

GVDG: There’s a real lack of accountability in security. There’s a lot of elitism. We’ve all sat in the room with security people badmouthing the users and the business, like: “Oh, management won’t give us money.” But we’re all very confident about how important we are.

But if I go up to your head of InfoSec, who is asking for $2 million of security spending, and I ask them, “Will there be a positive return on investment for the business?” They’re absolutely adamant: “Oh yes, yes, we’ll definitely save money this way.” I’m like: “OK, how about you pay for it yourself and then you get to keep all the ROI?” All of a sudden, no one’s very sure anymore.

I often say that security in many ways is the best job in the world because no one really understands what you’re supposed to be doing. No one knows whether you’re actually doing it. And, if you screw up bad enough, they triple your budget!

When I would go into a place as an auditor or a consultant, especially as a consultant, where you’re really trying to help them, they would get very upset at you.

They don’t like you criticizing or pointing things out that they didn’t think of. It’s very much like you’re calling my baby ugly. It gets hostile very quickly.

But, if you put the same group of people in a room and you’re not talking about their business specifically – you start explaining the concepts – then they just kind of light up and say: “This makes a lot of sense.”

They’re very keen to go into work the next day and start applying the principles because you haven’t insulted them directly. You’ve given them an idea, an approach that they can implement, take credit for, and then they’re all too happy to do it. But the direct approach tends to be very, very difficult.

MF: It’s easier to say “well, we mitigated these 47 vulnerabilities this year” than it is to say “nothing happened this year again. We’re all set.” How do you change the conversation to: “This is how you should start advocating for changes so that people can see the value. Because if you don’t, the bottom line is going to win out over everything else."

GVDG: I think risk quantification is quite interesting but also pointless. Because OK, we removed 47 vulnerabilities, but what is the actual value of those vulnerabilities? Risk management calculations are – even the quantitative ones – extremely arbitrary.

And the next thing you know, it’s like, “Well, yeah, you removed vulnerabilities, but it’s actually running on a hypervisor running Windows 2008.”

Everything you’ve done can be circumvented like that. So how can you stand behind that value? I think risk quantification as a whole is very tricky because there’s no way of saying what those risks actually cost or whether they would’ve been exploited or not.

One of the points I like to make sometimes is this. You say: “We’ve done all the calculations and we’ve got an annualized loss expectancy for this risk of £200,000. We can mitigate it 90% for £50,000.”

That’s a good ROI if that quantification is accurate, which I highly doubt it is. But let’s assume it is. But then, what if you increase the scope of it: “We’re going to spend, let’s say £50K to eliminate a risk of £100K. What could marketing do with an extra £50K?”

And if the answer is, “Well, marketing could probably give us an extra million quid in sales if we give £50K,” does it still make sense to spend that money in security? Isn’t it better for the business to not do the security and do the marketing instead? How do you reconcile that?

I don’t think security should be risk-led at all. I think it should be business-led and a quality function – fixing your engineering defects.

“I don’t think security should be risk-led at all. I think it should be business-led."

For example, by fixing the engineering defects that are introducing the security vulnerabilities, I am lowering your AWS costs by €2 million a year. I’m doing a security review of your Salesforce (this is an actual scenario), in which I spent €20,000 and have removed all the excess accounts, reducing your spend on Salesforce by €48,000 per year. I’ve just made you money by securing you.

If you look at security as a quality function on pure cost savings and agility enablement, you can justify it. The risk reduction is a byproduct. You don’t even have to count it. It’s just gravy. That’s the approach I’ve been taking because I can actually save the company more than double the cost of the security function – demonstrably.

I probably can’t even demonstrate half of what I’m saving them, but I can demonstrate that I’m saving them more than what they’re paying me!

MF: Where can folks go to learn more about you and the consultancy work? How do they bring you in and have you help them put some of this stuff into practice?

GVDG: I wrote a book about three and a half years ago called Rethinking InfoSec, which was just an amalgamation of articles. I’ve recently done a collaboration with Hitachi Vantara, a book called What We Call Security. That one is really calling out this quality approach because what we are doing simply is not working. Every year we spend more and every year we spend more as a percentage of budget. It’s unsustainable.

I’m also starting a new consultancy. I’ve not actually launched it, but by March it’ll be out there. The website’s up, it’s sequoia-consulting.co.uk. I’m hoping to really help people address these high-level, strategic structural leadership issues.

Jenn Marshall

Contributing Writer