In my last post, I mentioned that the FFIEC was preparing an update to their 2005 guidance on internet banking authentication. Well, that update is out, and Anil John couldn’t wait to let me know about it (:)). The update, entitled ‘Supplement to Authentication in an Internet Banking Environment‘ recognizes both the growth in online banking and the dramatic change in the nature of internet threats it faces. The supplement stresses three key areas:
- the need for financial institutions to perform risk assessments against an ever-evolving threat landscape,
- the need to implement and constantly adjust a layered security strategy to mitigate the identified risks, and
- the requirement to raise customer awareness of potential risks through education programs.
The most telling aspect of the enhanced guidance seems to be its recognition of the fact that the threat landscape is not just different from what existed in 2005, but constantly evolving. Without actually stating this explicitly, the guidance attempts to make the point that this constant evolution means that any guidance put forth will become defunct pretty quickly, and places responsibility on financial institutions to make the effort in understanding the risks they face (through periodic risk assessments) and continuously improving their security posture in response. Personally, I would have liked to have seen them be much more explicit and take a much harder line on this, because multiple case studies and anecdotal evidence suggests that far too many banks put in the minimal effort necessary to simply comply with the letter of the 2005 guidance without attempting to be true to its intent.
An Emphasis on Risk-Based Authentication
The guidance brings out the need for financial institutions to create a more accurate and granular model of their risks based on a much wider variety of factors than previously described – the evolving threat landscape, the changes in the nature of their customer base and the kinds of transactions being done online. A more accurate calculation of the transactions risk must then be mapped to appropriate security controls, both at the time of the initial authentication (logon) and at the time of the transaction itself. The supplement (smartly) brings out the need to factor in contextual information – from environment variables like device identification and time of day to detection of anomalies in behavior patterns – in any risk calculation. Interestingly, both anomaly detection and privileged account management are emphasized in the security architecture.
Calling Out Outdated Techniques
Both device identification (through cookies) and challenge questions are called out as having to be enhanced from their previous “simple” models to more sophisticated, or “complex” models. While the enhancements recommended in both cases are improvements, I don’t believe they go far enough. In the case of challenge questions, for instance, it recommends
- increasing the number of challenge questions asked (without actually giving a number, so in theory just increasing from 1 to 2 is good enough),
- avoiding challenge questions that can be answered by mining the users information through online searches and social networks,
- including a “red herring” question that a fraudster would attempt to answer but a legitimate user would not (huh?), and
- using only a random subset of the challenge questions that the user has provided answers for in a single session.
This guidance fails to take into account that this is actually hard to implement without neutering its effectiveness. Forcing users to set up more challenge questions usually leads to selection of easily guessable answers, and more helpdesk calls. The 2nd item above is very subjective, and the harder you make the questions, the more likely the legitimate user will mess them up too. And I don’t even know how the 3rd item is supposed to work.
Also of note, the guidance does point out the decreased effectiveness of multi-factor authentication (even though it was probably drafted before the RSA breach compromised SecurID tokens). It does however advocate it’s use as one of the many controls in a layered model. Out-of-band authentication mechanisms (like those delivering One Time Passwords over SMS) get a fair amount of time in this paper as a practical solution.
I was disappointed that the guidance didn’t talk more clearly about passwords, and the need to really educate consumers about both better policies and their inherent ineffectiveness. And I think the fact that there was not a single mention of federated identity, especially in the context of “Business/Commercial Banking”, was a real missed opportunity for the FFIEC to move the discussion towards a better security architecture. I’m sure Stephen Wilson is not surprised by that, though.
The guidance will go into effect starting January 2012, so there will probably be some banks scrambling to understand what the implications are for the controls they have already deployed. Smarter institutions that have been paying attention to the security landscape all along will probably find that they are in good shape, but a lot who did the bare minimum and want to meet these guidelines will face some serious work. I predict an uptick in the interest that risk-based security products like Oracle Adaptive Access Manager will garner in the market. The emphasis on staying up to date with the ever evolving threat landscape will create a requirement for more dynamic security products that aid not just in enforcing stronger controls, but in assisting with the periodic risk assessments (Identity Intelligence, anyone?).
But the fact that this is guidance and not regulatory mandates means that a lot of institutions will continue to pay lip service to it. Which is why the real emphasis needs to be on changing the fundamental security architecture underlying (and infiltrating) enterprise IT. The consumerization of IT will probably play a far bigger role in driving this change than the FFIEC guidance will. Time will tell.