FFIEC – Page 6 – Compliance Guru

16 Jul 2012

Hot Topics Tom Hinkel 0 comment

Commercially UNreasonable Security

So an appellate court has just reversed the PATCO court ruling, essentially deciding against the financial institution. They ruled that the banks’ security procedures were commercially UN-reasonable.

To summarize, a commercial e-banking customer (PATCO Construction) experienced a financial loss due to an account take-over. They sued the bank to recover the loss, claiming the bank used poor security. The original ruling was in favor of the bank. This ruling was in favor of the customer, and has major implications for all financial institutions as they navigate their way through the increasing risk and increased regulatory requirements of Internet banking.

The entire ruling is worth a read, but here are a few of the highlights from my perspective:

In the end, it wasn’t just a single control failure, but a series of failures on the part of the Bank that led to the ruling. One example is that the Bank lowered the alert trigger for challenge questions from $100,000 to $1, effectively requiring all transactions to require an additional authentication step. The Bank undoubtedly felt they were increasing the safety of all transactions by taking this step, but it actually had the opposite effect. By requiring challenge questions for all transactions they substantially increased the number of chances the criminals had to intercept the correct challenge responses.
The on-line banking product (NetTeller Premium) and provider (Jack Henry & Associates) offered adequate options for on-line transaction security, but not all options were enabled by the Bank. And…
…of those security options offered by the Bank, not all were accepted by the customer. And…
…of those offered and accepted, some were ignored. For example the anomaly detection capabilities worked properly, and automated risk profiling correctly generated abnormally high risk scores for the fraudulent transactions, but no action was taken by the Bank to block them.
The definition of “commercially reasonable” has evolved from the initial ruling favoring the customer, to the most recent one. Both rulings make several references to Article 4A of the UCC (Uniform Commercial Code). The initial ruling stated that because the customer signed the agreement, they implicitly agreed to the security measures, effectively rendering them commercially reasonable. However the most recent ruling quotes from UCC 4A and states “[t]he standard is not whether the security procedure is the best available. Rather it is whether the procedure is reasonable for the particular customer and the particular bank.” Therefore…
…a “one-size-fits-all” approach will not work, institutions MUST tailor their controls to the risks of the transaction.

But here is the most significant take-away for me, and the one with the biggest implication for financial institutions. The judge ruled that based on the UCC 4A official comments on Section (1)(b), if and when the security procedures are deemed commercially reasonable, the burden then shifts to the customer…

“…to supervise its employees to assure compliance with the security procedure and to safeguard confidential security information and access to transmitting facilities so that the security procedure cannot be breached.”

So, all you have to do is risk assess the customer and transactions and employ layered security suitable to the risk, and then the legal and financial liability shifts to the customer, right? Maybe not. According to the FFIEC Internet Authentication update, one of the controls an institution may include (translated from ‘FFIEC-speak’ as SHOULD include) in its layered security program is a “Customer Awareness and Education” program. Which means you are still on the hook unless you can document that you also maintain a customer awareness program AND your customers are actually being trained. (As I mentioned here, you may also want to add a summary of your customer awareness program to your annual report to the Board of Directors).

I’m certain we’ll see more lawsuits on this matter and future rulings may go either way, but the risk is real and immediate so don’t wait for the courts to sort things out. Here is what you need to do:

Complete the risk assessment if you haven’t already. Define high risk transactions, and identity high risk customers.
Implement a layered security program. Make sure you know and understand all of the controls available from your e-banking product vendor. Vendors are adding controls all the time to address the evolving threat environment.
Make sure your customers know and understand all of the controls you’ve made available to them. If they resist or refuse a particular control that you’ve recommended, have them sign-off that they understand and accept the increased risk.
Educate your customers, initially and periodically throughout the relationship, and regardless of whether they resist. Regardless of the quantity and sophistication of your technical controls, the customer is, and will always remain, the weakest link in the security chain.

10 Jul 2012

Hot Topics Tom Hinkel 0 comment

FFIEC issues Cloud Computing Guidance

Actually the document is classified as “for informational purposes only”, which is to say that it is not a change or update to any specific Handbook and presumably does not carry the weight of regulatory guidance. However, it is worth a read by all financial institutions outsourcing services because it provides reinforcement for, and references to, all applicable guidance and best practices surrounding cloud computing.

