Category: Hot Topics

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



7 Reasons Why Small Community Banks Should Outsource IT Network Management



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.

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.

10 Feb 2015
Hot Topics Tom Hinkel 1 Comment

FFIEC Issues Update to Business Continuity Guidance

The FFIEC just issued new BCP Guidance in the form of a 16 page addendum to the existing 2008 IT Handbook on Business Continuity Planning. It is titled “Appendix J: Strengthening the Resilience of Outsourced Technology Services”, and it has significant implications for both financial institutions and service providers, and across the entire business relationship between the two.

The following excerpt summarizes the intent of the update pretty succinctly:

A financial institution should be able to demonstrate the ability to recover critical IT systems and resume normal business operations regardless of whether the process is supported in-house or at a TSP (technology service provider) for all types of adverse events (e.g., natural disaster, infrastructure failure, technology failure, availability of staff, or cyber attack).

The appendix is focused on third-party Technology Service Providers (TSP’s), and organized in four sections (with associated sub-sections):

  • Third-party management
    • Due Diligence
    • Contracts
    • Ongoing Monitoring
  • Third-party capacity
    • Significant TSP Continuity Scenarios
    • TSP Alternatives
  • Testing with third-party TSP’s
    • Testing Scenarios
    • Testing Complexity
  • Cyber resilience

Assuming that you already have a relatively compliant* business continuity plan, I see several areas that may need immediate attention:

  1. Vendor management.  Expect expanded vendor pre-contract due diligence and on-going oversight, including a detailed understanding of how the vendor manages their subcontractors.  The guidance also introduces the concept of “concentration risk”, which is the increased use of, and over-reliance on, one or more key service providers.
  2. Contracts.  Expect increased contract requirements, including provisions related to subcontracting (see above), the right-to-audit, data ownership and handling, and how the servicer plans to respond to new guidance and regulations.
  3. Testing.  Expect an expanded testing section, including participation in critical vendor testing.
  4. Cyber security.  Cyber events should be factored into all aspects of your BCP, with emphasis on responding effectively to a cyber attack.  Expect your incident response planning and testing to get increased scrutiny as well.

There is one more element of the guidance that may prove to be the most challenging of all for outsourced institutions.  In the past, manual procedures were always the primary alternative to automation, but because of the increased dependence on outsourcing, it may no longer be feasible for an institution to operate manually for any length of time.  In those situations the guidance suggests that you have an alternative service provider identified to assume operations, or that you consider the possibility of moving the operations in-house.  Since the guidance admits that the latter option is likely not a valid one, that really only leaves the alternate provider as a possible solution.  Of course any institution that has converted their core system to a new provider knows that process is fraught with challenges even when the conversion is anticipated and carefully planned.  Undertaking the process after a sudden disruptive event is almost unthinkable, but the guidance expects you to going forward.

 

* A compliant BCP is built around a business impact analysis which identifies all critical business processes and their interdependencies, establishes clearly defined recovery time and recovery point objectives (RTO’s & RPO’s) for each process, specifies recovery procedures sufficient to restore process functionality within RTO’s, and then validates all procedures via testing.

02 Dec 2014
Hot Topics Tom Hinkel 0 comment

Vendor Management in 3 Parts. Part 3 – Risk Management (or, “can we or can’t we?”)

The last step in the vendor management process is to manage, or control, the risk that was identified in step 1, and assessed (as inherent risk) in step 2.  Controlling risk is defined as applying risk mitigation techniques (or “controls”) to reduce risk to acceptable levels  It’s important to understand that risk can never be completely eliminated, particularly third-party risk.  The goal of this last step is to understand the remaining risk, referred to as “residual risk”, and to decide if this residual risk level is acceptable to you.  Everything that has been done thus far in the risk management process has been building up to this point.  But you may not be done yet.  If residual risk is not necessarily within the “acceptable” range, additional controls must be implemented to further reduce risk to an acceptable level.  Think of step 3 as a cycle; apply controls, evaluate residual risk, if residual risk is not acceptable, apply additional controls.  Repeat until residual risk is acceptable.

So the risk management process begins by asking a series of “can we or can’t we?” questions (all of which should be answered “yes”):

  • Can we or can’t we…assure ourselves that the vendor understands the unique regulatory environment of financial institutions?
  • Can we or can’t we…gain an in-depth understanding of what the vendor is doing to protect our information?
  • Can we or can’t we…trust the vendor’s description of their controls, both what they are, and how effective they are?
  • Can we or can’t we…accurately measure the residual risk level of this vendor relationship, and…
  • Can we or can’t we…come to the conclusion that the residual risk level of this vendor is acceptable?

The answer to the first 2 questions depends on A.) how familiar the vendor is with the regulatory requirements of financial institutions, and B.) how forthcoming the vendor is about their internal processes that relate to information security.  As the FFIEC recently stated regarding outsourced cloud computing (but applying equally to all third-party providers):

Managing a cloud computing service provider may require additional controls if the servicer is unfamiliar with the financial industry and the financial institution’s legal and regulatory requirements for safeguarding customer information and other sensitive data. Additionally, the use of such a servicer may present risks that the institution is unable or unwilling to mitigate. One example of such risks would be if the servicer is not implementing changes to meet regulatory requirements. Under such circumstances, management may determine that the institution cannot employ the servicer.

 So if you can’t answer “yes” to the first 2 questions about the vendor’s familiarity with financial institutions and whether they will be forthcoming about their controls, then the answer to the last question about acceptable risk is most likely “no”.

Regarding the third question about trust, third-party audit reports are the best way to gain assurance that vendor controls are both adequate and effective.  SOC reports give third-party validation that financial reports (SOC 1) and information privacy, security, confidentiality, availability and integrity (SOC 2) are both adequate (Type 1) and effective (Type 2).  Without this validation all you have is the assertion of the vendor, which is inadequate for high-risk vendors.  For third-party providers that either process, transmit, or store customer data, a SOC 2 Type II report is essential.

One more thing about controls…you should do everything you can to match the control to the risk.  For example, if there is a high degree of complexity in the service the vendor provides, identifying an alternate vendor is important.  If the criticality is high (as defined by the recovery time objective of any interdependent services), then you should insist on a copy of the vendor’s business continuity plan and testing results.  Audited financials are also important for all critical contracted services to assure that the vendor has the financial strength and stability to honor the terms of their contract.  And as I mentioned previously, a SOC 2 report is essential if the vendor processes or stores customer NPI.

To summarize the entire 3-part vendor management process:  First, you must identify the source of the risk.  In other words, the vendors you utilize along with their associated products and services (more here).  Second, each vendor must be assessed for risk…risk arising from access to customer NPI and confidential data, risk arising from vendor failure, risk arising from vendor criticality and complexity (more here).  Finally, controls are applied to reduce risk down to an acceptable level.  Follow this 3-part approach when you tackle vendor management internally… and demand it from your provider if you outsource the process.

 

 

[poll id=”9″]

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;

  1. Identify the risk
  2. Assess the risk, and
  3. 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″]

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