The Gross Example of STRATFOR

Unless you've been living under a rock for the past month, you've undoubtedly heard about the STRATFOR hack by some anonymous or another. Who did it really isn't all that important to me, nor do I even care all that much about the purported, assumed, inferred, or otherwise construed ideology behind it. The important thing is to hold this up as a squalid, revolting example of IT mismanagement and outright legally indefensible negligence.

Let me state up front what's probably obvious from my open disdain and disgust: I was negatively impacted, having my mailing address, credit card, and email information exposed. Of these, I'm most upset about the credit card information, which included the CVV value. Talk about not even bothering to "mail it in" on some basic security. It begs the question "Why even bother storing the data yourselves if you aren't going to even make a weak attempt at protecting it?"

5 Putridly Egregious Failures

In my opinion, there are 5 major failures in this case that proves STRATFOR to be negligent (possibly criminally). I'm very much hoping some lawyer will step up and file a class action lawsuit against them. Money isn't my interest, but rather making sure that this company and these business "leaders" are severely hindered from being able to ever be in a position again to do this to people. In my mind, this provides a textbook example of where the legal code needs to be updated to outright ban these "executives" from owning, operating, or leading a business for a few years because they've shown themselves to be completely incompetent and dangerous to people and the market.

Sorry, enough venting... let's look at what I see as the 5 main failures:

1) No data encryption

STRATFOR maintained a database (or a few?) containing personal data, including credit card information (undoubtedly fore recurring subscriptions). Under PCI DSS, they are required to encrypt that full credit card number. It's now clear that they did not do so. It's hard to even begin to describe how completely ignorant and irresponsible this is. More importantly, why maintain the data yourself when there are so many 3rd party services out there that can tokenize the value and reduce your risk profile? This is cardholder data management 101, and they failed, big-time.

2) Storing CVV

As if the lack of encryption isn't bad enough, it also turns out that they stored the CVV value from the cards (the number on the back of your card on the signature strip). This is strictly forbidden in Requirement 3.2 of PCI DSS 2.0 ("Do not store sensitive authentication data after authorization (even if encrypted)."). While the lack of encryption is egregious, the storage of sensitive authentication data is simply unforgivable and reflects a wanton disregard for regulations and protection of customer data.

3) Blank or default passwords

As if the cardholder data handling wasn't bad enough, it also seems that STRATFOR's systems weren't even using basic security measures. Specifically, it's been reported that they had no password for their SQL Server access, and likely had default passwords in other cases. Seriously?!? How is it even remotely possible in 2011 (time of incident) that a company can be so ignorant and incompetent that they didn't even bother to set a basic database password? Of course, the answer is...

4) Failure to hire competent staff

STRATFOR did not hire good people. In fact, it's unclear if they had *any* security people onboard at any point in time. I'm guessing they never had an external pentest of their systems (if they did, and didn't act, then that would be another point toward negligence). According to one report, they were notorious for hiring people straight out of school with no real experience, and almost certainly with no security background. Their IT "lead" left the company in Sept. 2011 and was not replaced. Moreover, they'd been trying (without success) to hire an alternative resource for almost a year. Moreover, the idea has also been floated that this breach may have received insider help, which may never be known for sure, but certainly wouldn't help much. But wait, it gets better...

5) Failure to learn from previous incident

I've thus far been unable to find any citations to corroborate this assertion, but it was heard in passing last week that STRATFOR may have had a breach in 2010 as well. This would not surprise me in the least. This has to be about the softest target ever, and one with lots of juicy appeal (splashy in the news, lots of credit card numbers complete w/ CVVs, etc.). I mean, who wouldn't want to pop these guys just for the Lulz? *sigh* Suffice to say, if true, then this is, imo, the fifth and final nail in the negligence coffin. I'll post an update here if/when I get corroboration.


Left off this list are 2 additional points that people have raised:
* Their communication on the incident has been weak. While I'm not as upset about this as, say, subscribers to the free service, I can see the point. What I did find interesting is that they've relied more on posting updates to their Facebook group than they have in emailing customers. This is particularly interesting as some have asserted that the hackers stole all their data and then recursively deleted all the data on the servers (if true, how did they still have my email address? maybe through a 3rd party mailing service?).
* Inadequate enforcement of decent user passwords. I. Don't. Care. This will be in a separate blog post soon, but the user password question is grossly overblown. It didn't lead to this compromise, nor can it generally be attributed to major compromises anywhere. Yet, people in the industry loooooove to obsessively deride users for picking poor passwords. Whatever. Look for my post later this week, or check out my 2010 post "Password Complexity Is Lame."

In Closing...

I hope that STRATFOR is done for good. I hope the execs there find themselves banished from corporate America and, more importantly, the intel and military communities. Their sheer incompetence rises to a definitive level of negligence and incompetence that should not be seen in this day and age. There is no excuse for their failings, and they should be punished accordingly.

cryptome has been maintaining a running list of the data disclosures, available here:

Nick Selby (@nselby) provides an interesting overview of STRATFOR's initial response and communication, which seems fair:

ps: I intentionally waited a while on writing this piece to allow my anger to subside a bit. No, seriously! :)

About this Entry

This page contains a single entry by Ben Tomhave published on January 10, 2012 11:35 AM.

It's (nearly) 2012 - So What? ;) was the previous entry in this blog.

PCI, QSAs, and the Audit-Industrial Complex is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives


  • about
Powered by Movable Type 6.3.7