By now you should all be familiar with the “hack-in” on June 6 which led to the taking of over 6.5 million hashed user passwords. My colleague, Craig Burton, has addressed what should happen next, but I’d like to examine some issues which might appear tangential to the leak but should still be of concern.

First, according to LinkedIn Product Director Vicente Silveira: “Based on our investigation, all member passwords that we believe to be at risk have been disabled.” How does LinkedIn know what my password is? Sure, they could search through all accounts, comparing the hashed value stolen with the hashed value stored – but why can they do that? If it’s possible for someone at the company to see my password (hashed or not) then my account is still at risk to a criminal insider or to a duped insider.

Second, why such a fuss? As far as we know, it’s only passwords that were stolen – no other user information went along with it. As such, the data is only useful to construct a dictionary of possible LinkedIn passwords – or, maybe, passwords used by business users (the great majority of LinkedIn members). While it’s still wise to change your password, there’s no guarantee that you won’t choose another one that’s in the list of stolen ones! Would that make you better off, or not?

Third, we’ve discovered a new phishing attack. Hundreds of tweets, Facebook statuses and even LinkedIn statuses urged you to go to sites like this to check to see if your password was one that was compromised. Unbelievable! To feel better about your possibly stolen password (which really put you in little danger, see previous paragraph) you’re urged to give your password to some site you’ve probably never seen before! A site which can easily identify you through your browser, I might add. Hope the people who fell for this feel safer.

Besides these issues that mostly affect users of LinkedIn, other issues were raised about LinkedIn as a company, and its corporate culture.

My colleague Martin Kuppinger (“LinkedIn Password Disaster”) talks about the difference between teaching security skills to apps designers versus teaching app design to security experts. [spoiler alert] He thinks LinkedIn got it wrong. I agree.

Others have pointed to the company’s org chart, and faulted them for not having a Chief Information Security Officer (CISO) or even a Chief Information Officer (CIO) – do they not take these things seriously? As reported by Information Week, LinkedIn had a ready answer:

“LinkedIn said that the absence of a CSO or CISO label on the org chart reflects only the company's job-naming conventions, rather than its security posture. ‘LinkedIn historically has limited C-level titles only to its chief executive officer and chief financial officer, so while [security ‘czar’ Ganesh] Krishnan does not formally have the title of chief information security officer, that is the role he has played at the company since his hiring in 2010,’ according to the LinkedIn statement.”

Still others made snide remarks that Krishnan didn’t report to a “high enough” manager. Yet it’s quite evident that he does report to LinkedIn’s senior vice president of operations, David Henke, who reports to the CEO. That’s definitely nitpicking.

I’m reminded of an exercise that my old boss, Walt Thirion (then the CEO of Thomas-Conrad Corp., manufacturers of networking gear) would put his department heads through each year. At the time, we were a company of approximately 350 people, my IT department totaled eight (including me as Manager of Information Technology). Walt told us to imagine our departments should the company grow ten- to twenty-fold: How many people would report to me; What would their titles be; What would their duties include.

Now 20 years ago, when we did this, the title of CISO didn’t exist – we’d only just started using any CxO titles (CEO, CFO) but I did include a spot on my projected org chart for someone who would be in charge of information security and who would report to me in my guise of Senior VP of Corporate Information and Technology (which, of course, we’d now call the “CIO”).

The second part of the exercise was to devolve all of these positions onto the people in the department at the time the exercise was done. The information security post devolved to me. So I have no problem accepting LinkedIn’s explanation that “David Henke, the company's senior VP of operations, is solely in charge of security. Henke's LinkedIn profile lists his responsibilities as being the company's "production operations, IT, data systems, security." Since LinkedIn could still be considered in the SMB (Small to mid-sized business) class with a headcount between 500 and 900, it’s no problem accepting that a number of different jobs would devolve to a senior VP. I’m not going to fault the company for not having an officer designated as CISO.

On the other hand, I will certainly fault them for not having adequate security policies in place. To hash passwords without salting them is bad practice – and has been for many years – for anybody. The company claims they’ve been working on a plan to introduce salting to the process, and will now push it forward. But it doesn’t take a rocket scientist or more than a few days of coding and testing to do that. So I find the explanation lacking. More likely they pushed this forward when it was pointed out that they weren’t salting.

I’ll also fault the company for a poor response to the breach. Here they aren’t alone. Too often a company whose security has been breached appears like a deer caught in the headlights with no idea how to respond. Only after the breach do they sit down to discuss a response.

Mitigating a breach should be a part of everyone’s disaster recovery planning. Most companies have plans to deal with data loss through fire, flood, natural and man-made disasters. They also need a plan to deal with information leaks through hacking, insider theft, inadvertent exposure and the like.

One of the more painless ways of learning is through others’ mistakes (rather than our own), so take heed and learn from LinkedIn – as they evidently did not learn from others’ previous breaches.