Tag: FFIEC

12 Nov 2012
From the Field Tom Hinkel 0 comment

The Financial Institutions Examination Fairness and Reform Act (and why you should care)

Although it’s currently stuck in committee, financial institutions should be aware of this bill and track it closely in the next congressional session.  There are actually 2 bills, a House (H.R. 3461) and a Senate (S. 2160) version, both  containing similar provisions.  The House bill has 192 sponsors and the Senate version has 14 sponsors, and both bills have supporters from both political parties.  Here is a summary of the bill, and why you might want to support it as well:

What it does:

  • Amends the Federal Financial Institutions Examination Council (FFIEC) Act of 1978 to require a federal financial institutions regulatory agency to make a final examination report to a financial institution within 60 days of the later of:
(1) the exit interview for an examination of the institution, or
(2) the provision of additional information by the institution relating to the examination.
  • Sets a deadline for the exit interview if a financial institution is not subject to a resident examiner program.
  • Sets forth examination standards for financial institutions.
  • Prohibits federal financial institutions regulatory agencies from requiring a well capitalized financial institution to raise additional capital in lieu of an action prohibited by the examination standards.
  • Establishes in the Federal Financial Institutions Examination Council an Office of Examination Ombudsman. Grants a financial institution the right to appeal a material supervisory determination contained in a final report of examination.
  • Requires the Ombudsman to determine the merits of the appeal on the record, after an opportunity for a hearing before an independent administrative law judge.
  • Declares the decision by the Ombudsman on an appeal to:
(1) be the final agency action, and
(2) bind the agency whose supervisory determination was the subject of the appeal and the financial institution making the appeal.
  • Amends the Riegle Community Development and Regulatory Improvement Act of 1994 to require:
(1) the Consumer Financial Protection Bureau (CFPB) to establish an independent intra-agency appellate process in connection with the regulatory appeals process; and
(2) appropriate safeguards to protect an insured depository institution or insured credit union from retaliation by the CFPB, the National Credit Union Administration (NCUA) Board, or any other federal banking agency for exercising its rights.

Why you should care:

In addition to the provisions for more expeditious exit interviews and final reports, the Bills provide for certain changes to “examination standards”.   The standards pertain primarily to the non-accrual treatment of commercial loans and their effect on capital, and they also redefine “Material Supervisory Determination” as “any matter requiring attention by the institution’s management or board of directors”.  These are all generally good things for financial institutions, but I think the most significant provisions (and the ones with the biggest positive impact) are the provisions that establish the Office of Examination Ombudsman within the FFIEC.

The current appeal process for contested examination findings was recently re-addressed by the FDIC here (and I reacted to it here).  In summary, if you currently have a disagreement with the FDIC about any “material supervisory determination”, which includes anything that affects CAMELS ratings and IT ratings (the full list is here, search for “D. Determinations Subject to Appeal”) you must stay within the FDIC for resolution.  And this includes the current Office of the Ombudsman, which is also a part of the FDIC.

The agency makes it clear that they believe the appeals process is “independent of the examination function and free of retribution or other retaliation”, but whether it is or isn’t, the fact that the process never leaves the FDIC deters many financial institutions from pursuing the appeals process in the first place.  I believe moving the process to the FFIEC at least improves the perception of independence and objectivity, which may encourage more institutions to be more inclined to challenge examination findings.  What are your thoughts?

[poll id=”6″]

Again, I encourage you to learn about these bills for yourself and take a position. To support the Senate bill, go HERE.  To support the House bill, go HERE.  And feel free to share this post.  If enough people support it perhaps we’ll see some progress in the next congressional session!

01 Nov 2012
Hot Topics Tom Hinkel 0 comment

FFIEC Updates Technology Service Provider Guidance

Just posted, the new Booklet rescinds and replaces the previous one issued in March 2003, and is the first Booklet replacement since Retail Payment Systems in 2010.  In general this is not so much a complete re-write as a reinforcement of the importance the agency places on strong vendor management, which is a concept that we’ve seen from other recent FFIEC releases and updates.

So with all the similarity between this new publication and the one almost 10 years ago, I think it’s instructive to focus on the differences between the two to see how the FFIEC’s thinking has evolved.  It also allows the institutions affected to know exactly what they need to change or adjust to remain in compliance.

First of all, both Booklets state the following:

