In any case, the response is coming!

RE: Guns vs. Butter – I suppose it depends at what level you’re talking about.

For “cost of downtime vs. vulnerability” or “$5 million for security or $5 million for marketing” sort of decisions, I’d argue those are business decisions that security shouldn’t be making.

If it is “this is my $15 million security budget to figure out how much to P/D/R – then many times, yes, that is a CISO’s decision – but again I would qualify that by saying that the CISO’s job is to spend that money within the *context* of the risk tolerance of the business owners.

Pick carefully among those presented to you by readers of airline magazines, choosing those that make sense for achieving the one metric that matters: does sufficient revenue (or other measure of organizational success) continue?

Then manage users and management with the “best practice” you and they have selected to achieve that goal.

Also, don’t hesitate to feed externally imposed “best practices” through a challenge/BS-filter. The whole password complexity thing is a case in point. Passwords are not compromised in the majority here by being non-complex. They’re mostly compromised by being phished or by being logged by trojans/malware. Our “best practice” for passwords thus have complexity and change requirements tailored to those threats, not to what too many others are still doing.

(I’m going to stay out of the whole “security metrics” thing beyond noting that it’s a wonderful goal for those with far more resources to do science on their users than most of us can afford.

Finally, your assertion that the economic decision of butter vs. guns is not our call to make is incorrect (I guess I disagree with more of CISSP than I knew). We do make that call; it’s what our management pays us for. Even better, their charge to us is to find ways to have both together at reduced expense. That’s a competitive advantage: employees are more productive because they both find it easier to get their work done, and we’ve reduced the hit from compromises and cleanup.

I totally agree. Best Practices are like checklists – they’re fine with significant experience/wisdom. Pre-flight checklists work because we know what makes an airplane fall out of the sky. We don’t really know what keeps a network “in the air”.

I couldn’t agree more – this issue is also a pet peeve of mine, although I am learning to keep my mouth shut more than I used to.

Best implies a comparison of at least 3 alternatives, right? good, better, best?
Absent data, it’s pretty hard to make such a comparison in any kind of meaningful way.

Standard practice is problematic for me, maybe because in medicine – part of my background – a standard of care implies a significant legal obligation.

Also I don’t see the relevance of saying that something would be standard just because everyone did it. Millions of lemmings jump off cliffs – I guess that by the time they figure out what they have done, terminology is almost irrelevant

I don’t have a problem with good practice. Some people do have long and deep experience, and it’s important to respect that, even if it’s “anecdotal” evidence.

Patrick
Dallas

But such password policies have usability problems:

“Security companies and IT people constantly tells us that we should use complex and difficult passwords. This is bad advice, because you can actually make usable, easy to remember and highly secure passwords. In fact, usable passwords are often far better than complex ones. ” http://www.baekdal.com/articles/Usability/password-security-usability/

But has anyone tested alternative password policies in realistic settings (i.e. real users or test users, real systems, real workloads) and evaluated them by measuring security outcomes (i.e. breaches, incidents, near-misses)? If so, then you deserve to call your preferred policy a “best practice”. Otherwise, it’s just folklore. Might be useful, might not.

We could probably assemble good evidence to support a list of “worst practices” (e.g. leaving web servers in default configuration, never patching critical software) from forensic analysis of breaches. But just because something is better than “worst practice” doesn’t make it a “best practice”.