Author: Tom Hinkel

As author of the Compliance Guru website, Hinkel shares easy to digest information security tidbits with financial institutions across the country. With almost twenty years’ experience, Hinkel’s areas of expertise spans the entire spectrum of information technology. He is also the VP of Compliance Services at Safe Systems, a community banking tech company, where he ensures that their services incorporate the appropriate financial industry regulations and best practices.
07 Dec 2011
Hot Topics Tom Hinkel 0 comment

2012 Compliance Trends, Part 2 – Vendor Management

In my first post in this series I discussed training (employee and customer) as a good candidate for increased regulatory scrutiny in 2012.  Although these posts are in no particular order, I had initially intended to list “Management” as the next trend.  However a comment made to me by a banker at a recent conference leads me to believe that vendor management has already started to emerge as an area of increased regulator focus, so I am making this trend #2.

Vendor Management

I’ve already posted numerous times on the importance of vendor management…most recently when risk assessing on-line backup vendors, and how the phase-out of the SAS 70 will affect vendor management (here and here), and I even selected it as a potential trend for 2011.  And all the existing reasons still apply, but a couple of fairly recent developments are pushing this issue up the priority list:

  • The increased popularity and adoption of new and emerging technologies, such as cloud computing,
  • New risks and new guidance in electronic banking,
  • The SAS 70 phase-out
  • Examiners are hearing these three words more and more; “…they handle that…“.

All these really go together.  Think about this…is there a critical product or service you offer that doesn’t involve a third-party relationship?  I’ve asked that question at a number of meetings and conferences this year and have yet to have anyone come up with an example.  And to further underscore the point, how many of your vendors have vendors of their own?

So more reliance on outsourcing means that examiners are hearing the phrase “they handle that” more often when they ask about data security.  But as we all know…

Management is responsible for ensuring the protection of institution and customer data, even when that data is transmitted, processed, stored, or disposed of by a service provider.1

In the past, saying “they handle that” to an auditor or examiner was usually followed up with “OK, let’s see the SAS 70 and financials on that vendor”.  You would produce the reports, and that was pretty much the end of that conversation, and indeed often the extent of your vendor management responsibility.  I believe this will change, and I’ve already gotten some validation on that.

Going forward expect examiners to ask to see your entire vendor management program, not just the third-party reviews and financials, and not just on select vendors.  Any vendor that could have access (even incidental access) to non-public information (yours or your customers) must be risk-ranked by your vendor management program.  And the process of evaluating vendors starts well before they become a vendor, when you are still in the pre-implementation stage.

Here are some of the essential, and yet often missing, elements of a vendor management program:

  • Have you conducted due diligence prior to vendor selection?
  • Have you documented that the product or service is in alignment with the goals and objectives of your strategic plan?
  • Is a BSCA filing required?
  • Are the vendor’s disaster recovery capabilities adequate to support your recovery time objectives?
  • Are vendor performance standards (SLA’s) clearly defined?
  • In addition to vendor access to NPI/PII, have you risk-ranked your vendors based on:
    • Access to other confidential (i.e. proprietary) information?
    • Criticality of the product/service they provide?
    • Complexity of the product/service?

Additionally, the new electronic banking guidance will force financial institutions to take a closer look at their Internet banking providers in order to conduct the required (starting in January) risk assessments.  When the examiner asks for your electronic banking risk assessment, and wants to know what layered controls have been implemented, you can not say “our provider handles that”.  The whole point of a risk assessment is to assure that you know, and are comfortable with, the residual risk.

And finally, the third-party report that will likely replace the SAS 70 for most service providers will be the SOC 2, and unlike the SAS 70 the SOC 2 is designed to be a deep dive into the control environment of the service provider.  Also unlike the SAS 70, financial institutions will have to actually review the SOC 2 document to assure themselves that there are no exclusions or other qualifications in the report, and to review the results of control testing (for a Type II).  And unless the service provider specifically excludes it from the report, you will also have a high degree of confidence that any sub-service organizations (providers to your provider) have an adequate control environment as well.

So for all these reasons, expect vendor management to be an increased regulatory priority in 2012.

22 Nov 2011
From the Field Tom Hinkel 0 comment

Thankful for…Dodd-Frank?

