80% Failure: FDIC Calls For More Controls in TPRM; A Look At Open Source Risk
Updated: Apr 8, 2019
On April 2, 2019, the FDIC released FIL-19-2019 entitled, “Technology Service Provider Contracts,” in which they implore banks through their Third Party Risk Management (TPRM) programs to ensure contracts contain provisions relating to: (1) business continuity; (2) recovery standards; (3) contractual remedies for failure to meet recovery standards; (4) security incident response capabilities; (5) undefined terms which create ambiguity and increase risk; and (6) Gramm-Leach-Bliley-Act safeguarding of non-public personal information through administrative, technical, and physical means to ensure the security and confidentiality of customer records and information.
This also cross-references existing guidance with greater detail about TPRM programs, specifically provisions one should expect in contracts, and identify during the due diligence process. TPRM programs help satisfy requirements outlined in FIL-49-99 relating to Section 7 of the Bank Service Company Act (12 U.S.C. 1867), for FDIC insured institutions to inform the FDIC of third party engagements for certain services including, "check and deposit sorting and posting, computation and posting of interest and other credits and charges, preparation and mailing of checks, statements, notices, and similar items, or any other clerical, bookkeeping, accounting, statistical, or similar functions performed for a depository institution." Id. However, that guidance was written in 2008, and the reminder notice before that was 1999. The Federal Trade Commission (a regulator of financial services prior to the CFPB, and somewhat today) last issued guidance on GLBA compliance in 2002 and 2006.
A 2017 report underlying the release from the FDIC Office of Inspector General found of service provider contracts:
Although supervisory guidance states that significant contracts should prohibit TSPs from subcontracting to another entity unless the institution determines that the subcontracting would be consistent with the due diligence standards used to select the TSP, the FDIC IG found that 80 percent of reviewed institutions allowing subcontractors failed to document subcontractor considerations within their TSP risk assessment matrix or due diligence reviews. The FDIC IG also found that 68 percent of reviewed institutions failed to include provisions to address risks associated with TSP access to sensitive or personally identifiable information.
Here’s the challenge
It’s 2019. What the FDIC didn’t anticipate in 1999, or 2008, when this guidance was issued is the combination of third parties involved in building one tech solution, and the associated risk of information sharing across these sub-parties without controls in place, a mechanism for identifying them, or even a basis for holding them accountable for misuse. However, this is something your TPRM must now address.
So really, how can we control for subcontractor risk in current TSP relationships where so much of the technology we now use contains open source software and cloud solutions?
Consider this scenario:
Let’s assume I build a custom solution through a software solution provider like Pivotal. I engage Pivotal by way of contract including a mutual NDA with GLBA provisions as well as a contract with SLAs intended to detail precise practices for safeguarding customer information and recovery times of any providers used. This language in the agreement then also extends by express reference to the agents of Pivotal; e.g. those persons Pivotal engages to perform work. I even include indemnifications for any data breach, while they offer representations and warranties that safeguards exist. I obtain a copy of their DR/BC plan and SOC2. My TPRM protocol for Pivotal is likely met.
Pivotal starts building my site and an app. It employs a tech stack to do so. Components of a tech stack are like a recipe with each part serving as an ingredient that needs to be introduced in proper order. In this stack, the programing languages, HTML, CSS and Java are just communication tools and display configurations. The web framework, database, server, OS, and other plug-ins are likely provided by separate third parties often and may contain code drawn from an open-source format to expedite the build. Open application program interface (API) simply means that, in building this application, the developer is going to use existing software code which is made available for distribution, and recognized as reliably able to perform the task it is written to perform. The OSS code is not necessarily a piece of the stack, but helps the stack function without re-writing code.
Now, for the functionality to integrate with your core or CRM, the OS in the stack is going to have to pull information from a root source which becomes an identifiable location, maybe a cloud computing service like MS Azure. When an action in the application calls for data, it will be retrieved from that cloud source.
What I’m saying is …
Your contract with Pivotal and the TPRM program in place will meet the GLBA requirements for safeguarding NPPI, but how can you know whether those same requirements are extended to downstream parties; subcontractors in the eyes of the FDIC. Subcontractors who likely have license agreements which expressly disclaim any agency relationship or liability for your use of their OSS code or other format. What if a provider of code identifies a bug which impacts security that makes your NPPI vulnerable? Who is accountable for the patch if your primary vendor is not the source?
MIT even provides an open-source license intended to protect developers. Believe it or not, this license actually serves as an stamp of credibility to the user because MIT has conducted a vetting process through its Technology Licensing Office. Though they may not test the code functionality, they likely test for infringement of copyright or patent filings. This ultimately adds some protection for your use because it is less likely to be interrupted by any IP dispute:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
What can we do to meet FDIC expectations in our TPRM programs under the FDIC requirements in a new age of technology?
Your first party technology solutions provider likely will not indemnify you against data breaches by persons other than agents which are also affiliates whom it can control. To the extent it relies upon other third party solutions or providers to build the stack for your application, you are likely not a third party beneficiary to those license agreements or broader service contracts. That is something to negotiate through your attorneys. In lieu, the following may be the only steps you can take in the due diligence process:
1) Ensure your TPRM includes a streamlined due diligence process for subcontractors of your first-parties;
2) Request the primary service provider identify any of its key third party service providers and include them as secondary providers within your TPRM, also inquire about the degree of dependency on this provider;
3) Request the primary service provider map or itemize what information will be shared with each downstream third party provider and whether it includes NPPI;
4) Whether any information shared with subcontractors will be encrypted, tokenized, accessed by Oauth authentication or similar;
5) Whether any secondary providers rely on cloud computing to operate your service and if so then their SOC controls, DR and BC plan;
6) Identify key pieces of open source code incorporated to determine its origin, then retain an inventory of providers of OSS source code and conduct a streamlined due diligence;
7) Whether developers followed applicable security guidelines;
8) Whether developers employed data validation processes;
9) Whether they maintain a process for proactively identifying and patching bugs;
10) Whether the code or program has been certified as secure by any independent third parties;
11) Which other institutions are utilizing the code without incident;
12) Any version history demonstrating major security incidents or patches;
13) If the code provider is using an MIT license was it actually vetted by the MIT TLO;
14) Identify any other license agreements available from any secondary providers for users of the platforms and review the safeguarding and indemnification provisions for those license holders, as well as any representations and warranties relating to the services;
15) If the downstream provider is not a licensor, but rather an engaged service provider, request a redacted copy of the contract governing your services to review for safeguarding and indemnification provisions, as well as representations and warranties upstream, and any undefined terms, e.g. words or phrases with material legal significance but not defined within the definitions section of a contract, and likely having little common law meaning;
16) Obtain cyber insurance for your institution and request copies of any liability insurance coverages for any known secondary providers, if possible; and
17) Draft your application terms and conditions to inform consumers of the potential risks associated with use of platform and have them acknowledge the risks.
The above is not advice, but a discussion you should be having with your internal IT, Risk and TPRM teams to understand your vulnerabilities in an open source environment. It's what the FDIC will expect to see during your next exam.