cybersecurity

19 Oct 2016

Ask the Guru Holly Hooks 1 Comment

Ask the Guru: “The Cybersecurity Assessment Tool… Do we have to?”

Hey Guru!

Management is asking why we have to complete the FFIEC Cybersecurity Assessment Tool when it is voluntary. They feel it is too much work if it is not mandatory. I think it is still needed even though it is voluntary. Is there any documentation as to why it is still necessary for OCC banks to complete the Assessment?

The FFIEC issued a press release October 17, 2016, on the Cybersecurity Assessment Tool titled Frequently Asked Questions. This reiterated that the assessment is voluntary and an institution can choose to use either this assessment tool, or an alternate framework, to evaluate inherent cybersecurity risk and control maturity.

Since the tool was originally released in 2015, all the regulatory agencies have announced plans to incorporate the assessment into their examination procedures:

OCC Bulletin 2015-31 states “The OCC will implement the Assessment as part of the bank examination process over time to benchmark and assess bank cybersecurity efforts. While use of the Assessment is optional for financial institutions, OCC examiners will use the Assessment to supplement exam work to gain a more complete understanding of an institution’s inherent risk, risk management practices, and controls related to cybersecurity.”
Federal Reserve SR 15-9 states “Beginning in late 2015 or early 2016, the Federal Reserve plans to utilize the assessment tool as part of our examination process when evaluating financial institutions’ cybersecurity preparedness in information technology and safety and soundness examinations and inspections.”
FDIC FIL-28-2015 states “FDIC examiners will discuss the Cybersecurity Assessment Tool with institution management during examinations to ensure awareness and assist with answers to any questions.”
NCUA states “FFIEC’s cybersecurity assessment tool is provided to help them assess their level of preparedness, and NCUA examiners will use the tool as a guide for assessing cybersecurity risks in credit unions. Credit unions may choose whatever approach they feel appropriate to conduct their individual assessments, but the assessment tool would still be a useful guide.”

Even though the FFIEC format is officially voluntary, the institution still has to evaluate inherent risk and cybersecurity preparedness in some way. Therefore, unless you already have a robust assessment program in place, we strongly encourage all institutions to adopt the FFIEC Cybersecurity Assessment Tool format since this is what the examiners will use.

NOTE: The FAQ also made it clear that the FFIEC does not intend to offer an automated version of the tool. To address this, we have developed a full-featured cybersecurity service (RADAR) that includes an automated assessment, plus a gap analysis / action plan, cyber-incident response test, and several other components.

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:

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.

31 Mar 2015

Hot Topics Tom Hinkel 0 comment

FFIEC Issues 2 Statements on Cybersecurity

Both statements address recent cybersecurity threats; one targeting online credentials (passwords, usernames, e-mail addresses that may be used by employees or customers to authenticate themselves), and one addressing destructive malware. The statements advise specific risk mitigation steps institutions should consider, and I thought it would be instructive to compare the steps to see which are common to both threats (highlighted in bold).

The statement on compromised credentials lists the following risk mitigation steps:

Conduct ongoing information security risk assessments.
Perform security monitoring, prevention, and risk mitigation.
Protect against unauthorized access.
Implement and test controls around critical systems regularly.
Enhance information security awareness and training programs.
Participate in industry information-sharing forums.

The statement on destructive malware lists the following steps:

Securely configure systems and services.
Review, update, and test incident response and business continuity plans.
Conduct ongoing information security risk assessments.
Perform security monitoring, prevention, and risk mitigation.
Protect against unauthorized access.
Implement and test controls around critical systems regularly.
Enhance information security awareness and training programs.
Participate in industry information-sharing forums.

As you can see there is a core set of 6 steps, or controls, that are common to both threats. I’m certain that you can expect them to be a part of the FFIEC cybersecurity self-assessment tool and policy updates when they are released later this year. Forward thinking institutions would be wise to evaluate their cybersecurity controls now and make sure all 6 are in place, up-to-date, and functioning properly.

← Previous 123 Next →