It is a fairly short document (4 pages) and again does not represent a new approach, but rather reinforces the fact that managing cloud providers is really just a best practices exercise in vendor management. It makes repeated reference to the existing guidance found in the Information Security and Outsourcing Technology Services Handbooks. It also introduces a completely new section of the InfoBase called Reference Materials.

The very first statement in the document pretty well sums it up:

“The (FFIEC) Agencies consider cloud computing to be another form of outsourcing with the same basic risk characteristics and risk management requirements as traditional forms of outsourcing.”

It then proceeds to describe basic vendor management best practices such as information security and business continuity, but one big take-away for me was the reference to data classification. This is not the first time we’ve seen this term, I wrote about examiners asking for it here, and the Information Security Handbook says that:

“Institutions may establish an information data classification program to identify and rank data, systems, and applications in order of importance.”

But when all your sensitive data is stored, transmitted, and processed in a controlled environment (i.e. between you and your core provider) a simple schematic will usually suffice to document data flow. No need to classify and segregate data, all data is treated equally regardless of sensitivity. However once that data enters the cloud you lose that control. What path did the data take to get to the cloud provider? Where exactly is the data stored? Who else has access to the data? And what about traditional issues such as recoverability and data retention and destruction?

Another important point made in the document, and one that doesn’t appear in any other guidance, is that because of the unique legal and regulatory challenges faced by financial institutions, the cloud vendor should be familiar with the financial industry. They even suggest that if the vendor is not keeping up with regulatory changes (either because the are unwilling or unable) you may determine on that basis that you cannot employ that vendor.

The document concludes by stating that:

“The fundamentals of risk and risk management defined in the IT Handbook apply to cloud computing as they do to other forms of outsourcing. Cloud computing may require more robust controls due to the nature of the service.”

And…

“Vendor management, information security, audits, legal and regulatory compliance, and business continuity planning are key elements of sound risk management and risk mitigation controls for cloud computing.”

…as they are for all outsourced relationships!

03 Jul 2012

From the Field Tom Hinkel 0 comment

“Operational Risk Increasing”

In a recent speech to the Exchequer Club¹, Thomas J. Curry, the new head of the OCC, stated that although asset quality has improved, charge-off rates have fallen, and capital now stands at its highest level in a decade, another type of risk is gaining increasing prominence; Operational Risk.

“Some of our most seasoned supervisors, people with 30 or more years of experience in some cases, tell me that this is the first time they have seen operational risk eclipse credit risk as a safety and soundness challenge. Rising operational risk concerns them, it concerns me, and it should concern you.“

In fact, the OCC considers it currently to be at the top of the list of safety and soundness issues for the institutions they supervise. Earlier this year I wrote about how risk assessments were one of the compliance trends of 2012, and how regulators are now asking about things like strategic risk and reputation risk and operational risk, and expecting that these risks are assessed alongside the more traditional categories like privacy and security.

So the question is: What exactly is operational risk, and how can financial institutions effectively address it? The FFIEC defines it this way:

“Operational risk (also referred to as transaction risk) is the risk of loss resulting from inadequate or failed processes, people, or systems. The root cause can be either internal or external events. Operational risk is present across all business lines.”

Furthermore, because the implications of operational risk extend to all other risks….

“Management should distinguish the operational risk component from other risks to enable a stronger focus on operational risk mitigation.“

If you are still a bit confused about exactly what operational risk looks like, you are not alone. Because it exists in all business lines and manifests itself in every other risk, it is one of the most difficult risks to assess. In other words, it’s everywhere…and affects everything!

Simply put (and assuming your policies and procedures are adequate), most of the time operational risk can be defined as a failure to adhere to your own internal policies and procedures. In other words, if you don’t do what you say you will do, or you don’t do it the way you say you’ll do it, something will fail as a result. Whether a it’s a process, a control, a system, or a risk model…if they are in place and operational, but either flawed or not followed, operational risk is the result.² But here is the kicker, even if your processes/procedures/models, etc. are flawless and followed to the letter, if you can’t document that they are, you may still have a high operational risk finding in your next safety and soundness examination.

The best way to address operational risk is to implement an internal control self-assessment process to assure that risk management controls are adequate, in place, and functioning properly. Reporting will document that your day-to-day practices follow your written procedures. Finally, make sure all business decisions reflect the goals and objectives of the strategic plan, and report to the Board on a regular basis.

In summary, integrate assessment of operational risk into your risk management process, and expect to hear more about it from the regulators in the future. And don’t think that because you aren’t regulated by the OCC you won’t see this trend. After all, as Mr. Curry stated:

“As regulators, one of our most important jobs is to identify risk trends and bring them to the industry’s attention in a timely way. No issues loom larger today than operational risk in all its dimensions, the manner in which all risks interact, and the importance of managing those risks in an integrated fashion across the entire enterprise.”

[poll id=”3″]

¹ The Exchequer Club is comprised of senior professionals from trade associations, federal regulatory agencies, law firms, congressional committees and national press with a primary interest in national economic and financial policy.

² Business Continuity Planning uses a slightly different definition of operational risk. Since the basic assumption of a BCP is that your processes and systems have already failed because of a disaster, operational risk manifests itself in the additional overhead that the alternative recovery processes and procedures temporarily impose on your organization. Of course if your BCP is inadequate, failed processes will be the result.

25 Apr 2012

Hot Topics Tom Hinkel 0 comment

FDIC Supervisory Letter Issued on Critical Service Provider

(NOTE: Although the vendor in question has been publicized by the NCUA, I will not name it here because it is not relevant. If you currently contract with the vendor you know who it is, and you need to know how to respond to the letter. If you don’t, you’ll need to know how to respond in case it happens to a critical vendor of yours at some point.)

What if you received this letter from the FDIC on one of your most critical service providers (summarized and redacted)?

“Dear Board of Directors,

Enclosed is a copy of the Information Technology (IT) Supervisory Letter based on the interim review of (your vendor). We are sending you this Supervisory Letter for your evaluation and consideration in managing your vendor relationship…I encourage you to review the Supervisory Letter as it discusses some regulatory concerns that require corrective action by (your vendors’) management and Board of Directors.

Sincerely,

FDIC Regional Director”

The letter states in part:

“(Vendors’) Executive Management supervision and control over the Risk Management (RM) and Information Security (IS) functions are unsatisfactory. Additionally, the Board of Directors (BOD) does not provide sufficient direction and oversight for management responsibilities, as well as for independent review in these areas by Internal Audit (IA). The breadth and severity of weaknesses noted at this IR stem from management’s failure to adequately address previously identified systemic issues and to take proactive measures to mitigate the identified systemic risks. These weaknesses had exposed serviced financial institutions to increased risk, and have raised concerns regarding management’s ability to establish and enforce effective information security measures commensurate with the needs of (vendor).”

So the FDIC conducted an IT Examination on the service provider. Nothing new there…IT service providers are subject to the same regulatory oversight as financial institutions, and even have their own Examination Handbook*. However, in this case the exam uncovered significant material weaknesses in their audit, management and IT controls. Weaknesses so severe that the FDIC felt it necessary to proactively notify all institutions under their regulatory responsibility that utilize the provider.

Since the FDIC stated that they are sending the letter for “your evaluation and consideration“, they clearly expect you to take specific action on this matter. Don’t be surprised to see them asking for your formal response during your next visit from them. So here is what you’ll need to do:

The first thing you’ll want to do is call a meeting with the group you use to manage your vendor relationships. If you haven’t assigned vendor management responsibility to a management committee (as opposed to an individual), do so. IT Steering or Audit is a logical choice. Formally document in the committee that “the examiner’s letter represents certain concerns that will cause us to reevaluate the vendor, reassess the residual risk, and consider implementing additional compensating controls”.
Request, review and evaluate the vendor’s response to the examiners letter. Determine whether the response is sufficient to address your concerns. If not, consider implementing the following additional compensating controls:

