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

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
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2006-1318
Published: 2014-09-19
Microsoft Office 2003 SP1 and SP2, Office XP SP3, Office 2000 SP3, Office 2004 for Mac, and Office X for Mac do not properly parse record lengths, which allows remote attackers to execute arbitrary code via a malformed control in an Office document, aka "Microsoft Office Control Vulnerability."

CVE-2012-2588
Published: 2014-09-19
Multiple cross-site scripting (XSS) vulnerabilities in MailEnable Enterprise 6.5 allow remote attackers to inject arbitrary web script or HTML via the (1) From, (2) To, or (3) Subject header or (4) body in an SMTP e-mail message.

CVE-2012-6659
Published: 2014-09-19
Cross-site scripting (XSS) vulnerability in the admin interface in Phorum before 5.2.19 allows remote attackers to inject arbitrary web script or HTML via a crafted URL.

CVE-2014-1391
Published: 2014-09-19
QT Media Foundation in Apple OS X before 10.9.5 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted movie file with RLE encoding.

CVE-2014-3614
Published: 2014-09-19
Unspecified vulnerability in PowerDNS Recursor (aka pdns_recursor) 3.6.x before 3.6.1 allows remote attackers to cause a denial of service (crash) via an unknown sequence of malformed packets.

Best of the Web
Dark Reading Radio