“A financial institution’s use of a TSP (technology service provider) to provide needed products and services does not diminish the responsibility of the institution’s board of directors and management to ensure that the activities are conducted in a safe and sound manner and in compliance with applicable laws and regulations…”

and perhaps for extra emphasis the new Booklet adds the following verbiage:

“…just as if the institution were to perform the activities in-house.”

Nothing new here, all institutions are acutely aware that they bear full responsibility for the confidentiality, integrity and availability of their customer’s data regardless of where it may reside.  This re-statement is perhaps insignificant by itself, but interesting when taken in combination with the next sentence:

Old guidance – “Financial institutions should have a comprehensive outsourcing risk management process to govern their TSP relationships.”

New guidance – “Agencies expect financial institutions to have a comprehensive, enterprise risk management process in place that addresses vendor management for their relationships with TSPs.”

What is significant here is the addition of the word “enterprise” to the risk management process, indicating that you must acknowledge that vendors carry multidimensional risks.  These risks include not just operational risk (risk of failure), but strategic risk, regulatory risk and reputation risks as well.

However to me the most significant change in the guidance is in the sentence beginning with “…(the risk management) process should include…”, because this is what the regulators will expect from you.  Compare these:

Old guidance – “Such processes should include risk assessment, selection of service providers, contract review, and monitoring of service providers.”

New guidance – “The risk management process should include risk assessments and robust due diligence for the selection of TSPs, contract development, and ongoing monitoring of all TSPs’ performance.”

It’s clear that regulators will expect much more from your vendor risk management process going forward.  Not simply selecting a service provider, but robust due diligence in the selection process.  Not just contract review, but contract development.  And not just basic monitoring, but ongoing monitoring of all TSP’s performance.

The new guidance goes on to state that federal regulators expect technology service providers to be familiar with, and adhere to, not just this Booklet, but all 11 Booklets in the IT Examination Handbook series.  One more reinforcement that there are not 2 standards of measurement…one for financial institutions and one for vendors…but only one.  And that one same standard will be enforced by the same federal regulators that currently examine you.

The guidance goes on to describe how they will classify service providers (by size and criticality of the services they provide), and how that classification will determine who will examine them, and how often they can expect to be examined.   As far as who can expect to be examined, any service provider that provides any of the following services:

  • Core application processors
  • Electronic funds transfer switches
  • Internet banking providers
  • Item processors
  • Managed security servicers
  • Data storage servicers
  • Business continuity providers

So pretty much anyone that provides an application, system, or process that is vital to the successful continuance of a critical business activity, or anyone that interfaces with a critical business system, can expect to be examined.

Aside from being more comprehensive, the actual examination process hasn’t changed much.  Examiners will still scrutinize the AMDS (Audit, Management, Development and Acquisition, and Support and Delivery) components, and will still assign a 1 through 5 numerical score to each component with 1 representing the highest or best, and 5, the lowest rating or worst.  Examiners will then use the component scores to determine the overall composite rating.  Again, nothing new there.

So in summary, not a drastic change as much as a reiteration with amplification and clarification.  Simply put, more of the same…more regulatory expectations for your vendor management program, which means more scrutiny by the examiners (for you and for your vendors), all of which means more effort on everyone’s part!

21 Aug 2012
Hot Topics Tom Hinkel 0 comment

NIST Incident Response Guidance released

UPDATE – The National Institute of Standards and Technology (NIST) has just released an update to their Computer Security Incident Handling Guide (SP 800-61).   The guide contains very prescriptive guidance that can be used to frame, or enhance, your incident response plan.  It also contains a very useful incident response checklist on page 42.  I’ve taken the liberty of  modifying it slightly to conform to the FFIEC guidance.  It is form-fillable and available for download here.  I hope you find it useful for testing purposes as well as actual incidents.  I originally posted on this back in May 2012, here is the rest of the original post:

Although adherence to NIST standards is strictly required for Federal agencies, it is not binding for financial institutions.  However NIST publications are referred to 10 times in the FFIEC IT Handbooks, 8 times in the Information Security Handbook alone.  They are considered a best-practice metric by which you can measure your efforts.  So because of…

  1.  The importance of properly managing an information security event,
  2. The increasing frequency, complexity, and severity of security incidents,
  3.  The scarcity of recent regulatory guidance in this area, and
  4.  The relevance of NIST to future financial industry regulatory guidance,

…it should be required reading for all financial institutions.

