Tag: Vendor Management

09 Apr 2012

FFIEC Handbook Update – Outsourcing

The FFIEC has just added a section to the Outsourcing Technology Services IT Examination Handbook, and it should be required reading for financial institutions as well as any managed service providers.  The new section is Appendix D: Managed Security Service Providers, and it is the first significant change to the Handbook since it was released in 2004.  It addresses the fact that because of the increasing sophistication of the threat environment, and the lack of internal expertise, a growing number of financial institutions are (either partially or completely) outsourcing their security management functions to unaffiliated third-party vendors.

Because of the critical and sensitive nature of these security services, and the loss of control when these services are outsourced, the guidance stresses that institution must address additional risks beyond their normal vendor management responsibilities.  Specifically, more emphasis must be placed on the contract and on oversight of the vendor’s processes, infrastructure, and control environment.

The most interesting addition to the guidance for me is the “Emerging Risks” section, which is the first time the FFIEC has addressed cloud computing.  Although it is addressed from the perspective of the service provider, it defines cloud computing this way:

“…client users receive information technology services on demand from third-party service providers via the Internet “cloud.” In cloud environments, a client or customer will relocate their resources such as data, applications, and services to computing facilities outside the corporate firewall, which the end user then accesses via the Internet.”

Any data transmitted, stored or processed outside the security confines of the corporate firewall is considered higher risk data, and must have additional controls.  This would seem to infer that data in the cloud should be classified differently in your data-flow diagram, and have a correspondingly higher protection profile.*  It will be interesting to see if this will be the FFIEC’s approach when and if they address cloud computing in the future.

The guidance also has a useful MSSP Engagement Criteria matrix that institutions can use to evaluate their own service providers, as well as a set of MSSP Examination Procedures, which service providers (like mine) can use to prepare for future examinations.  In summary, financial institutions would be wise to familiarize themselves with the new guidance, after all to quote from the last line;

“As with all outsourcing arrangements FI management can outsource the daily responsibilities and expertise; however, they cannot outsource accountability.”

 

 

* A protection profile is a description of the protections that should be afforded to data in each classification.

09 Apr 2012

FFIEC Handbook Update – SAS 70 Transition

The FFIEC has just updated their online IT Examination InfoBase to address the AICPA phase-out of the SAS 70 reporting format.  All references to “SAS 70” have now been replaced, and the SAS 70 sections of the Audit and Information Security Handbooks have been completely removed.  Previously there were a total of 31 references to “SAS 70” in 8 different Handbooks.

I wrote about this a number of times, and speculated about when the FFIEC would update their Handbooks, and what would replace the term.  For the most part “SAS 70” has been replaced with “SSAE 16”, but there are also references to the SOC 2 and SOC 3 reports, as well as a more generic “other third-party review processes”.  I’m happy to see the FFIEC is allowing for more flexibility in the choice of vendor control reports they consider acceptable.  I’ve also made the case that although this does make the vendor management process a bit more challenging, institutions should welcome the transition.

22 Feb 2012

The single most important vendor management control

Pop quiz…according to the FFIEC Handbook on Outsourcing Technology Services

“The ________ is the single most important control in the outsourcing process”:

  1. Initial due diligence process
  2. Review of third-party audit reports
  3. Contract
  4. Risk Assessment
  5. Vendor’s financial stability

I’ve written before about the importance of the third-party review in the ongoing vendor management process (and how that changes with the phase-out of the SAS 70), and of course vendor financial stability can speak to the ability to continue to provide services.  And a vendor risk assessment has been an essential component of your Information Security Program since GLBA.  All of these are important, but according to the FFIEC;

“The contract is the legally binding document that defines all aspects of the servicing relationship. A written contract should be present in all servicing relationships.  This includes instances where the service provider is affiliated with the institution. When contracting with an affiliate, the institution should ensure the costs and quality of services provided are commensurate with those of a non-affiliated provider. The contract is the single most important control in the outsourcing process.

 I’ve already predicted that vendor management would become an area of increased regulator scrutiny in the coming year, and one of the first things they will be looking at are the contracts.  Actually, regulators asking to see vendor contracts is nothing new, but lately some have been examining these contracts for specific elements.  So here are the 18 elements that should be included (or at least considered) in all critical vendor contracts:

  • Scope of Service
  • Performance Standards
  • Security and Confidentiality
  • Controls
  • Audit
  • Reports
  • Business Resumption and Contingency Plans
  • Sub-contracting and Multiple Service Provider Relationships
  • Cost
  • Ownership and licensing
  • Duration
  • Dispute Resolution
  • Indemnification
  • Limitation of Liability
  • Termination
  • Assignment
  • Foreign-based
  • Regulatory Compliance

Not all contracts, even with critical vendors, will contain all of these elements.   But each of them represents an important factor for consideration as you negotiate (or re-negotiate), and your vendor risk assessment should ultimately determine exactly which elements you’ll require.

