Home » The Art of Data Protection » Nothing like a possible exploitable vulnerability to start off the holiday weekend
Nothing like a possible exploitable vulnerability to start off the holiday weekend
May 28, 2011, 10:07 am EDT
Hold on to your burgers and dogs. Put the ice back in the freezer. Stow your beach towels, we need to talk.
There is new speculation emerging that points the finger at the stolen RSA seed values as a key ingredient used to orchestrate an attack on a large defense contractor. Due to the highly valuable information held by systems integrators in the defense industrial base, advanced threats are consistently working to circumvent network defenses. Those in this community (and other users of SecurID) should be on elevated alert as similar attacks may surface.
If you have followed any of the RSA security breach story you are probably aware that specific assets were stolen that could be used to "reduce the effectiveness" of a SecurID implementation as part of a broader attack. While there has not been any public disclosure proving this speculation, the potential risk should sound the alarms. Customers who are currently using RSA SecurID tokens should take action:
A.) Update Client Protections: It is important to require clients to update system software with the latest security patches and access control policies prior to accessing the network. To reduce the opportunity for key logging of passwords and token information, clients need to make sure all clients connecting via SecurID's are scanned for malware and viruses.
B.) Increase Access Controls: If you are currently using RSA SecurID's you should introduce the use of an additional validation (password or pin) to access the network. This may include requiring strong passwords for accessing highly sensitive datasets and applications. Administrators should also force a password change for accounts to minimize the threat of compromised account information. Any exchange of credential information must be encrypted in transit.
C.) Elevate Monitoring and Audit: IT Administrators should look for repeated invalid log in attempts, concurrent log in sessions from different source IP's, and account activity that is anomalous. Other monitoring and audit capabilities should be leveraged to evaluate possible malicious activity.
D.) Plan for exchange of current tokens: Ultimately the best way to protect your organization from risk is to exchange SecurID tokens for either new tokens with an updated seed, or evaluate options from other vendors. SafeNet can provide a flexible and simple roadmap for customers to migrate to other one time password technologies. Administrators may wish to temporarily block access to remote users if they are especially concerned about a breach.
We will be updating this blog post as more details surface about the breach and if any other copy cat exploits are successful. Please also listen to our webcast "The Token is dead, Long Live the Token" June 2nd at 2pm. Mike Rothman, Analyst and President of Securosis Research and Andrew Young, VP of Authentication at SafeNet will present best practices, options and battle misconceptions. Follow our live chat during the webcast at #securechat
Interested in migrating RSA SecurID tokens to a secure solution? Click here for more information.
Keep our service members and their families in your thoughts this weekend. Have a safe holiday.This entry was posted in Authentication, Cybersecurity, Data Breach, Government, Token and tagged authentication, breach, hack, Lockheed, RSA, securID, token by Chris Ensey. Bookmark the permalink.
Business Drivers for Next Generation Authentication Blog Series, Part 5: Executives – Here’s Why a Remote Workforce Needn’t Jeopardize Data Security
Mor Ahuvia April 18, 2014, 11:16 am UTC
Stephen Helm April 17, 2014, 09:33 am UTC
Sharon Ginga April 16, 2014, 03:32 pm UTC
Business Drivers for Next Generation Authentication Blog Series, Part 4: Getting Lean Without Going Loose – CFOs Capitalize on Secure Cloud Migrations
Mor Ahuvia April 10, 2014, 11:49 am UTC
SafeNet October 10, 2013, 06:05 am UTC