Incident response is actually addressed in 4 FFIEC Handbooks; Information Security, Operations, BCP and E-Banking.  It’s important to distinguish here between a security incident and a recovery, or business continuity, incident.  This post will only address security incidents, but guidance states that the two areas intersect in this way:

“In the event of a security incident, management must decide how to properly protect information systems and confidential data while also maintaining business continuity.”

Security incidents and recovery incidents also share this in common…both require an impact analysis to prioritize the recovery effort.

So although there are several regulatory references to security incident management, none have been updated since 2008 even though the threat environment has certainly changed since then.  Perhaps SP 800-61 will form the basis for this update just as  SP 800-33 informed the FFIEC Information Security Handbook a few years after its release.  But until it does, proactive Information Security Officers and Network Administrators would do well to familiarize (or re-familiarize) themselves with the basic concepts.

NIST defines the incident life-cycle this way:

Each section is detailed in the guide, and worth reading in its entirety, but to summarize:

  1. Preparation – Establish an incident response capability by defining a policy (typically part of your Information Security Program), and an incident response team (referred to in the FFIEC IT Handbook as the Computer Security Incident Response Team, or CSIRT).  Smaller institutions may want to have the IT Steering Committee manage this.  Assess the adequacy of your preventive capabilities in the current threat environment, including patch management, Anti-virus/Anti-malware, firewalls, network intrusion prevention and server intrusion prevention.  Don’t forget employee awareness training…perhaps the most important preventive control.
  2.  Detection & Analysis – Determine exactly what constitutes an incident, and under what circumstances you will activate your incident response team and initiate procedures.  Signs of an incident fall into one of two categories: precursors and indicators.  A precursor is a sign that an incident may occur in the future.  An indicator is a sign that an incident may have occurred or may be occurring now.  Many of the controls listed in the preparation phase (firewalls, IPS/IDS devices, etc.) can also alert to both precursors and indicators.  The initial analysis should provide enough information for the team to prioritize subsequent activities, such as containment of the incident and deeper analysis of the effects of the incident (steps 3 & 4).
  3. Containment, Eradication & Recovery – Most incidents require containment to control and minimize the damage.  An essential part of containment is decision-making i.e., shutting down a system, disconnecting it from a network, disabling certain functions, etc.  Although you may be  tempted to start the eradication and recovery phase immediately, bear in mind that you’ll need to collect as much forensic evidence as possible to facilitate the post-incident analysis.
  4. Post-Incident Activity – Simply put, lessons learned.  It’s easy to ignore this step as you try to get back to the business of banking, but don’t.  Some important questions to answer are:
  • Exactly what happened, and at what times?
  • How well did staff and management perform in dealing with the incident? Were the documented procedures followed? Were they adequate?
  • Were any steps or actions taken that might have inhibited the recovery?
  • What could we do differently the next time a similar incident occurs?
  • What corrective actions can prevent similar incidents in the future?
  • What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

The FFIEC addresses intrusion response here, and recommends that “institutions should assess the adequacy of their preparations through testing.”  Use the checklist, and recent security incidents to train your key CSIRT personnel, and then use the full guide to fine-tune and enhance your incident response capabilities.

20 Aug 2012
Hot Topics Tom Hinkel 0 comment

Incident Response guidance – UPDATE

UPDATE – The National Institute of Standards and Technology (NIST) has just released an update to their Computer Security Incident Handling Guide (SP 800-61).   The guide contains very prescriptive guidance that can be used to frame, or enhance, your incident response plan.  It also contains a very useful incident response checklist on page 42.  I’ve taken the liberty of  modifying it slightly to conform to the FFIEC guidance.  It is form-fillable and available for download here.  I hope you find it useful for testing purposes as well as actual incidents.  Here is the original post:

Although adherence to NIST standards is strictly required for Federal agencies, it is not binding for financial institutions.  However NIST publications are referred to 10 times in the FFIEC IT Handbooks, 8 times in the Information Security Handbook alone.  They are considered a best-practice metric by which you can measure your efforts.  So because of…

  1.  The importance of properly managing an information security event,
  2. The increasing frequency, complexity, and severity of security incidents,
  3.  The scarcity of recent regulatory guidance in this area, and
  4.  The relevance of NIST to future financial industry regulatory guidance,

…it should be required reading for all financial institutions.

