Chatting With An Auditor About Credit Union Compliance

Friday, December 16, 2011

Ed Moyle

Fe3139b2aae983885565da7757da08a8

So if you recall, I received an inquiry the other day to take a bit further my post where I was quacking about credit unions.

As a refresher, the gist of that discussion was that I found it to be somewhat lame that credit unions were complaining about how they have stringent technical controls whereas merchants don't. 

My meta-point was that merchants (at least for card-based payments) have some very stringent (i.e. technically prescriptive) security controls by virtue of PCI compliance.  

Credit unions, on the other hand, by virtue of their regulatory context, have more "interpretive latitude" in how technical security controls get implemented.  Meaning, they should try on PCI compliance before calling out merchants (especially the big ones) for having it soft.

To get some additional context on this point, I reached out to a former colleague who's now an auditor for credit unions and community banks.  I'll keep his name off the record - not because he asked me to necessarily, but because he asked that I not identify his employer... and anybody with a browser and a LinkedIn account can look at my background, guess who he might be, and determine his place of employment.  So let's just call him "Papa" - for "Papa Smurf", his nickname when we worked together.  

Anyway, mega-thanks to him for going through this with me. Below is the record of the discussion I had with him.  I'll pull out some of the material that I think highlights or negates my point from earlier in a subsequent post (since we really got into detail and covered a lot of ground in our discussion):

Can you briefly describe the type of work that you do with credit unions?

Typically under contract, what we do is a full-scope risk assessment.  Under the current regulations, a credit union, unlike a bank, does not have to have an IT audit.  They are instead required to have an “IT risk assessment”.  This risk assessment looks at approximately 27 control objectives that come out of COBIT. 

The objective is the same as an audit - the difference is that during a risk assessment, you don’t collect work papers and the client is responsible to complete specific areas of a risk assessment themselves.

We have credit unions that request an IT audit over and above a risk assessment.  Audit is basically a “black & white” evaluation exercise (you either “have it” or you don’t – you meet the bar or you do not); An IT Audit is based on COBIT, a methodology from ISACA (Information Systems Audit and Control Association) to evaluate the controls  and how they comply with the FFIEC IT Audit guidelines.  

A risk assessment on the other hand is based on the National Institute of Standards and Technology’s (NIST) Special Publication 800-30 and follows the guidance provided in the FFIEC Information Security Booklet to evaluate the risks and safeguards in place to support the bank or credit unions Information Security Program.

How many banks and credit unions would you say you’ve worked with in the past two years?

Probably around 24.  About one per month.

What specifically is required of a bank or credit union with respect to security controls?  What standards do they need to adhere to? 

Credit unions are regulated by the NCUA (National Credit Union Association).  The difference is that credit unions are non-profit.  Regulatory-wise, there’s no difference between a credit union and a bank and from a financial aspect, they both provide services to customers/members and the business community such as loans (car, mortgages), savings, checking, etc. 

The FFIEC is the inter-agency chartered to provide guidance to all banking institutions.  FFIEC includes OCC, FRB, Federal Deposit, and the NCUA.  It also used to provide governance to OTS, but that’s gone because there are very few thrifts ( savings and loans - think: “It’s a Wonderful Life”).

In terms of our risk assessments, we take into account items from COBIT as well as guidance from PCAOB in addition to industry best practices.  We use  best practices because they change faster due to technology and procedure than the guidance from the FFIEC and elsewhere. 

The fact that it is not FFIEC guidance, doesn’t mean it’s not useful for these organization to consider.  For example, we sometimes use the PCI DSS as a best practice guideline for what these organizations should look to from a best practices standpoint.  The DSS has straightforward questions looking for straightforward responses.

What’s the role of the FFIEC examiner handbook?  How much teeth do those controls have?  How do those rules compare to PCI DSS?

FFIEC guidance is high level in terms of technical content.  While it is called ‘guidance’ they are standards and the banks and credit unions must comply with the guidance. They are examined using the FFIEC as the source document for compliance.  PCI is not a regulatory requirement – it is private enterprise (Visa, MC, Amex) that established specific rules that a card issuer/merchant must follow. 

That doesn’t mean that nothing goes wrong – all you need to do is look at the TJ Max and Hannaford incidents.  Under PCI, card issuers/merchants  are required to comply to the requirements and have an annual PCI audit done by persons certified directly by PCI. More than that, I am not sure – nothing in the PCI documentation indicates you will lose your right to be a card merchant but there must be some ramifications.

What happens when a credit union doesn’t comply?

When a credit union is being examined by the NCU, assuming a  full-scope exam, it would include all areas of IT including BCP/DR, handling of member (customer) information, data at rest/in transit, user (employee) access controls, and LAN/WAN networking. 

However, in the past few years, my take has been that they are focusing more attention on the financial  side rather than IT.  So when it comes to IT – the credit union gets a pass because areas were not examined but that doesn’t mean when we do an audit or risk assessment we will let it pass – we cannot because of the COBIT, NIST, FFIEC, and other guidance factors.

FFIEC guidance – even though it’s guidance – is required for these organizations to meet it.  Incident response for example, is a requirement.  But there’s some interpretive latitude relative to the degree or depth of that plan.

Is there any “wiggle room” when an organization can’t meet the guidance?

The rule of thumb I use relative to Incident Response is a clause in the FFIEC guidance that speaks to “size and complexity”.  A smaller credit union might not have the same level of technical expertise, IT staffing, or funds to purchase something like enCase (the forensic product) to do investigations; they might not have the money to support it, to train users, licensing fees, etc. – you have to measure their response plan and ability to support it based on what makes sense for an organization their size.

However, BCP/DR for example, requires a  recovery and a continuity plan.  They have to have a plan in place.  On the other hand, there is no regulatory requirement for a bank to have a generator.  When I got into this line of work, I thought there was because it makes sense. 

However, there isn’t.  When you have a power outage in an area, you’re not opening your doors.  There’s guidance and then there’s a flaw in the guidance.  There are some that do, but many banks and credit unions do not.

What’s the role of GLBA?

GLBA says that customer information (name, ssn, etc.) otherwise referred to as non-public personal information and it must be protected.  This is information that is not commonly found such as in a telephone bill, a telephone book, or a car rental agreement. 

The primary objective of an information security risk assessment is to identify, evaluate, and prioritize threats to information assets and vulnerabilities in the control environment.  The risk assessment represents the foundation of the Information Security Program and is an ongoing process that highlights needed program enhancements.

This entire process requires the bank/credit union to have appropriate policy and procedures in place to provide guidance to all employees on how to handle and control customer (member) information.

Not having formal policy, but having documented procedures isn’t great, but it is a start.  The Board of Directors are expected to develop, or have developed for the bank/credit union, policies that they, the BOD are required to review, and approve and have implemented.  If they don’t, they cannot protect the information properly and I would write it up  a high or medium priority in a risk assessment I’m doing.

Protection of all media (optical, magnetic, or paper) at rest (sitting in a cabinet or database) or in transit (sent from main office to backupsite, etc.) has to be protected as well.  It must be secured such that only persons who need access to it, do.  This is commonly referred to as the rule of least privilege.   

I did one audit for example where regulatory required documentation was stored in one central room and a number of individuals had access.  They stored non-perishable foods, holiday decorations, etc. in the same room.  That was an issue.  The paper materials should be in a secured location – either in a secured desk, locked room, cabinet, etc.  

Cross-posted from Security Curve Weblog 

Possibly Related Articles:
19459
PCI DSS
Information Security
NIST PCI DSS Compliance Regulation COBIT Merchants FFIEC Credit Unions
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.