As many would have rightly guessed, Target has been sued due to the significant data breach affecting its customers in 2013. According to this Reuters article, “Trustmark National Bank and Green Bank NA accused the defendants [,Target Corp and Trustwave Holdings Inc, which provides credit card security services,] of failing to properly secure customer data, enabling the theft of about 40 million payment card records plus 70 million other records.”
This reminds me of the prominent TJX (operator of TJ Maxx stores) data breach eight years ago that affected ~94M records, making it the largest single data breach to date. You can learn more about it on the Hacks of Ages timeline that Erin O’Malley so eloquently described recently. Juniper will add the Target breach to it.
According to the Ponemon Institute 2013 Cost of Data Breach Study: Global Analysis report, German and U.S. companies had the most costly data breaches ($199 and $188 per record, respectively). For U.S. retailer TJX, the financial losses were significant. The company agreed to pay $9.75 million to 41 states. Of this, per the settlement, $5.5 million was to be dedicated to data protection and consumer protection efforts by the states, and $1.75 million was to aid in reimbursement of the costs and fees of the investigation. Further, $2.5 million of the settlement was to be used to fund a Data Security Trust Fund to be used by State Attorneys General to advance enforcement efforts and policy development in the field of data security and protecting consumers’ personal information.
Let’s see how Target financially fares with regards to the settlement. In the meanwhile, I hope that both these and other enterprises will take effective, preventative measures to detect and stop such attacks early. If they don’t protect their customers’ data, certainly, sooner or later, they will have to pay the price. And, as my esteemed colleague, John Pennington, warned loudly and clearly in his blog, which summarizes the findings of a compelling study of the cybercriminal world, “Take action or be hacked!”Read more...
As a regular shopper at Target, I’ve been closely following the data breach ordeal. This week, I learned that the company did, in fact, have security intelligence in place, but the company’s Security Operations Center (SOC) didn’t react in time to prevent the damage. Astonishing!
It’s my hope that the following questions will eventually be answered, too . . .
If you’re an IT professional like me who likes to stay in touch with and expand your network, you’re probably familiar with LinkedIn (LNKD), operator of the world’s largest Internet-based professional network with 161 million members spanning over 200 countries and territories. In early June, the company learned that the encrypted passwords of over 6.4 million subscribers had been compromised and posted online.
In response to this incident, LinkedIn Director, Vicente Silveira, in a blog, said, “To the best of our knowledge, no email logins associated with the passwords have been published, nor have we received any verified reports of unauthorized access to any member’s account as a result of this event.” The company disabled passwords of those members believed to be at risk and sent them a message explaining how to reset their passwords. LinkedIn also stated that since the incident, it had enhanced its security measures (beyond SHA-1) by applying an additional layer of data protection know as “salting” to better secure members’ information.
Here’s how salting works. Before generating the hash (note: hash function is the transformation of a string of characters into a usually shorter fixed-length value or key that represents the original string) for each user password, you would create a random string of characters of a predetermined length and prepend this string to each plain text password. As long as the string (aka. a "salt") is of sufficient length and sufficiently random, the resulting hash will almost certainly be different each time the hash function is executed. By randomizing the hashes, lookup tables, reverse lookup tables, and rainbow tables become ineffective. Because an attacker won't know in advance what the salt will be, he or she can’t pre-compute a lookup table or rainbow table to crack passwords. If each user's password is hashed with a different salt, the reverse lookup table attack won't work either. Furthermore, in case an attacker tries to use brute force cracking in order to obtain passwords, Mykonos Web Security may be used to help prevent that.
On the other hand, if a legitimate user is logging into the Web site, because the user’s password associated salt is stored in the user database along with the hashed password, the authentication server will take the user supplied password and apply the user’s salt to obtain the hashed password. If there is a match, the user will successfully be authenticated.
Discussing a wide range of topics impacting enterprises and
data center security.