Incident response is actually addressed in 4 FFIEC Handbooks; Information Security, Operations, BCP and E-Banking.  It’s important to distinguish here between a security incident and a recovery, or business continuity, incident.  This post will only address security incidents, but guidance states that the two areas intersect in this way:

“In the event of a security incident, management must decide how to properly protect information systems and confidential data while also maintaining business continuity.”

Security incidents and recovery incidents also share this in common…both require an impact analysis to prioritize the recovery effort.

So although there are several regulatory references to security incident management, none have been updated since 2008 even though the threat environment has certainly changed since then.  Perhaps SP 800-61 will form the basis for this update just as  SP 800-33 informed the FFIEC Information Security Handbook a few years after its release.  But until it does, proactive Information Security Officers and Network Administrators would do well to familiarize (or re-familiarize) themselves with the basic concepts.

NIST defines the incident life-cycle this way:

Each section is detailed in the guide, and worth reading in its entirety, but to summarize:

  1. Preparation – Establish an incident response capability by defining a policy (typically part of your Information Security Program), and an incident response team (referred to in the FFIEC IT Handbook as the Computer Security Incident Response Team, or CSIRT).  Smaller institutions may want to have the IT Steering Committee manage this.  Assess the adequacy of your preventive capabilities in the current threat environment, including patch management, Anti-virus/Anti-malware, firewalls, network intrusion prevention and server intrusion prevention.  Don’t forget employee awareness training…perhaps the most important preventive control.
  2.  Detection & Analysis – Determine exactly what constitutes an incident, and under what circumstances you will activate your incident response team and initiate procedures.  Signs of an incident fall into one of two categories: precursors and indicators.  A precursor is a sign that an incident may occur in the future.  An indicator is a sign that an incident may have occurred or may be occurring now.  Many of the controls listed in the preparation phase (firewalls, IPS/IDS devices, etc.) can also alert to both precursors and indicators.  The initial analysis should provide enough information for the team to prioritize subsequent activities, such as containment of the incident and deeper analysis of the effects of the incident (steps 3 & 4).
  3. Containment, Eradication & Recovery – Most incidents require containment to control and minimize the damage.  An essential part of containment is decision-making i.e., shutting down a system, disconnecting it from a network, disabling certain functions, etc.  Although you may be  tempted to start the eradication and recovery phase immediately, bear in mind that you’ll need to collect as much forensic evidence as possible to facilitate the post-incident analysis.
  4. Post-Incident Activity – Simply put, lessons learned.  It’s easy to ignore this step as you try to get back to the business of banking, but don’t.  Some important questions to answer are:
  • Exactly what happened, and at what times?
  • How well did staff and management perform in dealing with the incident? Were the documented procedures followed? Were they adequate?
  • Were any steps or actions taken that might have inhibited the recovery?
  • What could we do differently the next time a similar incident occurs?
  • What corrective actions can prevent similar incidents in the future?
  • What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

The FFIEC addresses intrusion response here, and recommends that “institutions should assess the adequacy of their preparations through testing.”  Use the checklist, and recent security incidents to train your key CSIRT personnel, and then use the full guide to fine-tune and enhance your incident response capabilities.

03 Aug 2012
Hot Topics Tom Hinkel 0 comment

Risk Assessing iCloud (and other online backups) – UPDATE 2, DropBox

Update 2 (8/2012) – Cloud-based storage vendor DropBox confirmed recently that a stolen employee password led to the theft of a “project document” that contained user e-mail addresses. Those addresses were then used to SPAM DropBox users.  The password itself was not stolen directly from the DropBox site, but from another site the employee used.  This reinforces the point I made in a previous post about LinkedIn.  If you have a “go-to” password that you use frequently (and most people do) you should assume that it’s out there in the wild, and you should also assume it is now being used in dictionary attacks.  So change your DropBox password, but also change all other occurrences of that password.

But passwords (and password change policies!) aside, serious questions remain about this, and other, on-line storage vendors:

  1. Do they hold themselves to the same high information confidentiality, integrity and availability standards required of financial institutions?
  2. If so, can they document adherence to that standard by producing a third-party report, like the SOC 2?
  3. Will they retain and destroy information consistent with your internal data retention policies?
  4. What happens to your data once your relationship with the vendor is terminated?
  5. Do they have a broad and deep familiarity with the regulatory requirements of the financial industry, and are they willing and able to make changes in their service offerings necessitated by those requirements?

