Software and AppSec Challenges and Opportunities in Banking and Fintech — Part Two
In this, the second of three blog posts, we continue to examine the issues discussed in our recent webinar, “Software and Application Security Challenges and Opportunities in Banking.”
In the webinar, Rhys Arkins, Mend’s VP of Product Management, was joined by James McLeod, Director of Community of the Fintech Open Source Foundation (FINOS); Kate Stewart, VP of Dependable Embedded Systems at the Linux Foundation; and Amol Shukla, Executive Director of Engineering at Morgan Stanley, to discuss what measures the banking and fintech sector can take to secure their software and applications, and how they can reinforce security within the industry by pro-actively fostering a security culture.
We pick up from where we left off at the end of part one, when Rhys, James, Kate and Amol were talking about risk factors in the fintech sector, more on software bills of materials (SBOMs) and software supply chain attacks.
Are there any specific risk factors to consider for the health of a project, or are there things that are not always at the top of mind on the dependency tree?
Amol Shukla (AS): I think we have a pretty good sense of CVEs and security — things that have happened. The gap between when zero days occur and their detection is also reducing. The issue that remains is predicting the future. What other risk attributes can we take into account to anticipate issues, or at least be able to set thresholds, maybe based on the number of maintainers or the frequency of releases? If you know what the location of a maintainer may be, you can set different risk profiles for onboarding these types of dependencies.
A real step forward would be moving beyond security vulnerabilities that have happened towards having a broader range of attributes available so that you prepare for potential scenarios. Now, what makes sense for a bank might be different than what makes sense for a technology company, but just having the metadata about open source dependencies in particular would enable you to construct security policies in advance. That’s definitely one thing that would make a lot of difference.
Kate Stewart (KS): There’s a project called Community Health Analytics Open Source Software (CHAOSS), and they’ve got a risk working group. So, pulling in more of the metrics that are key for the finance sector will make sure we have standard definitions of these metrics that will help us automate security practices. And when you’re talking four hundred thousand projects a year, you want the automation and the dashboards in place.
Rhys Arkins (RA): Additionally, encouraging the publishing of open source and training programs are two great ways to attract and retain talent, especially in the finance sector.
What should the finance industry know about SBOMs and what is the current regulatory and governmental state of play with SBOMs?
KS: Going back to basics, a Software Bill Of Materials (SBOM) is a way of describing the software that may be on a system. The software is effectively components, be they source files, binary files, packages, and the relationships between them all. There are items that have dependencies in order to execute properly. So, mapping out all your dependencies for a successful execution or installation is part of trying to define what an SBOM is.
In the hardware sector, the concept of a bill of materials is well-known because when you ship a box you open it up and you get real materials in it. What we’re trying to do is get the same transparency in the software sector, so that whenever you are using some software you’ll know what dependencies it uses.
It’s not always clear what’s known. So, being able to identify what’s unknown is one of the things that working groups at the U.S. NTIA (National Telecommunications and Information Administration) have focused on for the last few years. They conducted a listening session with the White House last year, which resulted in the publication of an Executive Order about cybersecurity, and the definition of the fields that need to be addressed to reinforce security.
These are minimum requirements, and most of the risk criteria go way beyond that minimum. But at least things are progressing by getting these minimum requirements in play and starting to get the discipline to have them generated automatically for software going into organizations, and then figuring out what is acceptable to share outside of organizations.
This is how the ecosystem is transforming right now. Surveys last year indicated that there was a fairly good recognition of the term SBOM, and a lot of people seem to be motivated to start to adopt it. So that’s why you’re hearing a lot about it this year.
The tooling for producing SBOMs is definitely coming online. There are lots of great products coming in from various companies and from open source projects as well. And then there’s also tooling that’s starting to emerge for consuming them and adding knowledge to them, and it’s the consuming and adding knowledge is the area that’s being worked on.
From a regulatory standpoint, in particular the U.S. Government perspective, the Cybersecurity and Infrastructure Security Agency (CISA) is taking the lead on advancing the technologies, on how to explain whether or not you have a vulnerability that could be exploitable, and then how do you factor that risk into an SBOM.
They’re also looking at how we deal with cloud issues, how we get the tooling pervasive, and how people find the right tool for the right task. One of the areas I’m working on in the Software Package Data Exchange (SPDX) project is how we start to capture AI data, the training of materials and data, because in finance there is a lot of AI and knowledge about the heuristics, and we need to know how to capture that. I think we’ll see a bit of an evolution in this area within the next few months.
RA: Talking about regulation brings to mind the legendary Equifax incident from about five years ago when the company was dragged before the U.S. Government, because the patch to the vulnerability was available for three months before it was implemented, which was unacceptable. In comparison, fast forward four or five years to like the Log4j incident, the response was so fast it was almost like a pre-disclosure, and if you weren’t reacting within around three hours rather than three months then you were potentially going to have big problems.
In a perfect world where every third-party software that was consumed by the finance industry shipped with an accurate SBOM, how would that have changed a situation like this or people’s abilities to resolve such risks faster?
AS: That’s really the first important starting point. And at most organizations now, for internally developed software, enough progress has already been built to give us a pretty decent handle on what sort of dependencies are involved. The challenge is with third-party software, and in many cases not even open source.
If you get a third-party vendor’s zip file with an SBOM, you would at least know, for example, whether it actually contains Log4j. Then, you’ll be able to better understand that it’s running, manage the risks, and so on. Just knowing what the components are from a third-party is a good starting point, because I think most organizations have some sort of a policy for this type of risk. These are the applications that need these types of tests. And that’s where you know the push is coming from the likes of the Open Source Security Foundation (OpenSSF), and even the various governmental organizations.
Don’t miss the first part of this blog series on the challenges and opportunities of software and application security in banking and fintech. Read it here.
And look out for the final part of this series.
