EMC To Replace SecureIDs

EMC has confirmed that information stolen from RSA related to its SecurIDs had been used in the Lockheed Martin breach, and has offered to replace millions of potentially compromised “SecurID” tokens after hackers used data stolen from its RSA security division.  The Pentagon’s number one arms supplier and the government’s top information technology provider was attacked online last month, underscoring a growing threat to national US security.

The widely popular electronic tokens use a two-factor approach to authenticate the person trying to access a system.  They also interfere with the effectiveness of common key-logging malware in capturing and compromising passwords by generating new passwords each time a system is accessed.  The SecurID token generates a new string of digits every minute, that the user must enter along with a secret PIN, before they can access the network.  If the user fails to enter the string before the timer expires, access is denied.

This will be an expensive fix for EMC.  I await details on who to contact and how to get the new SecureID tokens.

Lockheed Martin Breach Update

Jeffrey Carr has done some good research and blogged about what is known so far regarding the Lockheed Martin compromise.  A very good analysis of what appears to have happened using public informaiton sources, and illustrates some of the contradictory information Lockheed has released.  The extent of the RSA SecurID breach appears to be somewhat worse than EMC has reported and EMC still disclaims its role in this attack.

As Jeffrey points out, Lockheed Martin has a history of significant cybersecurity breaches dating back to Titan Rain in 2003, and the F-35 Joint Strike Fighter program in 2009.  They have never publicly acknowledged the F-35 breach and lost a the lawsuit when a jury awarded a multi-million verdict for wrongful termination in the Sandia National Labs incident.

I will continue to watch this situation, and provide links to what I believe are good articles and information.

 

RSA Breach Notification

Hackers have breached the security arm of EMC, to steal information related to its RSA two-factor authentication products.  The company’s President Art Coviello revealed the sketchy details in an undated letter to customers Thursday.  “Recently, our security systems identified an extremely sophisticated cyberattack in progress being mounted against RSA.”  The vendor does not believe any personal customer or employee information was compromised in the attack.

The attack was categorized as an advanced persistent threat, typically a sophisticated and stealthy attack that is often leveraged in espionage to steal intellectual property.  Neither the letter nor a Securities and Exchange Commission filing identifies what data was stolen, but Coviello said the information obtained by the hackers may aid in circumventing RSA’s SecurID products, which include hardware authentication tokens , software authenticators, authentication agents and appliances.

Speculation indicates that attackers may have gained access to the so-called “seed values” that are used to generate the six-digit PIN that is changed by SecurID tokens every 60 seconds.  Millions of companies worldwide use SecurID to protect access to their sensitive assets, such as web servers, email clients and VPNs.  Other possibilities include the theft of source code that could provide attackers with a treasure map of vulnerabilities to exploit, or the theft of private cryptographic keys that might allow them to imitate RSA servers or register new employee tokens.

Coviello wrote, “We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.”  The company plans to “share our experiences from these attacks with our customers, partners and the rest of the security vendor ecosystem.”  Ironically, RSA has been researching the APT threat for more than a year, in attempts to develop new mitigating technologies.  In an interview last month with SC Magazine at the RSA Conference in San Francisco, RSA CTO Bret Hartman said organizations should accept that they cannot stop an APT attack and should instead focus on early detection, damage containment, and impact reduction.

RSA is strongly urging customers to:

• Increase focus on security for social media applications and the use of those applications and websites by anyone with access to critical networks.
• Enforce strong password and pin policies.
• Follow the rule of least privilege when assigning roles and responsibilities to security administrators.
• Re-educate employees on the importance of avoiding suspicious emails, and remind them not to provide user names or other credentials to anyone without verifying that person’s identity and authority.
• Employees should not comply with email or phone-based requests for credentials and should report any such attempts.
• Pay special attention to security around active directories, making full use of their SIEM products and also implementing two-factor authentication to control access to active directories.
• Watch closely for changes in user privilege levels and access rights using security monitoring technologies such as SIEM, and consider adding more levels of manual approval for those changes.
• Harden, closely monitor, and limit remote and physical access to infrastructure that is hosting critical security software.
• Examine help desk practices for information leakage that could help an attacker perform a social engineering attack.
• Update security products and the operating systems hosting them with the latest patches.

