Banking systems security: a complete guide

More than three-quarters of Americans used a mobile device to check their bank balance in 2019. We value mobile apps for their availability, the ability they give us to make transfers at any time, and easier budget planning. However, banking applications, just like banking systems, don’t always provide customers with 100% security. What cybersecurity gaps are banks struggling with, and what actions should they take to care of consumer data and money even better?

Although banks always try to be a few steps ahead of potential fraudsters, there are many opportunities to steal personal data or financial resources. Unfortunately, the security measures they take aren’t always sufficient. The range of distribution channels through which banking services are provided creates many opportunities for hackers. There’s no point in looking for statistics about the most common reasons for breaking into banking systems and applications, but the most popular ones include hacking into an online bank account, uncontrolled disclosure of personal data from bank resources, identity theft, and fraud in electronic payments.

Banks themselves feel well protected against threats. They give the best ratings for the prevention of hacking into online bank accounts (94%). In their opinion, security related to temporary system failures and theft of data from payment cards still requires some work.

On the other hand, a study of 14 banking applications conducted by Positive Technologies showed that as many as 13 of them had gaps that could give undesirable access to customer data. A total of 76% of the vulnerabilities could be exploited without having to physically access the account owner’s device. Servers included 54% of all vulnerabilities found in the survey – each bank had an average of 23 of them.

The standard that imposes the rules for ensuring the security of banking applications and systems in the United States is the so-called PCI Standard. The standard must be used when a contract is concluded between a trader and an acquirer or a center and a payment organization.

The standard is divided into 12 requirements divided into 6 groups, each of which corresponds to the achievement of a specific goal:

One of the current legal bases regulating the security of banking systems and applications is the EU PSD2 Directive. It requires payment service providers to strongly authenticate their customers. According to the directive, the user’s identity must be verified on the basis of two out of three components:

Double verification must be performed whenever a customer wishes to access their account online, conduct an electronic transaction, or carry out any other activity that may involve a risk of payment or other fraud.

The PSD2 directive also introduced new requirements for communication interfaces with third parties (TPP). According to the law, payment service providers (ASPSPs) must provide open programming interfaces (APIs) on the basis of which TPPs will be able to offer innovative services and products. Each ASPSP should provide at least one communication interface with the TPP. It’s essential to initiate authentication with the consent given by the user and to ensure the integrity and confidentiality of the credentials. An important order imposed by PSD2 is also the need for banks to use secure data encryption throughout the duration of the communication session.

Recommendation of the Polish Financial Supervision Authority

The Polish banking sector must also operate in line with the recommendations of the Polish Financial Supervision Authority. This recommendation on the security of electronic payments reminds us about risk assessment guidelines and payment security policy. It resembles the general principles of risk analysis, good practices, and standards that should be followed by banks when establishing standards for auditing processes. It’s also essential that banks cooperate with the relevant law enforcement authorities in the event of security incidents.

Hacking attacks against banking systems and applications can take many forms. Banks can protect their customers from many of them by securing the system and application code, as well as taking other actions by the IT department. The bank itself doesn’t have control over some attacks – they’re aimed directly at unaware consumers and prey on their ignorance. The institution can protect customers from such situations only through effective information, education about safe banking, and self-monitoring of potential frauds.

What should banks and similar institutions be prepared for in particular?

Phishing, also known as password harvesting fishing, is a social engineering banking fraud that comes in many varieties. Phishing refers to an attempt to impersonate an institution to acquire personal information such as login passwords, bank or credit card numbers, or other relevant information. It offers a quick way to take over the user’s account.

Phishing takes many forms, and its quick identification might be difficult. For example, an attacker might:

An attack aimed directly at the user’s device can be carried out using a QR code. A fake QR code can be sent by email or text message or located on materials that pretend to be banking. Scanning the code is supposed to provide the customer with some benefits, for example, downloading the bank’s mobile application. In reality, the software installed on the consumer’s device passes control over it to the hacker. The hacker can then easily eavesdrop or redirect conversations or messages (e.g., containing login details).

In the case of Android, one of the vulnerabilities used here is Stagefright, a bug in the library responsible for multimedia handling. The smartphone can be attacked by receiving a message, usually an MMS. Contrary to typical phishing, the user doesn’t have to download any file from the message or even open an MMS to be attacked. The mere presence of it on the phone can be used by a hacker to explore the content of the device. After the issue was reported, Google developed patches to fix this vulnerability. But according to research from Zimperium, up to 1.5 billion Android users could be vulnerable to similar attacks.