I made a similar post last year about this time, so I thought I would continue the “Thanks-giving” tradition here…and no, I haven’t completely lost my mind about Dodd-Frank.  Let me explain.  Over the past year I’ve had the opportunity to give several presentations to various groups on the impact of Dodd-Frank (DFA) on community financial institutions, and I know the attitude out there on DFA ranges from cautious optimism to dread, but “Thankful”?!?  Actually so far, overall, the impact had been negligible to slightly positive for community financial institutions (defined as <$1B in assets).  But there is also reason for caution.

Reasons to be thankful

First and foremost among these are lower assessment rates.  Lower deposit insurance assessments mean that the vast majority of community banks will see 30% – 40% decreases in their fees paid to the FDIC.  And at the same time the amount of deposit insurance coverage has increased to $250,000.  Getting more for less is always a good thing.

Although we can’t really credit this to Dodd-Frank, we can nevertheless also be thankful that financial institutions are for the most part healthier than they were last year at this time:

 

Another reason to be thankful is that the provision limiting debit card interchange fees does not apply to institutions with less than $10B in assets.  In fact the vast majority of DFA provisions will only apply to institutions larger than $1B in assets, which as of June 2011 is only 8.9% of all financial institutions:

 

Reasons to be cautious

But as I said, there are still reasons to be cautious.  According to DavisPolk in their latest Dodd-Frank Progress Report, 326 of the 400 rules required by the law have not yet been enacted, which, (regardless of whether or not community institutions will ultimately be affected)  still leads to a climate of regulatory uncertainty. And there are  couple of other more obscure provisions that will affect all institutions, like the Source of Financial Strength provision, and the requirement for risk committees to have outside directors, and of course whatever burdens the CFPB brings…stay tuned!

I mentioned previously that one of the reasons that I’m NOT thankful for DFA is that it raises the threshold for triggering a Material Loss Review from $25M to $200M, so we’ll have fewer post-failure reports to review.  I believe the best way to avoid repeating the mistakes of the past is to learn from them, and the MLR’s were a great way to do that.  I think they can also predict future examination trends…which is a preview of my next 2012 Trends post!

 

(I’d be remiss if I didn’t take this opportunity to express thanks for all the blog readers out there…over 11,000 visits since this time last year!  THANK YOU!!)

15 Nov 2011
Hot Topics Tom Hinkel 0 comment

2012 Compliance Trends, Part 1 – Training

This post will begin a series of 5 topics that I consider to be good candidates for increased regulatory scrutiny in the coming year.  For each topic, I will make the case for increased scrutiny based on 3 criteria:

  1. Recent audit and examination experience,
  2. Regulatory changes, and
  3. Recent events.

In keeping with my policy of trying to provide clear actionable solutions to each challenge, I will also provide suggestions to keep you ahead of the trend.

The first topic is actually making its debut appearance this year, and although training has always been important for financial institutions, it only recently crept into the top 5.  And this is really a two-part trend;

Employee training and Customer training.

First, the case for employee training.  I have always placed the importance of this in the top 10, but a recent event and examination experience have moved this into my top 5.  The recent event is the RSA breach, which I first wrote about here right after the news broke in March, and again here a couple of months ago.  This turned out to be a rather standard social engineering attack conducted over a long period of time exploiting the trust of a single employee.  The FFIEC defines social engineering this way:

Social engineering involves an attacker obtaining authenticators by simply asking for them. For instance, the attacker may masquerade as a legitimate user who needs a password reset or as a contractor who must have immediate access to correct a system performance problem. By using persuasion, being aggressive, or using other interpersonal skills, the attackers encourage a legitimate user or other authorized person to give them authentication credentials. Controls against these attacks involve strong identification policies and employee training.

Additionally we continue to see employee security policy and awareness training questions in every pre-examination questionnaire, regardless of whether the examiners are Federal or State.  With the increased use of social media by financial institutions, and the understanding that the employee is still the weak link in the security chain*, I  predict increased need for, and emphasis on, employee training.

Customer training has always been a best practice, but it’s now a requirement.  Also referred to as customer awareness and education, the case for customer training as a trend is two-fold.  The first is the recent updated FFIEC guidance on Internet authentication.  Customer training is listed as one of the effective controls that may be included in a layered security program for both retail and commercial account holders with Internet access capability (in other words, almost all account holders), and compliance starts in January.  According to the FFIEC, customer training should contain, at a minimum:

  • An explanation of what is, and what isn’t, covered under Reg E.
  • Under what circumstances the institution may contact the customer and request log on credentials.  This one is the most important, and even though the answer is probably “never”, it can’t be repeated enough.
  • A strong suggestion that the customer perform their own risk assessment.  (The verbiage in the guidance actually leaves out the word “strong”…I added it.)
  • To go with the previous risk assessment, a list of possible controls that the customer may consider, including where they may get additional assistance.  (Institutions may be tempted to offer their own assistance, but I recommend against it.  Not only may this prove to be a resource drain, it may also inadvertently set you up for a liability claim if a customer does experience a breach.)
  • A list of institution names and contact numbers for the customer to use in the event they notice suspicious account activity.  Make sure to include off-hour contact information if applicable, as most recent exploits have occurred on weekends and other non-business hours.