“The time and resources devoted to managing outsourcing relationships should be based on the risk the relationship presents to the institution. “

And unlike some risk assessments, where smaller financial institutions may have enjoyed less scrutiny because of their size and complexity…

“…smaller and less complex institutions may have less flexibility than larger institutions in negotiating for services that meet their specific needs and in monitoring their service providers.”

So smaller institutions may actually be in for a more rigorous vendor management review than larger institutions!

I’ve created a check-list of all contract considerations listed above, along with a brief description of each one.  I hope you’ll find it useful.  You can download it here.

06 Feb 2012

NIST releases new Cloud Computing Guidelines

Although not specific to the financial industry, the new guidelines provide a comprehensive overview of the privacy and security challenges of this increasingly popular computing model.  It’s worth a look by both financial institutions considering cloud-based services, as well as service providers, because NIST guidelines often wind up as the basis for new or updated regulatory guidance.

They start by defining the concept of cloud computing as characterized by the “…displacement of data and services from inside to outside the organization” and by correctly observing that “…many of the features that make cloud computing attractive, however, can also be at odds with traditional security models and controls.”   This pretty accurately summarizes the challenges faced by financial institutions as they consider, and try to manage, the risks of cloud computing…data and services are out of their direct control, but risks of privacy, security, confidentiality, data integrity and availability must be controlled.

NIST offers the following guidelines for overseeing cloud services and service providers:

  • Carefully plan the security and privacy aspects of cloud computing solutions before engaging them.
  • Understand the public cloud computing environment offered by the cloud provider.
  • Ensure that a cloud computing solution satisfies organizational security and privacy requirements.
  • Ensure that the client-side computing environment meets organizational security and privacy requirements for cloud computing.
  • Maintain accountability over the privacy and security of data and applications implemented and deployed in public cloud computing environments.

For financial institutions, all these guidelines should be addressed in your existing policies.  The privacy and security elements are mandated by GLBA, and should already be present in your information security program.  One of the required, but often overlooked, elements of your vendor management program is the requirement to strategically justify your decision to engage a cloud services provider, and periodically review and reaffirm that decision.  Understanding the cloud provider environment is indeed a challenge for financial institutions, and I have already addressed this, and some possible solutions, here.  I’ve also discussed why increased adoption of cloud-based services will likely make vendor management a topic of increased regulatory scrutiny in 2012 here.  Additionally I think that the new SOC 2 report will directly address many of the concerns facing institutions employing cloud-based services.

As for the FFIEC, I was surprised to see that a search of the word “cloud” on the IT Examination InfoBase turned up not one single mention.  The Handbooks are getting a bit dated…perhaps, given the importance of managing outsourced relationships, plus the increased challenges of cloud computing, they should address this next?  Or do you think the existing guidance on managing outsourced technology and vendors is sufficiently broad?

22 Dec 2011

FDIC offers “Insight” on Mobile Banking

Although not considered official supervisory guidance, the most recent FDIC Supervisory Insights newsletter offers an instructive early look into how the agency might examine this emerging electronic banking delivery method in the future.  (Before you tune out and decide to wait for the formal guidance, remember it was the Winter 2009 issue that first introduced us to the concept of the Enterprise-wide risk assessment as the preferred replacement for the traditional information security risk assessment.  I consider these Supervisory Insight newsletters to be a pretty accurate peek into the regulatory crystal ball.)

The article is titled “Mobile Banking: Rewards and Risks”, and is a fairly deep dive into this relatively new banking service.  Mobile banking is defined as the use of a mobile device, commonly a cell phone or tablet computer, to conduct banking activities.   The article starts by discussing the current, and estimated future, market for this service, quoting a survey placing the potential adoption of mobile banking at 38 million households by 2015.  Clearly, if institutions have not already considered adopting this delivery method, they certainly will in the near future.  They separate the mobile service offerings into 3 broad categories based on the delivery method:

  • Text messaging/short message service (SMS)
  • Mobile-enabled Internet browser
  • Mobile applications (apps)

They then discuss the channel-specific mobile banking risks, and this was one of the most interesting parts of the article for me:

A recent study looked at the security of four types of mobile applications – financial services, social networking, productivity, and retail.  The study focused on the types of sensitive data that mobile applications store on the device and whether these data were stored securely. Each application was rated “Pass,” “Warn,” or “Fail.” A “Pass” rating means sensitive data are not stored on the device or are encrypted.  A “Warning” rating means certain data are stored on the device, but this does not put the user at significant risk of fraud. A “Fail” rating indicates sensitive data, such as account numbers and passwords, are stored on the device in clear text, placing the user at an increased risk of identity theft or other financial fraud.

