This blog is the first of a three-part series.
The banking and fintech industries live and die on the reliability of the online services they offer. It’s vital that the sensitive data that the industry handles is robustly protected, and that the software and applications that it uses are secure.
For effective software and application security, it’s critical that banking and fintech organizations rapidly detect, identify, and remediate software vulnerabilities. This is particularly important with open source software, which is increasingly prevalent in the sector.
In our recent 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. They discussed the challenges and opportunities of software and application security in banking and fintech. In this blog post, we’ll take a look at the issues they covered.
Amol Shukla (AS): What is different for banks is that there is a much higher regulatory as well as internal set of risk controls and expectations. There are lots of processes and internal policies that we need to consider to make sure that the software that’s being built is secure. So, the landscape is generally more risk-averse than it is at some other tech companies. And the increase that we have seen in cyberattacks and zero-day vulnerabilities like Log4j has now resulted in more scrutiny from both external regulators, as well as internal risk groups.
Our business and stakeholders want to make sure that we address these security concerns correctly, along with the broader software supply chain risks that are shared with the rest of the industry. For banks and for groups like mine at the bank, the issue is, how do we balance development productivity with these security requirements? That’s a really key challenge for us because we do want to make sure that all of our development community can leverage and keep up with all the advances that are happening in the industry so that they happen in a safe way and are aligned with the controls we have in place.
Rhys Arkins (RA): Obviously the amount of regulation facing finance is high, and your risk aversion naturally needs to be quite high as well. But we also have to keep in mind that finding and retaining developers is a challenge for everyone and not unique to finance. If you’re trying to retain developers while putting extreme levels of security controls on them, no doubt that increases the challenge. So, I assume that a common theme across the industry is how to find that balance.
James McLeod (JM): You need to be able to attract and retain engineers in banking, so you need to make sure that the engineers inside banks remain engaged. You don’t want to be working within a team, where the world is moving on outside of your bank, but you’re inside a kind of bubble in which software engineering slows down or doesn’t keep up with the pace of change because of institutional caution.
We need to understand why security is important in banking. Retail banks deal with consumers on the front end, through mobile banking, current accounts, mortgages, navigating payments, and making sure that loans, credit cards, and everything that you may hold within the bank is safe. In fact, people use banks to keep their money safe. Nowadays, this may not mean in a vault or a strong box, it means digital security.
Therefore, the technology within the industry needs to be accountable, to ensure that we’re all kept safe when performing everyday transactions. That’s why security should be top of mind for everybody in the industry.
What’s really interesting is how this need for security works within agile practices, working with cybersecurity teams within infrastructure in banks, because there are people out there who want to get access to this stuff. It’s down to us to be knowledgeable about how to keep them out and understand the outcomes if something does happen. So, it’s really important that we understand the risk that the industry faces and how we respond with regulation and policy.
RA: The increase in supply chain attacks, particularly in finance, is one of the leading areas that bad actors are hoping to exploit. If they find software that’s more commonly found in finance, they will try and attack that.
Kate Stewart (KS): This is where knowing exactly what you’re running on your systems as part of a software bill of materials (SBOM) starts to become a roadmap for the defender rather than the attacker, because you actually know where your risks are. And the finance sector is obviously very keyed-in on additional risk factors and marries that information with the software information in the supply chain.
AS: There are other industries, automotive, for example, or insurance or healthcare, where the implications of supply chain attacks are probably about the same as they would be for banks. And I think we do look at what sort of solutions exist externally. For example, there was recently an open source project by New York-Presbyterian hospital and healthcare, around getting better insight into dependencies, that we could learn from. So, absolutely we cannot address this in a silo as just one industry. Everyone is consuming open source software, so we should collectively work on this problem because the solutions are very much shared across all of these sectors.
KS: The project is called Daggerboard, and it was created as part of a proof of concept of medical device manufacturers sharing information with hospitals about what goes on in their devices. Obviously, when you’re working with medical devices, there’s a lot of criticality associated with that and the safety side. And there are a lot of risk factors, so monitoring the vulnerabilities is something that the team at New York Presbyterian is starting to do. This includes compiling SBOMs, and matching them up with the vulnerabilities and monitoring them. What they ended up doing was open sourcing the project so that other organizations who didn’t have big IT teams could get the same sorts of capabilities to be able to do that. The medical device industry and the energy sector care about a lot of these things. Indeed, we’ll see a lot of interest in aspects of risks in any environment in which there’s regulation.
RA: One example of this is compliance with the Health Insurance Portability and Accountability Act (HIPAA). The healthcare sector is a target of attack precisely because of the regulatory outcomes if it gets compromised and because the value of finding or creating and exploiting a vulnerability is quite high.
AS: Open source is used extensively across the tech stacks in finance, not just for libraries and modules used for application development with infrastructure components, and the rate at which open source is getting adopted is only increasing. For instance, we’ve just finished the third quarter of the year and we’ve on-boarded upwards of 400,000 open source modules since the start of the year. That’s a very large number, and I don’t see this rate decreasing. Consequently, the integrity of the software supply chain is a key concern for us because there is this much use of open source.
JM: Open source within banking is everywhere in production software and the internal infrastructure being used to develop software. There’s automation from open source contributions and in open source teams, all the way through to hybrid cloud.
It’s the hybrid cloud where the banks are actually pushing the production of software, whereas before it was used for development, all the way through to the mainframe. Now, we’re seeing containerization on the mainframe. We’ve got an open mainframe project that is being run as well, so open source is actually being developed throughout finance organizations.
One of the common use cases for open source within banking is digital transformation, to create cost savings, improve efficiency, and accelerate engineering. Without that, we’d have big teams, working within banks, developing their own software multiple times and duplicating them globally, and that just can’t happen. There simply aren’t enough engineers in the world to do that, and replicating similar or identical software is an unnecessary waste of time and resources.
RA: I think everyone agrees that the perfect role for open source is to collaborate, but if you put all your technologies out in the open, then you can expose yourself to risk and potentially make your organization insecure. So, what are the changing attitudes to inbound open source use, rather than outbound? How are finance companies trying to balance this issue by segmenting away certain components, so that the code and the applications are protected by design?
JM: There are a lot of training materials on how to run a fully secure open source that are specifically targeted at maintainers. So, there are loads of best practices to call upon. And the Linux Foundation team keeps on top of all of the endeavors to keep open source projects safe. FINOS has plenty of members, including banks and technology companies, who contribute to these efforts because banking takes this issue extremely seriously.
KS: There has been a lot of focus on this. There were surveys done in 2021 to try to understand the state of readiness and understand the landscape of maintainers. The key insight was that maintainers probably spend less than five percent of their time on security. They really don’t want to spend much more than that, so we need to make it as easy as possible for them to understand what good practices are and figure out how we can make security ubiquitous throughout the ecosystem.
The Open Source Security Foundation (OpenSSF) supports efforts to publish guides on secure coding best practices for developers. Also, free training has been created, so that developers can walk through these practices and certify that they’ve completed the training. The course is called “Developing Secure Software LFD121” on the Linux Foundation site.
We’re trying to make resources such as these available to developers so that it’s easier for them to do the right thing from the start, and also have a place for a community in which they can ask questions.
The OpenSSF is also leading initiatives on how we get SBOMs everywhere and how we make sure developers are following best practices in open source projects as a way of reducing the risk in these projects.
AS: Half of my team has already taken the training component that the OpenSSF has launched. I can’t say enough good things about it. Feedback has been great and we really need a lot more of this type of benchmark, so that we know we can set levels as an application development community and as risk managers.