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.
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.
So what do we need instead of more money?
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.
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.
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 then measure:
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.
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.
This post was written by Sylvia Fronczak. Sylvia 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.
Photo by Anamul Rezwan