In a disappointing bit of news last Friday, RSA is compromised by "an extremely sophisticated cyber attack".This time, for real.
While RSA does not disclose exactly what was stolen, knowing the technology, one can still design a mitigation strategy.
I will recount options for those who's eager to do something to protect themselves.
1. Switch to a different token vendor. This is the most disruptive and costly measure, but if your trust is lost, and you have the budget, this may be your strategic option. It will require to replace your authentication server, and may introduce other problems as well as disrupt business. While RSA took the lion's share of the market, there are still other companies who make tokens and develop two-factor authentication technology, you just have to look out. Besides, "security by obscurity" principle, while often being laughed upon by experts, seems to work for many customers.
If you prepared to wait and see, I would advise the following mitigation strategies to reduce the risk of being exploited by someone logging in on behalf of your user:
2. Replace all SecurID tokens. Call RSA and request all of your tokens to be replaced by new, UNCOMPROMISED tokens. This last one is important thing. Unfortunately, you won't be able to verify if your new tokens were compromised, unless RSA publishes full list of compromised token's serial numbers.
Depending on exact fields of data stolen by hackers, and the way RSA kept their token records, you may have the following options:
3. If the data stolen includes token serial numbers and private seed keys used to initialize tokens, but does not contain token-to-client mappings (every token in the list is "anonymous") then attacker may not know which token they should recreate for attacking your company. Your protection measure may be to remove serial number white labels from the tokens, and file off (yes, I mean mechanically) the embossed serial numbers on the back of your tokens. This would probably require a temporary recall of tokens from your users, unless you can delegate the task to your end users. Also ask you users to never give tokens to anyone, even "just to see", and never leave them unattended or exposing the back side (upside up on the table). Also be sure your internal records, containing [previously public] serial token numbers, are secured and were never compromized. If this cannot be done, seek another option.
4. If stolen data records contain seed keys, serial numbers, and client names linked together, the worst has happened. Someone can recreate your token, and the attacked will know which company the token's for. This effectively removes one layer of protection (something you have). Remember, though, that still have other layers. One option would be to require all users to change PINs. You can increase complexity requirements for PINs, for ex, require 6-digit PINs where previously they were 4-digit only. Since only one part of your security mechanism was compromised, you still may rely on user PINs and obscurity (unknown VPN address, unknown VPN group password, unknown user name, unknown PIN), depending on your business requirement. Also remember, that, as tokens expire, the exposed data becomes more and more obsolete with time. In the interim solution, you may want to consider options.
Keep safe.
NB. This article does not constitute a formal advice, nor will I accept responsibility for you taking my advice, as well as neglecting it.
Every business should carefully revise their security mechanisms, based on new input, including this article.
