Outsourcing technology – Compliance Guru

04 Jun 2013

Hot Topics Tom Hinkel 1 Comment

Incident Response in an Outsourced World

UPDATE – On June 6th the FFIEC formed the Cybersecurity and Critical Infrastructure Working Group, designed to enhance communications between and among the FFIEC members agencies as well as other key financial industry committees and councils. The goal of this group will undoubtedly be to increase the defense and resiliency of financial institutions to cyber attacks, but the question is “what effect will this have on new regulatory requirements and best practices”? Will annual testing of your incident response plan be a requirement, just as testing your BCP is now? I think you can count on it…

I’ve asked the following question at several recent speaking engagements: “Can you remember the last time you heard about a financial institution being hacked, and having its information stolen?” No responses. I then ask a second question: “Can anyone remember the last time a service provider was hacked, and financial institution data stolen?”. Heartland…TJX…FIS…almost every hand goes up.

As financial institutions have gotten pretty good at hardening and protecting data, cyber criminals are focusing more and more on the service providers as the weak link in the information security chain. And wherever there are incidents making the news, the regulators are sure to follow with new regulations and increased reinforcement of existing ones.

The regulators make no distinction between your responsibilities for data within your direct control, and data outside your direct control;

“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.” (Emphasis added)

In other words, you have 100% of the responsibility, and zero control. All you have is oversight, which is at best predictive and reactive, and NOT preventive. So you use the vendor’s past history and third-party audit reports to try to predict their ability to prevent security incidents, but in the end you must have a robust incident response plan to effectively react to the inevitable vendor incident.

The FFIEC last issued guidance on incident response plans in 2005 (actually just an interpretation of GLBA 501b provisions), stating that…

“…every financial institution should develop and implement a response program designed to address incidents of unauthorized access to sensitive customer information maintained by the financial institution or its service provider.” (Emphasis added)

The guidance specified certain minimum components for an incident response plan, including:

Assessing the nature and scope of an incident and identifying what customer information systems and types of customer information have been accessed or misused;
Notifying its primary federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information;
If required, filing a timely SAR, and in situations involving federal criminal violations requiring immediate attention, such as when a reportable violation is ongoing, promptly notifying appropriate law enforcement authorities;
Taking appropriate steps to contain and control the incident to prevent further unauthorized access to or use of customer information; and
Notifying customers when warranted in a manner designed to ensure that a customer can reasonably be expected to receive it.

The guidance goes on to state that even if the incident originated with a service provider the institution is still responsible for notifying their customers and regulator. Although they may contract that back to the service provider, I have personally not seen notification outsourcing to be commonplace, and in fact I would not recommend it. An incident could carry reputation risk, but mishandled regulator or customer notification could carry significant regulatory and financial risks. In other words, while the former could be embarrassing and costly, the latter could shut you down.

So to summarize the challenges:

Financial institutions are outsourcing more and more critical products and services.
Service providers must be held to the same data security standards as the institution, but…
…the regulators are only slowly catching up, resulting in a mismatch between the FI’s security, and the service provider’s.
Cyber criminals are exploiting that mismatch to increasingly, and successfully, target institutions via their service providers.

What can be done to address these challenges? Vendor selection due diligence and on-going oversight are still very important, but because of the lack of control, an effective incident response plan is the best, and perhaps only, defense. Yes, preventive controls are always best, but lacking those, being able to quickly react to a service provider incident is essential to minimizing the damage. When was the last time you reviewed your incident response plan? Does it contain all of the minimum elements listed above? Better yet, when was the last time you tested it?

Just as with disaster recovery, the only truly effective plan is one that is periodically updated and tested. But unlike DR plans, most institutions don’t even update their incident responses plans, let alone test them. And while there are no specific indications that regulators have increased scrutiny of incident response plans just yet, I would not be at all surprised if they do so in the near future. Get ahead of this issue now by updating your plan and testing it. Use a scenario from recent events, there are certainly plenty of real-world examples to choose from. Gather the members of your incident response team together and walk through your response, the entire test shouldn’t take more than an hour or so. Answer the following questions:

