The new banking paradigm has to be supported by a new security paradigm as well, says this software expert.

Hardly any bank is just a bank anymore. And entities that are not banks are invading turf that we all used to think was owned by banks. They are all now part of the financial services industry (FSI).

All these services, along with currencies, are going digital. Who but the older generation carries cash anymore? 

Bank branches are closing because an entire generation of people see no need to use them. The financial life of millions of customers is now in their pockets—on their smartphones.

Legacy banks and challenger banks

The cloud-based architectures that FSIs usually run on are the ‘vault’ that protect the assets. Due to tight finance sector laws, these architectures require rigorous software security and secure cloud configurations.

The opportunities for growth and profit are huge, as a consumer’s or corporation’s entire financial life can be connected to one FSI player. However, especially in the case ‘legacy’ banks that have been around for generations, the digital transformation is a heavy lift because their decades-old infrastructure was made for a model that is increasingly obsolete—and a portion of their customer base still wants that model.

That makes the playing field a bit uneven. The newer, or ‘challenger’ banks are tech firms that typically use mobile distribution channels to offer competitive retail banking services. They can move at a very fast pace because they have no legacy infrastructure like mainframes sitting around disparately across 20 different regions of the country. They also have a younger and more agile workforce.

Meanwhile, legacy banks have the advantage of size, which includes lots of money, so they try to run a massive legacy infrastructure while trying to accelerate their processes, practices, and procedures to keep up with the challenger banks.

According to our security consultant Ian Ashworth, some challenger banks “aren’t even true banks,” and do not have to reimagine anything because “they’re starting from what amounts to a clean sheet of paper,” while legacy banks must overhaul their infrastructure to stay in the game.

SAST, SCA and IAST

The big legacy players, Ashworth said, “are constantly having to keep pace with what regulators are asking them to do, and this is holding them back because these new, nimble challenger banks, sometimes termed banking-in-a-box, are providing things from a very fresh starting point so they don’t have all these regulatory demands.”

But, while there is value to compliance but the reality remains that compliance is not security, and security is an existential requirement for FSI players. Security involves “a combination of tools, data, information, processes, and people,” said Ashworth. “You can’t afford to have a breach because you won’t have a customer base if you don’t show that you’ve got authority on the subject. If you get it wrong, it’s game over. It’s not something you can take lightly.”

Ashworth said for FSIs, one of the most important software testing tools is static application security testing (SAST), an automated testing tool that finds defects in code while it is being written. SAST is often mandatory “although the deeper implementation details of what it must try and find and whether these findings are consequently deemed ‘passable’ are often left to individual organizations.”

Also, given that FSIs have an internet presence, and many open source components make up the front-end web and mobile solutions, software composition analysis (SCA) is essential to pre-vet their selection and mitigate third-party risk, he said.

Finally, interactive application security testing “is gaining in appeal and perhaps is an as-yet untapped gem of a technology that has great potential, especially as we see more adoption of micro-service architectures and the desire to report proven high impact issues.” 

Security risks in the Cloud

Besides application security testing tools, there are the risks to being in the Cloud. 

While cloud service providers are 100% responsible for providing security software for organizations to use, the organizations themselves are 100% responsible for software security. Organizations that were not doing software security well in their private data centers are likely not doing software security well in the cloud either.

Ashworth added: “You expose yourself to the Cloud and you suddenly have to learn all about cloud configurations and secure networking, and then you’ve got all the worries of operational security because you’re now facing everything through the Internet rather than through a closed network where you were talking to a teller across a desk.”

All of this means that a “Sec” must become embedded into DevOps. The goal is to use DevSecOps to drive digital transformation while keeping systems, customers, and the companies’ bottom lines secure.