The full story of the RSA hack can finally be told
wired.com
wired.com
As for RSA, it came out a couple years later their products were compromised various ways by the NSA. Then a couple years later the NSA lost control of its own hacking tools with the infamous Shadow Brokers release. Not only is building secure systems hard, but the US government actively works to undermine its own companies' security.
https://www.reuters.com/article/idUSBRE9BJ1C220131220?irpc=9... https://arstechnica.com/information-technology/2014/01/how-t...
That's not really an air gap, isn't it?
...also, since they detected the breach before the attackers got to the "seed warehouse," why did they try to tail them in real time? just pull power to the whole DC.
Access between network segments, or to a protected host, is through a single specifically-hardened host. Through network traffic (natting or bridging) is typically disabled or at least not provided by default, though in practice, it's challenging to entirely prevent tunelling.
But no, it is not an air-gapped system. Likely a journalistic compromise as "bastion host" is a less familiar term to the public.
What boggles my mind is that the seed machine and the intervening network and the firewall did not appear to have "scream loudly then shutdown when this threshold is exceeded" mitigations in place.
They were wise enough to have a single connection from the seed host to the seed requester. They were wise enough to limit the requester to one request every 15 minutes.
They only discovered that threshold was being exceeded when they logged in to that machine.
The firewall itself should have had detection and response capabilities to notice when calls were being made faster than that, and it should have had a third, dedicated warning connection to alert humans to the fact. The seed host should have had detection and response capabilities.
And, given the value of the asset, it would have been entirely reasonable to have a transparent bit of network gear doing the same, like a custom switch invisible to the request host.
Since the article didn't mention any of these things, and since it said that the high request rate was detected only by humans on the box, I'm going to assume they didn't have these, for reasons mysterious.
EDIT: Come to think of it, since that machine was being used to burn CDs, there should also have been strict limits with appropriate detection mitigations on what that machine could do outbound.
I get the compulsion to delete it, but deleting it wouldn't have provided any real comfort. You would have no idea if that was the only copy. So, delete it just in case it is, but it doesn't change what you would have to do afterwards...the master keys have to be assumed leaked.
Have to assume the data were compromised anyway, as you point out.
> As the recovery effort got under way, one executive suggested they call it Project Phoenix. Coviello immediately nixed the name. “Bullshit,” he remembers saying. “We're not rising from the ashes. We're going to call this project Apollo 13. We're going to land the ship without injury.”
This is the sort of response that would increase my trust to choose this company in the future. This is not easy. Our human instincts naturally kick in to minimize our faults and protect ourselves. Choosing to put the customer first at risk of your own reputation is hard, but the right choice, even for your reputation in the end.
https://en.wikipedia.org/wiki/Tylenol_(brand)#1982_Chicago_T...
In the end, their brand got stronger and more trustworthy.
(and I believe we got sealed bottles)
You probably see "tamper-resistant" more often.
https://www.npr.org/2020/05/19/859182015/johnson-johnson-sto...
https://www.cancer.org/cancer/cancer-causes/talcum-powder-an...
Ummm
Your link contained no evidence for this. A search of the NHS website also suggests no clear evidence [1]. Cancer Research (a respected UK charity) give a layman's summary (albeit focusing on ovarian cancer), stating no clear evidence and pointing out that there are far more serious risks to worry about [2].
[1] https://www.evidence.nhs.uk/search?om=[{%22ety%22:[%22Inform...
[2] https://www.cancerresearchuk.org/about-cancer/causes-of-canc...
This isn't a first for Andy Greenberg, either. https://www.imdb.com/name/nm5200697/
(My comment isn't critical of his writing; it's merely an effort at explaining it.)
Now I wonder if there are any cool SecOps movies or tv shows out there(?)
Yes, but why did there have to be a central server with the shared secret for every token on the planet?
The way the SecurIDs were designed, there was not way to plug into them, so there was no way to program them. So when you bought a batch you entered each serial number into your RSA auth server, which phoned home, and got the seed/secret.
Huge single point of failure.
TOTP (and HOTP before it) has a shared secret between the auth server and the token (software), but if Company X is hacked they don't get the secrets to Company Y:
* https://en.wikipedia.org/wiki/Time-based_One-Time_Password
Yeah, this struck me as a huge flaw. The breached system was used to create CDs full of IDs for customer deployment. For convenience the manufacturing system was almost but not fully air gapped. They retained the ID data in case the customer needed a copy in the future. However, keeping all of the IDs ever made on one system seems crazy.
If they had just deleted the data after backing it up to discrete offline media every week...
Data loss probably scared them more than risk of breach.
The real failure, after all, was not having the system actually airgapped. Aside from electromagnetic leakage through the power system there isn't much difference between spinning disks and tapes if they're not connected to anything else.
I'll take whatever improvements I can get in security.
That must've been a sickening feeling.
I'm not seeing an indication that it was routine, just that all the people involved happened to have 10 year NDAs in place. Might've been RSA-specific, potentially as a consequence of the breach or just an artifact of RSA's own policies; it's not actually mentioned. I'm also only familiar with 5 year NDAs.
An agreement cannot be perpetual.. A contract without a specific time period stated may potentially be terminable by either party with notice once the business relationship ends after a reasonable amount of time. So stating a number of years (less than 50) may strengthen the NDA in some respect - The "indefinite" NDA of an employee may possibly be terminated unilaterally by the employee with written notice after they left the job, so better for the employer to have them signing a new NDA at the time of separation giving a time period for the agreement.
Well that’s not exactly comforting. Who else might have had the keys to the kingdom?
RSA SecureID has been compromised for decades, way before this puff piece of sensationalist sell newspapers bit.
It wasn't that long ago when magazines like Wired cared a great deal about the page. What a mess.
Edit: I had to sign out and then back in after paying. Now the only ads I see are in-house ones (they really want you to sign up for newsletters).
Do you remember the super-early Wired print editions, because those colors made it barely readable.
You still get to read the article, but no "ridiculously obnoxious" ads appear anywhere.
https://news.ycombinator.com/newsguidelines.html
(This guideline isn't there because such complaints are wrong or inaccurate; just the opposite.)
It doesn't sound like it. Even our production servers hosted by a "rackspace" company have outgoing ports closed by default, we earn a tiny amount compared to RSA.
I know there will be reasons but honestly, the server should have been air-gapped or something. I can't imagine they need changing very often so why not copy it across the gap on a USB stick when you need it and leave it non-networked otherwise?
Of course, I know nothing about this organisation, it just sounds weird that a system that was so crucial was so vulnerable.