Vulnerabilities / Threats
6/8/2011
01:59 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Schwartz On Security: Confused By RSA's Clarification?

While RSA has offered to replace some tokens, many customers still don't know how or why their SecurID tokens may pose a security risk.

Could attackers break into your SecurID two-factor authentication system?

Despite the open letter issued this week by RSA chairman Art Coviello, many of the company's customers remain confused about exactly what attackers stole from RSA in March, and what risk that information might pose to their enterprise, even if they're not a defense contractor.

That's because RSA still hasn't fully detailed the SecurID-related data that attackers stole. Many people suspect that attackers captured copies of the seeds, or factory-encoded random keys installed on its hardware tokens. But as noted--not least in a recent story comment--stealing seeds alone isn't enough. Attackers would also have to tie a specific user to a specific token, which is much more difficult, but could theoretically be accomplished.

Is that the threat vector? We don't know, and in fact, it could be much worse. "There might be other trade secrets the attackers made off with which would facilitate other sorts of attacks," says Paul Ducklin, Asia Pacific head of technology for Sophos, in a blog post.

"For example, a cryptanalytical report might show how to clone tokens without any customer-specific data. Or confidential engineering information might suggest how to extract cryptographic secrets from tokens without triggering any tamper-protection, allowing them to be cloned with just brief physical access," he says. "In short, the situation is confused because RSA hasn't attempted to remove our confusion."

Should the security giant also have done more to prevent the advanced attack that breached its systems in the first place? "It doesn't make that much sense to blame RSA Security for what has happened. For sure they made mistakes--but ... the question is: What can and should customers do now?" asks Martin Kuppinger, founder and principal analyst at identity and information security analyst firm KuppingerCole, via email.

Perhaps unsurprisingly, according to the Wall Street Journal, some of RSA's 25,000 business customers are getting the jitters and requesting replacement tokens. But customers in industries not designated by RSA as being at high risk of attack--and to which RSA may not yet have reached out--will have to pay for the new tokens, according to Threatpost.

Security analyst Pete Lindstrom at Spire Security has said that RSA will have difficulty manufacturing enough new tokens to meet the needs of both new customers and replacement requests. As a result, there could be a token bottleneck in upcoming months, especially for companies deemed to not be at increased risk of attack.

No doubt, some SecurID customers will take their two-factor authentication business elsewhere, although this would be an even more expensive option, since most still have contracts with RSA. "Yes, companies will stop using RSA SecurID over time in many cases--not all, but many of them. SecurID is as reliable as a technology with centralized storage of secrets can be; the limits have been demonstrated now," says Kuppinger.

That gets to the bigger picture, as well as lessons to be learned from the RSA breach. For starters, he says, remember that no security mechanism is foolproof. Accordingly, ask in advance what to do if one authentication mechanism should fail. "The answer is versatility," he says.

In other words, don't put all of your authentication mechanisms in one basket, or faith in just two-factor authentication fobs. "Customers shouldn't focus on one specific technology in the future but the flexibility to use, add, combine different technologies for different use cases," says Kuppinger.

To do that, he recommends pursuing a more "versatile authentication" approach, mixing some combination of "soft tokens, out-of-band authentication, hardware token and other mechanisms." Using this approach, organizations could employ more varied and thus more secure authentication policies, for example, by requiring more types of authentication for more high-risk transactions. Furthermore, if one of a company's authentication vendors gets hacked and sensitive, product-related information is stolen, its technology could more easily be suspended or replaced, all while maintaining sufficient levels of security in the interim.

In this new Tech Center report, we profile five database breaches--and extract the lessons to be learned from each. Plus: A rundown of six technologies to reduce your risk. Download it here (registration required).

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web