RSA have disclosed a breach of some sort of data associated with its SecurID two factor product. Bejtlich was among the first to comment that this could indeed be a plausible target of choice for the so-called "APT". We might have anticipated this given that two factor is a strategic technology in the fight against structured threats.
Securosis have posted some analysis including a link to the 8K filing which contains the notification message to customers. The official guidance states, "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." It sounds like the attackers might have data they can use to conduct phishing, social engineering or possibly PIN harvesting operations against two factor users in support of attacks against targets using two factor auth. The suggested actions sound like responses to a scenario where compromised two-factor creds to critical systems may be in play;
* Increase their focus on security for social media applications and the use of those applications and websites by anyone with access to their critical networks.
* Enforce strong password and pin policies. We recommend customers 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 their 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 their help desk practices for information leakage that could help an attacker perform a social engineering attack.
* Update their security products and the operating systems hosting them with the latest patches
Update 1: Whitfield Diffie speculates in a NYT story that a “'master key'— a large secret number used as part of the encryption algorithm — might have been stolen". It may be time for strategic technology vendors to think about air gapping.
Update 2: US-CERT released Technical Information Paper-TIP-11-075-01, System Integrity Best Practices, the day before the RSA announcement. The document "offers recommendations for best practices to use to achieve system integrity through software authenticity and the assurance of user identity" and appears to outline preparatory steps taken or recommended in the government space.
NSS labs have released an advisory making rather profound statements and recommendations; it is unclear to me what the precise basis of their recommendations are unless they are in possession of additional information.
The New York Times also ran a new story with additional speculation. I'm uncertain if such speculation is productive but it is probably inevitable with the sparse amount of hard detail we have.
Update 3: Secureworks have published a threat analysis with some actionable recommendations for security operations centers and threat detection teams;
- Direct attacks against an ACE server.
- Confirm current patch levels and general server hardening
- Monitor IPS/IDS logs
- Monitor server logs
- Brute-Force attacks attempting to determine the specific seed used for a given account's SecurID token, as well as attacks aimed at compromising other authentication factors.
- Monitor for repeat authentication failures, both on the ACE server and on intermediate appliances and systems
- Monitor for authentication failures not followed by success both on the ACE server and on intermediate appliances and systems
- Changes in source of authentication attempts.
- Multiple concurrent logins for a single account.
There is also some discussion in a SANS subscription bulletin; the terms of use prohibit posting on the web but these bulletins can be subscribed to at http://portal.sans.org/
Update 4: One of the SecurID inventors says in a Security Week story that deployments using PINs are probably safe. Steve Gibson asserts that based on what we know, tokens in circulation should be replaced. Schneier believes we have insufficient data to make recommendations. Adam Shostack concludes social engineering attacks are the most likely scenario.
Links
http://taosecurity.blogspot.com/2011/03/initial-thoughts-on-rsa-apt.html
http://securosis.com/blog/rsa-breached-secureid-affected
http://www.sec.gov/Archives/edgar/data/790070/000119312511070159/0001193125-11-070159-index.htm
http://www.nytimes.com/2011/03/18/technology/18secure.html?src=busln
http://www.csoonline.com/article/677537/industry-searches-for-lessons-after-rsa-breach?source=rss_data_protection
No comments:
Post a Comment