RSA Breach Long Term Impact for Security Professionals

Wednesday, March 30, 2011

Nick Owen


Full-disclosure: I am the co-founder of a company that competes with RSA. Consider the source, but don't toss this post as FUD without reading. I have tried to be as fact-driven and as clear in my recommendations as I can.

The Longer Term Impact of the RSA Breach for Security Professionals

The past few weeks have seen successful attacks against providers of key elements of Internet security for many companies. Most people seemed unsurprised about the lax security around a certificate authority while most were surprised by a breach at RSA.

Both of these attacks demonstrate how organizations rely on the security of their vendors. In general, this is a bad idea because a vendor's idea of security might not be the same as yours - and even if it is, they may be more of a target than you.

More than that, with the explosion of cloud-based services, organizations are relying on the security of their vendor's vendors. What lessons can we learn from these episodes and how should it impact decision making? Here are some longer-term items to think about:

Analyze your purchasing heuristics. Do you not purchase from open-source companies because you think closed source is more secure? Perhaps it is time think again. Do you prefer large public companies to smaller vendors? Smaller vendors can notify before the stock market closes. Do you prefer the market leader? That leader is a bigger target these days.

Heterogeneous vs Homogeneous. Is a single vendor is responsible for a large portion of your defenses? This attack puts a bigger question mark on single-sourcing. However, strong interoperability is required for a heterogeneous environment. Do your products support standards?

Use asymmetric encryption and "Best practices" for encryption, especially when performing key generation. Key generation should be performed on the device. The concern with the RSA SecurID tokens is that the keys/shared secrets were generated by RSA and presumably a copy was kept for licensing purposes.

Switching costs. How long would it take to swap out a vendor's product and at what cost? If you are using RADIUS for all your authentication, then switching two-factor authentication servers is quite simple. You may have spent a great deal of money getting your system set up, but remember that is a sunk cost. The only costs that matter are the ongoing costs.

Expect a chain of failures. To what extent do you rely on your vendor? To what extent does your vendor rely on other vendors? What are the motivations for security of your vendor's vendors? SMS is a great example of the divergence of security goals. The carriers are under tremendous financial pressure to make resetting the account password as easy as possible. Do you really want to use SMS for strong authentication? Is it really better than plain email?

Much of this should sound basic. In fact it is. But so is "Use SSL" and "Use two-factor authentication". Clearly not all SSL and two-factor authentication are equal and there is more than one way to implement both.

While the RSA breach was a shock, what does it show? That two-factor authentication works. The attackers felt the need to attack RSA to get to their ultimate targets. (Although it is possible that they found an exploit and just tried to take advantage of it. we may never know.) That's a big barrier.

This year has been a big year for two-factor authentication, thanks in most part to Google. I would hate to see this progress stalled due to misconstruing the RSA breach for something it is not. Notice how Comodo is rolling out two-factor authentication now.

Some of this content was originally published on my blog here and here

Possibly Related Articles:
Network Access Control
RSA SSL hackers breach Professional SecurID
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.