To ward off cybercriminals, the financial services industry needs to get over the following assumptions, misconceptions and complacencies.
It is obvious why cybercriminals are drawn to the financial services industry (FSI): because “that’s where the money is!”
But today it is not just banks. Financial services also include credit unions, investment and insurance companies, credit card companies, mortgage lenders, private equity firms, and venture capital organizations.
The FSI is also an almost unlimited attack surface. All that money and all those attack points mean the need for online security is greater than ever. And unfortunately, how best to do that is not so obvious. Common myths about securing FSI are also part of the difficulties in galvanizing cybersecurity efforts in the industry.
According to research from Synopsys Software Integrity Group on application security and data on the software security initiatives of 130 firms, primarily in nine verticals, here are seven FSI security myths worth noting.
Seven myths of FSI application security
The following myths are common and most likely to put both individuals and organizations at risk.
- Financial services firms are secure because they must be
The perception that the FSI is secure because it handles so much sensitive data is wrong. The industry is heavily regulated and virtually all firms meet compliance requirements, but one of the ongoing mantras at security conferences is “compliance is not security.” In the case of the FSI, the high rate of compliance “has helped lull security leaders and customers into a false sense of security.”
The result is predictable. A recent independent study commissioned by Synopsys found that 50% of FSI firms suffered data theft due to insecure software. - Financial software is different than other software (and therefore cannot change)
In this case, the misperception is that the development of financial software cannot evolve toward DevOps, as is happening in other industries.
But as our reports assert, “there are no special snowflakes”. Just because the purpose of financial software is unique does not mean it is written, managed, and tested any differently than software written for any other purpose.
Outdated development models inhibit development velocity and hinder go-to-market speeds. Organizations that refuse to adapt to the modern software landscape will fall behind, if they have not already. - Small firms have different AppSec needs than big ones
Yes, small banks tend to buy software while the big ones more often build their own. But the security of software, bought or built, is the responsibility of the user, not the vendor. Even the big firms that build their own software use commercial or open source components.
And when it comes to the importance of security, size does not matter. Attackers are opportunistic and target systems using automated tools. If you are vulnerable, they do not care what size you are.
Yet the persistence of this myth is evident in the statistics. The Ponemon Institute found that only 43% of financial services firms surveyed required third parties to adhere to strict cybersecurity requirements or verify the security practices of third parties. - You control everything that is in your deployed software
These days, even if a company knows everything in a software stack, it still may not have a complete picture of everything going into production. Open source software is a part of virtually every codebase, and it covers a broad range of AppSec activities and environments, from Docker and Kubernetes to supply chains, cloud deployments and shared responsibility models. Organizations need to understand them all. - Cloud security is the job of cloud operators and owners
The Cloud does not do security for you. The 2019 Capital One breach, enabled by the company’s misplaced trust in Amazon Web Services, was a stark illustration of that. While cloud providers work hard to secure users’ deployments, security teams must still deploy secure containers into their cloud.
As our reports put it: Cloud providers are 100% responsible for providing security software for organizations to use, but the organizations are 100% responsible for software security. - Penetration testing, gate testing and final step security are sufficient
Penetration or pen testing is a critical component of application security but it is not enough. Synopsys has documented that 50% of defects found in software are architectural flaws, which pen testing cannot unearth.
Security has to be built in throughout the software development life cycle, which begins with architecture risk analysis or threat modeling to identify those flaws. - Developers can learn AppSec skills on their own with experience
This may be true for a select few, but not for most software developers. And depending on the aptitude of developers and how much time the learning curve takes, an FSI organization could be at serious risk while that learning does or does not take place.
The reality is, if developers are going to become AppSec experts, they need training as well as experience. A Ponemon Institute study found that is not happening most of the time. Only 38% of FSI firms surveyed had employees with the cybersecurity skills required to secure their software. And 25% of employees in their study had no security training at all, yet they were still tasked with AppSec responsibilities.
Obviously, clinging to myths can put organizations at risk of becoming the next Capital One. Organizations that are now more aware of such myths can turn to a BSIMM assessment to examine their existing security program to compare themselves with the security levels of industry peers and leaders.
Also, with this BSIMM assessment, organizations will be able to improve their security strategies, capabilities and improvement programs to tighten cybersecurity.
