SWIFT issued the v2020 of its customer security controls last year as part of the CSP (Customer Security Programme). We reported on this in one of our earlier blog article. This year, there will be mandatory independent audits of compliance with the standard, so it is time to take a clear, unbiased look at the current situation because nobody wants to have a nasty surprise. In this article, we show you what changes have been implemented compared to the v2019 controls, what the most important controls are based on our hands-on experience as an external service provider and assessor, and how you as a SWIFTNet participant can tackle the implementation of the controls effectively.
Note: The SWIFT Security Attestation has decided that due to COVID-19, the originally published timing will be regraded. This year, companies must be compliant with the CSPv2019 with self-attestation. The "Mandatory" of external assessments is postponed to 2021.
All companies that take part in SWIFTNet for processing payment transactions (i.e. with their own SWIFT BIC) must meet SWIFT's own Security Standard CSP (Customer Security Programme) security criteria.
SWIFT (short for Society for Worldwide Interbank Financial Telecommunication) differentiates between controls in terms of their scope and divides this into categories depending on the type of architecture: A (from A1 to A3) and B. We will be looking at these in more detail later on. The distinction is also made between "Mandatory" and "Advisory" controls; "Mandatory" controls have to be complied with, whereas in the case of “Advisory” controls, it is just recommended to implement them. Every year, certain advisory controls are selected to be upgraded to "Mandatory" status, so it is worth keeping an eye on the advisory controls as well.
The controls that have been upgraded from Advisory to Mandatory in the v2020 version are:
The following new advisory control has been added in the v2020 version:
Adapting the scope:
It is explicitly stated in SWIFT's Customer Security Controls Framework (CSCF) that the framework is not to be used as an "Audit Checklist". In the same way, the implementation guidelines described should only be regarded as indications and options. This means that it also possible for there to be implementations that diverge from the implementation guidelines. Implementation should be carried out on a risk-based basis. The auditor also needs to take this factor into account.
SWIFT provides a useful guide for determining the type of CSP architecture to use. However, they state that the examples below are "non-restrictive". Or to put it another way: you cannot rely on the (generally formulated) principles and examples to define the type of architecture definitively - the SWIFT guidelines regulate this.
If you are using the following products and they are controlled by you ("I own"), you can see an overview below in table form of the types of architecture that are eligible to be considered:
| Type of architecture | Components specified |
| B |
|
| A1 |
|
| A2 |
|
| A3 |
|
The following example illustrates architecture type A1 in diagram form. With architecture type A by SWIFT, there are a total of three variants of more or less SWIFT components (messaging interface, communication interface, RMA etc.), which are controlled by the participant.
The "Middleware Server" is particularly worth mentioning. If a server of this type connects the local SWIFT components as a "connector", this is now classified as architecture type A3. (Previously, this was assigned to architecture type B).
In contrast, the figure below shows a schematic example of architecture type B "with no local user footprint". The SWIFT components are not under the participants' control but are (wholly) operated by a service provider. Participants gain access to the SWIFT network via an interface (API) and/or a (web) application.
SWIFT CSP controls can be broken down into three categories:
The CSCF lists 31 security controls. Of these, 21 (for type A; 14 for type B) are mandatory and 10 are recommendations. Within each security control, SWIFT has documented the most common drivers of risk that the control is intended to address and reduce.
In our experience, the following controls are challenging to put into practice.
1: "Safeguard your environment"
2.2 Security updates:
Although security updates are installed, the challenge in practice is to implement them as comprehensively as possible. This means that all applications, operating systems and system components should get security updates promptly and regularly. But in practice, it is not always possible to roll out security updates on all systems "promptly", i.e. within a period of a few hours or days. In addition, integrity checks (validation of checksums and digital signatures of security update files) make extra demands on costs and process flows.
Optimal implementation is where security updates are consistently made to SWIFT systems, at the latest a few days after they are made available. This also involves the test capacities required to do this before security patches are rolled out. In general, when CVSS scores are higher than nine, a security patch should be rolled out as quickly as possible.
2.3 System hardening/protection:
The control is specified rather vaguely, and depending on the system manufacturer, there are no instructions for hardening. However, the SWIFT implementation guidelines do contain useful information, for example on CIS (CIS Hardened Images). Such guidelines should be applied to system hardening as comprehensively as possible.
2: "Knowing and limiting access"
2.6 The confidentiality and integrity of the user session:
Internal system connections (client-to-server, server-to-server) are not yet consistently and comprehensively encrypted throughout company networks. Every single communication connection in modern infrastructure, be it an internal or external one, should be encrypted in line with the principle of "encrypt everything". SWIFT recommends the use of up-to-date algorithms and protocols, which means at least TLS v1.2, and under no circumstances SSL. Time-out settings for inactivity (idling, time-out), which should be configured to appropriate values, should also be taken into consideration. This is typically ten to twenty minutes.
4.2 Multi-factor authentication:
In what is referred to as MFA (multi-factor authentication), also previously referred to as 2FA (two-factor authentication), SWIFT expects that:
In practice, MFA is primarily used for remote access, but also to a lesser extent for applications and (internal) systems (operating systems). Unfortunately, manufacturers do not always support such extensive implementations, so it is critical for there to be a fundamental design for in-house MFA Today, MFA should be carried out via out-of-band communication such as authenticator apps.
3: "Recognising and reacting"
6.4 Logging and monitoring & 7.1 planning actions for cyber incidents:
Comprehensive logging is increasingly being used in corporate system environments, yet there is less ability to effectively detect unusual activities. In the same way, it is difficult to trigger an action plan in the event of (identified) security incidents. We recommend that you prepare a response plan, which should ideally take into account different incident scenarios and respond to each cyber incident with separate procedures. Doing this demands cooperation with a number of different specialist departments within the company. Subsequent regular testing of detection and response capabilities in this area should not be forgotten either.
This is by no means an exhaustive list of important controls and should not be used as a basis for prioritising or weighting controls. All the same, our experience tells us that you should keep these points in mind.
The attestation phase for CSCF v2020 ends (new!) in December 2021 – do you know the current status of your compliance? Do you need assistance with interpreting and implementing the measures required? Are you on the lookout for a qualified external service provider to assess within your company?
InfoGuard is a SWIFT assessor, and Cyber Security Provider as well as member of the SWIFT Customer Security Programme. This This will enable InfoGuard to conduct a compliance assessment for the confirmation required in the second half of 2020. We are pleased to be available to assist you with the implementation of SWIFT CSCF controls or to perform a compliance assessment of your SWIFT CSP implementation. Our SWIFT Assessment gives you a comprehensive overview of your current status and can provide recommendations for the measures you may need to take to meet Compliance v2020. You can find more information and a contact form here:
Note: SWIFT does not certify, warrant, endorse or recommend any service provider listed in its directory and SWIFT customers are not required to use providers listed in the directory.
Source: