Find the thread

Sure, blame the user

Because there isn’t enough recent security news, everyone is all worked up about the 2012 LinkedIn breach. Okay, it’s somewhat newsworthy because some lowlife is now trying to sell the data. All the security vendors have jumped on the bandwagon¹, but in particular lots of people are mocking the fact that people are using common or easily-guessed passwords:

• 123456

• linkedin

• password

• 123456789

• 12345678

Now a bot has emerged which attempts to reuse known leaked passwords to log in to sensitive sites such as online banking systems. Predictably, the main response has been mockery, with El Reg opining that If your Netflix password is your banking password, you'll get what you deserve.

This sort of victim-blaming has got to stop. It may be fun in an elitist, look-at-the-lusers sort of way, but it’s not actually advancing the cause of better security.

Obviously the real villains of the piece are the people exploiting those credentials, but those sorts of people are probably going to be with us until the ultimate heat death of the Universe, so blaming them is not a particularly productive exercise. Law enforcement could and should do more to bring the perps to justice, but that can only ever happen after the fact, when it’s too late for the victims.

Among people we can actually expect to influence, I would start with the banks. Given that people are out there trying to break into banking systems, because that's where the money is, and given the potential consequences of a breach, the design of those systems must include more advanced security than a simple username and password pair.

For reasons too complicated and boring to relate, I actually have two bank accounts with different institutions in different countries. Both, however, implement two-factor authentication. One has a challenge-response device that works with my ATM card, while the other requires me to make a call from my registered phone number and enter a one-time code. Any bank not implementing something along those lines in 2016 is negligent with their customers’ security. If your bank does not offer two-factor authentication, you should run, not walk, to the exits.

But what about the (l)users?

Users certainly bear some responsibility for not sharing passwords - but in the real world, there are already far too many services that require me to create an account with a username and a password for no good reason. Log in to comment, log in to review, log in to purchase, log in to make a reservation… No wonder people share passwords between services!

It’s fine to sit in the ivory tower of security policy and blame people for doing this sort of thing, but it’s the reality. At least nowadays most places accept an email address as the user account, so that’s one thing less to remember - without worrying about whether this particular site right here wanted a username of less than eight characters, exactly eight characters, or more than eight characters, or whether somebody had already picked my chosen user name so I made a variant, or whatever.

Passwords themselves are still a problem, though. Logging in via Google, Facebook or Twitter is becoming more common, but there the issue is that I don’t necessarily want to share my social ID with every random website that I need to have a one-time interaction with.

The result is that I reuse passwords for unimportant services all the time. However, all the important ones are unique - including my LinkedIn password, since my old one was caught up in that 2012 breach. Security needs to be done in layers. If someone gets my Random Website password, that won’t get them into my LinkedIn - and if they get my (new) LinkedIn creds, that still won’t get them anywhere with my online banking.

And here’s a pro tip - for all those one-time, "log in to use our wifi"-type deals, just do like my good friend Annie Onymous, who is always happy to share her email address: ann.onymous@myo.biz.

Stay safe out there.

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 mailinator.com.

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

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.

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.

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!

Get ready for the next time you have to change your domain password at work.

For a more serious take, check out XKPasswd. It’s inspired by this XKCD strip.

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:

☑ register http://t.co/ZGfyHkwhcr domain
☑ get custom graphic designed
☐ disclose to distros in advance
☑ disclose to public
Priorities

— keyist (@keyist) April 8, 2014

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.

Rant Blog: World's Worst Penetration Test Report by #ScumbagPenTester http://t.co/yT86WCJkm4

— Security Monkey (@chiefmonkey) January 29, 2014

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 127.0.0.1. Recommend configuration change to not allow remote connections.

I

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 127.0.0.1?