http://www.netpublishing.com/2012/01/03/stratfor_lessons_learned.html By Gregory W. MacPherson Computer Security Expert, CISSP, etc. January 3, 2012 The stratfor.com hack is old news by now, so what lessons, if any, are there to be learned from this high profile data spill? To review, stratfor.com private data including credit cards, user accounts, and passwords was dumped on pastebin.com on Christmas Day, 2011. The data spill exposed not only tens of thousands of users to potential identity theft but more importantly exposed the security practices of those users, as well as the security practices of stratfor.com. A review of the data and of the incident suggests several points worthy of consideration. The data was compromised using either a cross site scripting or SQL injection attack. From this fact one might conclude that application security trumps data security, and in this case one would be correct. Of course if the administrators of stratfor had practiced basic data security techniques such as encrypting data at rest, then the sensitive PII of tens of thousands of users might not be on display for the world today. While the Web site did incorporate SSL for user transactions, the account and credit card information existed in a data store in clear text rather than as encrypted hash values. Once the exterior security of the site was breached, regardless of the method, the entire site was compromised. This is referred to in the vernacular as "hard exterior, soft chewy inside" and is an unfortunate and prevalant security strategy. Numerous discussions of layered security have addressed the point, therefore I will not belabor it here. Suffice to say that the administrators of stratfor.com now may be viewed as idiots for not following well documented and oft published best practices for computer security. A heuristic study of the user account credentials reveals another salient fact: stratfor users are idiots as well when it comes to security. The password distribution curve for stratfor includes multiple uses of passwords of one character, two characters, three characters, ad nauseum. Additionally dozens of "joe" accounts - accounts where the password echoed the username - are in evidence. Stratfor.com made no effort to enforce a strong password policy - a few lines of JavaScript would have sufficed - and as a consequence we find embarrassing examples such as username stratfor, password stratfor. One real benefit of this data breach is that it illustrates a real world example of the poor choices that users make when it comes to computer security. Strong security must be enforced, not optional, and allowing users to decide whether the security measures inconvenience them leads to situations such as the current topic of discussion. A third point for consideration is the situation where multiple users with credentials ending in TLDs such as dot-edu, dot-gov, and dot-mil utilized passwords on stratfor.com that echo their credentials on their more sensitive home sites. One would like to think that people who boast of academic, government, or military credentials would be more cognizant of their responsibility to protect the privileged information entrusted to them, but apparently they too, despite their august credentials, are idiots when it comes to authentication credentials and the management thereof. Suffice to say that dot-mil sites routinely employ two-factor authentication to prevent compromises of this exact sort. Some government sites also employ two-factor authentication methods, and possibly a few academic sites do as well. For those sites which rely solely on the arcane userid and password combination, I suspect that this holiday season was less than merry as their security staff worked late to try and head off the inevitable compromises that would result after dozens of credentials were published. [...] _____________________________________________________ Did a friend send you this article? Make it your New Year's Resolution to subscribe to InfoSec News! http://www.infosecnews.org/mailman/listinfo/isnReceived on Wed Jan 04 2012 - 00:31:19 PST
This archive was generated by hypermail 2.2.0 : Wed Jan 04 2012 - 00:28:14 PST