How to Secure Financial Services Applications

Technology has dramatically transformed the financial services industry in the last decade, ushering in a new ecosystem of digital payment platforms. A good proof point of this evolution is the rapid growth of payment service Venmo, which processed $159B in payments in 2021, a 59% year-over-year increase. Though this growth is remarkable, it isn’t the only growth metric we should be concerned about. Consumer and business expectations are also growing considerably as well.

With that said, greater expectations have created the ‘need for speed’, causing development teams to build and iterate applications at a faster pace. But this haste presents a serious challenge to the development organizations building them – notably around security. At the core of this innovation in financial services lies application programming interfaces, or APIs. APIs connect the microservices within banking applications and facilitate operations. This makes APIs a prime target for hackers to exploit. And as the number of applications and connections increases, so does the API attack surface. When you couple that with the fact that developers are working faster, likely sacrificing code quality in the process, the risk of a breach multiplies. 

In the 2021 IBM Security report, it is estimated that the average cost of a financial services security breach reached $4.24M. But there are also other costs that can’t be easily tabulated since reparation is a function of a longer period of time. For example, the time it takes to build back an organization’s reputation and trust with third party vendors, consumers and investors can’t be measured in a short span because it takes years. 

Next, there is the issue of compliance. Any serious breach of compliance is going to bring levels of scrutiny that will also take several years to recover from. This scrutiny will slow down operations and include substantial regulatory fines as well. And let’s not forget the operational pain of staff turnover. Both developers and AppSec personnel worried about personal reputations, or frustrations dealing with onerous oversight, will likely jump ship.

So how can your organization avoid this scenario? 

The best place to start is by testing and removing risk at the beginning of the application and API development process. This is what’s known as a shift-left approach. By actively testing APIs during the development process, developers reduce upfront risks and eliminate the headache of addressing design flaws after they’ve been exploited. Peter Klein of Forbes solidifies this idea in the third section of his blog on banking APIs. 

With security and testing baked into each step of the API development or DevOps process, a shift left approach ensures developers will be monitoring for vulnerabilities throughout the lifecycle. Shift-left principles enable security teams to increase developer autonomy by providing support, expertise, and tooling while still delivering the required level of oversight. Developers can release more secure code at scale, build API security into the design, and make fixes early in the development process instead of scrambling to fix them later. And code testers are able to evaluate features as they are created and help ensure higher quality.

Does Noname Security offer this level of testing?

Yes, Noname Active Testing proactively secures APIs by eliminating vulnerabilities before code reaches production. We automatically run over 100 dynamic tests that simulate malicious traffic, including against the OWASP API Top 10. You can streamline testing with role-based access controls, so only the right teams can access APIs for testing. Pretty cool right? We thought so too. If you think you could benefit from a solution like this, I encourage you to  learn more about Noname Security Active Testing here.