Error in deserializing body of reply message for operation 'Translate'. The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 8654.
RSA SecurID customers are bracing for the worst in the wake of the revelation by RSA late yesterday that information related to its SecurID two-factor authentication products had been stolen a major cyberespionage attack.
Word of the attack, which RSA categorized as an advanced persistent threat (APT)-type breach, came via a an open letter posted by RSA executive chairman Art Coviello on RSA's Web site as well as via a Securities and Exchange Commission (SEC) filing. RSA provided little detail on exactly what was taken or how, but the vendor did provide a list of recommendations for its customers that ranged from hardening their social media application security, using least privilege for administrators, and reiterating with employees to avoid suspicious emails and phone calls to ratcheting up security in their "active directories" and closely monitoring their SIEM systems.
Of major concern is just what the attackers actually got their hands on from databases storing RSA's SecurID information. The uncertainty and lack of specifics from RSA has left some RSA customers frustrated and unsure just how to respond internally. A security officer at one large enterprise that uses SecurID, and who requested anonymity, says RSA's announcement of such a critical security breach should have come with more "actionable" recommendations than the general ones the company offered.
"My chief concern is we don't know what they [the attackers] got," he says. "What RSA is saying, and what they are not saying. is that whatever [the attackers] got, [with] some other information they could socially engineer from a user would let them be able to pretend they have a token by duplicating it somehow."
One worry is that the attackers gained the serial numbers from SecurID customers' tokens and other information that would give them the ability to clone the tokens and then use social engineering to gain additional information in order to use the SecurID authentication to in turn target large RSA customers of the technology.
The security officer says he's now stuck trying to figure out how to assess the risk to his organization, but he doesn't have enough details or information to provide an assessment to his senior executives. He says RSA contacted his company, but only offered up the same recommendations and information the company has put online about the breach. "They've mostly been dark since yesterday," he says.
Recommendations such as the one that advises customers to "pay special attention to security around their active directories" is the equivalent of telling the user to check the engine light on his car, the SecurID customer says. "The engine is there. Be more specific," he says. "I understand that they don't want to provide a recipe [for an attacker] to break in . . . But we are relying on their product to protect that infrastructure. They should be able to relay some of the details . . . and what to do."
Meanwhile, security consultants and researchers warn customers not to panic and note that even if the bad guys got hold of the six-digit key, they would still need the PIN code to use it, for example. Don Gray, chief security strategist for Solutionary, says organizations should educate users to take care with their SecurID tokens and to watch out for social engineering and phishing attacks that take advantage of the news surrounding the attack and offer to "reset" or "validate" a SecurID token.
Nick Percoco, senior vice president at Trustwave's SpiderLabs says waging a targeted attack using stolen SecurID tokens for authentication would be difficult for an attacker, but not impossible. "If we presume the attackers gained access to the token 'seed' files or the algorithm used to generate them, they would then need to identify a system that uses this type of authentication to target," Percoco says.
Take an online brokerage, with its customer portal as the main target, he says: "The attacker would then need to be able to map specific RSA tokens back to specific individuals. This assumes that the serial numbers on the tokens can be used to generate or lookup 'seed' values from the data stolen by the attackers from RSA. Once that is accomplished and the attackers can predict the token codes for a specific token, they would then need to guess the end user's PIN," Percoco says.
That step would entail getting the token's serial number and the PIN, which could be grabbed via a phishing attack taking advantage of the RSA breach, for example. "Once they have both the ability to predict the token codes and the end user's PIN, they can access the accounts on the online brokerage system," he says.
Just how widely deployed is SecurID? David Schuetz, a security consultant with The Intrepidus Group, noted in a blog post Friday that SecurID has more than 25,000 customers and that there are around 40 million physical SecurID tokens in circulation, plus 250 million software-based ones. "Many of these are used for secure authentication to corporate websites and email, and they've seen increasing use in online banking. A 'reduction in effectiveness' could have very serious, and wide-ranging, consequences," he blogged, referring to RSA's warning that the hack could have compromised the SecurID technology's effectiveness.
SecurID basically generates random numbers in a sequence known only to the authentication server—those numbers are then used by the person holding the token to log into a system, Schuetz explained. "To keep the tokens unique, each is pre-loaded with a seed that initializes the sequence for each token. The resulting 6-digit numbers, or 'tokencodes,' are therefore produced in a sequence specific and unique to each token."
Meanwhile, RSA exec Coviello's open letter raises plenty of questions. "While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations," he said in the letter.
"We have no evidence that customer security related to other RSA products has been similarly impacted. We are also confident that no other EMC products were impacted by this attack," he said, and that RSA plans to provide SecurID customers "tools, processes and support" to shore up security in the wake of the breach.
No one knows for sure as yet whether the attack was an isolated one or part of a broader APT-type attack. But APT-type attacks, which typically originate out of China, are notoriously stealthy, long-term, and often difficult to detect.
"It's hard to say, but I don't think this is an isolated attack. If anything, hackers are incredibly persistent and now they might also have your SecurID in their back pocket," says Frank Kenney, vice president, global strategy and product management at Ipswitch File Transfer. "If this is an advanced persistent threat attack, then we can expect to see additional attempts on RSA, and on owners of compromised SecurID's. Businesses and agencies need to be especially diligent in keeping tabs on how employees are sharing information, who they are sharing it with, and ensure that they are not using personal email for business communications--especially in the government."
SEE ALSO: RSA Breach Leaves Customers Bracing For Worst
Cutting-edge attacks like Stuxnet and Zeus will be the everyday exploits of the future. Here's what you need to know. That and more--including five best practices to improve the budgeting process for security spending--in the debut all-digital issue of Dark Reading. Download the issue now (free registration required).
Página 2:
