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:
- Fraud detection and monitoring (automated and manual)
- Dual customer authorization and control
- Out-of-Band (OOB) verification of transactions
- Multi-factor authentication
- “Positive Pay”, or payee white-lists
- Transaction restrictions such as time-of-day, dollar volume, and daily volume
- IP restrictions, or black lists
- Restricting account administrative activity by the customer
- 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!