Perimeter
4/7/2011
12:16 PM
Mike Rothman
Mike Rothman
Commentary
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
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8142
Published: 2014-12-20
Use-after-free vulnerability in the process_nested_data function in ext/standard/var_unserializer.re in PHP before 5.4.36, 5.5.x before 5.5.20, and 5.6.x before 5.6.4 allows remote attackers to execute arbitrary code via a crafted unserialize call that leverages improper handling of duplicate keys w...

CVE-2013-4440
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 generates weak non-tty passwords, which makes it easier for context-dependent attackers to guess the password via a brute-force attack.

CVE-2013-4442
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 uses weak pseudo generated numbers when /dev/urandom is unavailable, which makes it easier for context-dependent attackers to guess the numbers.

CVE-2013-7401
Published: 2014-12-19
The parse_request function in request.c in c-icap 0.2.x allows remote attackers to cause a denial of service (crash) via a URI without a " " or "?" character in an ICAP request, as demonstrated by use of the OPTIONS method.

CVE-2014-2026
Published: 2014-12-19
Cross-site scripting (XSS) vulnerability in the search functionality in United Planet Intrexx Professional before 5.2 Online Update 0905 and 6.x before 6.0 Online Update 10 allows remote attackers to inject arbitrary web script or HTML via the request parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.