Again: Identity Data Theft

Yesterday, news spread about the theft of millions of credit card dates at the US company Heartland Payment Systems, based in Princeton, New Jersey. Even while that might be one of the largest cases of data theft in the credit card industry, it wouldn’t be that interesting that I’d blog about. The – from my perspective – really interesting point is, from what I’ve read in the news, the way the attack has been performed.

The information sent is encrypted but has to be decrypted to work with it. The attackers grabbed the then unencrypted information. Surprise? Not really. The problem with security is that virtually any approach is incomplete – and thus inherently insecure. Examples?

• Passwords are frequently encrypted via SSL when sent to a eCommerce website but then decrypted and compared – and often they are even stored unencrypted and sent back in case of a lost password. I’ve just seen this again recently, when I received my password in cleartext via eMail.
• Data is encrypted on a specific type of device using some DLP (Data Loss Prevention) technology. Once delivered, it is decrypted – and might be mailed as an attachment.
• Access Control Lists are enforced to provide security for data at file servers – but they are sent to the client unencrypted and the user might store an unshielded copy (or mail it or do something else).

These are just three examples – of hundreds or thousands. Another was discussed in a Kuppinger Cole Webinar yesterday, where we talked about “service oriented security”, e.g. application security infrastructures, SOA security, and so on. The question was about the security between the applications and the security systems (and eventually the security systems themselves). That is a good question. Often there are security holes somewhere at the center of the security system. SSL itself isn’t the answer. In that case it is about a consistent security approach. Unfortunately, even many IAM and GRC applications don’t provide a really sophisticated security model.

Another interesting point is that there are always other potential security holes. Trojans which grab keystrokes are one example, the man behind you reading the information at your screen is another one. Some of these problems can be adressed, for example with external keyboards for entering sensitive information in eBanking. Others will be always there.

There is no easy solution to these issues. Information Rights Management will help to address many of these problems – I’ve blogged about the need for IRM some time ago. But IRM won’t solve everything. Information has to be processed, thus the systems which process data are extremly sensitive (like in the case I’ve started with). And a business document in an ERP system is, finally, stored in fragments within a database.

From my perspective, the most important point is to work on an authorization strategy (or access strategy) which covers all aspects. Any investment in DLP is at risk as long as it isn’t part of the bigger picture. Point solutions are perfect for masquerading the real security problems, but they don’t really solve them. An overall strategy which identifies the security holes and which tries to use a limited number of well linked technologies is mandatory to minimize security risks. That strategy has to include everything, from the firewall and SSL-secured connections to IRM and the security of backend systems. That is no easy task, especially because there are frequently many different parties involved which all claim that they have found the holy grail for enforcing security. But it can be done – and it will save you a lot of money by avoiding investments in security technology which don’t really solve your problems.

For the ones of you capable of reading German: Please participate in this survey. That fits well to the topic of this blog post.