Resources Blog Holding the industry accountable

Holding the industry accountable

Editor's note: This presentation by Chris Roberts was a session at last year's All Day DevOps. Readers are reminded that individual actions influence the direction our industry takes.

"Today we're going to have a conversation about holding our feet to the fire," said Chris Roberts (@Sidragon1). "We're going to break down what's going on in the industry and why we should care about it. Then we'll talk about what we should change, as well as why we should change it."

First, why are we failing?

Going back to childhood, we were told not to touch a hot kettle on the stove. But what did we do? We touched it. Or at least some of us did.

As humans, we need to experience something before we change. Can we fix humans? Can we change this behavior? In short, no, we can't.

For example, when we send emails to our employees to verify if they'll click on potentially dangerous links once a year, we're not going to get the results we want. We're going to have people click the link. Instead of sending a yearly email to complete the audit, we need something more.

So let's be clear. If you experience it, you will listen and change.

Why we need DevSecOps

Now let's look at the adversary's perspective. They have a large toolbox and a lot of time to do what they do.

On the organization's side, we have fewer tools and technologies. We also have policies, resources, and controls. They're not an effective tool against the adversary.

In short, we need help. We're erratic, conflicted, and disorganized. And we debate every decision. This is why we need DevSecOps.

Does that mean we need to spend more money on security? No. Currently we spend more than $124 billion in 2019. We're spending enough, but not in the right way. We're still expecting to hit $6 trillion in losses from security issues.

If money isn't the answer, what is?

So what do we need instead of more money?

  • Communication
  • Cooperation
  • Coordination
  • Collaboration

It's simple stuff. We don't need more tools from vendors. We need to focus on how we work with teams — security teams, design teams, development teams.

So how do we communicate in a way that others understand? It may not be a way that we're comfortable with. We might need to use terms that the business can understand. Networks are roads, IP addresses are mailboxes. Make it understandable.

And if we get it wrong, people can die. When we program autonomous vehicles, we need to account for things like jaywalking. Otherwise we'll end up with disastrous results.

Basics to focus on

So what basics should we focus on?

First, fix the human — sort of. Even though we can't completely fix the human, we can make people understand that safety is not security. We should also remove the easy ways into our systems, and we should realize we don’t have a perimeter. And once again, note that passwords are important.

All of these need a plan. So the final step is to get a plan.

One-hundred-percent security is a fallacy. We can only communicate our level of risk and reduce our level of risk.

Holding the industry accountable

The first way we hold our industry accountable is to look at our maturity model. What decisions and technology move the needle and reduce risk? Then let's talk about risk. Look at the business risk strategy and see how it compares to our risk strategy. And finally, measure it. If you have technology that's supposed to help, prove it.

Using Roberts' reference material, you can measure:

  1. Where you are now
  2. Where you want to be
  3. Where you need to be
  4. Where you have to be

If it seems overwhelming, don’t worry. It shouldn't take more than two hours to complete. If it takes more than that, you're doing it wrong.

Areas to focus

Think about detection and deception: we should always assume a breach. Then, if we assume breach, how will we know about it, and what are we going to do about it?

Until this point, we've approached technology in a reactive way. So how do we things differently? How do we engage someone earlier in the process? And how do we teach others earlier?

It's simple. We take an asymmetric shift to the blue team. We need to look at how we give the blue team more teeth.

On a final note, let's look at a fundamental attribution error. We play the blame game. Unless we know who was on the keyboard — what their motivations are — we can't do that. We need to look at ourselves in the mirror to see what we can do better.

Instead of focusing on blame, look to fix the problem.

We're all in this together. We need to sit down and work together. We need to collaborate because this is important.

Picture of Sylvia Fronczak

Written by Sylvia Fronczak

Sylvia Fronczak is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.