Showing all posts tagged security:

Password to the Ivory Tower

My big focus at work lately is the SecOps gap, the breakdown in communications between IT Security and Operations groups. The problem here is that the infosec group comes up with some policy that is great in theory, but runs into issues when the poor sysadmins try to apply it. Either the policy is too vague, or it is contradictory, or it would break some application that the line of business depends on, or it is simply too cumbersome and time-consuming to implement properly.


At work I talk about this in the context of enterprise IT, but the exact same thing applies in consumer IT. Case in point: there was recently a breach of Starwood's SPG loyalty programme - see Brian Kreb's report. Sure enough, I got an email from SPG entitled "Protect Your Information by Updating Your SPG Password".


SPG should be applauded for being so proactive, and the breach does not seem to be due to any gross negligence on their part. The only thing they might have done differently would be to have more aggressive back-off policies for repeated authentication attempts, but let's not forget that this is a generalist site, and one that is probably not used that frequently by most people. Users may legitimately forget their credentials between one login and the next. No, my problem is with Brian Krebs' advice:

far too many people re-use the same passwords at multiple sites that hold either their credit card information or points that can easily be redeemed for cash.

Well yes, this is true, and I'm as guilty as anyone - but on the other hand, there are simply far too many passwords out there! When every website I visit wants me to create a profile and secure that with a password, of course I'm going to reuse those credentials!

The trick is not to reuse credentials on anything valuable. Don't reuse the credentials for your online banking, for instance - those have to be unique. But for every Tom, Dick and Harry who wants a password? They can all get the same one, and that's if I don't simply introduce myself as Ann Onymous, with this handy email account at

This is why using central login services via Facebook, Twitter or Google is so popular. The problem there is that I don't necessarily want any of that unholy trio tracking my every move, nor do I entirely trust random sites with my Oauth creds, so there's a problem there too. I did like OpenID as a concept, but it's pretty much dead now in practice.

Bottom line

Berating people for poor password security practices won't cut it. We as an industry have to make it easy for people to do the Right Thing, not set up obstacle courses and then point and laugh when people trip over them.

Image by Keith Misner via Unsplash

Security Theatre

There are many things in IT that are received knowledge, things that everyone knows.

One thing that everyone knows is that you have to manage employee's mobile devices to prevent unauthorised access to enterprise systems. My employer's choice of MDM agent is a bit intrusive for my personal tastes, so I opted not to install it on my personal iPad. The iPhone is the company's device, so it's their own choice what they want me to run on it.

Among other things, this agent is required to connect to the company Exchange server from mobile devices. You can't just add an Exchange account and log in with your AD credentials, you need this agent to be in place.


But why the focus on mobile devices?

When I upgraded my work and home Macs to Yosemite, I finally turned on the iCloud Keychain. I hadn't checked exactly what was syncing, and was surprised to see work calendar alerts turning up on my home Mac. My personal Mac had just grabbed my AD credentials out of iCloud and logged in to Exchange, without any challenge from the corporate side.

So how is that different from my iPad? Why is a Mac exempt from the roadblock? A Mac is arguably less secure than an iPad if it gets forgotten in a coffee shop or whatever - never mind a Windows machine. Why is "mobile" different? Just because?

Many enterprise IT people seem to lose their minds when it comes to mobile device management. I'm not necessarily arguing for just dropping the requirement, just for a sane evaluation of the risks and the responses that are required.

Dark Security

Brian Krebs reports a spike in payment card fraud following the now-confirmed Home Depot security breach.

This is actually good news.

Wait, what?

Bear with me. There has always been a concern that many security breaches in the cloud are not being reported or disclosed. The fact that there are no other unexplained spikes in card fraud would tend to indicate that there are no huge breaches that have not been reported, frantic stories about billions of stolen accounts notwithstanding.

The day we should really start to worry is when we see spikes in card fraud that are not related to reported breaches.

I'm published!

A piece I wrote on Heartbleed was published in Cloud Computing Intelligence magazine:
Once you’ve dealt with Heartbleed, how do you prevent it recurring?

Summary and lead-in:

You've got rid of Heartbleed, and you're relaxing with a soothing cup of something strong, but how do you know that it's gone for good? Dominic Wellington looks at creating a containment policy for Heartbleed and for any subsequent nasty bug that will stop them from coming back to plague you again.

Feedback welcome!

Marketing is a four-letter word

To techies, “marketing" has always been a four-letter word. My own first exposure was in the Browser Wars of the Nineties, when Microsoft was widely held to have won by “marketing" (pronounced with extreme scorn). That attitude is alive and well today:

Luckily, this time around there are people calling out that attitude as misguided: What Heartbleed Can Teach The OSS Community About Marketing:

Remember CVE-2013-0156? Man, those were dark days, right?

Of course you don’t remember CVE-2013-0156.


Compare “Heartbleed" to CVE-2014-0160, which is apparently the official classification for the bug. (I say “apparently" because I cannot bring myself to care enough to spend a minute verifying that.) Crikey, what a great name that is.


The open-source community has always had a bit of a hair-shirt attitude to it: if you can’t hand-code your own YAML config files at the command-line and recompile your entire toolchain at least once a month, you are not worthy. That’s all well and good, but at some point you have to be able to talk to other people, especially when what you do has become critical infrastructure. This may - shock, horror - require you to engage with marketing.

Guess what? It’s not that bad. The sort of “marketing" that offends OSS purists is generally bad marketing. It’s mis-targeted, content-free, and exaggerated - and none of those things are goals of good marketing. I can say that, since I have the word “marketing" right there on my business card, and also patched my home Linux server against Heartbleed.

Better marketing, and communications in general, is the only way we are going to solve the problem of poorly-funded and -managed open-source software becoming critical infrastructure. From the WSJ (emphasis mine):

Matthew Green, an encryption expert at Johns Hopkins University, said OpenSSL Project is relatively neglected, given how critical of a role it plays in the Internet. Last year, the foundation took in less than $1 million from donations and consulting contracts.

Donations have picked up since Monday, Mr. Marquess said. This week, it had raised $841.70 as of Wednesday afternoon.

Guess what? Eight hundred bucks doesn’t buy much code review. “I think I’m going to audit some code for buffer overflows this Saturday night", said no-one ever. The way to get more attention to the problem… is marketing.


tl;dr version: CISO pays for pen-test, receives ridiculous report. In addition to involving legal, he shares it with a prominent security blogger. Hilarity (and viral hashtag #ScumbagPenTester) ensue.

My favourite bit of the report is probably this:

MySQL configured to allow connections from Recommend configuration change to not allow remote connections.


used to put stuff like this in pen tests to see if my boss was paying attention.

This sort of thing happens
in every industry, but what shocks me is that someone would try it on in an area like security. If you know you need a pen-test, surely you know enough to recognise