Risk Assessment – Compliance Guru

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.

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.

18 Nov 2014

Hot Topics Tom Hinkel 5 Comments

Vendor Management in 3 Parts. Part 2 – Risk Assessment (or, “will they or won’t they?”)

In Part 1 I said that vendor management, just as any other risk management endeavor, consists of 3 basic phases;

Identify the risk
Assess the risk, and
Control the risk

I also discussed why risk identification was a more difficult task today because of the “access to data” question, and also because “data” includes not just NPI, but confidential data as well. Everyone from your technology providers to the office cleaning crew could have access to non-public or confidential data, and as a result must be included in Phase 2; the risk assessment. The good news is that even though all vendors must be assessed, only a handful will required significant follow-up in terms of controls reviews (phase 3).

So in this post I will discuss how the risk assessment of vendors has changed over the last few years. Traditionally assessing a vendor was limited to determining the extent to which the vendor had access to (and could possibly disclose) non-public customer information (NPI). This grew out of GLBA, specifically the privacy and security elements of the legislation. Today regulators expect a much broader assessment of third-party risk. In addition to NPI, you must also assess vendor access to confidential information, such as HR records, Board reports, strategic plans and unaudited financials. You should also understand how a failure of the vendor’s product might affect your ability to deliver critical products or services to your customers. Does the vendor provide interdependencies to critical products? If they failed, how many of your services would fail too? Additionally, how difficult (costly & time consuming) would it be to find an alternate vendor, should the need arise?

In a recent speech to a community bankers group, Thomas J. Curry (current FFIEC chairman and Comptroller of the Currency) stated:

“While they have important benefits and are in many ways an essential part of business, it can be easy for financial institutions to become overly dependent upon third parties and overly-trusting. But just because these contractors have long client lists and hard-to-duplicate expertise doesn’t mean they are infallible.”

So vendor risk assessments really come down to determining “will they or won’t they?”:

Will they or won’t they…disclose customer NPI?
Will they or won’t they…disclose confidential information?
Will they or won’t they…fail?
Will they or won’t they…meet the terms of the contract?
Will they or won’t they…continue to meet our strategic objectives?
Will they or won’t they…properly manage their third-party relationships?

Once these questions have been addressed (i.e. asked and answered) you have a good idea of the raw, or inherent, risk level. Now you are expected to…

“…have risk management practices in place that are commensurate with that risk.”

Asking the right “will they or won’t they” questions are the key to accurately assessing inherent risk. The next step is to manage (i.e. control) the risk at acceptable levels. More on that in Part 3.

[poll id=”9″]

14 Oct 2014

Hot Topics Tom Hinkel 0 comment

Vendor Management in 3 Parts. Part 1 – Risk Identification (or, “do they or don’t they?”)

Service provider oversight (aka vendor management) is undoubtedly the hottest hot-button item on the regulator’s agenda right now, and for good reason. For one thing, regulators know that the vast majority of financial institutions outsource at some point, in fact recent studies put the number of FI’s that either transmit, process or store information with third-parties at over 90%. They also know that most recent cyber security incidents affecting financial institutions involved third-party service providers. (The Chase breach is a notable exception.) And increased scrutiny of your vendor oversight program has been cited as a focal point for the ongoing regulatory cybersecurity assessments. Clearly a new vendor management standard is here, and a new expanded approach is required.

I’ve broken the vendor management process into 3 parts, and all areas must be expanded;

Risk Identification
Risk Assessment, and
Risk Management

Again, all three areas have increased expectations. You are expected to manage the risks of third-party relationships the same way you manage internal risk, and step 1 is always to identify the source of the risk. This is relatively simple when all data is stored and processed in-house, but that doesn’t reflect the current outsourced model. So identifying the source of the risk means asking the following question about the third-party…“do they or don’t they have access to my information”?

“Access” means everything from incidental read-only (as in a piece of paper or computer screen), to full read & write. In other words, vendors that provide or support critical processes clearly must be assessed, but anyone that might be allowed in your facility could conceivably see something non-public or confidential. And the definition of “information” has evolved from strictly non-public customer information (NPI), to anything you consider confidential, such as Board reports, HR records, strategic plans, and unaudited financials.

But I think the biggest challenge for most financial institutions is in understanding exactly how to define a “service provider”. The traditional thinking was that only at a few key providers (like core) were defined that way, but the definition of “service provider” has definitely expanded. In fact the Federal Reserve issued a regulatory update in 2013 titled “Guidance on Managing Outsourcing Risk“. In it, they defined “service providers” as

“…all entities that have entered into a contractual relationship with a financial institution to provide business functions or activities”.

The OCC defined it even more broadly, stating in their 2013 update “Risk Management Guidance on Third-party Relationships” that;

“…a third-party relationship is any business arrangement between a bank and another entity, by contract or otherwise.” (Emphasis added.)

So expand your definition of “access”, and expand your list of providers to include all potential sources of risk… from your core provider to your cleaning crew, all third-party relationships with all levels of access should be assessed.

One more thing, don’t forget to assess vendors that may not have access to sensitive information, but have a high degree of criticality. More on that in my next post on Risk Assessment.

[poll id=”9″]

25 Oct 2013

Hot Topics Tom Hinkel 0 comment

Windows XP and Vendor Management

The FFIEC issued a joint statement recently regarding Microsoft’s discontinuation of support for Windows XP. The statement requires financial institutions to identify, assess, and manage the risks of these devices in their institutions after April 8, 2014. After this date Microsoft will no longer provide regular security patches or support for this product, potentially leaving those devices vulnerable to cyber-attack and/or incompatibility with other applications.

Identifying, assessing and managing these devices within your own organization is fairly straightforward. Have your admin or support provider run an OS report and present it to the IT Committee for review and discussion of possible mitigation options. But somewhat lost in the FFIEC guidance is the fact that you are also responsible for identifying and assessing these devices at your third-party service providers as well. While the statement was written as if it was directed at both FI’s and TSP’s separately, the FFIEC makes it clear that:

A financial institution’s use of a TSP 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, just as if the institution were to perform the activities in-house.

So my interpretation of the expectations resulting from this guidance is that you must reach out to your critical service providers and ask about any XP devices currently in use at their organization. If they aren’t using any, an affidavit from the CIO or similar person should suffice. If they are, a statement about how they plan to mitigate the risk should be made a part of your risk assessment. The fact that the FFIEC mentioned “TSP’s” five times in less than two pages indicates to me that they expect you to be pro-active about this.

One other thing that might have been overlooked in the guidance is this concept of operational risk. Many IT risk assessments focus exclusively on the information security elements in their risk assessments, i.e. access to NPI/PII. They only assess the GLBA elements of privacy and security. Operational risk addresses the risk of failure, or of not performing to management’s expectations. If your risk assessment is limited only to GLBA elements, expand it. Make sure the criticality of the asset, product, or service is assessed as well. And, when indicated by high residual risk, refer to your business continuity plan for further mitigation.

12…4 Next →