If I asked everyone to tell me what security is, what do you do about it, and why you do it. I wouldn’t get two answers that were the same. I probably wouldn’t even get two that are similar. Why is this? After recording Episode 9 of the Open Source Security Podcast I co-host, I started thinking about measuring a lot. It came up in the podcast in the context of bug bounties, which get exactly what they measure. But do they measure the right things? I don’t know the answer, nor does it really matter. It’s just important to keep this in mind as in any system, you will get exactly what you measure.
Why do we do the things we do?
I’ve asked this question before, and I often get answers from people. Some are well thought out reasonable answers. Some are overly simplistic. Some are just plain silly. All of them are wrong. I’m going to go so far as to say we don’t know why we do what we do in most instances. Sure, there might be compliance, with a bunch of rules, that everyone knows don’t really increase security. Some of us fix security bugs so the bad guys don’t exploit them (even though very few actually get exploited). Some of us harden systems using rules that probably don’t stop a motivated attacker.
Are we protecting data? Are we protecting the systems? Are we protecting people? Maybe we’re protecting the business. Sure, that one sounds good.
Measuring a negative
There’s a reason this is so hard and weird though. It’s only sort of our fault, it’s what we try to measure. We are trying to measure something not happening. You cannot measure how many times an event didn’t happen. It’s also impossible to prove a negative.
Do you know how many car accidents you didn’t get in last week? How about how many times you weren’t horribly maimed in an industrial accident? How many times did you not get mugged? These questions don’t even make sense, no sane person would even try to measure those things. This is basically our current security metrics.
The way we look at security today is all about the negatives. The goal is to not be hacked. The goal is to not have security bugs. Those aren’t goals, those are outcomes.
What’s our positive?
In order to measure something, it has to be true. We can’t prove a negative, we have to prove something to measure it, so what’s the “positive” we need to look for and measure. This isn’t easy. I’ve been in this industry for a long time and I’ve done a lot of thinking about this. I’m not sure I’m right in my list below, but getting others to think about this is more important than being right.
As security people, we need to think about risk. Our job isn’t to stop bad things, it’s to understand and control risk. We cannot stop bad things from happening, the best we can hope for is to minimize damage from bad things. Right about now is where many would start talking about the NIST framework. I’m not going to. NIST is neat, but it’s too big for my liking, we need something simple. I’m going to suggest you build a security score card and track it over time. The historical trends will be very important.
Security Score Card
I’m not saying this is totally correct, it’s just an idea I have floating in my mind, you’re welcome to declare it insane. Here’s what I’m suggesting you track.
1) Number of staff
2) Number of “systems”
3) Lines of code
4) Number of security people
Here’s why though. Let’s think about measuring positives. We can’t measure what isn’t happening, but we can measure what we have and what is happening. If you work for a healthy company, 1-3 will be increasing. What does your #4 look like? I bet in many organizations it’s flat and grossly understaffed. Good staff will help deal with security problems. If you have a good leader and solid staff, a lot of security problems get dealt with. Things like the NIST framework is what happens when you have competent staff who aren’t horribly overworked, you can’t force a framework on a broken organization, it just breaks it worse. Every organization is different, there is no one framework or policy that will work. The only way we tackle this stuff is by having competent motivated staff.
The other really important thing this does is makes you answer the questions. I bet a lot of organizations can’t answer 2 and 3. #1 is usually pretty easy (just ask ldap), #2 is much harder, and #3 may be impossible for some. These look like easy things to measure and just like quantum physics – by measuring it we will change it, probably for the better.
If you have 2000 employees, 200 systems, 4 million lines of code, and 2 security people, that’s clearly a disaster waiting to happen. If you have 20, there may be hope. I have no idea what the proper ratios should be, if you’re willing to share ratios with me I’d love to start collecting data. As I said, I don’t have scientific proof behind this, it’s just something I suspect is true.
I should probably add one more thing. What we measure not only needs to be true, it needs to be simple.
Send me your scorecard via Twitter