Addressing Software Security for Financial Services in 2021
Companies operating in the financial services arena today must adhere to a host of complex regulatory standards, which makes perfect sense given that the assets and information managed by these companies are valuable and sensitive, and therefore, highly. targeted daily by sophisticated cyber attackers. .
Adding to these challenges is the large volume of Personally Identifiable Information (PII) that these organizations also process, which is subject to a plethora of industry standards and the General Data Protection Regulation. While some regulations are self-explanatory, such as PCI-DSS, others are more general, simply stating that personal information should be protected from attacks. However, in order to comply with any major regulatory standard, organizations must have visibility into the risks, vulnerabilities, and data flows in their software. They also need to have systems and a plan in place to address it.
While financial services organizations have historically been strong when it comes to using application security testing tools, more can be done to accelerate efforts and make them continuous.
So what specific steps can companies in this space take to ensure the security of the software they build for the remainder of 2021, and how will that benefit them in the long run?
SEE ALSO: Certificate lifespan is getting shorter and there has never been a better time to automate
Risk ranking applications
From a business risk perspective, not all applications are created the same. The first step in reducing risk must therefore be to quantify the inherent risk associated with each application. Organizations can achieve this by using a risk-prioritized methodology to rank applications based on potential damage to the company’s business objectives following a successful attack.
For example, the security of an online banking application that allows customers to transfer funds, complete large transactions, and change their privileges is critical to a bank’s business goals. A violation of such an application could cause enormous financial, regulatory and reputational damage. On the other hand, it is likely that there are internal applications which do not handle sensitive information or which have a limited attack surface. In terms of business value, these are less critical and do not warrant the same consideration from a safety point of view.
Ranking risks is a good practice to adopt and can allow time and resource-limited security teams to apply the appropriate resources to the most risky applications, thereby maximizing operational efficiency. The result should be an application inventory with a risk ranking for each application. Resources can then be allocated based on the risk ranking of each business application.
Establish clear security requirements
To achieve true DevSecOps, teams must agree on “metrics” for adequate security. This requires open and continuous communication and collaboration between development, security, and operations teams, as metrics differ across application types. For open source components, these requirements should include an understanding of each project, including how well it is supported by the community, its security history, and any open source licensing requirements. For custom code and full application, it’s critical to have an agreement in place that explicitly states when security testing will take place and what conditions will require a build to be discontinued.
For example, an organization can (and should) require that applications cannot be deployed if a “severe” vulnerability is identified. The automated build process for an application should stop if and when this condition applies.
Continuous identification of vulnerabilities
Security should be built into all phases of software development for financial services organizations. This approach will not only improve security in DevOps (i.e. DevSecOps) environments, but will also speed up time to market and reduce development costs, as vulnerabilities detected earlier are generally less complicated and long to correct.
Static Application Security Testing (SAST) solutions can be integrated into SDLC early in the code phase, through the source code repository when checking in new source code, or added to automated build processes . Software Composition Analysis (SCA) can be used in early releases to identify open source dependencies and map components to publicly disclosed vulnerabilities, continuing throughout the testing / QA phase. Integrated Application Security Testing (IAST) can be performed during automated functional testing in the test / QA stage.
By integrating the above into the continuous integration (CI) orchestration, teams can automate processes and perform incremental scans only of code that has changed. In contrast, solutions that take hours to analyze a full version of an application do not fit well in DevOps environments.
Enable developers to code securely from the start
It’s important that security teams take an active role in engaging and collaborating with their DevOps counterparts from the start. Education here is of enormous importance.
Security teams in financial services organizations should train DevOps teams in specific attack methods and common hacking techniques, providing the tools necessary to identify vulnerabilities while writing code. They should also act as a sounding board throughout the process. By providing ongoing feedback and being available to answer secure coding questions on demand, security teams can dramatically reduce the time it takes to remediate vulnerabilities, resulting in better security and more predictable software delivery.
By establishing best practices and making Secure Coding Education (SCE) an ongoing process, security teams can empower developers to code securely from the start. Developers can also be more receptive to training when it is relevant, more easily retain lessons learned, and ultimately become better security champions for the organization. It can also be useful to specifically identify security champions in development teams in order to become the point of contact for that team with regard to security issues and who have a closer connection to the security team. compared to the rest of the development team.
Remembering application security is not a one-time job
Open source components and frameworks offer clear benefits, including lower development costs and faster time to market. However, in order to maintain strong security, they must be analyzed during the coding and construction phases. And it does not stop there.
Continuing to monitor open source software for newly disclosed vulnerabilities across the SDLC is critical. Some vulnerabilities such as ShellShock (CVE-2014-6271) were only discovered decades after the original vulnerability was introduced. Without visibility into both the version of the open source component and its location in the code base, it is very difficult to find and fix vulnerabilities. Today, effective application security must be continuous.
SEE ALSO: “The main use case of AIOps is to ingest multiple streams of monitoring data”
Leading the way to safety success
Today, malicious actors are providing large amounts of personal information used for identity theft, while the impact of data breaches goes far beyond annoying a business. Attacks now result in loss of reputation, shareholder value and, in some cases, the dismissal of company executives. And that’s before hefty fines, increased legislative inquiries, and continued public mistrust.
The way financial services organizations create software today is radically different from what it was a decade ago, with new development models making it possible to deliver software faster than ever before.
Although financial services organizations have had a good track record to date, they need to scale up their efforts and make them continuous from the start of the SDLC, integrating different testing tools from a holistic perspective with a combination of results from SAST, SCA and IAST. In such a highly competitive market, it is simply no longer possible to provide something that has not been tested for security issues throughout the development process. The risks are simply too great.
We rely on both the software itself and its security to complete billions of transactions every day. Now is the time to build security right from the start of the SDLC. This will only help businesses on the ground better manage, measure and address risk, empower development teams, and ensure secure delivery of software at the speed of DevOps.