Tag: Authentication

28 Jun 2011

Final FFIEC Authentication Guidance just released

Well, after much anticipation and speculation we finally have the updated FFIEC guidance, and there doesn’t appear to be anything radically new here that would justify waiting an additional 6 months.  At the very least I thought we might see some changes in the Effectiveness of Certain Authentication Techniques section, or in the Appendix (Threat Landscape and Compensating Controls), but both sections are virtually unchanged.  That said, I examined the final release against the draft, and here are my observations divided into 3 categories; Good, Bad, and Odd (all bold and italics in quoted text is mine):

Good

Education: “A financial institution’s customer awareness and educational efforts should address both retail and commercial account holders…”.  Agreed.  This is a good change from the draft.  Education shouldn’t be limited to high-risk transactions only.

Risk Assessments for Financial Institutions: (Generally good, but see below under Bad and Odd)

Layered Security Programs: (Again, generally good, but see below under Bad)

Bad

Multifactor Authentication: The draft release stated that “Financial institutions should implement multifactor authentication and layered security…”.  The final release changed that to “Financial institutions should implement layered security…the Agencies recommend that institutions offer multifactor authentication to their business customers.”  The verbiage change seems to remove multifactor authentication as a requirement.

Layered Security Programs: “Financial institutions should implement a layered approach to security for high-risk Internet-based systems”…how about layered security for ALL Internet-based systems?  (Late edit – the guidance does recommend layered security for both retail and business banking customers, but only “consistent with the risk” for retail customers.  More prescriptive guidance on determining a high risk retail customer from a low risk retail customer would have been beneficial here.)

And,

“The Agencies expect that an institution’s layered security program will contain the following two elements, at a minimum.
Detect and Respond to Suspicious Activity”.  NO, NO, NO, the FFIEC has previously stated that layered security programs must contain ALL THREE types of controls; preventive, detective and corrective.  The omission of preventive controls is particularly puzzling because in the section on Control of Administrative Functions it states “For example, a preventive control could include…An example of a detective control could include…”.  Preventive controls are the least expensive to implement, and by far the most effective. It’s such a glaring error that I’m inclined to believe it was a typo.

Risk Assessments for Financial Institutions: The final release changed an “and” to an “or”, possibly introducing some confusion.  Here is what the draft release said:

“Financial institutions should review and update their existing risk assessments as new information becomes available, focusing on authentication and related controls at least every twelve months and prior to implementing new electronic financial services.”

The final release says:

“Financial institutions should review and update their existing risk assessments as new information becomes available, prior to implementing new electronic financial services, or at least every twelve months

The final guidance might be misinterpreted to suggest that conducting risk assessments every 12 months are an either/or situation instead of a minimum requirement.

Risk Assessments for Customers: “A suggestion that commercial online banking customers perform a related risk assessment and controls evaluation periodically”  Really?  Nothing stronger than a suggestion?  This should be a requirement.

Odd

Specific Supervisory Expectation – Risk Assessments: Original draft:  “…financial institutions should perform periodic risk assessments and adjust their customer authentication, layered security, and other controls as appropriate in response to identified risks, including consideration of new and evolving threats to customers’ online accounts.”

Final release:  “…financial institutions should perform periodic risk assessments considering new and evolving threats to online accounts and adjust their customer authentication, layered security, and other controls as appropriate in response to identified risks.”

Not sure why the verbiage change there, but I don’t perceive any change in meaning…I actually liked the original verbiage better.

General Supervisory Expectations: This verbiage appeared in both the draft and final version, and it is this final odd observation that disturbs me the most…”The concept of customer authentication…is broad.  It includes more than the initial authentication of the customer when he/she connects to the financial institution at login.”  It would be extremely instructive here to define the “concept” by focusing on what it is, and not what it’s not.  Specifically, what more does the concept include beyond initial authentication?  The authentication of the transaction itself?  The transmission of the transaction through the Internet?  All interaction of the user with the interface?  The processing of the transaction at the financial institution and/or payment provider?  By defining the concept only as “broad”, by saying that it includes more than the initial authentication, this guidance has the potential of expanding the liability of the financial institution, and I can easily see this used in a future legal proceeding  to obfuscate the lines of responsibility*.

