The Sony case – or how to best ignore security best practices

04.05.2011 by Martin Kuppinger

The data theft at Sony has been in the headlines for some days now. What makes me most wonder is that – from what I’ve read and heard first – even the passwords were stored unencrypted. However, Sony claims to have used a hash to protect these passwords. It looks like Sony also has stored the credit card numbers plus the associated security codes (which are, by the way, one of the most ridiculous approaches to enhance security) together and, no surprise, unencrypted. But if Sony has used hash values: Why did everyone assume that these passwords become common knowledge (at least for the hackers and their “customers”)?

But let’s start with passwords: Even while it is still done frequently, it is anything but good practice to store passwords unencrypted. You not even need to store them encrypted. Just store a hash, apply the same mathematical algorithm to passwords entered and compare the hashes. Even while some of the algorithms in that area aren’t “bullet-proof” that is far better than storing millions of passwords unencrypted. Storing passwords unencrypted is such a fundamental error that you just can call that grossly negligent. That is not a simple fault but ignorance against fundamental security requirements – even more, when that information is associated with credit card information and other types of highly sensitive data like bank accounts. If Sony has stored hash values that would be good practice, depending a little on the algorithm used. That reduces the risk for the Sony customers even while there is still some risk of having the hash values being stolen. Passwords might be derived from these for example based on brute-force attacks.

Let’s look at the next point. Sony has become, from what we know, a victim of an external attack. Accessing large numbers of data most likely involves a SQL injection attack. Interestingly, the Sony Playstation website has been hit by such an attack before, some three years ago. Given that something happened before raises the question why Sony didn’t protect information better. Haven’t they heard about database security tools and especially database firewalls? That’s exactly the type of technology which helps you protecting data like (if you have them) hashed or unprotected passwords or credit card data. We recently had several webinars on database security and database governance, the last one yesterday about database firewalls specifically. All the recordings are available.

Overall it looks like this hasn’t been the most sophisticated hack ever. It looks like no internals were involved (which would lead to the topic of PxM, e.g. protection against privileged access/users). It looks like Sony just has ignored not even best or good practices, but in many areas even average practices in security.

The bad thing about this is, that Sony isn’t alone out there when it comes to ignoring good/best practices in security. The most common reason is that they just don’t think about security – either because it is too complex or because of the price to pay for security. Hopefully, the Sony case alerts some of the others to review their security and to improve it. However, there is a saying in German that hope dies at last. And I feel that this is more about hoping than about really expecting web sites to become more secure by design.

By the way: European Identity Conference, to be held next week in Munich, is about information security, IAM, GRC, and database security. A good place to learn more and to meet the analysts of KuppingerCole to discuss Information Security issues in person.


Should you learn about fraud from your customers?

06.04.2011 by Martin Kuppinger

Today I stumbled about an interesting survey. The core result: More than three-quarters of financial institutions learn of fraud incidents when notified by their own customers. The quote I like most is: “In other words, despite the availability today of world-class fraud detection technology, despite broad awareness of the current fraud threats and incidents – nothing spreads faster than word of a breach”. Fascinating, isn’t it!? However, it is really somewhat irritating.

There is some reason for financial institutions not to invest as much as they could and should in security. Security comes at a cost and financial institutions still balance these costs against the fraud-related losses. I doubt that this equation really works out as expected, but I had this discussion more than once – frequently with CIOs and CISOs which don’t have the budgets they’d like to have around security.

However, taking some risk is a valid approach. Given that there never ever will be the perfect security, a 100% security, everyone has to balance the cost of security and the (potential) cost of incidents happening. That’s the same approach everyone uses in daily life when deciding about insurances. The fundamental problem in that area is that risks tend to be rated too low whilst costs are seen much more realistic. That’s especially true when it comes to severe issues which might affect the net cash inflow, because that heavily affects the business. However, such risks are frequently ignored or missed when looking at IT security in financial institutions, leading to an underestimated risk and thus a lack of willingness to invest in security.

Another problem is the frequent lack of a holistic security strategy. Attacks at the operating system layer are still possible even when security at the application layer is good – and so on… Investing in point solutions might give the feeling of security, but it seldomly leads to real security.

However, all this doesn’t explain why financial institutions not even are aware of incidents in some many situations. Even when someone takes a risk, he should have controls in place which provide the fraud information. Not doing this is just inacceptable because it moves the things from risk to uncertainty – and thus is against the governance requirements the management has to fulfill. Not knowing about fraud is a clear indicator for an insufficient risk management, because risks are just ignored.

From my perspective, financial institutions have to act in that area by looking at all risks and by acting appropriate – by at least knowing, but better mitigating these risks.

EIC 2011 will have several sessions around security for financial institutions and there will be a lot of experts from the finance industry attending – thus it’s a perfect place to meet with peers and to discuss.


RSA SecurID again