The second reason for the importance of customer training is the realization by the fraudsters that customers are an easy target.  As one recent example of this trend, Trusteer just issued a warning that fraudsters are actually setting up call centers to facilitate ID theft by targeting merchants.  This goes way beyond simply installing malware and grabbing login credentials,  this attacks the most secure elements in the transaction chain; controls such as the one-time passwords, IP blocks (black lists) and positive pay (white lists).  Although the actual details of the attack are fascinating…and frightening…at its core this is really nothing more than an extremely sophisticated social engineering attack, and as such the standard social engineering controls apply.

In summary, re-examine your employee AND customer training and awareness programs, and plan on increasing your training in both areas in 2012.  Make sure your customer training contains at least the minimum elements, and that you periodically repeat the training.  Finally, conduct testing on both groups to validate comprehension where you can (easier for employees than customers), and document everything!

 

*Additional reading:

http://www.csoonline.com/article/print/691910

 

08 Nov 2011
From the Field Tom Hinkel 1 Comment

Access Rights a frequent finding

In reviewing recent audit and examination findings, the issue of access rights and permissions is coming up with increasing regularity.  Making sure that end-users have no more access rights than absolutely necessary to do their job is one of the best information security controls.  According to the FFIEC, formal access rights administration for users consists of four processes:

  •   An enrollment process to add new users to the system;
  •   An authorization process to add, delete, or modify authorized user access to operating systems, applications, directories, files, and specific types of information;
  •   An authentication process to identify the user during subsequent activities; and
  •   A monitoring process to oversee and manage the access rights granted to each user on the system.

One best practice for simplifying the management of access rights is to assign them via  group membership based on the employee’s role.  Most financial institution employees are easily categorized by job duties (lending, deposit ops, senior management, IT, etc.).  Job duties logically translate to responsibilities, and network file and folder access flows from that.  When an employees job duties change, changing group membership is much easier than changing individual file and folder permissions.

One of the main reasons for audit and exam findings in this area is not necessarily that users and groups aren’t maintained, but that there is a  disconnect between access rights on the Core system and the local network (Active Directory).  Unfortunately until the Core providers implement Active Directory integration this is a manual, 2-step process.

The key to addressing the FFIEC guidance (and preventing rights gaps in the process) is to manage all four of the above steps at the same time in the IT Steering Committee (or functional equivalent).  Each time the committee meets it should approve all access rights adds, changes and deletes, and review activity logs.  Periodically review the existing users (by group if possible) to validate the appropriateness of their (and the groups) access rights on a schedule commensurate with the risk.  Properly restricted regular users may only require semi-annual reviews, but privileged access (administrative) accounts should be reviewed for activity and re-approved at each committee meeting.

28 Oct 2011
Hot Topics Tom Hinkel 0 comment

The “Security Breach” and your Incident Response Program

Last week Wells Fargo said that some of their customers in South Carolina and Florida received portions of other customers’ bank statements in the mail as the result of a printer error.  Essentially a printer malfunction caused some printed statements to contain a portion of another customer’s statement to be appended to the bottom.  A Wells Fargo spokesman said that “we’re treating this matter as an information security breach.”  This got me thinking about what constitutes a “breach”, vs. what is an “event”, and what the regulators expect you should do about it in either case.

I usually associate a breach with an act perpetrated by an intelligent agent*, and in fact BusinessDictionary.com defines breach as “An act from outside an organization that bypasses or contravenes security policies, practices, or procedures.”  Based on this definition the Wells Fargo incident was not technically a breach because it originated from within the organization.  On the other hand, Wikipedia defines data breach as “…the intentional or unintentional release of secure information to an untrusted environment.”  This seemingly would include both internal and external events, as well as intelligent as well as inanimate agents…cause and source don’t matter.

