Tom Hinkel – Page 2 – Compliance Guru

04 Mar 2016

Hot Topics Tom Hinkel 0 comment

FDIC Expands Criteria for 18 Month Exam Cycle

The FDIC released FIL-17-2016 today, which will increase the examination cycle for community banks meeting certain criteria from 12 months to 18 months, thereby potentially decreasing one of the most intrusive events in the bankers life.

The criteria is as follows:

Must be less than $1 B in assets
Must have a CAMELS composite rating of “1” or “2”
Must be well-capitalized
Must be well-managed
Must not have undergone any change in control during the previous 12 months
Must not be under an enforcement order or proceeding.

The 18 month examination cycle was previously not available to any community bank smaller than $500 million in assets, but now any bank smaller than 1 B will qualify, provided they meet the other criteria.

This is good news for already overly-burdened and otherwise healthy institutions, but what concerns me is the definition of “well-managed”. All of the other criteria is objective, and pretty easy to define and establish. But how will the regulators define well-managed? For example, if the institution had a single, non-material, repeat finding in their last exam, could that reflect poorly on management? After all, responsiveness to recommendation from auditors and supervisory authorities is one of the elements that make up the CAMELS management component.

And is it even possible for an institution to rate a composite score of “1” or “2” if it is not well-managed? Here is an extract from the FDIC Uniform Financial Institutions Rating System (UFIRS) relating to management:

Composite 2 : Only moderate weaknesses are present and are well within the board of directors’ and management’s capabilities and willingness to correct.
Composite 3: Management may lack the ability or willingness to effectively address weaknesses within appropriate time frames.

7 Reasons Why Small Community Banks Should Outsource IT Network Management

Based in this I think it’s highly unlikely that a bank could score a “2” and be poorly managed.

Anyway, time will tell how examiners define well-managed, but this is certainly a step in the right direction and should bring much needed relief to many institutions.

11 Nov 2015

Hot Topics Tom Hinkel 0 comment

FFIEC Updates (and Greatly Expands) the Management Handbook

This latest update to the IT Examination Handbook series comes 11 years after the original version. And although IT has changed significantly in the past 11 years, the requirement that financial institutions properly manage the risks of IT has not changed. This new Handbook contains many changes that will introduce new requirements and new expectations from regulators. Some of these changes are subtle, others are more significant. Here is my first take on just a few differences between the original and the new Handbook:

Cybersecurity

The original Handbook contained only a single reference to “cyber”. The revised Handbook contains 53 references.

IT Management

The Board and a steering committee are still responsible for overall IT management, but the guidance now introduces a new obligation for the Board, requiring that they provide a “credible challenge” to management. Specifically, this means the Board must be “actively engaged, asking thoughtful questions, and exercising independent judgment”. Simply put, no more “rubber stamps”. The Board is expected to actually govern, and that means they need access to accurate, timely and relevant information.

The IT Management Structure has changed. The 2004 Handbook listed the following structure:

Board of Directors / Steering Committee
Chief Information Officer / Chief Technology Officer
IT Line Management
Business Unit Management

The Updated Guidance is a bit more granular, and recommends the following structure (changes in bold):

Board of Directors / Steering Committee
Executive Management
Chief Information Officer or Chief Technology Officer
Chief Information Security Officer
IT Line Management
Business Unit Management

“Risk Appetite”

The FFIEC Cybersecurity Assessment Tool introduced this new term (addressed here), and the Management Handbook makes an additional 11 references. Institutions should understand this relatively new (for IT anyway) concept and incorporate it into their strategic planning process.

Managing Technology Service Providers

The 2004 guidance contained a separate section on best practices in this area. The new guidance has removed the section, incorporating references to vendor management best practices throughout the document. This reflects the reality of the prevalence and importance of outsourcing in today’s financial institutions.

Examination Procedures (Appendix A)

The 2004 Handbook had 8 pages containing 9 examination objectives. The new guidance is almost completely re-written, and has 15 pages containing 13 objectives. Several of these new objectives deal with internal governance and oversight, and a couple address the enterprise-wide nature of IT management. All areas have been greatly expanded. For example, the objective dealing with IT controls and risk mitigation (Objective 12) consists of 18 separate examination elements with 53 discrete items that examiners must check.

Best Practices for Control and Management of Your Community Bank’s IT

A community bank’s digital assets are every bit as valuable as the money in the vault.

In summary, the updated Handbook represents a significant evolution in both the breadth and depth of IT management requirements. It will set the standard for IT management best practices for both examiners and institutions for some time to come, and should be required reading for all Board members, CEO’s, CIO’s, ISO’s, and network administrators.