Accelerate the normal annual due diligence process by requesting more frequent financial statements (quarterly instead of annual).
Request that vendor provide additional 3^rd party security reviews other than SSAE 16 if possible (i.e. SOC 2, PEN tests, etc.). The SOC 2 is a good choice, as it directly addresses controls related to privacy, security, confidentiality, integrity and availability…all the things that are important to you.
Have legal review existing vendor contracts for possible breach of contract claims.
Consider adding a “right to audit” clause in future contracts.
Become active (or more active) in vendor user groups. The intent is to stay close to the situation, and possibly influence them to release additional 3^rd party reviews (such as SOC 2).

It is important to take action even if you are in a long term contract with the vendor, or if the vendor would be difficult to replace. And you can’t take the position that since you can’t control what the vendor does, you’ll simply have to go along…that it’s not your problem to solve. Guidance makes it clear that “institutions should ensure the service provider’s physical and data security standards meet or exceed standards required by the institution.” So for all intents and purposes, the vendor’s deficiencies are your problem.

*According to the FFIEC:

The federal financial regulators have the statutory authority to supervise all of the activities and records of the financial institution whether performed or maintained by the institution or by a third party on or off of the premises of the financial institution.

The decision to examine a service provider is at least partially based on the number of Bank Service Company Act (BSCA) filings the regulators receive on the provider. I explain this here, and make the point that because the definition of a “Service Company” has expanded, more service providers can expect more examinations in the future.

09 Apr 2012

Hot Topics Tom Hinkel 1 Comment

FFIEC Handbook Update – Outsourcing

The FFIEC has just added a section to the Outsourcing Technology Services IT Examination Handbook, and it should be required reading for financial institutions as well as any managed service providers. The new section is Appendix D: Managed Security Service Providers, and it is the first significant change to the Handbook since it was released in 2004. It addresses the fact that because of the increasing sophistication of the threat environment, and the lack of internal expertise, a growing number of financial institutions are (either partially or completely) outsourcing their security management functions to unaffiliated third-party vendors.

Because of the critical and sensitive nature of these security services, and the loss of control when these services are outsourced, the guidance stresses that institution must address additional risks beyond their normal vendor management responsibilities. Specifically, more emphasis must be placed on the contract and on oversight of the vendor’s processes, infrastructure, and control environment.

The most interesting addition to the guidance for me is the “Emerging Risks” section, which is the first time the FFIEC has addressed cloud computing. Although it is addressed from the perspective of the service provider, it defines cloud computing this way:

“…client users receive information technology services on demand from third-party service providers via the Internet “cloud.” In cloud environments, a client or customer will relocate their resources such as data, applications, and services to computing facilities outside the corporate firewall, which the end user then accesses via the Internet.”

Any data transmitted, stored or processed outside the security confines of the corporate firewall is considered higher risk data, and must have additional controls. This would seem to infer that data in the cloud should be classified differently in your data-flow diagram, and have a correspondingly higher protection profile.* It will be interesting to see if this will be the FFIEC’s approach when and if they address cloud computing in the future.

The guidance also has a useful MSSP Engagement Criteria matrix that institutions can use to evaluate their own service providers, as well as a set of MSSP Examination Procedures, which service providers (like mine) can use to prepare for future examinations. In summary, financial institutions would be wise to familiarize themselves with the new guidance, after all to quote from the last line;

“As with all outsourcing arrangements FI management can outsource the daily responsibilities and expertise; however, they cannot outsource accountability.”

* A protection profile is a description of the protections that should be afforded to data in each classification.

09 Apr 2012

Hot Topics Tom Hinkel 1 Comment

FFIEC Handbook Update – SAS 70 Transition

The FFIEC has just updated their online IT Examination InfoBase to address the AICPA phase-out of the SAS 70 reporting format. All references to “SAS 70” have now been replaced, and the SAS 70 sections of the Audit and Information Security Handbooks have been completely removed. Previously there were a total of 31 references to “SAS 70” in 8 different Handbooks.

I wrote about this a number of times, and speculated about when the FFIEC would update their Handbooks, and what would replace the term. For the most part “SAS 70” has been replaced with “SSAE 16”, but there are also references to the SOC 2 and SOC 3 reports, as well as a more generic “other third-party review processes”. I’m happy to see the FFIEC is allowing for more flexibility in the choice of vendor control reports they consider acceptable. I’ve also made the case that although this does make the vendor management process a bit more challenging, institutions should welcome the transition.

← Previous 1…567…15 Next →