The State of Banking and Finance Security
An Industry Under Attack.
Today, every organisation is a technology organisation, and cybersecurity should be an integral aspect of their IT operations regardless of the perceived level of threat to their industry sector. Over the past decade, major data breaches have affected over 1-trillion user accounts with the volume of attacks increasing year on year, and the total global cost rising by more than 6% in year-end 2018.
The risk associated with organisations inside the finance sector, however, is even more pronounced due in large to the obvious fiscal aspects, but also in part, the sensitive information such institutions hold in terms of their clients’ data, things like home addresses, contact details, DOB, etc, known as PII (Personally Identifiable Information). And there’s no doubt that the financial industry is under attack. The 2018 Financial Breach Report from Bitglass has underscored the prodigious increase in cyber criminal activity in the sector with a three-fold increase in compromises compared to 2016. This increasing pressure to the finance sector is reiterated by IBM Security and the Ponemon Institute with similar findings, placing banking and finance as the most at-risk sector.
The genesis of these breaches has shifted too. Historically lost or stolen devices were the catalyst for compromise in most instances, but now deliberate activities from threat actors account for 75% of breaches, with lost or stolen devices slipping to just 20%.
As anyone that’s been inside cybersecurity for any time might have predicted, the breaches were most commonly attributed to issues with the fundamentals of their respective environments. While simple, implementing the basic steps in tightening operational and process controls is not necessarily easy due to the scale and complexity of these environments. Many institutions have found that while having the goal of improving overall IT operational security is a requirement for any roadmap, limited resources mean that vulnerabilities are routinely generated by IT staff. Pragmatically, penetration testing can identify potential vectors for attack and catalogue risks as a step towards immediate remediation. While this can be seen as a ‘band-aid solution’, it’s more akin to a constant state of necessary triage.
The Requirements to Be Secure
Compliance. Trust.
Trust is the main commodity in which banking & finance institutions should be interested. Any breach or perceived compromise can undermine the credence customers and partners have in your business.
Fort Safe work extensively inside banking and finance institutions, and have visibility over the nuances of many of the fundamental systems and requirements found therein. While the industry as a whole has had opportunity to evolve their security frameworks to cater to the aforementioned core infrastructure (despite advances in the tech, it’s fundamentally ‘the same’), not so the more recent emergence and approaching ubiquity of web applications.
We have been instrumental in helping recognised names in banking & finance examine the web applications in their ecosystems, and understand the capabilities, vulnerabilities and potential risk associated with this, and potentially how to resolve or mitigate potential issues and threats.
The groundwork for a methodical and well thought-out strategy to approach pentesting has already been laid. Organisations like OWASP have evolved the details around vulnerability and security information, approaches to testing, and even the parametres around pentesting tools. While many of the OWASP measures are argueably less releveant for some sectors than when first released 15 years ago, they are absolutely still the gold standard. The banking & finance sector tends to lag behind faster adopting industry verticals as legacy systems are often sunsetted far more slowly due the complexity, scale, their interwoven nature, and the operational reliance finance organisations may have on them. This further supports OWASP as integral to the security of financial web applications.
The Processes
The Steps to Take.
As part of cybersecurity due diligence, intelligent organisations run penetration tests against their core infrastructure like systems and networks, as well as web applications, and really should against any technical aspects attached to their business. These tests are designed to unearth potential vulnerabilities by mimicking the same tools, techniques, and procedures at the disposal of cybersecurity criminals. With this critical information, organisations then have a roadmap against which they can take steps to improve their overall security posture.
While many organisations develop their own intelligent slant on OWASP based on the experiences and expertise of their Subject Matter Experts (SME’s), external validation is vital to ensure compliance. By way of example, in the case of Payment Card Industry Data Security Standard (PCI DSS), compliance with NIST Controls Framework 800-53A, and ISO 27k compliance all require pentesting. Governing bodies for compliance often go so far as to stipulate explicitly that an external validation must occur to avoid any potential compromise in integrity. This aspect is often neglected on other pentesting requirements, where internal parties responsible for implementation and integration perform the function, largely invalidating the usefulness of such tests.
The approaches to individual pentests are typically categorised as one of three variations;
Whitebox Testing
This is tantamount to an ‘open book test’ at university. In whitebox testing, all aspects of the web application are made available, including the overall design and architecture, and the actual source code, hence moniker of ‘clearbox testing’ used interchangeably. This environment of whitebox pentesting for banking and finance web applications lends itself to a more thorough and rapid execution inside financial institutions as one would expect. The aim of this category of test is to fully explore any and all potential issues, often zooming in to a specific aspect of the environment. When many banking and finance web applications are huge in terms of code base, often running to the tens of millions of lines, this scale translates to increased time and effort. So while more complete, the resources required are substantial as the whole-of-thing is to be examined
Blackbox Testing
This form of testing more closely mimics a real-world attack as it’s executed without supplied insight into any environment. Given the scale and complexity of most banking and finance institutions, this means the volume of potential vulnerabilities follows suit. A blackbox tests purpose is to uncover these using the same methods and tools that are available, and hence theoretically identifies the same opportunities/vulnerabilities allowing them to be documented and subsequently addressed.
Greybox Testing
As you likely surmised, this is a combination of the above where some details are known. While source code is not provided, some aspects of architecture may be. This is to replicate what may be discovered through footprinting from an external vantage point, but without the otherwise necessary (long!) time being allocated.
The reason all three classifications exist and one has not superseded the others, is that they are all useful in identifying vulnerabilities in web applications. Using Static Code analysis (SAST) is the typical route to identify problems with code, as even the most dedicated auditor will be overwhelmed by the scale of many modern banking and finance web applications. But a whitebox approach won’t uncover logical vulnerabilities. You need a manual and arguably creative aspect to this, and that can only really originate from a seasoned security professional.
So while your internal team might be employing a secure-by-design approach to development, and likely even some whitebox testing, an external party like Fort Safe can provide the levels of assurance for your web applications required within banking and finance by unearthing technical and logical vulnerabilities and providing steps for remediation.
The Findings and Outcomes
Improving Web Application Security.
Once the findings from any testing are reported, implementation is obviously the next step. To do this after the web application is ready for deployment (or god forbid, already live) can be a costly mistake. Web applications often have to be scrapped once ‘finished’ when insurmountable security issues have been identified. This makes it vital that the detection process for web application vulnerabilities permeates the entire SDLC, rather than as an addendum once finalised. This processes, called the ‘Secure SDLC’ should be the cornerstone for this process. It’s worth noting, that this also avoids the trimming back of security measures due to budget issues that are often encountered towards the final stages of projects.
While any form of testing can be valuable and should certainly be done prior to release, a secure-by-design approach through the rather than attempts to retrofit security measures.
Without clear and actionable steps towards remediation, any testing falls short of its true purpose. To ensure that a web application is optimised for security, you have to identify security flaws and vulnerabilities within the web application itself before any threat actor exploits them, but you also have to make the requisite changes. That’s why we at Fort Safe have developed a comprehensive and actionable reporting format for all our testing, that facilitates prioritisation and decision-making to rapidly address vulnerabilities we’ve identified.
Please request your report through the form below, or call 61.2.9098.4407
Actionable Steps
Actions You Can Take Today.
As you can see from this article, there are myriad aspects and considerations to ensuring good security with web applications bound for, or already in, a production environment.
To ensure you’re taking the necessary and immediate steps to begin securing your environment, ensure you’re addressing the fundamentals;
- Implement a Secure SDLC
- Implement a Web Application Firewall and tune it appropriately – apps change constantly and thus so should your WAF settings
- Regular Vulnerability Scans of the Web Application and the underlying Operating System
- Annual Pentesting of applications at a minimum, more frequently if your organisation is changing or releasing new applications
- Pre-launch penetration testing of all web applications
- Security Controls Assurance evaluation – Determine confidence level (High, Medium or Low Assurance) in the security controls you have in place to defend the applications
If you need industry experts to help your banking and finance company secure its web applications, reach out to us today and start a conversation and make sure tomorrow is safe.
