Authentication – Compliance Guru

26 Mar 2013

Hot Topics Tom Hinkel 0 comment

Court rules in favor of Bank in account takeover case

Unlike the PATCO ruling, a district court in Missouri has ruled in favor of the bank in an account takeover case brought by one of its commercial customers. This case was very similar to the PATCO case with one important exception, which I’ll discuss shortly. But it also raises some interesting questions that could impact financial institutions.

First, the details. In March 2010, BancorpSouth received a request via the Internet to execute a wire transfer in the amount of $440,000 on behalf of its customer, Choice Escrow and Land Title. The Bank wired the funds, and the following day the customer contacted the Bank to notify them that they they in fact did not authorize the wire transfer. The company filed suit to recover the loss, claiming that the Bank did not use appropriate security measures. But their claim wasn’t that appropriate security wasn’t made available, but that there were several security options available and the Bank allowed the customer to select an inferior option. This is quite different from the PATCO case, where strong authentication was available to the Bank from the software vendor, but the Bank in that case decided not to offer it to their customer. In this case the Bank offered both single and dual-control authentication options, and the customer waived the dual-control option. This gave any authorized user of the software the ability to initiate and approve a wire without requiring a second user to approve and release the funds. Using malware, a hacker was able to gain control of the PC, record the user name and password via a keystroke logger, and send the fraudulent wire.

The PATCO case was decided in favor of the customer because the Bank failed to make strong, commercially reasonable, authentication options available to the customer even though the software vendor offered them to the Bank. But in this case, the judge decided just the opposite; stronger options were made available, but were declined by the customer. Remember, according to UCC 4A the risk of loss for an unauthorized transaction will lie with a customer if the bank can establish that its security procedure is a commercially reasonable method of providing security against unauthorized payment orders. So, advantage Bank. But again, the customer claimed that the Bank should NOT have offered the weaker option to them knowing that it was insufficient to address the risks. In other words, simply offering the weaker option to the customer was an implicit acknowledgement by the Bank that it was commercial reasonable. In the end this argument was rejected because the Bank had documentation that it offered, and the customer refused, the stronger option multiple times.

Although this case turned out OK for the Bank, the verdict does raise several questions for financial institutions:

Knowing that one option is better than another, should institutions even offer more than one authentication option to their customers? And what happens when a customer (or product) increases in risk? Do you require the users to upgrade?
Since the judge in both this case and the PATCO case referenced UCC 4A as the legal basis for their decisions, should the FFIEC be more prescriptive about exactly what constitutes “commercially reasonable” (and what doesn’t)? The 2003 FFIEC E-Banking guidance says that “whether a method is a commercially reasonable system depends on an evaluation of the circumstances.” But the updated 2011 FFIEC authentication guidance doesn’t mention “commercially reasonable” (or UCC 4A) at all. Why not? Specifically, why not include the “…the risk of loss for an unauthorized transaction will lie with a customer if…” language?
Are institutions putting too much faith in technical measures, and avoiding simpler, but more effective, controls? Anomaly detection is getting a lot of attention these days, but in this case Choice had a history of transfers with similar size and quantity, and anomaly triggers were not activated. Simple dual-authentication would have prevented this fraudulent transfer.
On the other hand, are vendors overlooking more effective technologies, such as out-of-band authentication and secure DNS?

In summary, there are still questions, but there are also a couple of lessons financial institutions should take away from this. First, the court determined that although dual-control was more labor intensive for the customer, it was also the more secure option, and as such Choice should have opted for increased security over the increased inconvenience. Lesson? Perhaps you should be less concerned about inconveniencing your customers with increased security requirements, and more focused on convincing (i.e. educating) them on why a little increased effort on their part is justified…i.e. security trumps useability. Second, customer awareness efforts and documentation made all the difference in this case. If the Bank had not made, and documented, multiple efforts to implement stronger authentication, this case could easily have gone the other way.

20 Sep 2012

Hot Topics Tom Hinkel 0 comment

New cyber attack targeting small to medium-sized financial institutions

The FBI, in association with the Financial Services Information Sharing and Analysis Center (FS-ISAC) and the Internet Crime Complaint Center (IC3), recently issued a fraud alert warning that criminals are using a multi-vector attack to compromise financial institution networks and initiate fraudulent wire transfers. The first thing that struck me about this attack is that although all the recent focus has been on strengthening controls on the merchant side, this is targeted not at the merchant, but directly at the financial institution itself.

