Compliance: back to basics
Compliance: back to basics
Ensuring security on Swift’s network doesn’t have to be rocket science. Getting the basics right will help individual institutions and Swift’s community, writes Daily News at Sibos editor Heather McKenzie.
Amid the hype and disinformation about cyber attacks and who perpetrates them, it is often easy to forget that prevention isn’t rocket science. While those launching such attacks are increasingly well-organised groups that act like corporates, they often take advantage of lax security – the equivalent of leaving a window open, or the keys in a car’s ignition. The May ransomware attack on the UK’s National Health Service, for example, was made possible because the service – subject to swingeing government cuts – was using unsupported XP operating systems.
The attempts to hack into Swift’s network last year were largely made via central banks or other banks in emerging economies. Attackers started by exploiting security weaknesses within institution’s local environments to steal valid operator credentials to their local payment infrastructure. They then inputted seemingly legitimate payment instructions with those valid credentials and hid the evidence of fraud.
Following these attacks, Swift launched the Customer Security Programme (CSP) to support users in their fight against cyber attacks. While Swift members are responsible for protecting their own environments, CSP is designed to raise standards among Swift members. It focuses on three aspects: an institution itself, the institution’s counterparties, and the community.
Swift points out that securing a bank’s local environment is the most important action to take. Securing the physical set-up of the local Swift-related infrastructure and putting in place the right people, policies and practices, are critical to avoiding cyber-related fraud. This can be as simple as ensuring that the Swift terminal is in a secured environment and accessible only to those who are authorised to use it.
From January 2018, Swift members will be required to meet mandatory rules within CSP, including inspections from internal or external auditors conducted with samples of customers to check quality. The detailed compliance status of each customer will be made available to their counterparties (for example via the KYC Registry), providing transparency and allowing other users on the network to apply risk-based decision making regarding their counterparty relationships.
Swift has introduced new security features to its products to make those requirements easier to meet. For example, two-factor authentication has been introduced for Alliance Access customers that do not yet have the facility.
For counterparties, Swift operates the Relationship Management Application, which enables members to control access and check that they are doing business with their trusted counterparties. Swift is also facilitating discussions with banks to develop a common understanding between sending and receiving parties of the warning signs that should lead to payments being investigated, and of how suspicious payments should be stopped.
Finally, Swift is also encouraging members to share information about attacks. The cooperative’s Customer Security Intelligence team can help limit the community impact by sharing anonymous information on indicators of compromise and by detailing the modus operandi used in known attacks. This information is disseminated through Swift’s Security Notification Service to which all members can subscribe.
“With CSP, Swift is attempting to raise the bar on security,” says Jerry Norton, head of strategy for CGI’s UK financial services business. “It provides a set of controls to which Swift members have to adhere, whether they are banks, corporates, bureaus etc. Some members will be very well-versed in these controls, but others possibly not.”
A chain is only as strong as its weakest link, which makes Swift’s CSP a “necessary step” in addressing cyber crime, says Phillipe Lepoutre, deputy head of global transaction and payment services at Société Générale. “As a global network, Swift allows exchanges between different types of banks – from the very largest multinational institutions through to very small banks. The perception is that perhaps some of the smaller banks have not taken cyber security as seriously as they should, which has created weak points in the Swift network. The fraud attacks on the network were a wakeup call for many Swift members. That is why the CSP is very timely and the whole Swift community should engage with it.” CSP will create transparency between members on the Swift network and will be a strong incentive for all banks to show they are not lagging when it comes to cyber security, he adds.
Initially the CSP assessments are based on self-evaluation, but that may evolve over time to assessments conducted by a third-party. The card industry’s Payment Card Industry Data Security Standard (PCI DSS) is a good indicator of how CSP may evolve, says Lepoutre. Most of the card industry players have engaged with PCI DSS, which provides a strong and demanding standard for card security. It is becoming very necessary for the Swift community to engage in a similar type of project, he says.
To a certain extent, self-certification protects Swift from taking on the responsibility of certifying the security of all its members. It is up to each Swift member bank to assess its counterparty’s security and make a risk-based decision on whether it is prepared to do business with that member bank.
“CSP isn’t rocket science,” says Norton. “It is bringing consistency and standards to security.” For example, in addition to ensuring Swift access is isolated from non-authorised users, firms are also urged to have robust password policies. For example, passwords should be longer than four characters and be regularly changed.
“There is an issue that while some larger institutions may have policies and procedures, not everyone enforces them. Smaller institutions may not have such policies at all and CSP is a way of helping those that don’t know where to start,” he adds.
Any security policy must start at the top, in the boardroom, says Norton. Moreover, the policy must be enforced. Cybersecurity is not a back-end IT problem, but is all about best practice and how risk is managed. Cyberattacks are a business risk and therefore should be put on a register of risks by the institution’s risk committee.
Leigh Mahoney, head of wholesale digital transformation at ANZ, says good cyber security successfully considers both people and technology. “The focus is often on having the latest, best in class technology, but cyber attacks more often occur because someone, somewhere, did something they shouldn’t have. It is important to consider this ‘people’ element, the user experience and the culture of an organisation where the technology is deployed from the outset.”
Stephen Scharf, chief security officer, DTCC, says mitigating cyber risk requires a joint effort as it is an industry-wide challenge. “We don’t believe any firm can be 100 per cent successful fighting cyber attacks on their own. In the securities industry, we have learned that we are better protected if we work together, rather than in isolation.”
Whereas in the past security was a private issue and few people spoke about their challenges, this trend has completely reversed, says Scharf. “It used to be thought of as foolish if you spoke out about problems; now it is foolish if you don’t.”
Industry groups, based on collaborative sharing of information about security, can help. For example, the Financial Services Information Sharing and Analysis Centre (FS-ISAC) is a collaborative effort between banks and utilities. It was launched in the US in 1999, after a Presidential Directive (later updated in 2003) mandated that public and private sectors share information about physical and cyber security threats and vulnerabilities to help protect US critical infrastructure.
More recently, FS-ISAC established Sheltered Harbor, a “forward looking attempt to prevent future risks”, says Scharf. An industry-led organisation, it enables financial institutions to securely store and rapidly reconstitute account information, making it available to customers, whether through a service provider or another financial institution, if an institution appears unable to recover from a cyber incident in a timely fashion. Consumer data stored in a Sheltered Harbor specified data vault is kept private by each institution, is encrypted and protected from change. The model is a distributed one, with no central repository of information. The concept for Sheltered Harbor arose during a series of successful cyber security simulation exercises between public and private sectors.
It is “inevitable” that the cyber control environment of a bank’s clients will become a larger and more integral part of their know your customer framework, says Mark McNulty, head of global clearing and FI payments at Citi treasury and trade solutions. “The increase in cyber attacks on banks, that have often resulted in the successful transfer of money, highlights the need for counterparty cyber risk assessments to grow in sophistication.”
While he welcomes the development of Swift’s customer security controls and the upcoming transparency that Swift counterparties will have on each other’s attestation against those mandatory controls, more industry work is needed, he says. “The industry must create a common interpretive framework for counterparty risk with the information on Swift mandatory controls being a critical, but not the sole, input.”
The common framework is required to ensure that assessments can happen in the most efficient way possible and banks can focus on acting on the output.
Scharf emphasises that the way to strengthen cyber security lies in “getting the basics right”. This includes adhering to core principles of updating software patches, identifying vulnerabilities and ensuring ID management is robust. “The core, fundamental tenets of a security program are very important. Often these are tried and true approaches; firms should understand that innovation and security can work together. Building in these basic tenets of security from the start of any product design will ensure that new products can be very secure.”
Lepoutre points up that knowing how to fight a fraud or cyber attack that has not yet happened is challenging. Banks must bring together specialists in payments, Swift, data science and technology to work together and detect the possible ways a fraud might be attempted through Swift. “A deep understanding of the flow that comes through the Swift pipes every day will help in pinpointing suspicious transactions. In retail payments, the large volumes mean that machine learning systems can self-learn more easily based on the track-record of frauds; this is not the case with Swift payments.”
Ideally, says Lepoutre, internal defences at banks should be combined with defences inside Swift itself. Within a global network like Swift it is often easier to detect fraudulent transactions than it is within a single bank. “Such an approach could involve Swift managing a set of generic rules, which are based on members’ experiences. This combination of security at individual financial institutions and at Swift would provide the most secure approach. This will take time to build, but is in the direction the industry should head.”
This article is also featured in the Daily News at Sibos 2017 – Day 3 edition.
Click here to read the issue online or pick up a print copy if you are at the conference!
The digital and print editions are free.