In the end, although the basics of the guidance are sound, I was disappointed that it didn’t go farther.  I will repeat what I said back in February; the guidance is still behind the curve on this issue, and institutions simply have too much to lose.  Implement additional preventive controls at the merchant side, additional controls at the institution side (such as dual authorization, out-of-band, positive pay, etc.), conduct annual (or more frequent) risk assessments, and most of all, educate everyone on basic security best practices.

 

*Particularly on the heals of recent court cases, one of which went the customer’s way, and the other (so far) going the Bank’s way.

27 Mar 2011

The RSA breach, and 5 things you should do

For those of us already waiting for the latest update on guidance from the FFIEC on Internet Authentication, the news of the recent RSA SecurID breach complicates things a bit.  One-time password (OTP) hardware devices (tokens and smartcards) are considered one of the most secure forms of the “something you have” element in complying with the multifactor authentication requirement.  So let’s take a look at the RSA breach in the context of authentication guidance, and what you should do to respond.

When the FFIEC released its original guidance on Internet Authentication in 2005, they said this about tokens: 

Password-generating tokens are secure because of the time-sensitive, synchronized nature of the authentication. The randomness, unpredictability, and uniqueness of the OTPs substantially increase the difficulty of a cyber thief capturing and using OTPs gained from keyboard logging.

And 6 years later, in the draft release of the FFIEC updated guidance, they said:

“OTP tokens have been used for several years and have been considered to be one of the stronger authentication technologies in use.”

And they are correct; in the last few years OTP tokens for authentication have proven to be very secure and have become very popular, and arguably the biggest player in that market is RSA.  There are millions of RSA SecurID tokens in use today, many of them in financial institutions, and many of those authenticating Internet based financial transactions…perhaps for your customers.

So what exactly happened?  Well, their Website is (strangely) completely silent on the event, and RSA customers I’ve spoken to say that information is slow coming to them, and extremely vague when it does, but according to what has been disclosed by the RSA, here is what we do know:

“…the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.”

So…according to the FFIEC, the security of the OTP is based on “randomness, unpredictability, and uniqueness”, but we don’t know if the “certain information” mentioned by the RSA included the main algorithm or some other critical information necessary to generate the OTP.

As a financial institution responsible (and liable) for the security of your customers’ Internet based transactions, you must err on the side of caution here if you utilize RSA tokens.  I’ve got to believe that RSA will do the right thing here, and place their customer’s security ahead of their own business interests, but in the meantime it may be prudent to consider some additional measures, such as:

  • Since multi-factor authentication relies on “something you know” in addition to “something you have”, encourage (require?) your customers to change their user names and passwords.
  • Review (and possibly temporarily adjust) your built-in transaction monitoring metrics, such as dollar volumes, transaction frequency, ACH / Wire recipient lists, etc.
  • Implement “Out-of-Band” confirmation for all high-risk transactions.  In other words, temporarily require all transactions to be confirmed via a return phone call, fax, SMS, or similar method.
  • Make sure your customers know exactly who they can contact if they suspect unauthorized activity, and most importantly, let them know under what circumstances (and what methods) you will contact them.
  • Finally, consider an alternate token vendor.  You may be at the mercy of your on-line banking software vendor on this, but there are 2 trust issues in jeopardy here…the one between you (or your vendor) and the RSA, and the much more important one between you and your customer.  RSA may be able to fix whatever problems allowed the breach, and thereby repair the trust (or not) with their customers (your vendor), but the trust issue with your customers may not be repairable.  Rightly or not, they may be reluctant to use anything with “RSA” printed on it.

All of these items (except the last) are best practices anyway, but the key is that you must be pro-active on this.  Do not wait for RSA to release all the details (we may never know them anyway), because what we do know now is enough to justify additional security measures.

In conclusion, tokens and OTPs are still very effective as one element in one layer of a multi-layer, multi-factor, authentication process, but clearly the lesson here is that there is no fool-proof method.  Indeed as we await the FFIEC update, this line from the draft release is almost prophetic:

“Since virtually every authentication technique can be compromised, financial institutions should not rely on any one authentication method or security technique in authorizing high risk transactions, but rather institute a system of layered security.”

Perhaps the only change necessary to that statement in the final release is to remove the word “virtually”.

17 Feb 2011

Mythbusting on-line security