Simply put, the attack uses a combination of SPAM and phishing emails (#1 below), keystroke loggers, and remote access software (#2 below) to capture employee authentication credentials. A successful attack results in the employee’s PC being under the control of the criminal, who will then use the employee’s authority to initiate wires, approve them, and even override built-in transaction limits. The following graphic describes how the attack occurs, with the exception that in #5 the victim is the financial institution, not the on-line banking customer:

(Click here for original document)

It is important to understand that this is not a “proof-of-concept” attack, this is actually occurring, and has resulted in attempted transfers ranging from $400,000 and $900,000.

One of the unique indicators of the attack is that either just prior to or just after the attack, the institution’s website is targeted by a denial of service attack which is designed to slow or deny access to the FI’s website, distracting institution employees and preventing or delaying them from detecting the fraudulent transactions. They recommend that institutions monitor for spikes in website traffic that may indicate the beginning of the attack.

The alert also lists 17 best practice recommendations for financial institutions designed to prevent and detect this (and similar) attacks. It is not surprising that the first 5 recommendations address the weakest link; the employee. I previously identified the employee as the biggest single risk to information security, and employee training as a trend for 2012. Many of the other recommendations should be familiar to most FI’s; restrict user access rights and login times, review Anti-malware and Anti-virus defenses, implement anomaly detection, and utilize IPS and “white-lists” to prevent connections to suspicious sites. They also recommend that institutions strongly consider (their words, my emphasis) implementing out-of-band authentication for wire authorization. This is where the final authentication approval is send back to the originator via a communication channel other than the one used to initiate the transaction. This was also one of the recommendations from the FFIEC in their authentication supplement released last year.

In my opinion there are 2 controls financial institutions can implement now that will do more than any other to significantly reduce the incidence of fraudulent transactions. The first is out-of-band authentication, and the other is utilizing a secure DNS service, similar to this.

22 Dec 2011

From the Field Tom Hinkel 0 comment

FDIC offers “Insight” on Mobile Banking

Although not considered official supervisory guidance, the most recent FDIC Supervisory Insights newsletter offers an instructive early look into how the agency might examine this emerging electronic banking delivery method in the future. (Before you tune out and decide to wait for the formal guidance, remember it was the Winter 2009 issue that first introduced us to the concept of the Enterprise-wide risk assessment as the preferred replacement for the traditional information security risk assessment. I consider these Supervisory Insight newsletters to be a pretty accurate peek into the regulatory crystal ball.)

The article is titled “Mobile Banking: Rewards and Risks”, and is a fairly deep dive into this relatively new banking service. Mobile banking is defined as the use of a mobile device, commonly a cell phone or tablet computer, to conduct banking activities. The article starts by discussing the current, and estimated future, market for this service, quoting a survey placing the potential adoption of mobile banking at 38 million households by 2015. Clearly, if institutions have not already considered adopting this delivery method, they certainly will in the near future. They separate the mobile service offerings into 3 broad categories based on the delivery method:

Text messaging/short message service (SMS)
Mobile-enabled Internet browser
Mobile applications (apps)

They then discuss the channel-specific mobile banking risks, and this was one of the most interesting parts of the article for me:

A recent study looked at the security of four types of mobile applications – financial services, social networking, productivity, and retail. The study focused on the types of sensitive data that mobile applications store on the device and whether these data were stored securely. Each application was rated “Pass,” “Warn,” or “Fail.” A “Pass” rating means sensitive data are not stored on the device or are encrypted. A “Warning” rating means certain data are stored on the device, but this does not put the user at significant risk of fraud. A “Fail” rating indicates sensitive data, such as account numbers and passwords, are stored on the device in clear text, placing the user at an increased risk of identity theft or other financial fraud.

As you can see, although financial institutions had the highest “pass” rate for mobile applications, they also had uncomfortably high “warn” and “fail” rates. (Also note the extremely high “fail” rates for social networking apps…this only confirms my concerns.) Although they don’t go into great detail on the availability and proper use of controls to mitigate the risks, they do make the point that proper vendor management is key. This is particularly true for community institutions who rely heavily, and almost exclusively, on the built-in controls provided by their product’s vendor.

But they also refer to the updated FFIEC Authentication guidance, stating that it “applies to mobile banking“. This is a bit of a news flash, as the term “mobile banking” is not specifically mentioned anywhere in the updated guidance. In fact this was one of the major criticisms of the update when it was released (although I disagreed). I think it’s clear now that the FFIEC intended for the updated guidance to be broad enough include new and emerging technology, and that we shouldn’t expect a new update every time technology changes. This also means that you should include mobile capabilities in your Electronic Banking risk assessment, as well as the associated controls.

So consider this an early Christmas present from the FDIC, and make sure to incorporate the mobile banking risk management concepts discussed in this article into your electronic banking risk assessment. In summary:

Financial institutions are challenged to ensure their mobile banking service is designed and offered in a secure manner, and customers are made aware of steps they can take to protect the integrity of their mobile banking transactions. (Edit – so does making customers aware mean mobile banking customer training will be a requirement?)

31 Aug 2011

Hot Topics Tom Hinkel 0 comment

Online Transactions – Defining “Normal”

I’ve gotten several inquiries about this since I last posted so I thought I’d better address it. The new FFIEC authentication guidance requires you to conduct periodic risk assessments, and to apply layered controls appropriate to the level of risk. Transactions like ACH origination and interbank transfers involve a generally higher level of risk to the institution and the customer, and as such require additional controls. But here’s the catch…given the exact same product with the exact same capabilities one customer’s normal activity is another customer’s abnormal. So defining normal is critical to identifying your abnormal, or “high-risk”, customers.

Most Internet banking software has built-in transaction monitoring or anomaly detection capabilities, and vendors that don’t are scrambling to add it in the wake of the guidance. As the guidance states:

“Based upon the incidents the Agencies have reviewed, manual or automated transaction monitoring or anomaly detection and response could have prevented many of the frauds since the ACH/wire transfers being originated by the fraudsters were anomalous when compared with the customer’s established patterns of behavior.“

So automated anomaly detection systems can be a very effective preventive, detective and responsive control. But I think there is a very real risk that a purely automated system may not be enough, and may even make the situation worse in some cases. For one thing, any viable risk management solution must strike a balance between security and usability. A highly secure automated anomaly detection and prevention system may be so tightly tuned that it becomes a nuisance to the customer or a burden to the institution. Customers are already reluctant to accept any constraints on usability, even if they can be presented as in their best interest. And if your requirements are just a little bit more than your competitor, you risk losing the customer to them. Interesting paradox…you implement additional controls to protect them, and lose them to a (potentially) less secure competitor!

But another way a purely automated solution may not achieve the desired result is that it may actually lull the institution into a false sense of security. I’ve already heard this in my discussions with our customers…”My vendor says they will fully comply with the new guidance, so I’m counting on them.” And indeed the vendors are all saying “Don’t worry, we’ve got this…”. But do they? In at least one incident, transaction monitoring did not stop an account take-over because according to the automated systems the fraudulent transactions were all within the range of “normal”.

So what more should you do? One thing is to make sure that you don’t rely solely on your vendor to define “normal”. Just as with information security, you can, and (because of your reliance on the vendor) should outsource many of the risk management controls. But since you can not outsource the responsibility for transaction security, you must take an active role with your vendor by sharing responsibility for monitoring. One way to do this is to participate in setting the alert triggers. For example, high account inquiries may trigger an automated anomaly alert, but really don’t carry a high risk of loss. (However, they could be indicative of the early stages of an account takeover, so they shouldn’t be completely ignored either.) On the other hand, a slight increase in interbank transfers may not trigger an alert, but could carry a potentially large loss. Rank the capabilities of each product by risk of loss, and work with your vendor to set anomaly alerts accordingly.

Once you’ve established “normal” ranges for your products by capability, and set the anomaly triggers, your vendor should be able to generate reports for you showing deviations from normal for each product. The next step is to separately assess each customer that falls outside those normal ranges. Anomaly triggers for these customers should necessarily be set more tightly, and your vendor should be able to provide deviation reports for those as well. By regularly reviewing these reports you are demonstrating a shared security responsibility approach, and most of all, demonstrating an understanding of both the letter and spirit of the guidance.

Remember, although your vendor can help, “normal” transaction frequency and dollar amounts must be defined by you based on your understanding of the nature and scope of your on-line banking activities.

22 Aug 2011

Hot Topics Tom Hinkel 0 comment

Risk Assessing Internet Banking – Two Different Approaches

One of the big “must do” take-aways from the updated FFIEC Authentication Guidance was the requirement for all institutions to conduct risk assessments. Not just prior to implementing electronic banking services, but periodically throughout the relationship if certain factors change, such as:

changes in the internal and external threat environment, including those discussed in the Appendix to this Supplement;
changes in the customer base adopting electronic banking;
changes in the customer functionality offered through electronic banking;
and actual incidents of security breaches, identity theft, or fraud experienced by the institution or industry.

The guidance also mandated annual re-assessments if none of these previous factors change, but given the increasingly hostile on-line environment it’s really a question of ‘when’ actual incidents occur, not ‘if’. That being the case, if you only update your risk assessment annually the regulators could reasonably take the position that you’re not doing it often enough.

So risk assessments must occur “routinely”, but what is the best way to approach them? Although the guidance does not specify a particular approach, it might be instructive to take a look at what the FFIEC has to say about Information Security and Disaster Recovery, both of which require (separate) risk assessments. In both cases the FFIEC encourages that you approach the task by analyzing the probability and impact of the threat, not the nature of the threat. This makes perfect sense. By shifting the focus of your risk assessment off of the moving target of the constantly changing threat environment, and on to strengthening the overall security of your Internet-based services¹, you can build a secure transaction environment that will scale and evolve as you grow. Here is the critical difference between the two approaches; if you take a “nature-of-the-threat” approach, you must list every possible specific threat both existing and reasonably anticipated². It doesn’t work very well for disaster recovery or information security risk assessments, and in my opinion it is not the best approach for Internet banking either.

Although certainly not the only way to do the risk assessment, I would recommend a 2-step approach that addresses most if not all of the updated FFIEC guidelines. Step 1 of this approach is to assess the overall risk of your products by listing the capabilities and controls for each one. As a part of that step you would determine how many customers use the product, and then also how many of those you consider to be “high-risk” as defined by high transaction frequency and high dollar amount. In Step 2 you should list those high-risk customers you identified in step 1 separately, along with the associated controls you plan to implement for each one.

Again, there is no one single way to do this correctly. Whatever you do should be consistent with the size and complexity of your institution, and the nature and scope of your Internet banking operations. Good luck!

¹ Although other regulations and guidelines address financial institutions’ responsibilities to protect customer information and prevent identity theft, this guidance specifically addresses Internet authentication, and should be the primary focus of this risk assessment.

² You must still re-assess if either you or the industry experience any actual incidents, but instead of adding a new threat to your risk assessment, you simply determine if your existing control environment is sufficient to address the impact of the threat. In other words, you re-assess for the impact, not the nature of the threat.

13 Jul 2011

Hot Topics Tom Hinkel 2 Comments

Interpreting The New FFIEC Authentication Guidance – 5 Steps to Compliance

We’ve all now had a couple of weeks to digest the new guidance, and what has emerged is a clearer understanding of what the guidance requires…and what it doesn’t. But before we can begin to formulate the specific compliance requirements, we have to interpret what the guidance is actually saying…and what it isn’t. And along the way I’ll take the liberty of suggesting what it should have required…and what it should have said.

The release consists of 12 pages total, but only a couple of pages are directly relevant to your compliance efforts. Pages 1 and 2 talk about the “why”, and pages 6 through 12 discuss the effectiveness (or ineffectiveness) of various authentication techniques and controls. But beginning on page 3 (“Specific Supervisory Expectations”), through the top of page 6, is where the FFIEC details exactly what they expect from you once compliance is required in January of next year. Since this is the real “meat” of the guidance, let’s take a closer look at what it says, and try to interpret what that means to you and your compliance efforts.

Here are the requirements:

Risk Assessments, conducted…
- …prior to implementing new electronic services
- …anytime “new” information becomes available, defined as:
  - Changes in the internal and external threat environment, i.e. if you become aware of any new threats
  - If your customer base changes, i.e. you take on a higher risk class of customer
  - Changes in the functionality of your electronic banking product, i.e. your vendor increases the capabilities of the product
  - Your fraud experience, i.e. you experience an account takeover or security breach
- …at least every 12 months, if none of the preceding occurs

According to the guidance, your risk assessment must distinguish “high-risk” transactions from “low-risk” transactions. This is not as simple as saying that all retail customers are low-risk, and all commercial customers are high-risk. In fact, the FFIEC defines a “high-risk” transaction as “involving access to customer information or the movement of funds to other parties.” By this definition almost ALL electronic transactions are high-risk! A retail customer with bill-pay would qualify as high-risk because they access customer information (their own), and make payments (move funds) to other parties. So perhaps the way to interpret this is that your risk assessment process should distinguish between “high-risk” and “higher-risk”. This actually makes sense, because the frequency and dollar amounts of the transactions are what should really define risk levels and drive your specific layered controls, which is the next requirement.

Layered Security Programs (also known as “defense-in-depth”)

This concept means that controls should be layered so that gaps or weaknesses in one control (or layer of controls) are compensated for by other controls. Controls are grouped by timing (where they fit into a hierarchy of layers), and also by type. So taken from the top layer down:

Preventive- This is the first layer, the top of the hierarchy, and for good reason…it’s alwaysbest to prevent the problem in the first place. These are by far the most important, and should comprise the majority of your controls. Some examples drawn from the guidance are:
1. Fraud detection and monitoring (automated and manual)
2. Dual customer authorization and control
3. Out-of-Band (OOB) verification of transactions
4. Multi-factor authentication
5. “Positive Pay”, or payee white-lists
6. Transaction restrictions such as time-of-day, dollar volume, and daily volume
7. IP restrictions, or black lists
8. Restricting account administrative activity by the customer
9. Customer education (this was actually listed as a requirement, but it’s really a preventive control)
Detective – Positioned directly below preventive in the hierarchy because detecting a problem is not as optimal as preventing it. However they provide a safety net in the event preventive controls fail. Often a preventive control can also have a detective component to it. For example, control # 2 above can both require dual control, and also report if authentication fails on either login. Same with #4…if payment is blocked because the payee is not “white-listed (or is blocked by IP restrictions as in control #6), the institution can be automatically notified. In fact, most preventive controls also have a detective element to them.
Corrective / Responsive – An important step to make sure the event doesn’t re-occur. This typically involves analyzing the incident and trying to determine what control failed, and at what level of the hierarchy. However, just as many preventive controls can detect, the best controls have the ability to self-respond as well. For example, the same control that requires dual control, and reports on failed login, can also lock the account. In fact, just as before, many preventive controls also have a responsive capability.

To properly demonstrate compliance with the layered security program requirement, you should have controls at each of the three layers. Simply put, higher risk transactions require more controls at each layer.

OK, now that you’ve classified your controls as preventive, detective and corrective (preferably a combination of all three!), you’ll need to determine the control type; overlapping, compensating, or complimentary.

Overlapping controls are simply different controls designed to address the same risk. Sort of a belt-and-suspenders approach, where if one controls misses something, a second (or third, or forth) will catch it. Again, higher risk transactions should have multiple overlapping controls and they should exist at each layer. So you should have overlapping preventive controls, as well as overlapping detective and even corrective controls. The idea is that no single failure of any control at any layer will cause a vulnerability.

Compensating controls are those where one control makes up for a known gap in another control (belt-or-suspenders). This gap may exist either because it is impossible or impractical to implement the preferred control, or because of a known shortcoming in the control. An example might be that you feel transaction restrictions (#5 above) are appropriate for a particular account, but the customer requires 24/7 transaction capability. To compensate for this, you might require that positive pay and IP restrictions be implemented instead.

Complimentary controls are often overlooked (indeed they aren’t mentioned at all in the guidance), but in my experience they are the one of the most effective controls…and the most common control to fail. Complimentary controls (sometimes called “complimentary user controls”) are those that requires action on the part of the customer. For example, the dual authentication control (#2 above) can be very effective IF the customer doesn’t share passwords internally. Similarly, customer education (#8) requires cooperation from the customer to be effective. Given the partnership between the institution and the customer (and recent litigation), I’m surprised there isn’t more discussion about the importance of complimentary controls. (I addressed some of these issues here.)

In summary, demonstrating compliance to the spirit and letter of the guidance is simply a matter of following these 5 steps:

Risk rank your on-line banking activities from higher to lower based on account type (consumer or commercial), and by frequency and dollar amount.
Apply overlapping, compensating and complimentary controls (# 1 – #9 above) in…
…preventive, corrective, and detective layers,…
…commensurate with the risk of the transaction. Higher risk = more controls.
Periodically repeat the process.

Nothing to it, right?! Well not exactly, but hopefully this makes the guidance a bit clearer and easier to follow.

By the way, although I have been somewhat critical of the updated guidance, I don’t share the same criticism of others that the guidance should have gone further and addressed mobile banking, or other emerging technology. Frankly if new guidance was issued every time technology progressed we’d have a couple of updates every year. Instead, focus on the fundamentals of good risk management. After all, there is a good reason why the FFIEC hasn’t had to update their guidance on information security since 2006 (even though the threat landscape has changed dramatically since then)….they got it right the first time!

12 Next →