SWIFT CSP v2020 – why you should never lose track of these controls

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.

CSP v2020: what do you need to be aware of?

The controls that have been upgraded from Advisory to Mandatory in the v2020 version are:

• 1.3 Virtualisation Platform Protection / Protection of virtual environments:
  Virtual environments and virtual machines (VMs) hosting SWIFT components must be protected to the same extent as physical systems.
• 2.10 Application Hardening:
  On SWIFT certified messaging and communication interfaces and their associated applications, the attack surface has to be reduced by hardening the application.

The following new advisory control has been added in the v2020 version:

• 1.4A Restriction of Internet Access:
  Within the protected SWIFT zone, the internet access of user PCs and other systems should be restricted to reduce the risk of internet-based attacks.

Adapting the scope:

• 2.4A Back Office Data Flow Security: 
  Has been made "Advisory" if Middleware / MQ Server is used (architecture type A3 – variant "Middleware Server (as a connector)").
• The RMA (Relationship Management Application) controls and transaction security controls have been split into two separate advisory controls:
  • New: 2.11A RMA Business Control.
  • New: 2.9A Transaction Business Controls:
    Measures should be implemented in the RMA (Relationship Management Application) to limit transaction activities to actual business partners. This is intended to reduce the risk of conducting a transaction with an unauthorised partner. SWIFT is already indicating that this measure will be upgraded to “Mandatory” in a forthcoming version of the document (v2021).

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.

What are the advantages of a CSP architecture type?

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:

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.

What are the important SWIFT CSP controls in our experience – how can you approach them?

SWIFT CSP controls can be broken down into three categories:

1. Safeguarding your environment
2. Identifying and limiting access
3. Recognising and reacting

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:

• on the one hand, user access to SWIFT-related applications ("dedicated operator PC / dedicated SWIFT workstations", "jump server" (if available and messaging/communication interfaces (if type A) are explicitly mentioned),
• and on the other hand – specifically – their operating systems, are protected by MFA.

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.

Ensure SWIFT compliance – act now

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:

• Table: SWIFT "Decision Tree Guidance"
• Graphics: "SWIFT Customer Security Controls Framework v2020 – detailed description"