Endpoint // Authentication
11/14/2011
07:27 PM
Connect Directly
RSS
E-Mail
50%
50%

Gauging The Long-Term Effects Of RSA's Breach

Worries still linger of future attacks, but experts hope the event shook industry out of black-and-white security mentality

More than eight months after the RSA SecurID breach bombshell was dropped on the industry, security professionals still whisper among themselves about the long-term ramifications of what RSA called the extraction of "information related to the RSA SecurID product." To this day, RSA still won't confirm what exactly was stolen from its systems, but speculation has run high that the token seeds were compromised in some way. Given the paucity of information coming from its quarters, security experts are left to speculate on whether we could still see an attack leveraging information stolen from RSA.

But the bigger question might be how the breach will change the authentication scene -- and the security industry at large.

For its part, RSA isn't trying to sugar-coat the situation. Company spokespeople couldn't say there would be no future attacks using old tokens, but they did point out that, to the best of RSA's knowledge, there has been only one customer confirmed to having been attacked using information stolen from RSA in the breach. That was an attack against Lockheed Martin that the defense contractor was able to stave off.

"Since there’s no such thing as perfect security, it’s impossible to predict what could happen. Nevertheless, we worked proactively and openly with customers immediately after the attack in March and continue to do so," says Eddie Schwartz, chief security officer at RSA. "We hardened our IT infrastructure and the processes related to SecurID manufacturing and delivery. Since March 2011, customers have been implementing our recommended best practices and remediation steps based on their views of the risk in this situation."

According to Rick Moy, CEO of NSS Labs, a security analyst and testing firm, even now it's hard to tell how sustained the long-term risks are without more information released from RSA.

"We still don't know what we don't know," Moy says. "I think it's hard to say without knowing how many of the tokens that RSA has replaced. There very well could be additional incidents out there. It's hard to close the book on it because they haven't really come forth with details."

Schwartz and RSA would not say how many tokens have been replaced so far, but that many customers have opted not to replace their tokens in favor of other mitigation techniques.

"We do not release specific numbers, but it is a fraction of the active hardware token user base. Based on their own assessment of risk, many customers remain comfortable using their existing tokens with the best practices we recommended in March," Schwartz says.

However, critics like Moy say the choice to stick with the old, compromised tokens is less a risk-based decision and more a pragmatic one. "I'm sure there's always going to be customers who are comfortable with that," he says. "It's very hard to rip out the plumbing in your house to put in new plumbing, and that's essentially what the identity solution is."

It's a matter of both inertia on the part of RSA customers and what Phil Lieberman, CEO of privileged identity vendor Lieberman Software, calls "incompetence" on the part of RSA's competitors in failing to draw more disillusioned SecureID users in the wake of the breach that has kept things pretty much in stasis despite its severity.

"It doesn't seem to matter that RSA's tokens have been compromised; nobody is getting off of them. Nobody is changing," he says. "The competitors who could potentially make hay on the opportunity simply don't want the business. The concept of making products ubiquitous with off-the-shelf SKUs, as RSA has done, seems to elude all of the competitors that they have. In a sense, it's somewhat like what happened with Microsoft and Novell. Novell was better, but Microsoft made it easy, and they were better at marketing and better at market control."

Nevertheless, the breach could have stirred some organizations that were already squirrelly about the security of one-time passwords (OTPs) to look for more secure alternatives. According to Aberdeen Group, the percentage of IT departments planning to deploy PKI smartcards in the next 12 months increased two-fold between December 2010 and May 2011, and the demand for one-time passwords dropped three-fold. The firm's analysts pinned that fluctuating demand curve on the RSA breach.

Even if smartcards are not the multifactor flavor of choice, and if an organization would prefer to work with OTPs, many within the authentication space say the RSA breach has at least brought the debate to a head as to whether it is a good idea to outsource the sensitive seed information fundamental to these tokens to an outside vendor. As the attack on RSA shows, all of that information for every customer can prove a tantalizing target for hackers.

“I think one of the things that this incident shows us is that a business model where an enterprise is trusting a third party to hold their seeds is potential very risky," Moy says. "There's a certain amount of risk that they have to calculate. If you're a small organization or don't have the resources to do it better in-house, you're going to probably go that route. If you're a large organization, you might want to look to other alternatives. There are other models where you don't have to give your seeds to someone else."

As a representative vendor that provides such an alternative, allowing organizations to program their own tokens, Stina Ehrensvard, CEO and founder of Yubico, says she has seen a lot of prospects not only from RSA's customer base, but from other organizations that use OTPs from other vendors that also hold onto a big repository of seeds waiting to be stolen.

"They've said the best way to be sure that it is secure and that there isn't a bunch of secrets being stolen from a database is if you control those secrets yourself and program the tokens in-house," Ehrensvard says. "We heard from one Department of Defense contractor that made a security audit of their tokens that were manufactured and programmed in Asia, and it turned out there was a copy of their seeds not only in Asia, but also Europe. There were two databases that they had no control over and weren't sure if they'd already been copied."

Next Page: More RSA customer attacks to come?

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.