The RSA Hack: Don't Overreact

Sunday, March 27, 2011

Eric Cissorsky

C6b9a422851928980389afe33c48e213

Since RSA announced its servers were broken into the security field has been innundated with news about it. 

While this can be a potentially serious problem for many organizations the bottom line is at this time we do not know the full impact of this incident.  Despite that, there are many in the security industry overreacting to the situation. 

Many articles with titles predicting doom and gloom for IT departments  are popping up all over.  This is no surprise though, we live in an age where news headlines are defined by the mantra "If it bleeds it leads" and this is the IT industries equivalent of that.

For its part RSA has been open, although cryptic, about the incident and has worked diligently with its customers to communicate the issue, educate them as to what remediation steps can be taken and to discourage this kind of overreaction. 

The company has stated the information that was stolen can not, repeat can not, be used in a direct attack on a SecurID protected device or the ACE /Authentication Manager server.  Still many IT security professionals are running around acting as if the sky were falling.

For the IT security professionals who are taking this approach I offer the following advice: relax.  It is absolutely critical for any information security department to remain calm throughout any incident. 

When IT Security panics it has ripple effects throughout the enterprise.  In the event this turns out to be a serious breach of security you will be credited with keeping your cool and weathering out the storm. 

Overreacting to this, or any security incident, can undermine your and/or your departments credibility and you may not be taken seriously when the next security issue arises.

As of this writing the full extent of the breach is not known and until RSA releases further information there is not much one can do.  RSA emphasizes securing your Authentication Manager database and limiting access to the ACE server.  This should already have been done at implementation time. 

Furthermore, access to the ACE server should already be strictly limited and enforced.  This is the backbone for secure access to critical data and systems in many environments, only highly trusted staff should have access! 

Another area RSA has provided guidance for is log analysis.  RSA recommends reviewing the ACE logs for repeated authentication failures or next tokencode requests.  Again, this is something that should already be in place. 

Whether it be the local logs or logs offloaded to a syslog server and/or SIEM a person or automated process should be scanning for anaomalies on a regular basis.  Repeated logon failures, especially from your ACE server, should raise flags and be investigated. 

RSA also recommends using strong PIN's, requiring regular PIN changes and enforcing lockout policies.  You already do this with passwords so why wouldn't you be following these same best practices with your SecurID's? 

Your Help Desk should be verifying the identity of any/all users requesting PIN resets (New PIN Mode) or other SecurID related requests.  This process should have been well defined, implemented and documented along with the SecurID deployment.

Finally, RSA has indicated certain customers may be targeted by spear phishing attacks through social media sites.  With the explosive growth of social media, and marketing departments exploitation of it, every organization should have some type of Social Media Policy in place. 

To help mitigate this risk use web filtering capabilities to restrict access to these sites from the corporate network to all but a select few.  Every organization should have at least a basic security awareness policy in place.  There are several basic concepts that any program will encompass. Among them are email and social engineering awarenesss. 

It may be advantageous to push these policies out to employees once again as a refresher.  In its latest SecureCare Advisory RSA even directs customers to the Anti-Phishing Working Group site, http://education.apwg.org/r/en/index.htm, for additional measures that can be taken to protect users.

These steps are not a patch or hotfix but rather basic common sense security practices that should already be in place in your environment.  This should help alleviate some security fears however it is by no means a panacea. 

As always the foundations of information security must be adhered to in order to limit an organizations risk not just to this but to any security incident.  If your organization uses the SecurID solution now is not the time to panic. 

Rather it is time to go back and review your security policies and make sure they have been implemented properly and are backed by a written process and other supporting documentation.

Possibly Related Articles:
17709
Breaches
RSA Authentication Incident Response breach Professional SecurID
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.