Perimeter
4/7/2011
12:16 PM
Mike Rothman
Mike Rothman
Commentary
Connect Directly
RSS
E-Mail
50%
50%

RSA Breach Disclosure: It's Not About You

Unless you're an RSA customer, you don't need to know more details about the hack

Given the recent RSA breach, plus the slow trickle of details about what happened and the impact, many folks are vilifying the company for not sharing more. They say the disclosure was bungled. Not so much. For a change, I’m going to play the contrarian. The rumblings of those not in the know (and pissed about it) are misguided.

My partner at Securosis, Rich Mogull, recently put up a great post on our blog about crisis communications, with the key takeaway being any breach notification needs to be clear, direct, and honest. I think RSA was all three relative to the attack. The company disclosed it was breached on March 17, and we received more details on April 1. RSA didn't pussy-foot around the fact it was owned and by a relatively unsophisticated attack. It talked about how the data was exfiltrated, and also how it detected the attack, though it was a little too late. According to my contacts at RSA, the company has also been talking to its customers since the breach with no holds barred, giving them sufficient information to assess the risk of the breach to the customer’s security.

That’s the point. RSA might not have totally opened the kimono with the world at large, but who cares? Any breach notification first and foremost must focus on the CUSTOMERS, not the press, not analysts, and not anyone else. RSA notified its customers and, I presume, told them what they needed to know. It probably hurts some folks' feelings that they don’t know the gory details, but that’s not RSA’s issue. Another complicating factor is the likelihood that law enforcement and more than a few three-letter agencies strongly recommended RSA say less, if anything.

Could RSA have handled the communication better? I don’t think so. It was between a rock and a hard place. Assuming the Feds told them to say nothing, saying too much will piss off the government (a bad place to be). Saying nothing wasn’t an option either since it had to notify its commercial customers of the breach. So RSA discloses the breach, with enough information to keep the Feds happy and a clear action for customers to ask for more detail (if they are interested).

The press goes nuts. The Twitters go bonkers hanging Art Coviello in effigy because they don’t know everything. But interested customers can (and did) get details after signing a nondisclosure agreement (which is reasonable given the likely pressure to not say anything). Customers can then do what they need to, which is figure out what (if anything) they need to do given what has been stolen.

Lots of folks disagree with RSA’s use of APT (advanced persistent threat), asking how a spear phishing attack leveraging an Adobe 0-day is very advanced. If we’ve learned anything about the APT attacker, they take the path of least resistance. Attacking some low-level finance folks and then escalating privileges until they got what they wanted was the path in this case. Sure sounds like an APT to me. You’ll probably never know definitively who the attacker was, but does that matter?

Furthermore, at this point, what don’t we know about the breach? Basically we don’t know what exactly was stolen. Does it matter? If it were the seeds to the tokens (which many believe was the case), how does that change anything from a customer’s standpoint? They have to decide if/when they want to replace their tokens. Or maybe migrate to another solution. Or revisit and eventually overhaul their entire authentication infrastructure. The customers have been given the information they need to make these decisions -- though to the chagrin of many, it’s under NDA.

We know something was stolen. If the objective is to learn from the attack, then we have enough information to do that now. Train your folks to not pull files out of the spam folder. Monitor the crap out of your infrastructure. What else? If you aren’t an RSA customer but want more detail, you don’t NEED more detail. You can (and should) ask your vendor how it is protecting its intellectual property.

But to think this is about you and that you need to know what really happened is ridiculous.

Mike Rothman is president of Securosis and author of the Pragmatic CSO Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2595
Published: 2014-08-31
The device-initialization functionality in the MSM camera driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, enables MSM_CAM_IOCTL_SET_MEM_MAP_INFO ioctl calls for an unrestricted mmap interface, which all...

CVE-2013-2597
Published: 2014-08-31
Stack-based buffer overflow in the acdb_ioctl function in audio_acdb.c in the acdb audio driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to gain privileges via an application that lever...

CVE-2013-2598
Published: 2014-08-31
app/aboot/aboot.c in the Little Kernel (LK) bootloader, as distributed with Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to overwrite signature-verification code via crafted boot-image load-destination header values that specify memory ...

CVE-2013-2599
Published: 2014-08-31
A certain Qualcomm Innovation Center (QuIC) patch to the NativeDaemonConnector class in services/java/com/android/server/NativeDaemonConnector.java in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.3.x enables debug logging, which allows attackers to obtain sensitive disk-encryption pas...

CVE-2013-6124
Published: 2014-08-31
The Qualcomm Innovation Center (QuIC) init scripts in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.4.x allow local users to modify file metadata via a symlink attack on a file accessed by a (1) chown or (2) chmod command, as demonstrated by changing the permissions of an arbitrary fil...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.