Layer 8

Why Alex keeps me up at night.

Things like this, that’s why.

And not just because he puts me in mind of songs:

(and yes, I can make references closer to this century)

but because his questions can’t be answered in a short comment.

When he asks, “What are you managing towards?“ and gives some good examples of answers, my first impulse is to combine one or more of them and say something like:

“I’m managing towards just enough control strength to let luck take over.“

That’s dipping into Good-Enough-Securityland, where “good enough” is measured as “whatever keeps us from shooting ourselves in the foot.“ This doesn’t sound at all noble, I know, and it’s not all cool like Andrew and the Metrics or even our Bayesian Homeboys, but to be real honest, my management doesn’t want to get to that level of elegance. They just want me to keep their names out of the papers, do the right thing by our customers, and tell them how much they should spend to achieve that.

I make it a point to remind them from time to time that we’re doing pretty well on the prevention and detection fronts, but that nobody is going to be able to stop a targeted attack. They’re reasonable folks; they understand this. They understand that you can’t control a threat, especially one that’s external. What I’m doing is working to prevent opportunistic attacks, and making sure we’re doing enough due diligence that a reasonable person would feel that our legal backsides are covered.

Managing to compliance is almost irrelevant to our security landscape. That would be like managing your accounting to compliance. Yes, you want to make sure you’re following the rules, but you sure wouldn’t manage your finances with the end goal of passing an audit. In fact, if you asked any CFO if he were “managing towards compliance,“ he’d probably look at you funny.

Schneier’s extremely depressing and extremely true essay on why it’s so hard to sell security says it all. My bosses don’t want to get to “best” or “100% compliant.“ They want to do better than the competition, but not radically so if it means incurring too much “loss” in the form of paying for security; they want to feel confident that they have done the best they can to put in reasonable controls. And then they want to forget about it and go about their real business.

Once a year, I write a report (oh, 40 to 60 pages’ worth) on what my section has been doing and what else I think we need to do to stay at “good enough.“ And then my senior management sits down with me and we have a discussion to update what we think “good enough” means for us. If they want metrics to help them narrow in on “good enough,“ they’re in the report. I tell them what I’m doing with their money, and if possible, I compare it to what our peers are doing. It’s one big “state of the union” talk, and it only lasts long enough for them to grok it, and then we’re done.

They get to spend the rest of the year feeling lucky.

Posted by shrdlu on Tuesday, June 03, 2008
(6) Comments • Permalink •

Next entry: What bugs me about my work.

Previous entry: Not too much to say.

Comments

Alex

on 06/03 at 08:16 PM:

“and tell them how much they should spend to achieve that.“

You get to tell them? Sweet!

OK, seriously - “If they want metrics to help them narrow in on “good enough,” they’re in the report”

That’s all you need, right? I’ve got an issue with this part:

“I compare it to what our peers are doing”

Now I understand why *you* specifically say that - and why that’s relevant to you (because I know your super-secret identity and all), but I’d really be cautious before I advocate that as a budget approach. But that’s another topic to give you another sleepless night..

Thanks for the kind link and discussion…

arthur

on 06/05 at 10:06 AM:

“I compare it to what our peers are doing”

See, I view this as the most basic of all metrics aka “best practices”. What my peers (at least the ones I respect) are spending, is a good measure for me, of whether or not my risk assessment of similar issues is in line or not. Obviously there will be some flux, but normalizing for things like relative organization sizes, I figure we should be more or less in the same order of magnitude.

shrdlu

on 06/05 at 11:38 AM:

I’d agree with you, arthur, if only to be able to answer why we’re doing something different. In other words, I wouldn’t blindly spend as much as the Joneses, but if you accept that a “normalized peer organization” would have the same kind of general risk profile (NOT appetite! profile), you can then decide whether you’re way off in your methods for addressing the risk, and if so, in which direction.

Maybe this is just enough to push Jack over the line into explaining why this is bad and wrong, but so be it—the weekend’s coming up and I can afford to be sleepless

on 06/06 at 07:02 AM:

There is another approach to risk management that isn’t threat based which may garner you more respect. Instead of worrying about threats to your business assets, discuss the business model and plans to grow it. From there discuss how your team can enable the business to grow in the manner they wish to grow. Discuss with them how security can help the business do what they wish to do, and how it can help remove the impediments to growth.

shrdlu

on 06/09 at 05:13 AM:

Walter, excellent point, thank you.

LonerVamp

on 06/12 at 12:06 PM:

“That’s dipping into Good-Enough-Securityland, where “good enough” is measured as “whatever keeps us from shooting ourselves in the foot.” This doesn’t sound at all noble, I know…“

This is one of the bigger things I’ve learned in recent years in IT in general, let alone security. The geek perfectionist in me screams at every little imperfect issue. But that has to be quelled to get “good enough” to do the job. Some jobs/orgs have a higher “good enough” than others, but in the end, that’s really the measure. I doubt I will ever work for an org whose definition of “good enough” means shopping at the most expensive stores on a credit card with no limit (NSA?).

Kinda like how coding and even my scripts at work are created. I dislike the fact that some of my administrative scripts are not very robust, maybe not even all that secure in the bowels of my network. In fact, a few are likely really shoddy pieces of work, spiderwebs upon which data flows that so much depends upon.

But what if those shoddy pieces of work last 5 years through the lifecycle of the solution? Should I have spent more time and energy and money on making it more robust for no return?