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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-4594
Published: 2014-10-25
The Payment for Webform module 7.x-1.x before 7.x-1.5 for Drupal does not restrict access by anonymous users, which allows remote anonymous users to use the payment of other anonymous users when submitting a form that requires payment.

CVE-2014-0476
Published: 2014-10-25
The slapper function in chkrootkit before 0.50 does not properly quote file paths, which allows local users to execute arbitrary code via a Trojan horse executable. NOTE: this is only a vulnerability when /tmp is not mounted with the noexec option.

CVE-2014-1927
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly quote strings, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "$(" command-substitution sequences, a different vulnerability than CVE-2014-1928....

CVE-2014-1928
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly escape characters, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "\" (backslash) characters to form multi-command sequences, a different vulner...

CVE-2014-1929
Published: 2014-10-25
python-gnupg 0.3.5 and 0.3.6 allows context-dependent attackers to have an unspecified impact via vectors related to "option injection through positional arguments." NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-7323.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.