Best Practices for the Lulz

by adam on February 21, 2011

The New School blog will shortly be publishing a stunning expose of Anonymous, and before we do, we’re looking for security advice we should follow to ensure our cloud-hosted blog platform isn’t pwned out the wazoo. So, where’s the checklist of all best practices we should be following?

What’s that you say? There isn’t a checklist? Then how are we supposed to follow advice like this:

So there are clearly two lessons to be learned here. The first is that the standard advice is good advice. If all best practices had been followed then none of this would have happened. Even if the SQL injection error was still present, it wouldn’t have caused the cascade of failures that followed.

So please, if you’re going to advocate for best practice security, please provide a list so we can test what you say. Otherwise, I worry that someone, somewhere will have declared something else a best practice, and your hindsight will be 20/20.

Incidentally, the opening sentence is a lie. Attacking this blog is probably like kicking stoned puppies. Even though we do try to ensure it’s up to date with patches and use strong passwords, we selected the blog hosting company on a diverse set of criteria which included cost effectiveness for our hobby blog.

Previously on best practices:

Finally, there’s a little more context below the fold.

I should own up that the quote is taken somewhat out of context for rhetorical purposes. The very next paragraph alludes to what I’m saying:

The second lesson, however, is that the standard advice isn’t good enough. Even recognized security experts who should know better won’t follow it. What hope does that leave for the rest of us? (“Anonymous speaks: the inside story of the HBGary hack

Ars Technica has had very good coverage, and so I’m using their offhanded comment to illustrate. As a writer, I know how hard it can be to write as much as they’ve written without a single annoying sentence, and that’s without the reporting effort they’re clearly putting in. I’ve bolded it, but included the fuller context. That coverage of the HB Gary Federal hack has included: How one man tracked down Anonymous—and paid a heavy price, Anonymous speaks: the inside story of the HBGary hack and Spy games: Inside the convoluted plot to bring down WikiLeaks


The problem, though, is that as soon as you get the aforementioned “checklist,” people will be screaming that it’s not comprehensive enough or that it’s too comprehensive, etc. A checklist is always based on an unspoken estimate of risk and is prescriptive for that level of risk. It’s also ignoring a lot of interactions among different components of infrastructure that can affect the efficacy of the recommended controls. So I’m skeptical that we’ll ever do better than a whole bunch of contextual “checklists,” if we get to any at all.

by shrdlu on February 21, 2011 at 4:55 pm. Reply #

Adam, you are spot-on accurate with your assessment regarding best practices. Security is not prescriptive, and it never will be. Practitioners that attempt to paint a one-size fits all formula under the guise of best practices are doing a disservice to the industry and the organizations they represent. If we look at the raw dilemma, we will see that a checklist is an unrealistic substitution for insurance in any situation, because the risk can never be dropped to zero.

As far as the other facet of the post, the reality is that those that seek out the damsel in distress must realize that dragons may lay in wait. A painful lesson for someone to learn, but one that must be learned nonetheless.

by K0nsp1racy on February 22, 2011 at 1:59 pm. Reply #

How about the mother of all checklists, the BITS Kalculator-with-a-K? Look under Operational Risk in the Publications section at You say you’re not a bank and that 1200 items is Too Much Information and no cloud provider is going to give you that kind of detail for less than a contract of $1,000,000 worth of services? Let someone else do the checklisting, and look for PCI or HIPAA certification.

Still too much work? Look for two items in the terms of service: “not suitable for any particular purpose” and “customer will indemnify and hold harmless”. Have your lawyer do the looking of course, but if they’re not going to take any responsibility for any breach, then they’re probably expecting to be insecure.

Oh, you’re not asking for actual security after all, and what you really want is for your site to be quickly restored from backup after it gets defaced? Why are you wasting your time and theirs with security checklists when you’re really asking for is response time for recovery? Our risk slogan: manage first, assess later.

by Dean on February 28, 2011 at 12:19 am. Reply #

Best practice: Have a security g33k on call (or staff) to give you advice and “best practice” when you need it.

by LonerVamp on February 28, 2011 at 6:53 pm. Reply #

Here’s more thoughts for ya! Let’s say we decide this strange idea of “best practices” just doesn’t work. Then what’s next when Team X/Person Y makes a request that is a bad security decision for very little gain. Often, management will ask, “What are the best practices?” Largely because they don’t know the real answer. If we can’t cite a best practice, very often the insecure option is chosen unless someone pinches their eyes shut and stomps their feet enough.

So…which way are we better? The theater of universal checklists that apply to everyone and no one at the same time? (Hello excuse #45: “Well, we’re slightly different so that doesn’t apply to us in the way it is written…”

by LonerVamp on February 28, 2011 at 7:02 pm. Reply #

Leave your comment

Not published.

If you have one.