What went wrong to cause the incident? Why (times 5…root cause)? If this is a vendor incident, full immediate disclosure of all of the facts to get to the root cause may be difficult, but request them anyway…in writing.
Was our customer or other confidential data exposed? If so, can it be classified as “sensitive customer information“?
Is this a reportable incident to our regulators? If so, do we notify them or does the vendor? (Check your contract)
Is this a reportable incident to our customers? How do we decide if “misuse of the information has occurred or it is reasonably possible that misuse will occur“?
Is this a reportable incident to law enforcement?
What if the incident involved a denial of service attack, but no customer information was involved? A response may not be required, but should you?
What can we do to prevent this from happening again (see #1), and if we can’t prevent it, are there steps we should take to reduce the possibility? Can the residual risk be transferred?

Make sure to document the test, and then test again the next time an incident makes the news. It may not prevent the next incident from involving you, but it could definitely minimize the impact!

NOTE: For more on this topic, Safe Systems will be hosting the webinar “How to Conduct an Incident Response Test” on 6/27. The presentation will be open to both customers and non-customers and is free of charge, but registration is required. Sign up here.

01 Nov 2012

Hot Topics Tom Hinkel 0 comment

FFIEC Updates Technology Service Provider Guidance

Just posted, the new Booklet rescinds and replaces the previous one issued in March 2003, and is the first Booklet replacement since Retail Payment Systems in 2010. In general this is not so much a complete re-write as a reinforcement of the importance the agency places on strong vendor management, which is a concept that we’ve seen from other recent FFIEC releases and updates.

So with all the similarity between this new publication and the one almost 10 years ago, I think it’s instructive to focus on the differences between the two to see how the FFIEC’s thinking has evolved. It also allows the institutions affected to know exactly what they need to change or adjust to remain in compliance.

First of all, both Booklets state the following:

“A financial institution’s use of a TSP (technology service provider) 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…”

and perhaps for extra emphasis the new Booklet adds the following verbiage:

“…just as if the institution were to perform the activities in-house.”

Nothing new here, all institutions are acutely aware that they bear full responsibility for the confidentiality, integrity and availability of their customer’s data regardless of where it may reside. This re-statement is perhaps insignificant by itself, but interesting when taken in combination with the next sentence:

Old guidance – “Financial institutions should have a comprehensive outsourcing risk management process to govern their TSP relationships.”

New guidance – “Agencies expect financial institutions to have a comprehensive, enterprise risk management process in place that addresses vendor management for their relationships with TSPs.”

What is significant here is the addition of the word “enterprise” to the risk management process, indicating that you must acknowledge that vendors carry multidimensional risks. These risks include not just operational risk (risk of failure), but strategic risk, regulatory risk and reputation risks as well.

However to me the most significant change in the guidance is in the sentence beginning with “…(the risk management) process should include…”, because this is what the regulators will expect from you. Compare these:

Old guidance – “Such processes should include risk assessment, selection of service providers, contract review, and monitoring of service providers.”

New guidance – “The risk management process should include risk assessments and robust due diligence for the selection of TSPs, contract development, and ongoing monitoring of all TSPs’ performance.”

It’s clear that regulators will expect much more from your vendor risk management process going forward. Not simply selecting a service provider, but robust due diligence in the selection process. Not just contract review, but contract development. And not just basic monitoring, but ongoing monitoring of all TSP’s performance.

The new guidance goes on to state that federal regulators expect technology service providers to be familiar with, and adhere to, not just this Booklet, but all 11 Booklets in the IT Examination Handbook series. One more reinforcement that there are not 2 standards of measurement…one for financial institutions and one for vendors…but only one. And that one same standard will be enforced by the same federal regulators that currently examine you.

The guidance goes on to describe how they will classify service providers (by size and criticality of the services they provide), and how that classification will determine who will examine them, and how often they can expect to be examined. As far as who can expect to be examined, any service provider that provides any of the following services:

Core application processors
Electronic funds transfer switches
Internet banking providers
Item processors
Managed security servicers
Data storage servicers
Business continuity providers

So pretty much anyone that provides an application, system, or process that is vital to the successful continuance of a critical business activity, or anyone that interfaces with a critical business system, can expect to be examined.

Aside from being more comprehensive, the actual examination process hasn’t changed much. Examiners will still scrutinize the AMDS (Audit, Management, Development and Acquisition, and Support and Delivery) components, and will still assign a 1 through 5 numerical score to each component with 1 representing the highest or best, and 5, the lowest rating or worst. Examiners will then use the component scores to determine the overall composite rating. Again, nothing new there.

So in summary, not a drastic change as much as a reiteration with amplification and clarification. Simply put, more of the same…more regulatory expectations for your vendor management program, which means more scrutiny by the examiners (for you and for your vendors), all of which means more effort on everyone’s part!

10 Jul 2012

Hot Topics Tom Hinkel 0 comment

FFIEC issues Cloud Computing Guidance

Actually the document is classified as “for informational purposes only”, which is to say that it is not a change or update to any specific Handbook and presumably does not carry the weight of regulatory guidance. However, it is worth a read by all financial institutions outsourcing services because it provides reinforcement for, and references to, all applicable guidance and best practices surrounding cloud computing.

It is a fairly short document (4 pages) and again does not represent a new approach, but rather reinforces the fact that managing cloud providers is really just a best practices exercise in vendor management. It makes repeated reference to the existing guidance found in the Information Security and Outsourcing Technology Services Handbooks. It also introduces a completely new section of the InfoBase called Reference Materials.

The very first statement in the document pretty well sums it up:

“The (FFIEC) Agencies consider cloud computing to be another form of outsourcing with the same basic risk characteristics and risk management requirements as traditional forms of outsourcing.”

It then proceeds to describe basic vendor management best practices such as information security and business continuity, but one big take-away for me was the reference to data classification. This is not the first time we’ve seen this term, I wrote about examiners asking for it here, and the Information Security Handbook says that:

“Institutions may establish an information data classification program to identify and rank data, systems, and applications in order of importance.”

But when all your sensitive data is stored, transmitted, and processed in a controlled environment (i.e. between you and your core provider) a simple schematic will usually suffice to document data flow. No need to classify and segregate data, all data is treated equally regardless of sensitivity. However once that data enters the cloud you lose that control. What path did the data take to get to the cloud provider? Where exactly is the data stored? Who else has access to the data? And what about traditional issues such as recoverability and data retention and destruction?

Another important point made in the document, and one that doesn’t appear in any other guidance, is that because of the unique legal and regulatory challenges faced by financial institutions, the cloud vendor should be familiar with the financial industry. They even suggest that if the vendor is not keeping up with regulatory changes (either because the are unwilling or unable) you may determine on that basis that you cannot employ that vendor.

The document concludes by stating that:

“The fundamentals of risk and risk management defined in the IT Handbook apply to cloud computing as they do to other forms of outsourcing. Cloud computing may require more robust controls due to the nature of the service.”

And…

“Vendor management, information security, audits, legal and regulatory compliance, and business continuity planning are key elements of sound risk management and risk mitigation controls for cloud computing.”

…as they are for all outsourced relationships!

09 Apr 2012

Hot Topics Tom Hinkel 1 Comment

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.

22 Feb 2012

Hot Topics Tom Hinkel 0 comment

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”:

Initial due diligence process
Review of third-party audit reports
Contract
Risk Assessment
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.