13 Oct 2015

Ask the Guru Tom Hinkel 2 Comments

Ask the Guru: Cybersecurity “Risk Appetite”

Hey Guru
I saw multiple references to the term “risk appetite” in the FFIEC Cybersecurity Assessment Tool. What exactly is risk appetite, and how can I address this in my institution? They just released Management Handbook contains 10 new references to “risk appetite”, including a requirement that the Board has defined the institution’s risk appetite and it’s risk tolerance levels.

There are 6 references to “risk appetite” in the FFIEC cybersecurity tool, and although it is not a new concept in risk management, this is a term I have not seen in regulatory guidance before outside of lending and credit practices. Here are all references in context:

The institution has a cyber risk appetite statement approved by the board or an appropriate board committee.
The board or board committee approved cyber risk appetite statement is part of the enterprise-wide risk appetite statement.
The risk appetite is informed by the institution’s role in critical infrastructure.
The independent audit function regularly reviews management’s cyber risk appetite statement.
The independent audit function regularly reviews the institution’s cyber risk appetite statement in comparison to assessment results and incorporates gaps into the audit strategy.
Threat intelligence is viewed within the context of the institution’s risk profile and risk appetite to prioritize mitigating actions in anticipation of threats.

Risk tolerance is pretty well documented in current guidance, and although there are subtle differences between the terms, I see risk tolerance and risk appetite as largely synonymous for most institutions. Here is a good working definition of risk appetite:

The amount of risk that an enterprise is willing to pursue and accept in order to achieve the goals and objectives of their strategic plan.

How should you address cybersecurity risk appetite? You probably already have both inherent and residual risk assessed in your cybersecurity risk assessment, and have identified each as either “High”, “Medium”, or “Low”. Risk “appetite” is simply a decision by management that the residual risk level is acceptable. In other words, management is willing to accept the remaining risk as the cost of achieving its objectives.

For example, you’ve identified a vendor as having high inherent risk, and applied the necessary controls to reduce the risk as much as you can. The remaining (residual) risk is deemed by management to be either acceptable or unacceptable based on their risk tolerance. So if you use a “High”, “Medium” and “Low” designation for residual risk, a value of “Low” or even “Medium” can be deemed acceptable if it is within the risk appetite of the institution.

Establishing your risk appetite for cybersecurity can be accomplished using either a qualitative or quantitative approach. A quantitative approach requires an analysis of specific financial loss connected to a cybersecurity event. While this is a valid way to document risk, it can be a challenge for all but the largest institutions.

Most institutions prefer a qualitative approach, which uses a scale (i.e. 1 – 10, or H, M, and L) to rank the impact of a cyber event on reputation risk, strategic risk, regulatory/legal risk and/or operational risk. Management can then determine the level of acceptable risk in each risk category. For example, you may decide you have a very low (1-3) tolerance for risks in the reputation category, but you may be willing to accept a higher level (3-5) in the operational area.

Dispelling 5 IT Outsourcing Myths within Financial Institutions

Learn why some of the most commonly believed “facts” about IT outsourcing for banks are actually myths.

Once you’ve established your risk appetite, the easiest way to document it is to add a “Risk Appetite” column to your existing cybersecurity risk assessment (ideally just after “Residual Risk”), where you designate remaining risk as either acceptable or unacceptable.

You might also want to amend your Information Security Policy to add a risk appetite statement. Something like this:

“The Board has established specific strategic goals and objectives as defined in its strategic plan. To increase the probability of achieving these goals, the Board has established acceptable risk tolerances within its risk appetite. The board periodically reviews the risk appetite and associated tolerances, and may adjust them to adapt to changing economic conditions and/or strategic goals.”

16 Jul 2015

Hot Topics Tom Hinkel 4 Comments

FFIEC Releases Cybersecurity Assessment Tool

UPDATE: Safe Systems just released their Enhanced CyberSecurity Assessment Toolkit (ECAT) – This enhanced version of the FFIEC toolkit addresses the biggest drawback of the tool; the ability to collect, summarize, and report your risk and control maturity levels.

Once risks and controls have been assessed (Step 1 below), institutions will now be better able to identify gaps in their cyber risk program, which is step 2 in the 5 step process.

This long-anticipated release of the Cybersecurity Assessment Tool (CAT) is designed to assist institution management in both assessing their exposure to cyber risk, and then measuring the maturity level of their current cybersecurity controls. Users must digest 123 pages, and must provide one of five answers to a total of 69 questions in 10 categories or domains. This is not a trivial undertaking, and will require input from IT, HR, internal audit, and key third-parties.

