Comments
Kerub • May 30, 2011 7:46 AM
was this attack in any way related to those denounced by McAfee about oil corporations?
The Verizon blog isn’t anymore (or the URL is wrong)….
Ry Jones • May 30, 2011 7:53 AM
S,
Remove the comma and the verizon url works fine.
Ry
If EMC is going to protect it’s reputation, it’s time for them to reissue new software tokens for free and hardware tokens at cost of hardware. They should eat the physical costs to distribute. Recall costs are huge but far less than reputation costs (which are already significant).
Next step is to realize the tokens are no longer the profit center it once was. Their rep is gone. Now sell a tool to allow a company generate their own key private keys and tokens so EMC doesn’t have the raw data.
A. Nonymous • May 30, 2011 10:29 AM
“All I know is what I read in the news”
Yet your chosen headline is all people will home in on. Lots of unnamed sources speaking with no details given.
You usually speak out against fear mongering, but here you are whipping it up.
Anonymous Coward • May 30, 2011 1:22 PM
RSA set themselves up for this kind of speculation by being so vague about the attack.
alexT • May 30, 2011 2:32 PM
If it is indeed true – and I doubt we will ever find out – it would reflect very negatively on Lockheed Martin’s security staff.
I know multiple companies that have dumped – sometimes at great expense – their RSA tokens as soon as the breach was uncovered as they could not, even trough back channels, get a straight answer about what was really compromised.
token user • May 30, 2011 2:41 PM
@J
“Now sell a tool to allow a company generate their own key private keys and tokens so EMC doesn’t have the raw data.”
Hardly novel. Some other token vendors sell programmers and unprogrammed tokens. The sales hook, if unwritten, is that tokens are made in China, and US companies are suspicious that their seed data was programmed in there, so the master file must have passed through Chinese hands, hence the option to do it yourself. Though whether some busy IT department in a big company actually has the discipline to manage the programming more securely than the token makers, I doubt.
VASCO even sells one token model that includes on its feature list “Made in the Philippines”, which is a pretty transparent way of saying “Not made in China”. Or maybe “Not made in Israel” for some customers.
But it seems to me that traditional US xenophobia will win out, and US banks and govt departments will stick with EMC even post breech because they’re American, and all the other vendors are foreign.
NobodySpecial • May 30, 2011 2:43 PM
@AlexT – not necessarily the best solution – especially if there isn’t an obvious replacement.
Security is more than just knee jerk reactions.
What if you are an airline needing to get safety updates or you are currently in Afghanistan trying to service a missile system ?
Before you just cut off all your staff, customers, partners and suppliers in the name of security (which is of course what LM have since done) you need to balance the consequences.
Dirk Praet • May 30, 2011 3:19 PM
A predictable result of lack of full disclosure on behalf of EMC/RSA, combined with a misguided sense of security on behalf of Lockheed Martin.
When are people finally going to learn that failure of companies to come clean on a breach equals customers being lied too, most likely meaning a worst case scenario. QED.
Richard Steven Hack • May 30, 2011 6:19 PM
As someone suggested the other day, this probably isn’t over. In a few months, we’ll read about how this breach was only the beginning and how Lockheed lost tons of data in a subsequent attack that they didn’t detect.
I’ve already pointed out that according to rumor Lockheed employees run test servers off their HOME networks because the Lockheed security makes it hard for them to provision servers. This, despite Lockheed’s claim to have a very secure system.
It doesn’t matter whether Lockheed and these other defense contractors have classified data and thus have DoD approved “security”. They’re large corporations like any other large corporation – they are inherently vulnerable and have probably been penetrated already without their knowledge like most corporations have been. At the very least, it’s almost certain that Chinese Intelligence have one or more employees working there, regardless of whatever vetting is done.
But even disregarding insiders, Lockheed is certain to be vulnerable to outside hacking. Unless all their classified data is on machines not even attached to their internal network (and thus only moved by sneakernet), let alone the Internet, it’s vulnerable. So all their reassurances are utterly hollow.
Stiennon • May 30, 2011 6:43 PM
Ancient history now but LM owns and operates Sandia Labs, were Titan Rain was so famously uncovered by Shawn Carpenter.
Patj • May 30, 2011 7:43 PM
Alext wrote, “I know multiple companies that have dumped – sometimes at great expense – their RSA tokens as soon as the breach was uncovered as they could not, even trough back channels, get a straight answer about what was really compromised.”
Please list those companies. Otherwise I smell BS.
jd • May 30, 2011 7:48 PM
@A. Nonymous
“fear mongering” ?!? Really? The headline is a direct, simple description of the contents of the stories. Your attack makes no sense.
Vles • May 30, 2011 9:03 PM
Off topic
@ jd – I think A. Nonymous picked up on a tone in those ten words that he – perhaps – is not used to reading here from Bruce. Though we can only speculate as to the mindset that belies the origin of those words, A. Nonymous choose to interpret it as deviating from his normal writing style. And in pondering the choice of those words – he felt they held sufficient “fear mongering” value to attack the authors persona in that – if such was the case – it contradicts what he preaches. Cheap shot to dismiss someone so easily in so few words..One could just have asked B why he used those words to announce what he wished to share, that the sources are unnamed, there’s little detail to go by and that is feels someone not B wrote this post. They would have been fair enough questions..
I have a feeling that if B had chosen to replace “All I know is what I”, with “This is what I”, there wouldn’t be so much fuss…
Personally I was wondering if that choice of words was influenced by a report referred to in a recent article on Slashdot in which B gets a mention.
http://yro.slashdot.org/story/11/05/27/2324227/DoD-Paper-Proposes-National-Security-Through-a-Culture-of-Restraint-and-Stigma
andy • May 30, 2011 9:50 PM
There are two reasons why RSA/EMC has lost credibility in my mind.
The minor reason is lack of full disclosure.
The major reason is: why the $!@% was there any secret to steal in the first place? They should issue a token, program the thing with a random secret, tell the client the secret, and keep no record at all of what the secret is. That way, even if their entire system were completely compromised (impossible, I know, for a company as security-conscious as RSA), there wouldn’t be anything to steal.
In other words, RSA is selling expensive little gadgets which require people to trust RSA’s integrity and competence for no good reason. I had hoped that RSA was better than that.
Clive Robinson • May 31, 2011 12:03 AM
@ andy,
“The major reason is: why the $!@% was there any secret to steal in the first place?”
The answer is simple “user support”, from a business prospective they had two choices, “keep the secret” or “not keep the secret”. If they kept the secret then they could offer “user support” on certain frequently occuring events, if they did not their customers ended up with non functioning security which would cost the customer big bucks to sort out (ie buy a new token).
The real problem is which “person” in EMC/RSA decided to make this database available on machines with external access and did they have any choice.
The cynic in me thinks that the choice was for “business efficiency” reasons and was made by a “bottom line watcher” in a senior position.
It has been said that EMC/RSA had an “opt out” policy for those customers that wanted to store the “secrets” themselves.
However nobody has confirmed if this realy was an opt out or not….
A little thought excercise for you to mull over,
If you think about the business process flow around the manufacture and supply of tokens you will realise that “opting out” is an extra stage which incures both expense and risk for the company.
That is for all tokens,
1, Manufacture tokens and give them serial numbers.
2, Make blank entry in the DB for the new serial numbers.
3, Program “secret” into the token and put in DB.
4, Add token to inventory.
Then at some future point,
5, Recieve order for tokens.
6, Ship tokens to customer.
Now most companies operate a “returns” process, where by a customer can return an item for a valid reason such as the wrong parts were shipped. Importantly these returns usually go back into the inventory.
Now if the “secret” had been wiped from the DB on dispatch then the returned tokens would effectivly be “land fill” as the cost of reprograming would probably wipe the profit off the item (due to unpackaging and repackaging and ensuring correct DB updates were made).
So in theory the removal of the “secret” would happen at some point after the returns period.
Now… this removal of the data would be a risky process, in that as it’s an exception to the normal process any error could result in the incorrect data being deleted ie that of another customer due to a “data entry error”.
The easy solution would be to have two DB’s a production DB which is effectivly write only from step 4 and a User Support DB that gets a copy of the details from the production DB at stage 6.
If the customer requests the “opt out” option the secret does not get coppied into the User Support DB.
Irrespective of if the customer “opted out” or not if they return the token it gets put back into inventory and the record in the User Support DB gets wiped.
As the production DB did not get wiped at any point stages 5&6 can be repeated with a different customer without any risk.
So on the lose assumption that a company worked on that sort of quite reasonable system, what would they do if a data breach occured became public knowledge?
A, What is the actual betting that they never actually removed the secrets from say the production DB only say from the User Support DB when a customer “opted out”?
B, What is the actual betting that the production DB was any better protected than the User Support DB?
C, What is the actual betting they don’t know which DB the crackers got access to?
D, So the lack of info from them is due to the fact they don’t want customers to know they never realy wiped the secrets, and don’t know if they have been stolen or not.
Now compare the results from the hypothetical company above to the response of EMC/RSA…
As I said it’ just a thought excercise to mull over.
Clive Robinson • May 31, 2011 12:46 AM
@ jd, Bruce,
“The headline is a direct, simple description of the contents of the stories.”
Yes and no.
The problem is the unqualified use of the word “linked” in the short title, it can have more than one meaning to a reader.
That is prior to reading the stories you do not know if the word means “linked by evidence” or “linked by conjecture”.
As such the short title is “out of context” because you need either to read the articles to put it in context or have other prior knowledge that sets it in context.
Bruce having read the articles has it already in context in his mind, thus it did not “jibe” when he was selecting a title.
But worse in this case there is an implicit association due to common usage to “linked by evidence” because it is simply “linked” implying a hard association of fact, not a soft association of conjecture or musing.
We see this deliberatly exploited in the UK by journalists/editors with “sensation crimes” where an article title says “Mr X linked to disapperance of child C”. The link might be very tenuous at best such as “he drives a car of similar make and colour”, or as has been seen with UK red tops, “lives in the area and acts a bit wierd” (google “Barry George” and “Jill Dando”, or look into early stages of the “Madeleine McCann” investigation).
thelocalhost • May 31, 2011 1:09 AM
Regarding Schneier’s “fearmongering:” This is a high-traffic blog. A post like that can prevent a delge of redundant emails. This blog is part headlines, part informed opinion. In the absence of sufficient information, you get a curt post like this one. Zero speculation. I want to know why someone who reads Schneier’s blog can’t piece that together.
Simon • May 31, 2011 2:51 AM
I’d just like to know why Lockheed-Martin were still using these tokens after the attack on RSA.
Frank • May 31, 2011 4:03 AM
And there must be more to the breach than just the tokens, doesn’t it? AFAIK the token is just one piece in a two factor authentication.
So the Bad Guys need to know a password that matches to the token. I’d like to know if the breach was done via an roadwarrior’s account or if they just got lucky while bruteforcing.
And I’d like to know if LM has some sort of ‘bait blueprints’ which would raise an alarm if those blueprints would appear on the (black-)market.
BF Skinner • May 31, 2011 5:55 AM
@ Stiennon
Sandia NATIONAL Laboratories is a GOCO. It is operated by a LM subsidiary but it is not owned by them. USG owns it. Government Owned/Contractor Operated (GOCO).
Nick P • May 31, 2011 2:44 PM
@ Clive Robinson
“The answer is simple “user support”, from a business prospective they had two choices, “keep the secret” or “not keep the secret”. If they kept the secret then they could offer “user support” on certain frequently occuring events, if they did not their customers ended up with non functioning security which would cost the customer big bucks to sort out (ie buy a new token).”
This is a good hypothesis. The problem is that the alternative you included, customers buying new ones, is often better for the bottom line. Merely training users to think such problems means a replacement leads to a steady stream of purchases. Additionally, this is the best strategy from a security perspective because RSA stores no seeds.
I wonder if you (or anyone else here) have specifics to validate the hypothesis. What support-related services are RSA offering that requires them to know the seed and couldn’t be handled via an interface to the SecurID server (which has the seeds)? I just don’t see a need for this as building support-related functions into the SecurID server would be better for RSA and the customer.
Joe Dietz • May 31, 2011 2:48 PM
But RSA ‘tokens’ are not always actually tokens. As has been mentioned before on this blog, RSA has been marketting ‘soft tokens’ as two-factor authentication for years now. In reality they are just a confused way of doing LM hash authentication with really short passwords (4 numerical digits anybody?). Dumb and dumber. I hope they loose the business line for this, but they deserved to loose it over the soft token snake oil.
Richard Steven Hack • May 31, 2011 8:35 PM
Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks
http://www.wired.com/threatlevel/2011/05/l-3/
“L-3 spokeswomen Jennifer Barton declined comment last month, except to say: “Protecting our network is a top priority and we have a robust set of protocols in place to ensure sensitive information is safeguarded. We have gotten to the bottom of the issue.” Barton declined further comment Tuesday.”
Sure.
“L-3 uses SecurID for remote employee access to the unclassified corporate network, but classified networks at the company would not have been at risk in the attack, the L-3 source said.”
Sure.
“The attacks come as the Pentagon is in the final stages of formalizing a doctrine for military operations in cyberspace, which will reportedly view cyberattacks that cause death or significant real-world disruption as the equivalent of an armed attack.”
Any way to start a new war is always welcome at the military-industrial complex.
Davi Ottenheimer • May 31, 2011 10:08 PM
Kudos to Verizon. If you really want to read about foreign threats to Americas infrastructure and vulnerability on the Internet, check out the news magazines and papers in 1984. Scary stuff.
Alan • June 1, 2011 10:27 AM
Yubikey, anyone? It seems like OATH HOTP or TOTP would be an ideal replacement for RSA’s products. The algorithms are openly available, and multiple implementations exist.
Nick P • June 2, 2011 5:05 PM
@ Alan
Nah, I think this is a perfect killer app for open hardware enthusiasts to try. They can use one of the existing protocols and/or implementation, but give us a cheap open hardware design for the tokens. Then some company can start making them and selling them slightly above cost. Maybe a bunch of companies. This reduces the risk for us. Maybe take it a step further and have several open hardware designs all using the same protocol.
Jimmyssock • June 3, 2011 3:03 PM
Reading some of the comments, and doing a quick google of lockheed tools in use, I’m sure they know exactly if any data has been stolen, with https://sjobs.brassring.com/1033/ASP/TG/cim_jobdetail.asp?SID=&jobId=190289&type=search&JobReqLang=1&recordstart=4701&JobSiteId=5010&JobSiteInfo=190289_5010&GQId=0&partnerid=25037&siteid=5010#Seabrook&Codes=IN-DirectEmp
Argus, arbor, netwitness deployed, I’d also be interested to see which product flagged an intrusion.
Alan • June 7, 2011 12:51 PM
Ooops. I guess RSA actually does have some explaining to do.
http://arstechnica.com/security/news/2011/06/rsa-finally-comes-clean-securid-is-compromised.ars
Again, use of an authentication algorithm open to review by anyone (without an NDA or such crap) is probably a better approach than simply accepting the “trust us” assurances of a company about their product, even if they do happen to have some really smart people working there.
John • June 9, 2011 10:33 PM
I work for a multibillion-dollar aerospace/defense contractor and today we got an internal memo advising that we’ll have our RSA tokens all replaced very soon, as quick as the manufacturer can send in the replacements.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Matthew X. Economou • May 30, 2011 7:27 AM
The Verizon Business Security bloggers are a little skeptical (from http://securityblog.verizonbusiness.com/2011/05/28/weekly-intelligence-summary2011-05-27/, “[as] it stands it is simply another sensationalized tale of a nascent hypothesis and cannot reasonably be regarded as actionable intelligence.”)