23.03.2011 by Martin Kuppinger

I’ve blogged last week about the RSA SecurID case. In the meantime there were several other posts and advices on that and I’d like to put together some thoughts from my side about that, looking at what customers should do now.

What should existing customers do short-term?

In most cases, RSA SecurID will be a standard mechanism for strong authentication which can’t be replaced immediately. If customers don’t use a solution for versatile authentication they usually aren’t able to opt for another (stronger) authentication mechanisms on the fly. Not using RSA SecurID however will make things even worse, because that would mean to step back to one factor with one or two means for authentication. Thus it is about staying with RSA SecurID and deciding about which additional actions to take – “compensatory controls”, e.g. increased auditing, additional fraud detection technologies, and so on.

Customers who have a versatile authentication approach in place might evaluate whether they can replace RSA SecurID with another factor – which then would be, for time and logistics reasons, an approach not depending on hardware. However doing that will be somewhat complex (helpdesk calls, technical aspects,…). Thus customers should first check whether the increased risk of using RSA SecurID is acceptable or not. Instead of replacing the option of adding another factor/means for interactions and transactions with high risk appears to be most appropriate. Besides this, the actions mentioned abovr in auditing have to be implemented.

What should existing customers do mid-term?

Replacing a technology like RSA SecurID is quite expensive. Given that RSA will harden its own systems and seeds can be changed over time, the threat will decrease. However, as mentioned in my last post, RSA SecurID never will be the same again. The mid-term answer, from my perspective, is versatility. Having more options for quickly changing to other and additional factors and means for authentication is the most promising approach. Thus, RSA SecurID is just one of multiple approaches.

For high risk environments, biometrics might come into play again (if not used yet). In addition there are some approaches of two-factor authentication which don’t rely on seeds and secrete algorithms. However they aren’t necessarily absolutely secure (if anything could be absolutely secure), thus customers should carefully evaluate whether other approaches provide real advantages above the established RSA SecurID approach. The same level of mistrust should be used for all types of authentication.

What should potential buyers do?

It is about re-evaluating the strategy for authentication. Versatility is key – and the strategies need to be re-thought if they are not focused on a versatile approach allowing different types of authentication mechanisms to be used and exchanged flexibly. Regarding RSA SecurID, the risk has to be rated again and decisions about whether the approach is sufficient for the interactions and transactions which have to protected have to be reviewed. From my perspective it is not that much about not using RSA SecurID (depending on what RSA does to increase security again, for sure – but I assume they will do a lot) but to carefully analyze the level of protection provided and weigh this against the risks of authentication fraud for what has to be protected. When deciding to use RSA SecurID appropriate controls have to be implemented – but that is true for any other authentication mechanism as well.

By the way: Regardless of the RSA SecurID approach, any authentication strategy which doesn’t focus on versatility, risk-based authentication/authorization and context-based authentícation/authorization should be re-thought.

Some general thoughts:

RSA has had a very strong image for their RSA SecurID approach – and it worked for many years. However there are two fundamental issues:

  • Centralized seeds
  • Confidential algorithm

Both are risks of that mechanism. Thus security is obviously limited. Regardless of which approach you use, thinking about the potential weaknesses (social phishing; central stores which might become target of attackers;…) is important. Unfortunately, security comes at a price, because there aren’t simple, cheap, easy-to-use approaches without logistics cost and other shortcomings which provide perfect security.

Again, like mentioned in my last post, we will discuss things like versatile authentication and the RSA SecurID incident at the EIC 2011. You shouldn’t miss that event.


VeriSign Identity Protection – an interesting approach

25.10.2007 by Martin Kuppinger

I still remember some tough discussions I had with eBay in 2004 when we had just started KCP around there missing investments in secure, strong authentication. Interestingly eBay and PayPal are amongst the first now to use VeriSign Identity Protection, abbreviated as VIP. And they start in the German market to roll out this technology.

Basically VIP is sort of a combination of strong authentication with a user-centric identity which can be used with different vendors and other companies in the market. The user requires a token which provides an OTP (one time password) which is used for authentication. Nothing new, so far. But: The VIP network is designed to support multiple partners and it uses only one token. Thus it addresses two of the biggest obstacles of OTPs as a means for strong authentication:

  1. The cost of deploying tokens is shared and thus lower.
  2. The user has one token instead of a collection of tokens from different providers.

I really like this approach because it’s a pragmatic one. And I will, for sure, test my VIP card today with my eBay account. Best of all, the token is in credit card form factor and thus very comfortable to take with me, in contrast to some other token I own.

Combine this approach with OpenID and CardSpace and you end up with a solution which isn’t perfect but far more secure and usable than most of the other approaches in the market. Interestingly I had discussing about that approach with VeriSign some 18 months ago the first time. Seems, that today the market is ripe for it.


Services
© 2014 Martin Kuppinger, KuppingerCole