Neil MacDonald

A member of the Gartner Blog Network

Neil MacDonald
VP & Gartner Fellow
15 years at Gartner
25 years IT industry

Neil MacDonald is a vice president, distinguished analyst and Gartner Fellow in Gartner Research. Mr. MacDonald is a member of Gartner's information security and privacy research team, focusing on operating system and application-level security strategies. Specific research areas include Windows security…Read Full Bio

Coverage Areas:

Some Thoughts on RSA SecurID Risk

by Neil MacDonald  |  June 9, 2011  |  1 Comment

On 3 June 2011, RSA, the Security Division of EMC, confirmed that Lockheed Martin had proof that hackers attacked its network partly by using data stolen in a March 2011 attack on RSA. Subsequently, on 6 June 2011, RSA announced a program to replace customers’ RSA SecurID one-time password (OTP) authentication product tokens

We’ve updated our advice to clients using SecurID tokens in this First Take.

For current customers, RSA has published guidance that focuses on putting in place better protection of the systems that maintain the userid-to-token mappings and of the token seed values.

However, the risk here is higher than it first might appear. Two thoughts:

1) Protection strategies absolutely must include better protection of endpoints where reportedly the hackers were able to obtain the user-to-token mappings using a keystroke-logger or Zues-like Trojan. It is typically much easier to target end-users as a weak link rather then enterprise servers. This problem is compounded when contractors, home users and other non-enterprise managed assets use SecurID for strong authentication. On these systems, the enterprise may or may not have a security stack present (like an endpoint protection platform), the users may run as administrators and the patching discipline is unknown. End-users are the weakest link and end-users coming from unmanaged devices make this even weaker.

2) The attack on RSA was an organized attack, likely a state-sponsored Advanced Persistent Threat. The assumption that the hackers would obtain the seed key values from RSA and then go target enterprises may be far too optimistic. It is quite possible that the hackers obtained at least some of the user-to-token mappings before the attack on RSA occurred, knowing that once the breach at RSA became public, enterprises would place stronger controls on the systems that contained the user-to-token mappings. In other words, we might be trying to close the barn door after the horse is already out.

1 Comment »

Category: Application Security Endpoint Protection Platform Information Security     Tags: , , , ,

1 response so far ↓

  • 1 Andre Gironda   June 9, 2011 at 11:44 am

    I had first run into these software-based token-only RSA clients about 2 years ago. However, I’ve been using SecurID hardware-based devices along with passphrases since 1996.

    There was a huge disconnect. Starting in the mid-2000s, the banker-trojans had the capabilities they needed to make these types of attacks work. Organizations that moved away from hardware-only devices made a huge mistake — they removed their central control — their primary control in their chain of client-side defense.

    Decision-making processes are at all all-time low for C-level execs involved in technology. Go back to MBA school and re-take that coursework, please!

    Also note that you do not need to universally apply hardware-device token-generating SecurID-like technology across an entire Enterprise. However, you certainly should for consultants, partners, IT/Ops staff, executives, and anyone handling any regulated or high-risk data. It’s also a good idea to not put all your eggs in one basket — there are many other solutions from CRYPTOcard, VASCO, Authenex, ActivIdentity, and others.

    I’m worried that 2FA will lose its control capabilities in terms of market mindset because of these SecurID failings. It’s time to set the record straight that all of these problems were decision-making issues internal to companies that chose the SecurID software-only tokens, which is NOT 2FA and fails to recognize the problem with “oversourcing” to a single solution provider.