CISO Lays It On The Line @ RSA

Representing the average customer, Tim Stanley, CISO of Continental Airlines had the opportunity to ask vendors and researchers direct questions regarding patches and vulnerabilities at the RSA 2010 Conference.  “Microsoft knows about a bug, researchers know about a bug, but I’m the guy who paid for the software.  When am I gonna know? … And don’t tell me about the pains you have in determining what has to be fixed, I don’t care.  You’re in the software business, you’re writing code, that’s what you’re supposed to do.  If you can’t handle it, get out of the business."

A panel discussion brought him in, and put him on the dais with Microsoft, Adobe and HD Moore.  He wasted little time making his displeasure known.  I am pleased to hear that he tossed cold water on some opening remarks regarding the exposure timeframe from the discovery of a bug to when a patch is released, as well as some points on the importance of constant communication between vendors and researchers.

"I love the love-fest between the vendors and researchers, but quite honestly, I don’t give a hoot.  I’m the consumer, the guy who paid for the product that I expect to be correct in the first place.  I’m perturbed with the relationships going on.  The issue becomes a matter where the people paying for the product need to be better represented in this process," Stanley said.

Discussion hit on all the usual topics: vendor triage, prioritization of patching, how zero-day vulnerabilities impact patch cycles, regression testing, and the quality and stability of patches.

HD Moore, famous for script kiddie tool MetaSploit for example, called responsible disclosure of vulnerabilities a vendor created delay tactic.  He opined that as a researcher reporting bugs, he’s at the vendor’s mercy.  Because the vendor controls the patch release cycle, the vendor determines when his research work becomes public.  Too bad, so sad.  Publicity is everything, it seems.  "If you have evidence that something is being exploited in the wild and a vendor has not patched it, at that point is the vendor irresponsible or you for not reporting?"  I only wish that the question was turned back to HD, asking if he publishes code publicly before or even shortly after a patch is available, or creates a plug-and-play module that simplifies exploitation, who is responsible.

I have nothing personal against him, but HD Moore needs to smarten up.  I hope nobody is buying what this guy is pedaling.  He is NOT the savior of all software and the elected dispenser of patch-justice.  Yes, the vendors don’t move fast enough, yes we can make them move faster by releasing dubious “admin” or “pen-test” labeled tools like MetaSploit and its modules that allow any clown with a PC to exploit serious threats.  Yes, HD stands to make a boot-load of money for himself and the company that bought his “product” (or as I’m sure he’d prefer, funds his research).  In my most humble of opinions, this is aiding and abetting an attacker to commit whatever crime they commit, and the authors of such tools and the companies that they work for/with/though should be accountable, regardless of whatever disclaimers are posted in their EULA.

I might not have all of the answers regarding what should be done to get vendors patching their mistakes faster, but lighting a house on fire to get the people to come out so you can save them from smoke inhalation is probably not the best route to take.  If “responsible disclosure” is a process that isn’t working, then fix the parts that aren’t working, or provide a better one.  One that meets the needs of those that a researcher and the vendors are supposed to be serving.  Why not advise the vendor, give them a REASONABLE amount of time to patch, if they don’t produce, release NEWS that you have discovered a serious vulnerability (if you don’t cry wolf, you will gain credibility) and have the vendor (or a trusted impartial 3rd party that is not seeking profit) confirm it.  If the vendor still doesn’t take action, start legal proceedings.  A couple of class action suits and they will probably get interested in patching, or better yet, cleaner coding practices…

There are too many self-serving and egotistical researchers and vendors already, running rough-shod, cowboy style across the windswept plain that is the Internet.  Time to clean up this one-horse town.

C-Net RSA 2010 Article List