As you can see, although financial institutions had the highest “pass” rate for mobile applications, they also had uncomfortably high “warn” and “fail” rates.  (Also note the extremely high “fail” rates for social networking apps…this only confirms my concerns.)  Although they don’t go into great detail on the availability and proper use of controls to mitigate the risks, they do make the point that proper vendor management is key.  This is particularly true for community institutions who rely heavily, and almost exclusively, on the built-in controls provided by their product’s vendor.

But they also refer to the updated FFIEC Authentication guidance, stating that it “applies to mobile banking“.  This is a bit of a news flash, as the term “mobile banking” is not specifically mentioned anywhere in the updated guidance.  In fact this was one of the major criticisms of the update when it was released (although I disagreed).  I think it’s clear now that the FFIEC intended for the updated guidance to be broad enough include new and emerging technology, and that we shouldn’t expect a new update every time technology changes.  This also means that you should include mobile capabilities in your Electronic Banking risk assessment, as well as the associated controls.

So consider this an early Christmas present from the FDIC, and make sure to incorporate the mobile banking risk management concepts discussed in this article into your electronic banking risk assessment.  In summary:

Financial institutions are challenged to ensure their mobile banking service is designed and offered in a secure manner, and customers are made aware of steps they can take to protect the integrity of their mobile banking transactions.  (Edit – so does making customers aware mean mobile banking customer training will be a requirement?)

07 Dec 2011

2012 Compliance Trends, Part 2 – Vendor Management

In my first post in this series I discussed training (employee and customer) as a good candidate for increased regulatory scrutiny in 2012.  Although these posts are in no particular order, I had initially intended to list “Management” as the next trend.  However a comment made to me by a banker at a recent conference leads me to believe that vendor management has already started to emerge as an area of increased regulator focus, so I am making this trend #2.

Vendor Management

I’ve already posted numerous times on the importance of vendor management…most recently when risk assessing on-line backup vendors, and how the phase-out of the SAS 70 will affect vendor management (here and here), and I even selected it as a potential trend for 2011.  And all the existing reasons still apply, but a couple of fairly recent developments are pushing this issue up the priority list:

  • The increased popularity and adoption of new and emerging technologies, such as cloud computing,
  • New risks and new guidance in electronic banking,
  • The SAS 70 phase-out
  • Examiners are hearing these three words more and more; “…they handle that…“.

All these really go together.  Think about this…is there a critical product or service you offer that doesn’t involve a third-party relationship?  I’ve asked that question at a number of meetings and conferences this year and have yet to have anyone come up with an example.  And to further underscore the point, how many of your vendors have vendors of their own?

So more reliance on outsourcing means that examiners are hearing the phrase “they handle that” more often when they ask about data security.  But as we all know…

Management is responsible for ensuring the protection of institution and customer data, even when that data is transmitted, processed, stored, or disposed of by a service provider.1

In the past, saying “they handle that” to an auditor or examiner was usually followed up with “OK, let’s see the SAS 70 and financials on that vendor”.  You would produce the reports, and that was pretty much the end of that conversation, and indeed often the extent of your vendor management responsibility.  I believe this will change, and I’ve already gotten some validation on that.

Going forward expect examiners to ask to see your entire vendor management program, not just the third-party reviews and financials, and not just on select vendors.  Any vendor that could have access (even incidental access) to non-public information (yours or your customers) must be risk-ranked by your vendor management program.  And the process of evaluating vendors starts well before they become a vendor, when you are still in the pre-implementation stage.

Here are some of the essential, and yet often missing, elements of a vendor management program:

  • Have you conducted due diligence prior to vendor selection?
  • Have you documented that the product or service is in alignment with the goals and objectives of your strategic plan?
  • Is a BSCA filing required?
  • Are the vendor’s disaster recovery capabilities adequate to support your recovery time objectives?
  • Are vendor performance standards (SLA’s) clearly defined?
  • In addition to vendor access to NPI/PII, have you risk-ranked your vendors based on:
    • Access to other confidential (i.e. proprietary) information?
    • Criticality of the product/service they provide?
    • Complexity of the product/service?

Additionally, the new electronic banking guidance will force financial institutions to take a closer look at their Internet banking providers in order to conduct the required (starting in January) risk assessments.  When the examiner asks for your electronic banking risk assessment, and wants to know what layered controls have been implemented, you can not say “our provider handles that”.  The whole point of a risk assessment is to assure that you know, and are comfortable with, the residual risk.

And finally, the third-party report that will likely replace the SAS 70 for most service providers will be the SOC 2, and unlike the SAS 70 the SOC 2 is designed to be a deep dive into the control environment of the service provider.  Also unlike the SAS 70, financial institutions will have to actually review the SOC 2 document to assure themselves that there are no exclusions or other qualifications in the report, and to review the results of control testing (for a Type II).  And unless the service provider specifically excludes it from the report, you will also have a high degree of confidence that any sub-service organizations (providers to your provider) have an adequate control environment as well.

So for all these reasons, expect vendor management to be an increased regulatory priority in 2012.