So what does the FFIEC have to say?  They don’t specifically use the “breach” terminology when referring to an information security event, but in the Information Security Handbook they define a security event this way:  “An event that compromises the confidentiality, integrity, availability, or accountability of an information system.”  So cause and source aren’t material to the definition of event, and by this definition the printer malfunction did constitute a security event.

Whether you refer to it as a “breach”, and “event” or an “incident”, your incident response plan must guide your response.  According to the FFIEC, your incident response program should contain, at a minimum, procedures for:

  •  Assessing the nature and scope of an incident and identifying what customer information systems and types of customer information have been accessed or misused;
  • Notifying its primary federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information;
  • Consistent with the agencies’ Suspicious Activity Report (SAR) regulations, filing a timely SAR, and in situations involving federal criminal violations requiring immediate attention, such as when a reportable violation is ongoing, promptly notifying appropriate law enforcement authorities;
  • Taking appropriate steps to contain and control the incident to prevent further unauthorized access to or use of customer information; and
  • Notifying customers when warranted in a manner designed to ensure that a customer can reasonably be expected to receive it.

Whenever I see events like this in the news, I see an opportunity for financial institutions to use it as training.  Conduct a table-top drill using the details of the actual event as your scenario.  Dust off your incident response plan, and follow it to the letter.  The objectives of the test should include such items as:

  • What defines an event?  Under what specific circumstances is the plan activated?
  • Who is notified and when?  Should an SAR be filed?  If customers are required to be notified, how will they be notified?  What will you say?
  • What was the root cause of the incident?  What controls failed and why?  Make sure you document and preserve as many of the details of the event as possible to facilitate the post-event investigation process.

Finally, update your program to address any gaps between what your plan says, and what you would actually do.  Incorporate any additional controls indicated by the post-event analysis back into your information security program.  And re-test as soon as possible to validate all changes.

 

 

*Although I suppose you could say that printers and copiers have become more “intelligent” in the sense that almost all of them contain some sort of microprocessor, and even storage, I think of an intelligent agent to mean human-based.

06 Oct 2011
From the Field Tom Hinkel 0 comment

Material Loss Reviews: Does responsibility = liability?

I asked in my previous post whether or not the regulators should share any of the blame when institutions fail, and if so, should they shoulder any of the liability?  The thought occurred to me as I was reviewing some recent Material Loss Reviews.

A Material Loss Review (MLR)  is a post-mortum written by the Office of Inspector General for each of the federal regulators with oversight responsibility after a failure of an institution if the loss to the deposit insurance fund is considered to be “material”.  (The threshold for determining whether the loss is material was recently increased by the Dodd-Frank Act from $25 million to $200 million, so we are likely to see fewer of these MLR’s going forward.)  All MLR’s have a similar structure.  There is an executive summary in the front, followed by a break-down of capital and assets by type and concentration.  But there is also a section that analyzes the regulator’s supervision of the financial institution, and I noticed a recurring theme in this section:

  • …(regulator) failed to adequately assess or timely identify key risks…until it was too late.
  • …(regulator) did not timely communicate key risks…
  • …Regulator should have taken “a more conservative supervisory approach”, and used “forward-looking supervision”.
  • …examiners identified key weaknesses…but…they did not act on opportunities to take earlier and more forceful supervisory action.
  • …serious lapse in (regulator’s) supervision
  • …(regulator), in its supervision…did not identify problems with the thrift
  • …(regulator) should have acted more forcefully and sooner to address the unsafe and unsound practices
  • …(regulator) did not fully comply with supervisory guidance

There were also many references to the responsibilities of the Board, which I addressed here, but in almost every case the regulator was found at least partially responsible for the failure of the institution.

Here is where you can find the reports for each regulator:

I encourage you to take a look at these and draw your own conclusions as to the issues of responsibility and liability.  But clearly there are lessons to learn from any failure, and one lesson that I think we should all learn from this is that regulators will be pressured to be much more critical going forward.  (I.e. quicker to apply “Prompt Corrective Action“.)  After all, no one likes to be called out for doing a bad job.

One other part I found interesting (in the sense that it perfectly fits the narrative) is where the review lists all examination CAMELS ratings in the periods immediately prior to the failure.  What struck me was how many times institutions scored 1’s and 2’s just prior to the failure, and then dropped immediately to 4’s and 5’s in a single examination cycle.  Again, the lesson is that there will be tremendous downward pressure on CAMELS scores.  And don’t think that just because you are healthy you’re immune from the additional scrutiny.  As one MLR stated “…a forceful supervisory response is warranted, even in the presence of strong financial performance.”

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