A Denial of Service attack is relatively easy to detect and quite frequent. The attack consists of blocking access to the system or application, and as a result, to services. In this case, the fraud targets banks directly, interfering with their reputation and business operations. To launch a DoS attack, hackers can deliberately overload the website so that it cannot perform its functions. A variant of the DoS attack is DDoS, where the attacker infects the hardware of “ordinary” users, taking it over and using it to remotely launch an attack on a given website.

We can note an increasing frequency of APT attacks today. Their great danger lies in the fact that they may remain undetected for months, all the while causing financial and reputation losses for the bank. These are dedicated attacks that take into account the specificity of a given organization and use many methods, including phishing, malware, or spearphishing. Financial institutions can protect themselves against APT by focusing their IT departments’ attention on the so-called Security Incident Response Workflow, i.e., a combination of speed, accuracy, and repeatability of response processes.

Banks also have to deal with the operational security of their own internal solutions. The process of protecting them against attacks should include both the development of a security policy at the technical level (infrastructure and applications) and ensuring the operational level related to processes and human resources. Naturally, the security of banking systems and applications needs to include preventive and incident management mechanisms.

Cloud computing may be the answer to the relatively new EU regulations that entered into force in the fall of 2019. Solutions allowing for quick adaptation of technology to business requirements or changing legal regulations are now a reasonable choice. The cloud, which is characterized by speed, openness to innovation, and a high level of security, fits the current needs of financial institutions perfectly. According to an Accenture study, 20% of global banks already allocate investment funds to the development of open banking.

The security of cloud solutions can be demonstrated by, for example, institutions that have decided to put their infrastructure in the cluster. They include the US Department of Defense, which plans to transfer the entire infrastructure to the cloud in the next 10 years, or the Pentagon, which is to allocate USD 10 billion for this purpose.

Of course, the bank itself must control the hosting provider’s activity. The Personal Data Protection Act requires that a financial institution:

A report of the Polish Bank Association and Accenture indicates 5 key recommendations regarding the migration and maintenance of the bank’s infrastructure in the cloud:

Learn more about the pros and cons of cloud hosting in this article.

After the implementation of the General Data Protection Regulation (GDPR) and the PSD2 Directive, application developers have no other option than to implement better security practices in their software development process. Even with all other aspects aside, designing a secure application requires the use of encryption. And the golden rule of cryptography says that you should never create your own cipher.

Encryption is the basis of modern software security. TLC encryption is used to secure communication between applications (or web browsers) and servers. VPNs provide more complete, secure tunnels that allow applications or devices to connect securely to the network. In many jurisdictions, encryption of sensitive data is regulated by a legal mandate. This makes it impossible for application developers to avoid encryption in their applications. The encryption field is divided into two broad groups: creating new ciphers and implementing existing ciphers. Many developers implement encryption in one form or another. They include it in the application (or application component) or use ready-made solutions from the point of view of IT operations.

Of course, it’s not just programmers who work on creating properly secured applications. In the field of encryption, some highly valued specialists are cryptographers with sufficient skills and relevant experience to create new, real, and effective cryptographic algorithms. Due to the shortage of professional cryptographers, banks don’t always have access to the right people able to implement legal and compliant encryption in their applications without the involvement of third-party application components. Cryptographers from around the world work together to design not only the algorithms we all use but also application components commonly used to provide the encryption functionality.

The legal regulation of the principle of “safety by design” is, therefore – at least in practice – a guarantee of the right to use third-party application components.

Vulnerability detection

Every code contains errors. Software flaws are the cause of security vulnerabilities. Using third-party components that provide encryption functions may not offer sufficient protection. Common encryption components have, over the years, exposed many famous security flaws. Cases like Heartbleed, Shellshock and Krack made headlines around the world. While some of them are easily patchable, others are more fundamental, requiring the switch from older cryptographic solutions in favor of more modern technologies.

Currently, preventive actions often include Big Data analysis due to the amount of data collected by banks. In addition, system tools are used to detect incidents and threats, generate real-time alerts, periodic reports, and analyze historical data. Such solutions include, among others, Splunk, IBM QRadar, or HP ArcSight. Financial institutions more and more often use operational security units (the so-called SOC). They allow for incident handling based on defined procedures and principles of information flow within the organization. At the same time, SOCs can communicate with relevant external organizations, such as the Police, Prosecutor’s Office, or NASK / CERT.