Any vendor that can not address these questions to your satisfaction should not be considered as a service provider for data classified any higher then “low”.

________________________________________________________

Update 1 (3/2012) – A recent article in Data Center Knowledge  estimates that Amazon is using at least 454,400 servers in seven data center hubs around the globe.  This emphasizes my point that large cloud providers with widely distributed data storage make it very difficult for financial institutions to satisfy the requirement to secure data in transit and storage if they don’t know exactly where the data is stored.

________________________________________________________

Apple recently introduced the iCloud service for Apple devices such as the iPhone and iPad.  The free version offers 5GB of storage, and additional storage up to 50GB can be purchased.  The storage can be used for anything from music to documents to email.

Since iPhones and iPads (and other mobile devices) have become ubiquitous among financial institution users, and since it is reasonable to assume that email and other documents stored on these devices (and replicated in iCloud) could contain non-public customer information, the use of this technology must be properly risk managed.  But iCloud is no different than any of the other on-line backup services such as Microsoft SkyDrive, Google Docs, Carbonite, DropBox, Amazon Web Services (AWS) or our own C-Vault…if customer data is transmitted or stored anywhere outside of your protected network, the risk assessment process is always the same.

The FFIEC requires financial institutions to:

  • Establish and ensure compliance with policies for handling and storing information,
  • Ensure safe and secure disposal of sensitive media, and
  • Secure information in transit or transmission to third parties.

These responsibilities don’t go away when all or part of a service is outsourced.  In fact, “…although outsourcing arrangements often provide a cost-effective means to support the institution’s technology needs, the ultimate responsibility and risk rests with the institution.“*  So once you’ve established a strategic basis  for cloud-based data storage, risk assessing outsourced products and services is basically a function of vendor management.  And the vendor management process actually begins well before the vendor actually becomes a vendor, i.e. before the contract is signed.  Again, the FFIEC provides guidance in this area:

Financial institutions should exercise their security responsibilities for outsourced operations through:

  • Appropriate due diligence in service provider research and selection,
  • Contractual assurances regarding security responsibilities, controls, and reporting,
  • Nondisclosure agreements regarding the institution’s systems and data,
  • Independent review of the service provider’s security though appropriate audits and tests, and
  • Coordination of incident response policies and contractual notification requirements.*

So how do you comply (and demonstrate compliance) with this guidance?  For starters, begin your vendor management process early, right after the decision is made to implement cloud-based backup.  Determine your requirements and priorities (usually listed in a formal request for proposal), such as availability, capacity, privacy/security, and price…and perform due diligence on your short list of potential providers to narrow the choice.  Non-disclosure agreements would typically be exchanged at this point (or before).

Challenges & Solutions

This is where the challenges begin when considering large cloud-based providers.  They aren’t likely to respond to a request for proposal (RFP), nor are they going to provide a non-disclosure agreement (NDA) beyond their standard posted privacy policy. This does not, however, relieve you from your responsibility to satisfy yourself any way you can that the vendor will still meet all of your requirements.  One more challenge (and this is a big one)…since large providers may store data simultaneously in multiple locations, you don’t really know where your data is physically located.  How do you satisfy the requirement to secure data in transit and storage if you don’t know where it’s going or how it gets there?  Also, what happens if you decide to terminate the service?  How will you validate that your data is completely removed?  And what happens if the vendor sells themselves to someone else.  Chances are your data was considered an asset for the purposes of valuing the transaction, and now that asset (your data) is in the hands of someone else, someone that may have a different privacy policy or may even be located in a different country.

The only possible answer to these challenges is bullet #4 above…you request, receive and review the providers financials and other third-party reviews (SOC, SAS 70, etc).  Here again, large providers may not be willing to share information beyond what is already public.  So the answer actually presents an additional challenge.

Practically speaking, perhaps the best way to approach this is to have a policy that classifies and restricts data stored in the cloud.  Providers that can meet your privacy, security, confidentiality, availability and data integrity requirements would be approved for all data types, providers that could NOT satisfactorily meet your requirements would be restricted to storing only non-critical, non-sensitive information.  Of course enforcing that policy is the final challenge…and the topic of a future post!  In the meantime, if your institution is using cloud-based data storage, how are you addressing these challenges?

* Information Security Booklet – July 2006, Service Provider Oversight

© 2025 UFS Tech. All rights reserved. Compliance Guru is a registered trademark of UFS Tech. Privacy Policy