Addressing software security for financial services in 2021

Companies operating in the financial services arena today must adhere to a whole host of complex regulatory standards, which makes perfect sense given both the assets and information managed by such firms are valuable and sensitive, and as a result, highly targeted by sophisticated cyber attackers daily.

Compounding these challenges is the large volume of personally identifiable information (PII) that such organisations handle too, which is subject to a plethora of industry standards and the General Data Protection Regulation. While some regulations are explicit – such as the PCI-DSS – others are more general, simply stating PII must be secured from attacks. However, in order to comply with any major regulatory standard, organisations must have visibility into risks, vulnerabilities, and data flows in their software. They must also have systems and a plan in place for addressing these.

While financial services organisations have historically been strong when it comes to employing application security testing tools, more can be done to accelerate efforts and make these continuous.

So what specific steps can be taken by companies in this space to address security in the software they create for the remainder of 2021, and how will this benefit them long term?

SEE ALSO: Certificate lifespans are getting shorter and it’s never been a better time to automate

Risk ranking applications

From a business risk perspective, not all applications are created equal, so the first step to reducing risk should be to quantify the inherent risk associated with each application. Organisations can accomplish this by using a risk-prioritised methodology to rank applications based on potential damage to the firm’s business goals as a result of a successful attack.

For example, the security of an online banking application that allows customers to transfer funds, perform large transactions, and change privileges is crucial to a bank’s business goals. A breach of such an application could cause huge financial, regulatory, and reputational damage. By contrast there are likely to be internal applications that don’t process sensitive information or have a limited attack surface. In terms of business value, these are less critical and don’t warrant the same scrutiny from a security standpoint.

Risk ranking is a good practice to get into and can empower time and resource-constrained security teams to apply appropriate resources to the applications with the most risk, in turn maximising operational efficiency. The result should be an application inventory with a risk ranking for each application. The resources can then be assigned depending on the risk ranking of each business application.

Establishing clear security requirements

To achieve true DevSecOps, teams must agree upon “metrics” for adequate security. This requires open and ongoing communication and collaboration between development, security and operations teams, as metrics will differ for various application types. For open source components, these requirements should include an understanding of each project, encompassing how well it’s supported by the community, its security history, and any open source license requirements. For custom code and the complete application, it’s essential to have an agreement in place explicitly stating when security testing will occur, and what conditions will necessitate breaking a build.

For example, an organisation may (and should) dictate that applications cannot be deployed if a ‘severe’ vulnerability is identified. The automated build process of an application should stop if and when that condition applies.

Continuously identifying vulnerabilities

Security must be integrated into all phases of software development for financial services organisations. This approach will not only improve security in DevOps environments (i.e. DevSecOps), but also accelerate time-to-market and lower development costs, since vulnerabilities found earlier are usually less complicated and time-consuming to fix.

Static application security testing (SAST) solutions can integrate into the SDLC from the beginning of 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 builds to identify open source dependencies and map components to publicly disclosed vulnerabilities, continuing through the test/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 of only the code that has changed. By contrast, solutions that require hours to scan a complete application build don’t fit well in DevOps environments.

Empowering developers to code securely from the beginning

It’s important for security teams to take an active role in engaging and collaborating with their DevOps counterparts from the very beginning. Education here is of huge importance.

Security teams in financial services organisations should train DevOps teams on specific attack methods and popular hacking techniques, providing the tools needed to identify vulnerabilities as they write 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 greatly reduce the time required to fix 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 make it mush easier for developers to code securely from the start. Developers may also be more receptive to training when it’s relevant, retain lessons learned more readily, and ultimately, become better security champions for the organisation. It can also be useful to specifically identify security champions in development teams so become the go-to person of that team with regard to security questions and who have a closer link to the security team compared to the rest of the development team.

Remembering application security is not a one-and-done task

Open source components and frameworks offer clear advantages, including lowering development costs and accelerating time-to-market. However, in order to maintain strong security, they must be analysed during the coding and building phases. And it doesn’t end there.

It’s critical to continue monitoring open source software for newly disclosed vulnerabilities throughout the SDLC. 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 codebase, it’s very difficult to find and fix vulnerabilities. Effective application security today must be continuous.

SEE ALSO: “The primary use case of AIOps is to ingest multiple monitoring data feeds”

Charting a course for security success

Today, malevolent actors deliver PII used for identity theft in vast quantities, while the impact of data breaches now go far beyond just embarrassment for a company. Attacks now result in loss of reputation, shareholder value, and in some cases the dismissal of corporate leadership. And that’s before significant fines, heightened legislative inquiries, and ongoing public distrust.

The way financial services organisations build software today is dramatically different to a decade ago, with new development models helping deliver software faster than ever before.

While financial services organisations have had a good track record to date they need to step up efforts and make these continuous from early on in the SDLC, integrating different testing tools into one holistic perspective with a combination of results from SAST, SCA and IAST. In such a highly competitive market, it’s simply no longer an option to deliver something that hasn’t 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. The time has come to ensure security is integrated from the very start of the SDLC. This will only help companies in the field better manage, measure, and address risk, empower development teams, and guarantee secure software delivery at the speed of DevOps.