When it comes to patching, most people refer to the operating system of their device. Every computer user has encountered a Windows update, macOS update, or update mechanisms on their smartphones. These ubiquitous patching systems are well known, but they’re not the only locations where patching can occur. Third-party components are often bundled directly into compiled applications. This means that these components must be patched before the application build process can begin so that the compiled applications contain their latest versions. Unfortunately, there’s no easy way to determine which components are patched by the operating system and thus need to be patched during the application build process.

An example of this is the Heartbleed bug, a flaw present in multiple versions of the OpenSSL cryptographic library, a common open-source component. The OpenSSL library is frequently downloaded, installed, and packaged on Linux operating systems. Many Linux applications are designed to invoke and use copies of the OpenSSL libraries managed by the operating system’s package manager. In this case, regular and automated OS updates would also update OpenSSL. And any application using it would use the new version when restarting the application without having to recompile or redeploy the application.

However, OpenSSL is also built directly into countless applications, especially if they’re intended for use on Windows. Windows Package Manager doesn’t install or manage any version of the OpenSSL libraries. In this case, the applications must be recompiled (or at least repackaged) every time a new version of the OpenSSL library is released.

One of the most important expenses related to the security of banking applications is applications that use open-source components with known vulnerabilities. The problem cannot be solved simply by improving the security of the devices. No antivirus software, application behavior profiling tool, endpoint security suite, or mobile device management tool can make an application with a known vulnerability not vulnerable to attacks. Building your own apps to take advantage of your device’s advanced security features won’t fix this issue either. Biometrics, NFC, and multi-factor authentication are just keywords if the application itself is vulnerable to attacks. Additionally, incorporating each of these security features into an application may require many additional third-party components, each of which will need to be kept up-to-date.

From the bank’s point of view, this is worrying. It means that the burden of security cannot be shifted back to the customer or any of the vendors in the supply chain between the customer and the bank. If the bank implements an application that includes open-source components with known vulnerabilities, or if it fails to update and deploy a new version of its applications immediately after detecting vulnerabilities in the components it uses, the bank is responsible for this. It’s not possible to shift the responsibility for security to the customer, device manufacturer, or operating system vendor. If a potential security vulnerability occurs as part of embedded code in an application, it’s the company’s responsibility to keep the application up-to-date and to add appropriate patches and security.

The introduction of open banking is becoming a necessity, but it also brings about new challenges when it comes to the security of user personal data. Depending on how your app development risks are analyzed, open banking may seem like an ideal solution to managing risk or potential disaster. Open banking shifts the burden of application development to external entities – the application is created by a commercial entity, completely unrelated to the bank. Open banking applications typically work with multiple banks, allowing the end-user to use the application regardless of the bank they choose.

As an app is designed, published, and maintained by third-party developers who aren’t contracted with a bank, the responsibility for updating the app rests with them and not with the organization itself. While this may be desirable from the perspective of accountability, it also means that the bank has little control over whether or not its customers are using applications with known vulnerabilities. This requires the bank to redouble its efforts to fight fraud.

The key to successful collaboration is trust between the bank and the developer of the open application. The same trust must also exist between the bank and the client and between the client and the developer. In the world of open banking, trust is often complicated by changes in customer relationships. Cooperative banks are used to the fact that the process of creating relationships with customers can last for decades. However, thanks to open banking, the developer of the open banking application gets to have many of the client’s everyday banking experiences.

It’s also worth mentioning that open banking provides the developer of an open banking application with an insight into many of the client’s everyday banking experiences. As the use of banking applications increases, the market becomes more and more competitive. Many banking app developers go to great lengths to gain trust, nurture relationships with banks their apps work with, and implement security certificates and formal code reviews for their apps. Banks that use open banking can improve security by leveraging partner app security initiatives. They can also increase their security by implementing controls that prove that open banking application developers use all the tools necessary to ensure the security of deployed applications through timely and ongoing updates.

Do you have any questions about mobile banking security or want to talk about securing your open-source project? Write to us – we will be happy to answer all your questions and find a solution dedicated to your project.

Read more: