Time to Replace SecurID Tokens?

SCADA Remote Access

A significant percentage of ICS owner/operators use SecurID tokens for strong, two-factor authentication for remote access. Similar to the IT space, it has the largest market share by far. With the recent hacks of RSA and Lockheed, it is time to reconsider if you can rely on these tokens for administrator remote access to the control center.

Back in March RSA announced they had been hacked, well sort of. They were a bid dodgy on what exactly was compromised. Eventually most agreed the seed keys that are used to generate the one-time password that changes every minute were compromised, based on analysis and leaked information. So an attacker could recreate the one-time password at any moment in time.

There still was a lot of work to convert this information to a successful compromise. The attacker would need to tie the seed key to an organization/department/individual, based on the deployment scenario. However the attacker may have also stolen the database information that tied token serial numbers / keys to organizations. The final hurdle is most organizations use a combination of the one-time password with a user selected PIN as the password. So the attacker would need to identify the token used and recover the PIN. None of this is easy.

But evidently not too difficult. Last week Lockheed announced, and RSA agreed, that compromised SecurID tokens were a “direct, contributing factor” to the Lockheed compromise.

The stolen SecurID data is being used. There are questions on who is using it? Who are their targets? Are the selling the data? For example, if you wanted to attack utility x, can you buy the SecurID data related to their tokens. This combined with a targeted phishing attack may be enough to get an adversary into the control center with administrator credentials.

This is where risk management gets very difficult. The risk of a compromised SecurID token being used to attack remote SCADA access was never zero, but it has to be considered much higher now than prior to March. Still the likelihood is very small, but the impact would be huge. Should an asset owner respond and move to a different method of secure remote access? I’ll split our recommendation into two cases.

Many SCADA and DCS owners have implemented an automated switch or a process that has secure remote access disconnected at all times, except when it is required and approved by an administrator … the emergency remote access scenario. The disconnect is an air-gap with no way to connect until the air-gap is closed. For these situations, the additional risk of a token compromise is minimal. The attacker would need almost complete control and monitoring of the administrator’s remote access pc and could only take advantage of it during the emergency window. If they had all of this, they actually would probably not even need the compromised SecurID token.

For owner/operators that have secure remote access always on, it is time to look at and consider other authentication options besides the currently deployed SecurID tokens. The number of remote users are minimal, or at least they should be, so the change would not be massive like issuing new tokens or another solution to the entire company. If a small expenditure in time and money would remove the risk of the RSA compromise, it should be considered. Organizations that are high profile targets are at a higher risk and therefore have more incentive to change.

Image by Travis Goodspeed

BTW: Travis has been busy trying a number of hardware attacks on the SecurID tokens. Awaiting the results.


  1. A Nonymous says

    Replacing *RSA* tokens with a token from another company is just shifting the problem, not actually addressing it.

    People flocked to Macs because “Apple products don’t get viruses,” but fast forward as Apple regains market share, and viruses for this platform begin to appear. As people decide to shift to other competitors or technologies, eventually the bad guys will too.

    Are you treating your RSA servers like the valuable asset they are? Do you jealously guard access and log all attempts to talk to the underlying server? C.I.A. — if you lose the ‘C’onfidentiality of the seed data on your internal enterprise SecurID server, of what value is it for protecting your larger enterprise?

  2. Peter Browning says

    ANonymous wrote:

    > “Replacing with a token from another company is just shifting the problem, not actually addressing it.”

    Not sure I’d quite agree. Using a known open standards based well documented algorithm (say sha based) with known seed mngt by the end user (as opposed to the current black box) process would go a long way to make this managable again.


  3. mtoecker says

    A Non,

    At the end of the day, would it really matter whether or not customer token infrastructure was treated like a critical and protected with uber-security?

    Nope. All those protections would be a waste if the seed values are lost.

    The moment initial seeds for One-Time Password tokens are lost, a countdown to exploitation starts. That countdown is equal parts standard user phishing and the devastating reversal of the statistical walls that protect 128 bit seeds and time based hashes from concerted attack.

    Protection of the auth server and the seeds at the customer side won’t stop people who have seed data. It’s just another piece of an intricate puzzle to them. Surprisingly enough, a defense in depth posture, relying on multiple layers of dissimiliar access controls and countermeasures, would be necessary and would probably save a lot of potential victims.

    Mike T.
    Private Citizen, my opinions are my own


Leave a Reply