Minimizing the impact of the RSA SecurID breach

Attackers have breached the servers at RSA, the security company, and may have stolen information that could be used to compromise the company’s SecurID 2-factor authentication product line.

The attack was an Advanced Persistent Threat (APT), which means that the attackers used very sophisticated methods and were able to stay undetected by RSA for a while. RSA has not revealed what was actually accessed or stolen by the attackers. It is assumed that company specific SecurID token seeds or the source code of the SecurID product might have been stolen.

If the token seeds have been stolen, it might be possible for the attackers to generate the pseudo-random numbers for the tokens. This will give them one piece of the authentication information that users will provide to login to their systems. If the product’s source code has has been stolen, it might be possible for the attackers to analyze the code and find vulnerabilities that can be exploited.

RSA will probably have to re-issue SecureID tokens to all their clients in the near future. As for SecureID customers, they should not have to panic at this point. Even if the attackers are able to generate the pseudo-random numbers, that will in almost every case, just be 1 factor of the authentication process. Every implementation that I have seen uses a password and the random value from the token. This means that the password must also be known before an unauthorized login happens.

That is the inherent strength of the 2-factor authentication method. What bothers me more is that fact that they were able to breach RSA’s servers and stay in there undetected for a while. If they could breach RSA’s systems, they will probably be able to get into other organizations also. I, for one, will be looking for more information on how the breach happened.

Meanwhile, there is a bunch of things that organizations can do to minimize the impact to themselves:

  • Enforce strong passwords that are used in conjunction with the SecurID token values and follow secure password practices (require regular password changes, do not allow last 4 used passwords, etc).
  • Follow the rule of least privilege when assigning roles and responsibilities to users, especially security administrators.
  • 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. Email or phone-based requests for credentials should be escalated, verified and decided on a case-by-case basis.
  • Monitor changes in user privilege levels and access rights using security monitoring technologies and consider adding multiple levels of manual approval for those changes, at least for critical infrastructure and software.
  • Ensure that all infrastructure hosting critical software is hardened.
  • Restrict and closely monitor remote and physical access to infrastructure hosting critical software.
  • Examine help desk practices and prevent any information information leakage that could help an attacker perform a social engineering attack.
  • Apply the latest patches and updates to all security products and the operating systems hosting them.

Every one of the above points is good practice to follow at all times. If you are scrambling to implement even one of these, you should take a good look at your security procedures.

RSA’s Breach Notification