After completing the assessment, management should gain a pretty good understanding of the gaps, or weaknesses, that may exist in their own cybersecurity program. As a result, “management can then decide what actions are needed either to affect the inherent risk profile or to achieve a desired state of maturity.” I found the CAT to be quite innovative in what it does, but it also has some baffling limitations that may pose challenges to many financial institutions, particularly smaller ones.

[pullquote]The CAT is quite innovative in what it does, but it also has some baffling limitations…[/pullquote]

First of all, I was stunned by the specificity of both the risk assessment and the maturity review. Never before have we seen this level of prescriptiveness and granularity from the FFIEC in how risks and controls should be categorized. For example, when assessing risk from third-parties:

No third-parties with system access = Least Risk
1 – 5 third parties = Minimal Risk
6 – 10 third parties = Moderate Risk
11 – 25 third parties = Significant Risk, and
> 25 third parties = Most Risk

Again, this is quite different from what the FFIEC has done previously. If Information Security guidance used the same level of detail, we might see specific risk levels for passwords of a certain length and complexity, and correspondingly higher control maturity levels for longer, more complex passwords. Of course we don’t see that from current guidance, what we get is a generic “controls must be appropriate to the size and complexity of the institution, and the nature and scope of its operations”, leaving the interpretation of exactly what that means to the institution, and to the examiner.

I see this new approach as a very good thing, because it removes all of the ambiguity from the process. As someone who has seen institutions of all sizes and complexities struggle with how to interpret and implement guidance, I hope this represents a new approach to all risk assessments and control reviews going forward. Imagine having a single worksheet for both institutions and examiners. Both sides agree that a certain number of network devices, or third-parties, or wire transfers, or RDC customers, or physical locations, constitute a very specific level of risk. Control maturity is assessed based on implementation of specific discrete elements. Removing the uncertainty and guess-work from examinations would be VERY good thing for over-burdened institutions and examiners alike.

7 Reasons Why Small Community Banks Should Outsource IT Network Management

So all that is good, but there are 2 big challenges with the tool; collection, and interpretation and analysis. The first is the most significant, and makes the tool almost useless in its current format. Institutions are expected to collect, and then interpret and analyze the data, but the tool doesn’t have that capability to do that because all the documents provided by the FFIEC are in PDF format.

If you can figure out how to record your responses, that still leaves the responsibility to conduct a “gap” analysis to the institution. In other words, now that you know where your biggest risks reside, how do you then align your controls with those risks?

One more challenge…regulators expect you to communicate the results to the Board and senior management, which is not really possible without some way of collecting and summarizing the data. They also recommend an independent evaluation of the results from your auditors, which also requires summary data.

In summary, there is a lot to like in this guidance and I hope we see more of this level of specificity going forward. But the tool should have the ability to (at a minimum) record responses, and ideally summarize the data at various points in time. In addition, most institutions will likely need assistance summarizing and analyzing the results, and addressing the gaps. But at least we now have a framework, and that is a good start.

08 Jun 2015

Hot Topics Tom Hinkel 1 Comment

.Bank or .Bust? New Top Level Domain Promises Increased Security (and Plenty of Questions)

Bankers are being encouraged to register their domain names under the new .bank extension, and although there are reasons to consider making the switch, there are also many questions to answer. Registration is currently open for institutions with a trademarked domain name. Open registration begins June 23.

First of all, the regulators have not offered an opinion on this yet. It’s important to note that all of the encouragement is coming from the folks profiting from the registrations…the ABA, Symantec, ICANN, and the multiple registrars (to be determined). The least expensive registration I’ve seen is around $1,000 per year. Multiply that by the number of FDIC insured banking institutions* (currently around 6,400) and you get a minimum $6.4M of new revenue each year. So it’s easy to see why the proponents are excited…but what’s in it for you? Will the significant increase in effort and expense pay off?

The proponents claim that “.BANK will be a protected, trusted, more secure and easily identifiable space…” on the Internet for banking institutions. But converting will come at quite a cost to each institution, not just in terms of financial outlay, but time, energy and other resources as well. And in the end, will the claims of the proponents be realized?

“It’s easy to see why the .bank proponents are excited, but will the significant effort and increased expense pay off for institutions?”

Let’s examine each claim, starting with “.bank will be more protected“. It is true that there are multiple safeguards in place to prevent a non-qualifying business from registering a .bank domain. There are 7 categories of banks and banking organizations that are considered qualified for registration, so consumers can have some level of assurance that xxx.bank is indeed a “qualifying” business. So theoretically Bob can’t just start up a website called BobsBank.bank unless he is a bank, and in that sense the environment is more protected.

