Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
Comments
Newest First  |  Oldest First  |  Threaded View
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-28488
PUBLISHED: 2021-01-22
This affects all versions of package jquery-ui; all versions of package org.fujion.webjars:jquery-ui. When the "dialog" is injected into an HTML tag more than once, the browser and the application may crash.
CVE-2021-22847
PUBLISHED: 2021-01-22
Hyweb HyCMS-J1's API fail to filter POST request parameters. Remote attackers can inject SQL syntax and execute commands without privilege.
CVE-2021-22849
PUBLISHED: 2021-01-22
Hyweb HyCMS-J1 backend editing function does not filter special characters. Users after log-in can inject JavaScript syntax to perform a stored XSS (Stored Cross-site scripting) attack.
CVE-2020-8567
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver Vault Plugin prior to v0.0.6, Azure Plugin prior to v0.0.10, and GCP Plugin prior to v0.2.0 allow an attacker who can create specially-crafted SecretProviderClass objects to write to arbitrary file paths on the host filesystem, including /var/lib/kubelet/pods.
CVE-2020-8568
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver versions v0.0.15 and v0.0.16 allow an attacker who can modify a SecretProviderClassPodStatus/Status resource the ability to write content to the host filesystem and sync file contents to Kubernetes Secrets. This includes paths under var/lib/kubelet/pods that conta...