On March 18, 2011, we blogged about a breach at RSA regarding the disclosure of unspecified sensitive materials related to SecurID. At the time, little information was made available as to the extent of the breach, the exact information that was compromised, or how it would affect RSA’s customers. In a related Threat Analysis, we reviewed the architecture of RSA’s SecurID system and proposed theories regarding information that would fit the criteria RSA laid out in their announcement. Events that have unfolded since that time have led to many more questions and concerns, and many of RSA’s customers are seriously thinking about their present reliance upon SecurID authentication solutions. In light of these developments, we thought this would be a good time to update our previous blog post and guidance.
Although not yet directly confirmed by RSA, there’s growing evidence that the secrecy of SecurID seeds has been compromised just as our initial analysis had indicated. A recent attack against defense contractor Lockheed Martin has been widely attributed to the breach at RSA in several press reports, with Lockheed sources quoted as stating that the RSA breach had been “a direct contributing factor” in attacks against their systems. RSA later confirmed these statements, stating: “…we were able to confirm that information taken from RSA in March had been used as an element of an attempted broader attack on Lockheed Martin…” Other defense contractors, including L-3 and Northrop Grumman, are also widely believed to have been targeted by similar attacks utilizing information obtained in the RSA breach.
Amid the news of attacks leveraging the still-unidentified information stolen from RSA comes the news of RSA’s plans to offer replacement tokens to many customers. While this action has been widely reported in the press as a wholesale replacement of all tokens, the language of RSA’s notice leaves some doubt, indicating that some clients will instead be offered “risk-based authentication strategies.” These actions will no doubt involve a significant financial cost to RSA, yet EMC (the parent company of RSA) has not amended their initial 8-k filing from the time of the breach disclosure. Although RSA is a relatively small portion of EMC’s larger revenue stream, it is surprising that they maintain that the replacement action will not “…have a material impact on its financial result.”
We strongly advise anyone using SecurID two-factor authentication to contact RSA and determine if they qualify for replacement or migration to the risk-based authentication solution mentioned in their notice. If RSA will not accommodate these requests, it may be time to consider replacing your SecurID implementation with an alternate multi-factor authentication solution. When evaluating any multi-factor solution, carefully consider what materials must remain secret to maintain integrity of the system, and where those materials are stored. As past events demonstrate, third parties maintaining control of secret materials could provide an avenue to compromise the entire system.
In the meantime, our recommendations as they pertain to monitoring RSA SecurID systems remain largely unchanged:
- Secure your Authentication Manager database and ensure strong policy and security regarding any exported data consistent with security best practices guidelines available from RSA.
- Monitor and review Authentication Manager logs for unusually high rates of failed authentications or next token events consistent with log monitoring best practices guidelines available from RSA.
- Educate your help desk and end users on best practices for avoiding social engineering attacks such as targeted phishing.
- Establish strong PIN (Personal Identification Number) and lockout policies for all users.
- Consider using out-of-band user notification for authentication events.
- For example, automatically send the user an email when their token has been used to authenticate and ask the user to immediately notify the incident response team if they did not initiate the authentication.
- Monitor SecurID authentication logs for anomalous IP geolocation or anomalous geographical velocity between authentication events
- For example, the user authenticated from New York and then two hours later from Los Angeles.
RSA still maintains that “…the specific remediations we have provided to customers will help to deliver the highest levels of customer protection.” However, until and unless they provide a detailed description of what information was compromised, it remains impossible to independently verify this claim and a shadow of doubt remains. The confirmation of related attacks warrants a cautious approach. The prudent response at this point is to request replacement of any tokens whose private seed data could possibly have been compromised or pursue other solutions.
Leave a reply
