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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2963
Published: 2014-07-10
Multiple cross-site scripting (XSS) vulnerabilities in group/control_panel/manage in Liferay Portal 6.1.2 CE GA3, 6.1.X EE, and 6.2.X EE allow remote attackers to inject arbitrary web script or HTML via the (1) _2_firstName, (2) _2_lastName, or (3) _2_middleName parameter.

CVE-2014-3310
Published: 2014-07-10
The File Transfer feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center does not verify that a requested file was an offered file, which allows remote attackers to read arbitrary files via a modified request, aka Bug IDs CSCup62442 and CSCup58463.

CVE-2014-3311
Published: 2014-07-10
Heap-based buffer overflow in the file-sharing feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center allows remote attackers to execute arbitrary code via crafted data, aka Bug IDs CSCup62463 and CSCup58467.

CVE-2014-3315
Published: 2014-07-10
Cross-site scripting (XSS) vulnerability in viewfilecontents.do in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote attackers to inject arbitrary web script or HTML via an unspecified parameter, aka Bug ID CSCup76308.

CVE-2014-3316
Published: 2014-07-10
The Multiple Analyzer in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote authenticated users to bypass intended upload restrictions via a crafted parameter, aka Bug ID CSCup76297.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.