1. the need for financial institutions to perform risk assessments against an ever-evolving threat landscape,
2. the need to implement and constantly adjust a layered security strategy to mitigate the identified risks, and
3. 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

1. increasing the number of challenge questions asked (without actually giving a number, so in theory just increasing from 1 to 2 is good enough),
2. avoiding challenge questions that can be answered by mining the users information through online searches and social networks,
3. including a “red herring” question that a fraudster would attempt to answer but a legitimate user would not (huh?), and
4. 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.

Whats Missing

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.

Looking Forward

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.

Tags: Federated Identity, FFIEC, Identity Context, Multi-Factor Authentication, Online Banking, Oracle Adaptive Access Manager, Passwords Must Die, Risk Management, Security Architecture

The Cloud Hanging Over Us

At Catalyst, Dan Blum stated that cloud computing is not ready to be a serious player in the enterprise when it comes to applications that handle sensitive data (some would argue that covers most enterprise apps). This reflects the biggest obstacle facing cloud computing acceptance – Trust. Enterprises need to be able to rely on cloud providers (read: have SLAs) for availability, security, performance, governance and privacy. But how can they do that when there are so many unanswered questions (as I pointed out in my previous post) and a lack of transparency on the part of the cloud providers? How can an Enterprise feel comfortable when Google says “The service is neither designed nor intended for high risk activities” or Amazons contract states “We are not responsible for any unauthorized access to, alteration of, or the deletion, destruction, damage, loss or failure to store any of, Your Content (as defined in Section 10.2), your Applications, or other data…”

Looking at the Silver Lining

When people talk about the business drivers for cloud computing, it is often summed up as the following list: Cost, Flexibility, Simplicity, Availability. But why not Security? Cloud architecture actually lends itself to a far more robust and reliable security architecture than anything that has come before. Everything can be built right into the platform and the applications, and the need for vendors to support multiple customers in a dynamic environment means that all of it has to be standardized and easy to put up/take down.

So what are the major identity management pieces in this puzzle?

• Federated Authentication that spans the enterprise environment and the cloud environment
  • Alternatively (or additionally), consider supporting User-Centric Identity
• Strong User and Access Lifecycle Management (Provisioning/De-Provisioning Capabilities)
• A Claims-Based Authorization model, coupled with strong XACML-based Entitlement Management
• Enterprise Identity Providers protected by IGF-style policy controls
• DLP (Data Leakage Protection) tools that protect sensitive data moved to the cloud
• A standardized Audit Framework for creating, managing and analyzing audit trails across cloud services

In my follow-up posts (and in the talks I am giving), I will look at each of these in more detail. In the meantime, register for the KuppingerCole webinar I’ll be doing and lets exchange some thoughts.

Tags: Cloud Computing, Federated Identity, Identity Services, User-Centric Identity