The high-profile hack of EMC’s RSA division, which resulted in questions being raised about the security of the SecurID hardware authentication system, and the eventual replacement of some 40 million tokens – a process that started in June and is likely to continue for some months – is a game changer on several levels.
It’s a serious game changer for most IT security managers, as they – and their teams – must now invest time, money and effort in deploying the new hardware tokens.
Whilst it’s hard to quantify the direct and indirect costs associated with the deployment of a SecurID token, figures of £100.00 or so have been discussed per token.
And this is before, of course, the old token is disposed of, as required by the European WEEE directive – a process that needs to be taken seriously owing to the metals and toxic compounds contained in each unit.
Whilst a £100.00 on-cost to handle the deployment of a new securID token isn’t going to break the bank in most organisations, the money has to come from somewhere, and from a CEO’s perspective, it’s a cost that could have been avoided.
Against this backdrop, I think that the CEO of most organisations that use RSA tokens now need to be discussing the future of hardware tokens within their firm, as well as asking a number of pertinent questions of their IT department.
These questions include – when did you first become aware of the RSA hack, and – assuming the answer of late March comes back (it happened on March 18) – then the next question will be, what have you done about it since then?
A good IT professional will have picked up on the fact that the hack meant that the SecurID system was effectively compromised, and started reviewing replacement technologies, as well as conducting a risk analysis within their organisation.
Assuming a risk analysis was carried out, then due diligence rules start to kick in and, if you are a publicly quoted company, there may be questions asked about who carried out the analysis, since questions may be asked by shareholders and auditors at a later stage.
Again, assuming standard governance has taken place, then the next step in the questioning process that the CEO should now be undertaking will include: what is the cost of deploying the replacement tokens?
But hold on a minute – can we be sure that the new tokens are going to assuage or remediate the current problem?
“As long as RSA send out pre-programmed tokens they will continue to hold a copy of the associated seed records. So what’s to stop this information becoming compromised again in the future?”
These are all heady, but necessary questions. And if your management don’t ask them, then auditors or other interested regulatory bodies will be asking them in the future, especially if something goes wrong within your company.
And there are consequential questions that need to be asked, not the least of which is how the quality of the new tokens may be affected by the required ramping up of production for the mass re-issue.
But let’s focus on the direct and indirect costs for now, as this is an area that our finance departments will inevitably focus on.
Financial questions that need to be asked include the organisational cost of using tokens, covering issues such as:
- Support & maintenance
- Staff costs for looking after databases and servers
- Token distribution costs for lost/faulty or damaged replacements
- Help desk calls for PIN resets
- Help desk calls for instances where token have been forgotten
- Cost of replacement tokens
Other issues that need to be tackled include questions such as, are there any alternative two-factor authentication solutions that are lower cost and more convenient that would save the organisation any operating expenses without compromising the overall security?
This can also be introduced to the mix by asking the simple question: when was the last time your organisation surveyed the market for alternative solutions?
One useful `belt and brace’ option that may be worth considering is the possibility of adding extra layers of security, such as additional passwords or other `things that you know’ information requirements to augment the security of the SecurID-assisted authentication process.
In some cases it may be appropriate to consider a digital certificate method of authentication of specific laptops for remote access, where this facility can be rolled out in a relatively short timescale.
In the longer term, however, it is clear that the RSA systems hack should drive most IT managers to rethink their basic strategies surrounding strong authentication and, if change is required (as it probably is in this case) then flexibility needs to be the order of the day with any new solution.
This flexibility needs to involve the de-coupling of the authentication process from the applications being accessed.
By de-coupling the authentication process in this way, it becomes a lot simpler to change the authentication process as and when circumstances dictate.
It is not inconceivable that a replacement authentication system that your organisation installed to replace the SecurID mechanism may be compromised, which is where flexibility can pay dividends.
If you’ve read this far you will hopefully have realised that security technology such as hardware-based authentication needs to adopt an evolutionary, rather than revolutionary, posture, as the set-it-and-forget-it approach is a non-starter into today’s multi-threat security landscape.
A good security posture, in my experience, is one that assumes a worst-case scenario if something goes wrong, and developing a solution that best defends against the consequences.
Any authentication technology that replaces your SecurID-based platform needs to be as versatile and flexible as possible, in order to handle the security problems that arrive both now and in the future. More importantly, never allow your seed records to reside outside of your organisation in someone else’s database!
With the RSA hack still fresh in our minds, now is probably a good time to start reviewing your security systems and procedures, but such a review needs to be a root and branch procedure, in order to maximise the potential and cost-effectiveness in the longer term. Could this be a good time to think about technology more pertinent to what the user has on them everyday such as a mobile phone or iPad – and thus using tokenless 2 factor authentication as a cheaper, smarter, more flexible solution?