Organisations today face more complex software risk than ever before. With an increasing number of breach and ransomware stories making front page news, the need for robust corporate defence has never been more vital.

Indeed, data breaches that regularly make the headlines are often perceived as 'outsider' hacks, characterised by the belief a hacker has penetrated a system externally. We believe this is often not the case. An external breach, which can cost millions, is being addressed with traditional security measures. However, many financial organisations require emergency internal focus to prevent ‘insider’ threats, which develop from within the roots of an organisations’ system.  

Enterprise security measures and its underlying software quality are closely interlinked. Banks can deploy the most cutting-edge and expensive security software, but if it is implemented on poor code structure and quality, it will fail under attack or strain. Think a mansion having been built on poor foundations. Additionally, with banking legacy systems often outsourced, this begs the question: how are they checking for system level violations and architectural adherence? Both of which are critical.

Attacks are going deeper

Banks spend millions of pounds to create a robust and secure architecture blueprint, but are they investing correctly? In our experience, Cyber Security programs only bolstered perimeter security, focusing on the vulnerabilities within the superficial hardware and network layers of a system. However, as hackers become more sophisticated they rarely stop once they have broken through this initial perimeter and now carry out much more damaging attacks from deep inside organisations.

Security and risk are both complicated issues and require a well-rounded strategy across both physical and virtual security measures. There is no ‘one size fits all’ approach.

Recently, Tesco Bank felt the full effects of exactly this type of cyber-attack when it saw £2.5m stolen from the current accounts of 9,000 customers. Tesco promptly halted all online transactions, including contactless payments, while working towards resolving the issues. The UK’s largest retailer has since faced allegations of failing to recognise the early warning signs that could have served to prevent, or mitigate, damage.

This comes at a time where the IT systems in banks are undergoing a tremendous amount of change due to initiatives around digital, DevOps, more agile Challenger banks and tighter regulation – all this at a time when budgets are limited. These changes create an additional level of pressure, so risk needs to be measured for it to be mitigated.

Fixing the code

Tesco Bank is not alone in having issues. Other UK high street banks have faced problems recently due to a lack of security investment at the core of their internal banking systems. Instead, they favour ways to stop hackers getting in. Rather than focusing on preventing attackers breaching the perimeter, banks should assume threats are already inside the system and work to resolve issues at the core, not just the perimeter. With strong code, even if the outer perimeter is breached, strong architectural adherence will minimise the total damage that can be done.

Very few employees, and even IT teams, fully understand the complexities of long-serving core banking systems. There are equally very few controls for development teams who need to work on these systems to deploy new products and services. Compounding this is the fact that many banks, including Tesco Bank, outsource the maintenance and development to third parties with little in the way of vital software structure checks, on the way in, or out. This results, at the very least, in incredibly slow change and the very worst a devastating security vulnerability. Whilst millions are spent on architectural blueprints, the compliance in software code development is not strongly enforced, especially across applications. Banks often have no idea if the code they have outsourced complies with best practice standards.

Therefore, it’s hardly surprising to discover security experts agree that 50% of application security weakness is architectural. Indeed, as most banking software becomes compartmentalised (as banks become increasingly digital), security holes emerge where these separate components interact across the application.

So, what can financial organisations do to address these security holes?

• Architecture compliance and adherence is vital for banks to not only achieve compliance within architectural governance standards, but to also ensure that a fit for purpose design for a robust security initiative is deployed and then followed.

• Banks also need to scan core systems for structural coding issues, as well as review and audit all software to ensure it is compliant.

• Organisations need to deploy more robust measures for application security and make sure software is architected around different levels of data classification and can facilitate better use of analytics. This will allow banks using outsource partners to check the underlying application code is compliant to the standard they have set and ultimately remain secure.

Poor code quality is frequently at the root of expensive system failures. The Consortium for IT Software Quality (CISQ) has recently published a checklist of code quality standards that addresses core code quality issues. However, without an automated tool, banks will continue to operate on trust and rely on manual code reviews and discussions.