News

RSA Issues Customer Guidelines After SecurID Hack

• By William Jackson
• 03/24/2011

RSA, after its SecurID was hacked, temporarily halted distribution of the token used for two-factor authentication and warned customers to take addition precautions.

In a new online SecureCare note to customers, RSA, the Security Division of EMC, said that the SecurID continues to be an effective tool for authentication of end users accessing sensitive resources, but apparently only if customer data remains secure.

"Whoever attacked RSA has certain information" about the product, "but not enough to complete a successful attack without obtaining additional information that is only held by our customers," the company said.

The note goes on to advise customers to lock down SecurID Authentication Manager databases, review recent logs for unusually high rates of failed authentication attempts, establish strong PIN and lockout policies, and educate help desks and users about avoiding social engineering attempts to gain information.

RSA still is holding details about the breach and what information was compromised close to the vest, but analysts and researchers said the exploit by an Advanced Persistent Threat should not come as a surprise and that it probably does not significantly change the security equation of SecurID.

"Certainly these types of attacks are pretty pervasive" against high-value targets, said Jon Oltsik, an analyst with the Enterprise Strategy Group. "Someone wanted access to SecurID source code and they got it."

It has been rumored that the source code or the seed numbers used with the SecurID algorithm to generate one-time passcodes was compromised in the breach. But even the worst-case scenario for the breach does not enable a direct attack against the product, said Russ Cooper, senior researcher with Verizon’s RISK security analysis team.

"The ability to perform a brute force attack may become slightly easier," by removing some of the entropy or degree of randomness from the process, Cooper said. "We’re taking a couple of trailing 9s off of the 99.999" percent of reliability for SecurID. "They would still have to compromise a user in some significant way," which is what the RSA recommendations is intended to prevent or mitigate.

RSA announced March 17 that it had been the victim of an "extremely sophisticated" ongoing attack that had obtained information about SecurID.

"Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat," RSA executive chairman Art Coviello said in announcing the breach.

Advanced Persistent Threats, or APTs, are a broad class of computer attacks that typically use sophisticated and often multiple exploits to quietly breach system defenses. The goal of such an attack usually is not to disrupt the system’s operations, but to remain hidden and quietly gather information for as long as possible without attracting attention.

Although APTs are not new, they have gained a high profile in the past year with the revelation of their use against Google and other companies to obtain proprietary source code, and Coviello warned about the danger of these threats at last month’s RSA Security Conference.

RSA has been briefing customers under nondisclosure agreements on the incident, but has not released any details of the breach itself. A company spokesperson said it will share appropriate information at the appropriate time with appropriate parties, but details of the breach might never become public.

"Providing additional specific information about the nature of the attack . . . could enable others to try to compromise our customers’ RSA SecurID implementations," the company said in its most recent advisory.

The security of SecurID relies on the complete operation of the scheme to generate a new passcode for a user every 60 seconds, which must be used in conjunction with a Personal Identity Number, and not on the secrecy of any one piece of information. To compromise a SecurID deployment an attacker would need information about the token, the corporate customer, the individual user and the user’s PIN, the company said.

Although a direct attack using all of this information is unlikely, indirect attacks leveraging some exposed information are possible. Such an attack would most likely use some combination of techniques against back-end servers, networks and user machines, and social engineering techniques against the customer’s help desk and end users.

Best practices to secure against such attacks include restricting remote access and physical access to the Authentication Manager, isolating the server with firewalls and encrypting offline copies of data contained on the server.

PINs should be randomly generated alphanumeric codes if the token supports both letters and numerals and should be eight digits if possible. Users should be instructed never to give out the PIN, that it will never be asked for in an e-mail or phone call, and that it should never be entered on a site that was accessed by clicking on an e-mail link.

The Authentication Manager should be configured to lock out a user after three failed authentication attempts, and server logs should be reviewed for abnormally high numbers of failed attempts or attempts that result in a notification to the user that the token’s next code is required. These could be signs of an attempt to attack the system.

Some RSA operations have been interrupted while the company hardens its IT environment, it said in the most recent note. "We expect to resume distribution" of SecurID tokens "soon and will share information on this when available."