The 'real' story is that HBGary charges that big bucks to tell other companies and/or government agencies about how they aren't following security best practices, yet they themselves weren't doing so. I don't think that anyone would be ragging on HBGary for lax security if Anonymous had pulled out some 0day kernel exploit to break into HBGary's systems.
They failed in:
- Keeping their systems patched and up-to-date.
- Convincing/forcing their users to use strong passwords.
- Convincing/forcing their users to use separate passwords per system.
- Convincing/forcing their power users/admins to use a unique, strong password on key systems (i.e. Google Apps Admin).
- Not-invented-here syndrome (or maybe security through obscurity -- hey! if we use an obscure CMS then it won't be exploitable!) with respect to their CMS. I can be a little lax on them here. Had they chosen 3rd-party software people would doubtless be railing on them for which off-the-shelf 3rd party software they were using (e.g. had they been exploited through a Wordpress vuln, then people would be lambasting them for using Wordpress vs <insert-cms-here>).
The 'real' story is that a motivated attacker will rarely fail.
You can take almost any intrusion and write it up in wildly different ways.
If HBGary had not failed in everything that you listed, odds are you would be listing some other comparable set of failures:
- something somewhere is always unpatched and out of date
- humans always deviate from best practices
- 99.99% of intrusions involve traditional threats, well known vulnerabilities, unpatched systems and human error
I could write up 100 different intrusions done in 100 different ways and almost always make the victim sound incompetent, or like a real life spy novel, or make the defenses sound like fort knox, or make the intruders sound like gods, or make it sound like my product would have prevented them, or draw the conclusion that the security environment is hopeless and out of control.
In the end it doesn't really matter how it happened or what I make it sound like.
Then again, a motivated defender is a very though adversary. Think "web server serves plain files only and is disconnected from the internal network"[1], "secure OSes everywhere"[2], "password quality checker installed"[3], "full-disk encryption for all serious data"[4], "SSH logins only via public key"[5], etc. Yes, this takes (some!) real effort. No, getting 0wned by "please drop the firewall and send me the root password" is not acceptable if you're a security outfit.
Really, you can go years without patching if you choose your software properly. (Except browsers - those just suck.)
As I've mentioned elsewhere, competent security needs to take into account sociological/economic analysis. Only looking at the technical and organizational side is literally just playing with yourself.
For example: if you're a major technology company, taking the step of publishing wildly popular content with DRM means you're going to be taking on a lot of highly motivated opponents. History demonstrates that this isn't a fight that you want to take on. Now consider: if you're a security company, what do you think is going to happen when you take on a subset of /b/?
Here's a hint: before you're in the position where you're risking the ire of a large, technically savvy population that's had demonstrated success taking on other corporations with comparable or greater resources than yourself and a history of flaunting the law, it really behooves you to do some preparation.
If you've been saving some chump change by keeping your mailserver on the same machine as your webserver, and you're about to take on /b/, now's the time to do something about it.
That's like some athlete not checking if his shoes are laced up properly before the event.
Did this security company ever audit its own security? Either they didn't or they did an incompetent job of that. Would you trust a security company that doesn't eat it's own cooking?
Not necessarily. It's easy to forget that attacks typically depend on, admittedly very common, multiple layers of security failures. For example, using the same passwords on many systems, etc. Good security is defense in depth. Keeping every component as secure as possible and keeping any breach of security as restricted as possible. It may not be possible to avoid every conceivable attack, but it's certainly possible to withstand a large number of attempted attacks.
The other side of the coin is that attackers don't publicize their losses. Every attacker has a limit to their skillset. If they can't compromise someone they won't announce to the world their failure, they'll just pretend like nothing happened and move on.
- Convincing/forcing their users to use separate passwords per system.
I have to disagree that this one is really a best practice at all. I have dozens of different accounts on different computer systems, if I didn't do at least some password reuse I would have a hard time writing them all down, and remembering them would be totally impossible.
With that said, I absolutely think passwords on critical systems must be unique and strong. But I have maybe three systems I consider critical and dozens that not. My bank password for instance is unique and long. But I am more worried about being able to remember my passwords than whether or not someone who gets into the account I use to play Go online can also get into the account I use to play chess online.
if I didn't do at least some password reuse I would have a hard time writing them all down, and remembering them would be totally impossible.
There are a variety of good password vault programs out there. I keep my passwords in a KeePass 1 file on Dropbox. I can run Keepass on Windows, Linux, OS X, and my iPhone and iPad. There are a variety of low-cost and free options that are about this good or better.
Sometime, I'll be working on a Keepass compatible iPhone program that can access Dropbox directly.
> I have to disagree that this one is really a best practice at all. I have dozens of different accounts on different computer systems, if I didn't do at least some password reuse I would have a hard time writing them all down, and remembering them would be totally impossible.
Yes, it's a pain in the ass (at present), but yes, you should be using different passwords for everything, and pubkey authentication where possible.
The problem of maintaining an encrypted master password list for many different accounts is just a technical one. It will be solved. Keyring managers already do this. I noticed the latest Chrome linux builds use the desktop keyring manager now for saved passwords, rather than storing them unencrypted in the browser's password store.
Personally, until these keyring managers are mature enough, I use a few simple scripts: one which generates a new semi-pronounceable password with random chars, one that adds a new account to a gpg-encrypted master password file, and one that queries the gpg-encrypted master password file when I've forgotten a password to an account.
You make good points and I think I may have to work more on using more distinct passwords.
Though, as you alude, this will become easier as keyring managers mature. I am also hoping that as security technology matures more places will move to forms for two factor authentication.
"The only way they can have some fun is to elevate privileges through exploiting a privilege escalation vulnerability. These crop up from time to time and generally exploit flaws in the operating system kernel or its system libraries to trick it into giving the user more access to the system than should be allowed. By a stroke of luck, the HBGary system was vulnerable to just such a flaw. The error was published in October last year, conveniently with a full, working exploit. By November, most distributions had patches available, and there was no good reason to be running the exploitable code in February 2011."
There was apparently a privilege escalation from Greg Holund's ssh account on the support machine - leading to the rootkit.com data and further credentials.
They failed in:
- Keeping their systems patched and up-to-date.
- Convincing/forcing their users to use strong passwords.
- Convincing/forcing their users to use separate passwords per system.
- Convincing/forcing their power users/admins to use a unique, strong password on key systems (i.e. Google Apps Admin).
- Not-invented-here syndrome (or maybe security through obscurity -- hey! if we use an obscure CMS then it won't be exploitable!) with respect to their CMS. I can be a little lax on them here. Had they chosen 3rd-party software people would doubtless be railing on them for which off-the-shelf 3rd party software they were using (e.g. had they been exploited through a Wordpress vuln, then people would be lambasting them for using Wordpress vs <insert-cms-here>).