As I write this (2/2011), we are expecting updated guidance from the FFIEC any day on on-line authentication and security.  It is way overdue, as the last release was way back in 2005.  It is supposed to address the changes in the security landscape since then, and hopefully it will even raise the bar a bit, but I’m afraid that it won’t do enough to dispel the 5 biggest myths regarding on-line security:

  • “My software vendor provides all the security I need.”
  • “My multi-factor hardware tokens provide all the security I need.”
  • “If I follow FFIEC guidelines, my measures will be considered ‘commercially reasonable'”.
  • “Multi-factor authentication is adequate”.
  • “The customer assumes partial responsibility for security (at least contractually)”.
  • “Unless Reg E is extended to commercial accounts, my financial liability is limited”.

I’m going to address why all these are false in future posts, but for now make sure your risk assessment doesn’t rely on any of them.

09 Feb 2011

Top 5 Compliance Trends for 2011 – Part 5

As I write this, the only case to go to trial of a Bank suing the Merchant over account takeover losses is awaiting the jury’s decision.  The result may redefine the liability, and by definition the roles and responsibilities, of both the financial institution and the merchant when it comes to securing electronic transactions.  It may also finally determine what is considered “commercially reasonable” security, or (I hope) even toss out the use of this murky term altogether.  I believe there is a perfect storm brewing over this issue, with several factors converging simultaneously to produce my final compliance trend for 2011:

Corporate Account Security (merchant capture, remote ACH and remote wire transfer).

Here are all the converging elements and their implications:

  1. The aforementioned lawsuit between EMI and Comerica- The trial just ended on 1/26 and it’s now in the hands of the jury.  We’ll see how this plays out, but it will have implications either way particularly if (as I suspect) the merchant prevails.
  2. The upcoming FFIEC update to authentication guidance – We are expecting final guidance on this from the FFIEC any day, but whatever the final requirements, increased scrutiny of authentication mechanisms will be the result.  New guidance always results in increased regulator focus, even if it is only an update to existing guidance.  Additionally, I suspect that the update won’t go far enough to address preventive measures.
  3. The tendency for affected institutions to under report incidents – Because of the potential for reputation risk, financial institutions are reluctant to report account takeover incidents.  That is the primary reason that most institutions choose to settle with customers rather than take the case to court (there have been only 2 cases brought to court so far).  In the meantime, we know that online crime complaints have increased substantially each year since 2005, resulting in losses of hundreds of millions of dollars.
  4. A fundamental misunderstanding by both merchants and financial institutions of their respective responsibilities – BankInfoSecurity.com recently interviewed a bank CEO affected by an account takeover incident.  In the interview, he reveals that he believes that remote transactions should carry a lower degree of perceived protection than transactions carried out inside the Bank’s security perimeter.  He also expected the third-party vendor that provided the remote ACH software to have done more to keep the bank secure.  In the meantime, merchants expect the transactions they initiate remotely to be just as secure as those initiated inside the physical confines of the bank.

Here is how this trend differs from the others...regardless of whether or not regulators increase focus on this issue in 2011, I believe institutions absolutely must.  The guidance is behind the curve on this issue, and institutions simply have too much to lose.  It is clear that the minimum requirement is not sufficient, you must go further.  Implement additional preventive controls at the merchant side, and educate everyone on basic security best practices.

14 Jan 2011

FFIEC to issue updated authentication guidance?

I’ve been hearing this rumor for a while now, but we may actually be seeing something new from the FFIEC soon.  Gartner is the latest to suggest that an update to the 2005 guidance on authentication is imminent.

In addition to updating it for technological advances since 2005, (Facebook and LinkedIn were in their infancy, and Twitter hadn’t even been launched), I hope it also addresses the increasing responsibility held by the customer, (both commercial and consumer) for data security.  I continue to believe that there should be shared responsibility, and liability, for establishing and maintaining a secure electronic banking environment.

Reg. E protects the consumer, and so far the courts have held overwhelmingly in favor of the commercial customer as well.  Will regulators extend Reg. E to commercial accounts, or place more responsibility on the customer?  Could the new guidance further define “commercially reasonable”?

My guess is that we may not see much clarification on these issues, but we are likely to see additional burdens placed on the financial institution.  For example, don’t be surprised to see customer education become more prescriptive, with the financial institution being responsible for it.

Stay tuned!