If there is a seismic shift happening at a breakneck pace, the financial industry is feeling it. Oh yes, new banking products, new ways to use blockchain, ledgers, crypto banking – the number of new initiatives and security products offered to customers have ballooned in the past few years. Banks usually thought to be the risk-averse, slow-moving pieces of a large economy now routinely have development teams working on new innovative projects and champion forward-thinking leadership positions.

In the effort to provide the services that the new generation of customers and businesses want, banks have had to also rethink their entire strategy for managing the risk of doing business. Before we jump into what are the changes that banks and financial institutions need to reconsider and ponder on, let us first understand where the guidance resides.

Traditionally, GLBA has been one of the primary resources that financial institutions have paid serious attention to. What specific guidance does GLBA provide to financial institutions?

Best practices for complying with GLBA

  1. Provide a privacy notice at all online application points.
  2. Ensure that opt-out notices and mechanisms are available at certain online information collection points.
  3. Implement security safeguards over the collection of financial information online.
  4. Ensure that personal financial information is not being passed to 3rd parties in contravention of sharing rules.
  5. Protect against any anticipated threats of hazards to the security or integrity of customer records.
  6. Protect against unauthorized access to or use of these records or information that might result in substantial harm or inconvenience to a customer.

Financial Information Letters

Another primary source for guidance and equally important has been the Financial Information Letters (FILs) from the FDIC. These letters are quite important as they are quite infrequent and contain significant amounts of information that help financial institutions understand and shape their long-term strategy. In the latest FIL posted on Aug 11, 2021, the FDIC has clearly recommended some interesting points that need to be considered.

  • MFA now needs to be more or less a de-facto option for controlling access to sensitive data. This is rightfully the correct direction to go towards. The next step would be for financial institutions to consider implementing MFA on the system to system communications, a.k.a API traffic so that if rate limiters are violated or the risk posture for system to system communication changes, the enterprise has a way to get alerted about the change, accept or deny the change in system to system communication.
  • Risk management principles need to be in place for information systems being accessed by employees, board members, third parties, and more.

The threat landscape portion of the FIL talks about how access to information via third parties combined with the increasing use of system-to-system communication via APIs is one of the most important threat vectors that institutions need to be planning for. In fact, the increased connectivity to third parties and dependency on external services forces businesses to be more conscientious in understanding the effect of exchanging data with third parties.

In fact the above lines up very nicely with the Risk assessment guidance provided in the same FIL – Inventory of Information systems, this includes the traditional catalog for laptops, servers, and other devices but also may include information system interaction with third party organizations. This means that there needs to be a way to identify and catalog all API calls being made to third-party suppliers. Furthermore, this cannot be a one-and-done approach, this needs to be a constant mechanism to scan for these types of interactions. 

Data aggregators and customer permissioned entities

Another interesting piece of guidance from the FIL talks about Data aggregators and customer permissioned entities. Specifically, this talks about some of the upcoming areas of concern where API tokens being used to authenticate against services need to be managed securely and permissioned properly. A comprehensive risk management program includes an assessment of risks and effective mitigating controls for credentials and API-based systems. For example, when the business communicates with a third party over APIs it may use API tokens. These third-party interactions should be secured by making sure the API tokens are stored safely and are not hardcoded in the codebase.

Bottom line is that for financial institutions who do look towards GLBA and FDIC FILs for guidance on how to secure their interactions with their partners, it is imperative to:

  • Catalog and understand who are your third party vendors
  • What APIs are being used to communicate with them
  • Are these API calls being secured appropriately with MFA
  • Are the mechanisms used to authenticate these API calls being secured properly, like not storing API keys in source  code

PCI and SBOM

If those were not enough acronyms to grapple with, get ready for some more: PCI and SBOM. PCI is yet another common standard in the financial industry and stands for “Payment Card Industry.” The purpose of PCI is to protect the entire payment card ecosystem by laying out a set of 12 security requirements designed to secure cardholder data and prevent data breaches. 

Software Bill of Materials (SBOM) has been around for a long time, but the recent SolarWinds vulnerabilities have dramatically increased the attention it. This led to an executive order from the Biden administration on cybersecurity with an emphasis on SBOM. An SBOM provides those who produce, purchase, and operate software with information that enhances their understanding of the supply chain, which enables multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks. SBOM will not solve all software security problems but will form a foundational data layer on which further security tools, practices, and assurances can be built. SBOM has become an increasingly common regulatory requirement, especially in highly regulated industries like the financial industry. In general, it is becoming a condition for doing business with a growing number of public and private sector customers.

This all sounds like a lot, but it is not all doom and gloom. SBOM, as it exists today, can already help with 3 of the PCI requirements, due to its focus on 3rd party library risk:

  • Regularly update and patch systems
  • Conduct vulnerability scans and penetration tests
  • Documentation and risk assessments

If an organization understands the scope of their 3rd party library usage, then they will be equipped to update 3rd party libraries (Requirement 1), which should help to reduce the vulnerabilities their software contains (Requirement 2), and they can document their 3rd party usage (Requirement 3). 

That is the SBOM of today, but what about the SBOM of tomorrow? We have already established that SBOM is becoming a common requirement in the financial industry, increasingly becoming an essential part of doing business with more customers in the public and private sectors, and has a particular focus on 3rd party library risk. However, there is another attack vector that poses a similar threat as 3rd party libraries. This attack vector is the APIs organizations use from their 3rd party vendors and is very relevant to the software supply chain that the SBOM aims to protect.

Organizations communicating with 3rd party software via their APIs has become nearly as commonplace as using 3rd party libraries in modern-day software, but unlike 3rd party libraries, you do not have the same level of control in remediating vulnerabilities with 3rd party software. You can bring your own 3rd  party vulnerabilities under control by updating them to less vulnerable versions, patching them yourself, or removing them but you do not control your 3rd party vendors’ security posture. To add to the risk, it can be a daunting task to try to keep track of what data you are sending to your various 3rd party vendors. Thus, given the relevancy and risk of APIs from 3rd party vendors to SBOM, it would be entirely conceivable that the inevitable SBOM v2 accounts for these.

Conclusion

Does this sound familiar? Earlier we stated that financial institutions who look to GLBA and FDIC FILs for guidance on how to secure their interactions with their partners must understand how they are interacting with APIs from their 3rd party vendors. PCI also happens to have a specific requirement related to these APIs – “Encrypt transmission of cardholder data across open, public networks”. If an organization understands which APIs are sending cardholder data to 3rd party vendors, then they will be better equipped to apply encryption where appropriate. Taking all of this into account, if the future of SBOM incorporates these APIs then it will become even more imperative to have a handle on this situation. You might even say that the present and future of SBOM help tie in some of the core standards in the financial industry: GLBA, FDIC FILs, and PCI.