Introducing Cyber Portfolio Management

At RSA’17, I spoke on “Security Leadership Lessons from the Dark Side.”

Leading a security program is hard. Fortunately, we can learn a great deal from Sith lords, including Darth Vader and how he managed security strategy for the Empire. Managing a distributed portfolio is hard when rebel scum and Jedi knights interfere with your every move. But that doesn’t mean that you have to throw the CEO into a reactor core. “Better ways you will learn, mmmm?”

In the talk, I discussed how “security people are from Mars and business people are from Wheaton,” and how to overcome the communication challenges associated with that.

RSA has posted audio with slides, and you can take a listen at the link above. If you prefer the written word, I have a small ebook on Cyber Portfolio Management, a new paradigm for driving effective security programs. But I designed the talk to be the most entertaining intro to the subject.

Later this week, I’ll be sharing the first draft of that book with people who subscribe to my “Adam’s New Thing” mailing list. Adam’s New Thing is my announcement list for people who hate such things. I guarantee that you’ll get fewer than 13 messages a year.

Lastly, I want to acknowledge that at BSides San Francisco 2012, Kellman Meghu made the point that “they’re having a pretty good risk management discussion,” and that inspired the way I kicked off this talk.

Calls for an NTSB?

In September, Steve Bellovin and I asked “Why Don’t We Have an Incident Repository?.”

I’m continuing to do research on the topic, and I’m interested in putting together a list of such things. I’d like to ask you for two favors.

First, if you remember such things, can you tell me about it? I recall “Computers at Risk,” the National Cyber Leap Year report, and the Bellovin & Neumann editorial in IEEE S&P. Oh, and “The New School of Information Security.” But I’m sure there have been others.

In particular, what I’m looking for are calls like this one in Computers at Risk (National Academies Press, 1991):

3a. Build a repository of incident data. The committee recommends that a repository of incident information be established for use in research, to increase public awareness of successful penetrations and existing vulnerabilities, and to assist security practitioners, who often have difficulty persuading managers to invest in security. This database should categorize, report, and track pertinent instances of system security-related threats, risks, and failures. […] One possible model for data collection is the incident reporting system administered by the National Transportation Safety Board… (chapter 3)

Second, I am trying to do searches such as “cites “Computers at Risk” and contains ‘NTSB’.” I have tried without luck to do this on Google Scholar, Microsoft Academic and Semantic Scholar. Only Google seems to be reliably identifying that report. Is there a good way to perform such a search?

Groundrules on Complaining About Security

Groundrules on Complaining About Security

In this article, I want to lead into some other articles I’m working on. In those, I’m going to complain about security. But I want those complaints to be thoughtful and within a proper context.

You will hear many of us in security talk about threat models. Adam literally wrote the book on threat models and if you don’t have a copy, you should get one.

Threat models are a way of thinking about security in a somewhat rigorous way. Without some sort of threat model, you’re not really doing security.

Threat models sound complex, but they’re really not. We all do them intuitively all the time, and here’s the basic outline of how to make one. You want answers to these questions:

  1. What are you doing?
  2. What could go wrong?
  3. What are you doing about it?

Among the valuable things in Adam’s book, he talks about these and more, but these three simple questions frame how to talk about security no matter who you are. If you don’t have a threat model, you might be doing something useful, but it’s not really security.

If you are a maker of security, without a threat model you might have a solution in search of a problem. You might also have a stone soup security system, in which you throw a bunch of things in a pot, and while tasty (or secure), isn’t organized. There are many, many stone soup security systems out there.

If you’re going to use a security system, without a threat model you have no way to know if what you’re getting meets your needs.

If you’re challenging a security system, without a threat model, your criticisms may be true but irrelevant.

It is these latter two cases – deciding what security system to you and providing a critique of a security system – that I’m going to focus on, particularly since I’m going to be engaging in challenges, and people selecting a system also need to think about what their own threat model is when selecting a system. If you’re going to use a secuity system, a little bit of thought about what you expect it to do and what you expect it to protect you from is in required.

Let me move a bit away from computer security for a moment; analogies often help.

Let’s look at this statement:

  • Aspirin doesn’t cure cancer.

It’s true. Aspirin doesn’t cure cancer. It doesn’t do half-bad on headaches (with of course, a number of other qualifiers), but it doesn’t cure cancer.

However, if Alice says, “I’m going to go take an aspirin” and Bob says, “Aspirin doesn’t cure cancer,” he has implicitly assumed that her threat model is not:

  • I have a headache
  • I’m going to take an aspirin to cure it

but

  • I have cancer
  • I’m going to take an aspirin to cure it.

Even if Alice actually does have cancer, she might also have a headache. Especially if she has to deal with someone with simplisitic thinking like Bob. This is the sort of headache that got me to write this essay.

Getting back to security, while I was typing the first part of this, a friend and I started on a discussion. We started with wondering if since most front door locks are easily picked, does that mean that they’re just security theatre. The discussion then went into social value of locks (most people are honest, after all), the technological merits of Abloy locks, the expense of getting a good lock for all your doors, the human factors aspects of wanting one key for all your doors, the security problem of weak points from the porch to the windows, and then on to reinforcing hinges and even the front door itself. It was a fun discussion, but it wasn’t a good security discussion, it was security stone soup. The initial question of whether most door locks do anything was the pot of water with a stone in it and we kept adding in garnishes until we ended up with a tasty conversation. However, at no point did we discuss a threat model. We don’t know what we were trying to protect, what threats we were protecting it from, or anything that turns it into a real security discussion.

I think we were talking about a stereotypical threat of a burglar backing up a van to the house and carting off a lot of valuables, but I am just presuming that.

I know of what I speak in this issue of threat models because I’m guilty of it, too. It’s so easy to get caught up in security stone soup that it happened to me while I was writing an essay on threat models and security stone soup.

Now that I have a couple of ground rules in place as a preface, I will complain about security in my next essay.