Software and AppSec Challenges and Opportunities in Banking and Fintech — Part Three
Third of a three-part series
Application security is particularly important in the banking and financial technology sector, where a single breach can put large portions of sensitive information at risk. How to manage that risk is a complex process that affects how teams secure applications across their software supply chain. In a recent webinar, Rhys Arkins, Mend’s vice president of product management; James McLeod, director of community of the Fintech Open Source Foundation (FINOS); Kate Stewart, vice president of dependable embedded systems at the Linux Foundation; and Amol Shukla, executive director of engineering at Morgan Stanley dove into this topic, from the role of a Software Bill of Material (SBOM) to the importance of context for the conclusion of their fascinating discussion.
How does the banking and fintech sector manage risk? How does it distinguish between security or vulnerability management and risk management?
Amol Shukla (AS): We previously talked a lot about software supply chain and dependency hygiene. But there’s also adding context to that information, such as what’s actually running in production that potentially poses risks. Let’s look at what’s internet-facing. This should be married with the information that you get from various static and dynamic analysis tools.
Most organizations need to know the context of what code they’re employing so they can conduct triage if necessary and make decisions based on this information. This is particularly important when something like Log4j happens because you have a limited amount of time to react in these scenarios. In a way, it’s risk prioritization, maybe more so than risk management.
Rhys Arkins (RA): When it comes to Software Bill Of Materials (SBOMs), I think the concept has an important role to play, but I think it’s also for us to set expectations about what it is not, and also what it is not yet, because we don’t want to give people the perception that as long as everyone starts using them we’re all secure suddenly.
The key: understanding risk in context
Kate Stewart (KS): A lot of the work of understanding your components, the relationship between them, and how things have been assembled, comes from the open source perspective, at least for licensing. If you’re using open source, and there’s a specific license associated with it, you need to conform to the terms of the license. This means there is a need to track all this information.
When Android started to make an impact, we needed to really get up to scale, to be able to share this information with others. So, the need arose for sharing information about the software components, how these things all connect, and what the dependencies are. This need has existed for a long time. Having a similar understanding of dependencies, and how they all fit together, is what security people need in order to make accurate judgments.
They need to understand whether something is a static dependency or it’s a dynamic dependency. Could it change? How has this all been put together in containers? These things have evolved, and they continue to do so. There are a lot of very interesting technologies. We just need to keep evolving the format of SBOMs and the information they convey.
But with SBOMs, you can at least know the dependencies in a relationship and know where the known unknowns are. For risks, you need a lot more information. Some of the formats have that already in them. and others allow you to add them in. It’s just a hard task to figure out where people want to take their policy engines and what they want to consume to work things at scale.
RA: Another consideration about SBOMs is that they help to build a risk profile, but they don’t necessarily present a master list of vulnerabilities that impact you. Some people will say that even if you produce an SBOM at the time of shipping, it’s going to be out of date. So, it might tell you that there’s no possibility of vulnerabilities. Then, a week later there is a critical run.
KS: This tension has been there for a while, and the U.S. government has basically tried to separate out the vulnerability because it has a different life cycle. Day zero starts the clock ticking and the information, whereas when you ship a product, that becomes day zero. There’s a fundamental disconnect of timelines between them. So, we need ways of linking the vulnerabilities back to the SBOMs and the SBOMs are there for the audit. When someone’s doing audits, they may want to know what’s there, or what has been known at a point in time, especially in the regulatory space. But for the most part, there are completely different life cycles. So what Mend is doing is right in line with this. We need to have the ability to show scenarios at different paces.
James McLeod (JM): When we’re talking about financial services and auditing them, that has to be positively regulated. Regulators would love everything to be evidence. SBOMs also remove the amount of effort that’s needed by engineering to be able to provide it. So, if I’m suffering a shift with an SBOM that you know breaks down all of your interrelated dependencies, then that can go straight into wherever you are collecting your evidence through automation, and then be provided to the regulator.
Another use case for open source is the consumption of open source software, where procurement teams might be looking at black box systems in order to provide functionality for banks.
Something that I’ve previously advocated is procurement schemes to look at open source alternatives to vendor-specific black boxes. That’s because SBOMs and open source allow engineers to have accountability and have eyes on everything that’s actually being consumed; whereas if you’re consuming something which is shipped through an executable, you don’t have a clear line of sight of what you’re actually consuming. The SBOM can provide you with that, but I’ve always thought that it’s good to see inside the project that you’re running inside your bank, even with some vendor support. This is where open source can actually give more evidence to engineers who are using software because you can see what’s written, and what’s being consumed and used.
What challenges to software and application security does the banking and fintech sector face, particularly indirect supply chain attacks, and what are the solutions for these challenges?
RA: There’s a lot of open source which is useful for finance, and it’s probably the first level of attack. But it’s not limited to that. Attack vectors could be any popular library that’s used, whether it’s financial, healthcare, or in other sectors. And it’s not just libraries that are targeted, but private software like SolarWinds, which was targeted probably because of the type of customers it has. It goes to show it’s not just limited to open source. So, I’m curious about this shift to the indirect attack approach to software supply chains.
JM: And we can address the question about security concerns for those who are creating and publishing open source software for others to use?
AS: This is very much a key area of concern, and the sort of concern that we see from our regulators, especially in the past. So, things like provenance, which we were always cognizant of, but are now being asked to demonstrate in response to these sorts of questions, are very much front and center,
Because we use a fair amount of open source software, we expect that open source contributors are doing certain things like making sure that they’re staying current with their dependencies so that they can respond quickly. They should have some sort of security policies and advisories that are enabled. They should have security checks, and maybe even tools like the scorecard project for the Open Source Security Foundation (OpenSSF).
This is so we have a higher degree of confidence in what software we consume. These things are some of the criteria that we use to decide whether particular open source components should be allowed, in addition to obvious things like licensing and any active security. They will give any users and consumers that extra degree of confidence, which is very important, given broader supply chain concerns.
RA: An important goal for us all is to raise the bar of quality and security, but not raise it to a point that it makes it prohibitive for people to still publish and contribute to open source. We want to make the tooling and the automation available and a lot of Linux Foundation programs on OpenSSF aim to do that.
KS: I encourage developers to take advantage of the training materials available for them to learn about best practices and familiarize themselves with the concepts. They should become aware that it’s more than just the libraries that should be considered. It’s also how some of the operating systems and the toolchains are built and assembled, each of which is vulnerable. We need the entire ecosystem to follow best practices to make ourselves hardened over time.
JM: The OpenSSF training isn’t just for developers. There’s a lot of reference material in there for scrum masters and product owners, and maybe even people who are doing code reviews. That’s because everybody who’s part of an open source team, even outside of development, is accountable for making sure that software engineering best practices are being followed.
Make sure that people are following the training material and getting their badges. They’re best practices that people will know, but it just ensures that we’re accountable to those in the open-source world, as well as internal development.
Taking a community approach to security
RA: You can broadly divide security challenges into three categories: those you can solve yourself, internally; those that require the expertise of a vendor; and those that can benefit from a community approach. Even as a vendor, if you can get things done in a community scenario, it’s a great approach. So, for anyone who’s in finance and cares enough about open source security, FINOS does a pretty good job and provides a good jumping-off point for collaboration across the industry between like-minded individuals who understand the burden of regulation.
JM: Indeed. FINOS is the fintech open source foundation. We are the financial services vertical with the Linux Foundation. So, we bring in a lot of our colleagues from different foundations and projects and we bring to the forefront the security conversation about open-source, SBOMs, and everything that we’ve discussed.
Don’t miss the first two parts of this blog series on the challenges and opportunities of software and application security in banking and fintech.
Read part one here. Read part two here.