A more protected space goes hand-in-hand with another claimed advantage; an “easily identifiable space“. I’m not sure this is a net advantage though. Currently, if a bad actor wants to target a bank with malware (ransomware, for example) it has to determine that the website belongs to a bank. Yes this is trivial, but there is at least some security in obscurity. A .bank domain makes it crystal clear that the site is a bank, so you should expect an increase in spear-phishing attacks on .bank websites. Also, having the .bank target on your back might make DDoS attacks more common (and none of the security enhancements will reduce the incidence of DDoS). So the advantage of being “more protected” comes at a cost.

But the most often touted advantage of the new domains is that they are designed to be “more secure“. This is definitely a good thing if it can be achieved. Cybersecurity is a big concern for regulators right now, and anything that might enhance the security of the industry overall will be strongly encouraged. (Again, regulators have not come out with a position for or against .bank yet.)

Here are the most significant security enhancements, with pluses and minuses for each:

Security Enhancement	Stated Advantage	Additional Considerations
Mandatory Verification of Charter/Licensure for Regulated Entities	More restricted and potentially more protected space. No non-banks posing as banks.	Banks will compete for choicest names, may not get domain you request (i.e. an existing .com does not guarantee a .bank with the same name.) Creates an easily identifiable target environment.
Mandatory Re-verification of Registration Data	Ensures registrants maintain eligibility.	Must remember to re-verify every 2 years or may lose registration. Additional expense.
Domain Name Security Extensions (DNSSEC)	Ensures users that bank website is legit.	Most banks already use this feature.
Email Authentication	Ensures users that bank email addresses are legit.	Most banks already use this feature. Does not prevent spoofed incoming email or phishing.
Multi-Factor Authentication	Ensures that only authorized bank personnel make registration changes.	Theoretically useful, but most banks already have measures in place to prevent unauthorized registration changes.
Strong Encryption	Ensures security of communication originating at the website.	Most banks already have strong security measures in place.
Prohibition of Proxy/Privacy Registration Services.	Prevents anonymous registrants.	Registrant contact information will be readily accessible for all to see. May lead to increase in registrant spear-phishing attacks.
Domains must be hosted on .BANK Nameservers.	Ensure all .bank sites adhere to security requirements.	Theoretically useful, but may pose a challenge for banks that host separate informational and transactional sites (i.e. if the transactional site is hosted by a Core vendor.)

Finally, whether or not the new domain extension is “more trusted” depends on 2 things; the rate of adoption among all banks, and whether or not the security advantages are realized.

The jury is still out on the security advantages, but regarding the rate of adoption…

* NCUA insured institutions are apparently out of luck for now, at least until the .CREDITUNION domain becomes available.

29 Apr 2015

Hot Topics Tom Hinkel 6 Comments

FFIEC Issues Stealth Update to BCP Handbook

This caught me by surprise as it was not formally announced in the “What’s New” section, but the Appendix J update to the Business Continuity Planning Handbook apparently constituted a complete update to the Handbook. Here is what the press release said in part:

The Federal Financial Institutions Examination Council (FFIEC) members today issued a revised Business Continuity Planning Booklet (BCP Booklet), which is part of the FFIEC Information Technology Examination Handbook (IT Handbook). The update consists of the addition of a new appendix, entitled Strengthening the Resilience of Outsourced Technology Services. (emphasis added)

If you only focused on the last sentence (as I did), you would think all they did was add an appendix to the existing booklet. But the first sentence states that they issued a revised booklet. And sure enough, they changed the date.

Here is the old booklet:

Cover page from 2008 FFIEC_IT_Booklet_BusinessContinuityPlanning

And here is the new booklet:

Cover page from 2015 FFIEC_IT_Booklet_BusinessContinuityPlanning

I’ve written about the wide-ranging implications of “Appendix J” previously. In comparing the old and new BCP booklets I was unable to find any other changes in the document except the addition of Appendix J, and some changes to Appendix A. Regular readers know that each of the 11 booklets has an Appendix A which contains the examination procedures. The message here is that the FFIEC considered the addition of Appendix J significant enough to warrant new examination procedures, and a whole new handbook with a new revision date!

7 Reasons Why Small Community Banks Should Outsource IT Network Management

I’ve gone through Appendix A of both the new booklet and the previous booklet and highlighted all of the changes. If you’re interested in how your next BCP exam might differ, you can download a copy of my marked-up document here. The complete BCP Handbook is here.

← Previous 123…28 Next →