Our cyber security products span from our next gen SIEM used in the most secure government and critical infrastructure environments, to automated cyber risk reporting applications for commercial and government organisations of all sizes.
There are always regulatory changes and challenges in the financial sector; rapid changes in technology, social habits and political environments all affect the ways in which we bank, how we manage our money and the way in which banking services are provided. One of these is PSD2.
PSD2, at a European level, is the second “Payment Services Directive” and it defines a way of handling and managing payment and banking services that introduces some fundamental changes to the financial sector – notably around the way larger banks and financial services providers need to allow access to systems and information, and the creating of new types of Fintech organisations that can access account information (Account Information Service providers, AISPs) and Payment Initiation Service Providers, PISPs).
More widely “Open Banking” – a big deal in the UK and elsewhere in the world – is driven by competition and markets rules. This also aims to force larger banks to make room for newer, innovative service providers. In many cases through the enforced creation of API (Application Programme Interfaces) into existing banking systems.
If you consider where banking IT has come from; a relatively short time ago banks had IT systems that were operated by their internal users and/or employees. Then came the web, ecommerce and online banking and now it is far more common for people (i.e. customers) to carry out banking transactions themselves through a web site and/or a smartphone app.
This mean that transactions, account lookups, queries and payment instructions went from operating at human-to-human speeds and volumes (governed by the number of employees, the availability of branches and the frequency of people calling in); to a world where they operated at human-to-machine speed where people conduct on-line banking and initiate transactions themselves at the speed they want and as often as they want.
The move to greater access by APIs from third party systems under PSD2 could be another order of magnitude change in volumes, speed, frequency and throughput. For example, you might access your online banking every day or maybe a few times a week to check balances and payments. It is entirely conceivable that a start-up Fintech will create a service that means they access your account every hour to check payment statuses, monitor for fraud or keep an eye on what your kids are doing, for example.
This type of service (an account information service) might lead to your bank having to deal not with one inquiry/transaction a month, or one a day, but one every hour or more! It also means a considerably higher volume of on-line access, instructions and queries to conduct security monitoring across.
The other challenge banks and other API providers may face is that at present they have a direct relationship with the customer making the request. So authentication, fraud detection, cross-selling of services and products, alerting to changes to terms etc all happen as a direct conversation with the customer; where intermediaries are involved this interaction will be less direct.
For security teams this may mean that although there will be a set of controls around the way APIs interact and the access/authentication processes; there may be security (or fraud) indicators that are less hard to utilise in a machine-to-machine world.
Suppose an organisation or service sprang up that carried out account/transaction checks every hour; or moved money around between accounts/savings continuously to maximise interest rates … these types of processes would mean that patterns of user behaviour, or login locations, or sources of connections become much less useful as indicators as it would be the location or origin of the service provider not the user, and the accesses could be continuous rather than at the set/usual times that a user might conduct on-line banking.
Past indicators of fraud, such as accesses or transactions from unusual locations or at unusual times, might now be obscured as the customer worked through an intermediary.
One challenge with the use of APIs is that the ability to enforce policy or limit/contain threats at a per user level will be harder for banks to process – risking the shutting off of a large number of users if a service is thought to be compromised or needing to work through a third party if a user has fallen under suspicion.
If an on-line banking user account, access device or card is currently reported stolen or known/suspected to have been compromised it is a simple process at present for the bank to put a stop on any further activity.
Where an API service falls under suspicion of being compromised then taking action to stop transactions could affect a large number of their users (and the banks customers) and hence attract a degree of regulatory attention (the regulations don’t allow blocking APIs accessing without good reason). If a user is felt to be at risk, then the bank may be able to stop activity from them via an API, but it might also need to communicate this to the API provider for them to convey to their customer (the individual) or to ensure that other banking services they are connecting to are protected.
Aside from the business and customer interaction changes that PSD2 and Open Banking will involve, there will be some implications for the way in which security monitoring and threat detection systems operate in this new environment.
In the past, security oversight often focused at the infrastructure layer and at web front ends; however with API based access there is a good chance that security information and intelligence may be more embedded in the application/transaction logs than in the past. The challenge here of course is that while there are often core banking platforms in use there are also often other applications involved and theses may be customer specific or highly customised; so deploying a monitoring solution to ingest and process these will mean having the flexibility to handle and configure ad hoc or bespoke flows of data and activity information.
Aside from the simplistic addition of application or transaction logs and activity mentioned above, the addition of an API to the online banking access model means additional data volumes. However, the big change, as we highlighted, is that humans tend to interact with systems in a fairly measured and predictable way. You might check your balance on Monday morning on the way to work, and then again Friday afternoon before the weekend. You might move money around or make payments 3-4 times a month.
An AISP or PISP acting on your behalf to monitor your account, provided a real time financial dashboard, or shifting money between spending accounts and interest bearing accounts may access the online bank interface several times a day, maybe even several times an hour.
Payments that you normally make on a monthly basis via direct debit might move to being charged daily, services you might currently subscribe to might charge AND BILL by the minute and in real-time (why would they wait till the end of the month to bill you?).
So this means a much higher volume of data, richer feeds and higher transaction rates, than in the past. Scalability, flexibility and licensing models that allow these high volumes to be handled, processed and stored will be key.
The speed with which a problem could become serious in an API connected ecosystem of banks and service providers could be alarming. Although regulators, service contracts or consumer protection laws might define who carries responsibility and liability for fraud of security problems, the speed of risk propagation might make this nugatory – if a small organisation ends up carrying liability for a massive amount of fraud as a result of a security breach, they could be come insolvent and then where would there be redress from?
The activity on the system is working at machine rather than human speed Any intelligence gathering, analysis, detection, triage, containment and response will ALSO need to operate at machine speed. Flagging up lists of problems, issues, threats or potential attacks for a human to work through one-by-one will not suffice.
See our blog on monitoring and context in cyber security.
This follows on from the need for real-time processing – systems are going to need to be set up with sufficient analytical ability to take the various streams of data and operating contexts and both generate and verify security threats themselves. It is not going to be sufficient to flag a list of “potential” issues. This list could be 1000 entries long, and only eight of those might be real. It is going to stretch the areas of security analytics, user behavioural, machine learning and anomaly detection to identify problems, rule out false positives and gather sufficient information so that security operators are presented with a confirmed problem and the background data to make a decision.
In fact for all cases where the risk/impact of responding or containing a threat is lower than the risk of not acting, the system needs to be empowered to achieve a level of certainty in the outputs it is allowed to verify and respond to an attack immediately. This can be done safely, using the context and workflows that human teams would also follow to reach the same decision – and should ensure that where an error is made (for example, in disabling an account or blocking a transaction flow) that the organisation can easily step back in to undo or redo the operation that was suspect (but turned out to be genuine).
See our blog post here on automation.
Changes to the way banks operate are inevitable under the Open Banking and PSD2 regimes. This will mean allowing third party systems access to data and systems that were previously only allowed to entities (staff and customers) over which the banks had some connection and control.
The effects on monitoring security operations, threat detection and analytics will be marked by a massive need to increase speed of detection and response in a scalable way; allowing machines to work at machine speeds means security processes will need to operate similarly fast.
Relying on security analysts to take on the volume of machine generated alerts and still respond at an acceptable speed in this interconnected banking and service provider system environment will become less tenable and increase the need for investment in AI, machine learning and automation not just in detecting issues; but throughout the incident lifecycle.
To discover the cyber security implications of PSD2, go to our PSD2 web page.
You can also download our Infographic:
A recent KPMG Report suggests that protecting against and dealing with cyber risks will be the major challenge for senior executives in 2024. It is clear that despite high levels of security investment, organisations continue to suffer from cyber attacks.Read more
The Australian Signals Directorate’s (ASD) recent publication of their Cyber Threat Report 2022-2023 unearthed a range of areas for concern for government departments and critical infrastructure entities at local, State and Federal level.Read more
As cyber risks increase, organisations are encountering the longer life cycle of insurance renewals and the need to demonstrate better management of security controls and their effectiveness.Read more
Highlights and insights from the recent Managed Services Summit in London & the ISACA Central Chapter Conference on Digital Trust, in Birmingham, UK. With two recent conferences in the space of three days, some interesting challenges were very evident in the topics discussed. Being very different events, the challenges were quite different, but interestingly they […]Read more
In early August 2023, the latest joint advisory on persistent vulnerabilities was issued by the intelligence and security agencies of the “Five-eyes” community. These joint advisories are becoming more common. Perhaps recognising the growing importance of shared security information and the common nature of many of the threats faced – the weight they carry makes […]Read more
The quality of your risk assessment and the security information it provides is important; if you plan to use it to actively manage your operational and cyber resilience activities. Organisations are constantly exposed to a rapidly changing threat environment, so you really need a similarly rapid evidence-based feedback system that informs you of the ongoing […]Read more
The UK market has its own regulators, security standards and challenges. And while rulings from SEC in the US or the Australian Prudential Regulation Authority (APRA) in Australia don’t apply to UK companies, for the most part, the observations are undoubtedly relevant and the resulting advice instructive. It would be wrong to think UK financial […]Read more
<<< Part 2a: Australia’s Essential Eight: Beyond Endpoint Control <<< Part 2b: Activating UK NCSC & US NIST Guidelines: Beyond Endpoint Control Part 4: Systematic Measurement of Cyber Controls >>> As much as we invest into cyber security controls, external threats are inevitable. In a recent Notifiable Data Breaches Report from the Office of the […]Read more
Keen campers, scouts and even the Swiss Army know – that a good penknife is indispensable. This simple device has mitigated many a disaster at one point in time or another. Whether it’s to cut through a bit of string, tighten a screw or simply to solve the problem of no bottle opener in the […]Read more
Supply chain risk is an area of cyber security that demands the ongoing attention of every enterprise; because it can make the difference between being resilient or not. It’s no surprise that insurers warn that the vulnerability of supply chains is potentially a systemic risk that can quickly propagate across supply chain dominated industries. Organisations […]Read more
Read by directors, executives, and security professionals globally, operating in the most complex of security environments.