Tools, processes and other thoughts related to securing Swift (Society for Worldwide Interbank Financial Telecommunication) infrastructure. Swift is an open global standard for financial information, providing consistent, rich and structured data that can be used for every kind of financial business transaction. As such, it is a prime target for threat actors, and requires appropriate security due diligence. Fortunately, the Swift organization provides a variety of security-related offerings and free resources to help security practitioners and businesses safeguard sensitive financial systems.

Note: Honestly, I think the Customer Security Controls Framework (CSCF) offered by Swift does a pretty comprehensive job of explaining most of what I plan to go over here. I’m not sure what this post will ultimately help explain that that guide doesn’t. For me though, I like to process things in this way. Maybe the way I organize the information, the additional color I provide, and any further thoughts about security testing these types of environments that I add in the future will be of use to you as well - beyond what the CSCF and accompanying documentation provides.

Swift Customer Security Program

The Swift CSP (Customer Security Program) is a collection of security-oriented tools and programs designed by the Swift organization. The CSP is comprised of the following…

For this particular write-up, I’m only going to dive into the CSCF and PCS components of the CSP.

Swift Payment Controls (PCS)

The Swift organization offers “Payment Controls” (PCS), a collection of security and fraud-detection capabilities.

PCS includes the following security controls… (From Packetlabs1)

  • Anomaly Detection on Repeated Payments: Identifies suspicious transactions by flagging repeated payments of the same amount and currency between accounts, helping detect potential fraud or human errors.
  • Monitoring of New Accounts: Detects transactions involving newly established accounts on the Swift network, which may signal fraud or operational mistakes, such as errors in beneficiary account details.
  • Account-Based Network Insights: Uses anonymized account-level data from the broader Swift network to detect unusual account behavior, which can reveal fraud patterns not visible to individual institutions.
  • Real-Time Screening and Blocking: Screens outgoing Swift ISO 20022 messages (e.g., MT103, MT202) based on configured rules, allowing for real-time interception of suspicious payments to prevent financial or reputational damage.
  • Customizable Rules Based on Risk Appetite: Institutions can configure specific rules aligned with their risk tolerance, business objectives, and payment policies, creating tailored detection parameters.
  • Hosted Solution for Security Resilience: Operates independently from institutions’ internal systems to provide protection in case of a cyberattack or operational disruption.
  • Behavioral Pattern Learning: Uses intelligent technologies to learn transaction patterns over time, continually improving fraud detection capabilities.

Security assessors should verify whether their organization is leveraging these capabilities via PCS. If not, do they possess similar defensive capabilities locally?

Customer Security Controls Framework (CSCF)

The Swift Customer Security Controls Framework (CSCF) consists of mandatory and advisory security controls for Swift users. These controls have evolved over time to combat new and arising threats. The 32 controls can be grouped within seven distinct security principles which in turn map to three over-arching framework objectives.2 3

Objectives, Principles, Controls

* You can access the latest CSCF framework docs here.

Mandatory Controls

The Swift CSCF lists 16 mandatory controls.4 They are described within the CSCF as…

Mandatory security controls establish a security baseline for the entire community and must be implemented by all users on their Swift infrastructure. Swift prioritizes the mandatory controls to set a realistic goal for short-term, tangible security gains, as well as risk reduction.

Mandatory Security Controls
1. Restrict Internet Access and Protect Critical Systems from General IT Environment
1.1 Swift Environment ProtectionEnsure the protection of the user’s local Swift infrastructure from potentially compromised elements of the general IT environment and external environment.
1.2 Operating System Privileged Account ControlRestrict and control the allocation and usage of administrator-level operating system accounts.
2. Reduce Attack Surface and Vulnerabilities
2.1 Internal Data Flow SecurityEnsure the confidentiality, integrity, and authenticity of data flows between local Swift-related applications and their link to the operator PC.
2.2 Security UpdatesMinimize the occurrence of known technical vulnerabilities within the local Swift infrastructure by ensuring vendor support, applying mandatory software updates, and applying timely security updates aligned to the assessed risk.
2.3 System HardeningReduce the cyberattack surface of Swift-related components by performing system hardening.
3. Physically Secure the Environment
3.1 Physical SecurityPrevent unauthorized physical access to sensitive equipment, workplace environments, hosting sites, and storage.
4. Prevent Compromise of Credentials
4.1 Password PolicyEnsure passwords are sufficiently resistant against common password attacks by implementing and enforcing an effective password policy.
4.2 Multi-factor AuthenticationPrevent that a compromise of a single authentication factor allows access into Swift systems, by implementing multi-factor authentication.
5. Manage Identities and Segregate Privileges
5.1 Logical Access ControlEnforce the security principles of need-to-know access, least privilege, and segregation of duties for operator accounts.
5.2 Token ManagementEnsure the proper management, tracking, and use of connected hardware authentication tokens (if tokens are used).
6. Detect Anomalous Activity to Systems or Transaction Records
6.1 Malware ProtectionEnsure that local Swift infrastructure is protected against malware.
6.2 Software IntegrityEnsure the software integrity of the Swift-related applications.
6.3 Database IntegrityEnsure the integrity of the database records for the Swift messaging interface.
6.4 Logging and MonitoringRecord security events and detect anomalous actions and operations within the local Swift environment.
7. Plan for Incident Response and Information Sharing
7.1 Cyber Incident Response PlanningEnsure a consistent and effective approach for the management of cyber incidents.
7.2 Security Training and AwarenessEnsure all staff are aware of and fulfil their security responsibilities by performing regular security training and awareness activities.

Advisory Controls

The Swift CSCF lists 11 advisory controls.4 They are described in the CSCF as…

Advisory controls are based on best practices that Swift recommends users to implement.

Advisory Security Controls
2. Reduce Attack Surface and Vulnerabilities
2.4 A Back Office Data Flow SecurityEnsure the confidentiality, integrity, and mutual authenticity of data flows between back office (or middleware) applications and connecting Swift infrastructure components.
2.5 A External Transmission Data ProtectionProtect the confidentiality of Swift-related data transmitted and residing outside of the secure zone.
2.6 A Operator Session Confidentiality and IntegrityProtect the confidentiality and integrity of interactive operator sessions connecting to the local Swift infrastructure.
2.7 A Vulnerability ScanningIdentify known vulnerabilities within the local Swift environment by implementing a regular vulnerability scanning process.
2.8 A Critical Activity OutsourcingEnsure protection of the local Swift infrastructure from risks exposed by the outsourcing of critical activities.
2.9 A Transaction Business ControlsRestrict transaction activity to validated and approved counterparties and within the expected bounds of normal business.
5. Manage Identities and Segregate Privileges
5.3 A Personnel Vetting ProcessEnsure the trustworthiness of staff operating the local Swift environment by performing personnel vetting.
5.4 A Physical and Logical Password StorageProtect physically and logically recorded passwords.
6. Detect Anomalous Activity to Systems or Transaction Records
6.5 A Intrusion DetectionDetect and prevent anomalous network activity into and within the local Swift environment.
7. Plan for Incident Response and Information Sharing
7.3 A Penetration TestingValidate the operational security configuration and identify security gaps by performing penetration testing.
7.4 A Scenario Risk AssessmentEvaluate the risk and readiness of the organization based on plausible cyberattack scenarios.

Architecture

Logically, we can separate the Swift architecture into two distinct areas, that which is owned and operated by Swift (and other third-party, Swift-affiliated organizations), and the local (user) infrastructure owned by any entity that conducts business on the Swift network. From a security testing perspective, this document mostly focuses on the latter. However, for more info on SwiftNet, and other Swift-org-related infrastructure/systems, see the resources provided below….

Swift Organization Infrastructure

SwiftNet is an application-level messaging service that connects financial institutions and businesses to the Swift payment network.

Swift User Infrastructure

To secure the local infrastructure which creates, transforms, ingests and stores Swift transactions, it is important to have an understanding of the relevant systems and their process flows, as well understanding the authorized actors of the overall system. A detailed accounting of these systems (e.g. constructing a data-flow / architecture / process-flow diagram) should be conducted before performing security testing.

Components
  • Secure Zone: Segmented/protected network zone which houses Swift-related infrastructure.
  • Messaging Interface: Software which supports a variety of Swift-related messaging standards (e.g. MT, MX, ISO 20022) via Swift FIN, FileAct, and SwiftNet messaging services. (Requires SwiftNet Link (SNL))
  • Communication Interface: Provides the link between SwiftNet and the messaging interface / back-office system.
  • Connector: Local software which facilitates commnication to an external messaging and/or communication interface. (e.g. Swift or Customer connector)
  • Swift Hardware Security Modules (HSMs): Stores tokens, smart cards and other sensitive/key material.
  • Operators: Individual end users that interact with Swift systems at the application or OS level.
  • Operator PCs: End users computer used to access Swift systems.
  • Data exchange layer: Transport of data between Swift-related components and a user back-office first hop.
  • Middleware server: Any infrastructure that brokers data within the data exchange layer.
  • File transfer server: FTP server used to exchange files between Swift-related components and user back-office. (i.e. bridging server)
Reference Architectures

Generally, the infrastructure design is described as one of five different reference architectures.5

  • Architecture A1: User owns communication and usually the messaging interface.
  • Architecture A2: User owns messaging interface but not the communication interface
  • Architecture A3: Swift Connector
  • Architecture A4: Customer Connector
  • Architecture B: No local user footprint in scope

Reference Architectures

One such architecture (in this case, Architecture A1) is displayed below…

Secure Zone Architecture

Swift Security

Swift-related infrastructure deserves a high level of security assurance given its responsibility in processinging and intiating payments. If not properly secured, incidents can prove extremely costly.

Incidents

Some notable Swift fraud incidents.1

  • 2015 Ecuadorian Banco del Austro (BDA): 12.2M lost
  • 2015 Vietnamese Tien Phong Commercial Joint Stock Bank: 1.36M lost
  • 2016 Central Bank of Bangladesh: 81M lost
  • 2017 NIC Asia Bank: 4.4M lost
  • 2017 Far Eastern International Bank (FEIB): 60M lost

Each of these incidents report in millions lost, but that isn’t the only impact of a security compromise of your Swift infrastructure. Consider the following…

Impacts

A list of potential impacts resulting from security compromise of Swift-related systems.3

  • Unauthorised transmission and/or modification of financial transactions
  • Receipt and processing of altered or unauthorised transactions
  • Transactions with unauthorised/unintended parties
  • Breach of confidentiality and integrity of information concerning personnel, business and technological components
  • Financial, legal, regulatory and reputational risks.

To realize these impacts, threat actors must identify vulnerability in the composite Swift system, and perform one, or chain-together multiple attacks.

Security Testing

Considerations for conducting security testing against Swift systems.

Questions & Scoping

Performing security testing against a Swift system is not too dissimilar from security testing anything else.

  • Has the system been kept in compliance with the CSCF? Does this include all advisory controls? Has this compliance been audited by an internal or independent third-party assessor?
  • Has the organization submitted a KYC-Security Attestation Application (KYC-SA)?
  • Is the organization leveraging Swift PCS? Are they using both alerting and reporting modules?
  • Are any outsourced resources used for managing/maintaining/accessing Swift-related infrastructure?6
  • How are in-scope Swift systems incorporated into back-up and Disaster Recovery contingencies.
  • What systems are out-of-scope? (Listed below are systems typically considered out of scope…)
    • Test systems if they are fully isolated from production and only support test traffic.
    • Back-office systems responsible for business-logic / transaction generation before transmission into the user’s Swift infrastructure. (e.g. SAP, General Ledger, etc…) unless the back-office systems are co-hosted on Swift-related infrastructure.
    • The general enterprise IT environment.
    • Connections to the Swift network supplied by Swift Network Partners and internet connections to Swift network. However, Swift Alliance Connect SRX VPN boxes are in scope courtesy of control 3.1.
  • (Per CSCFv2020 - 7.3A) Security assessments should be conducted against all hardware, software, and network components
  • (Per CSCFv2020: 1.1) Implement a ‘secure zone’ to separate and protect the local Swift infrastructure from the compromise of systems and services located outside of the secure zone
  • What payment message types does the organization use? (e.g. MT 103, MT 202, MT 202 COV, pacs.004, pacs.008, pacs.009)

Connectivity…

  • Bi-directional communications with back office applications and SwiftNet
  • Inbound communications from approved general-purpose operator PCs to the jump server
  • Outbound administration data (data logging, backups, etc)
  • periodically review rules governing connectivity

Security Testing

A list of test cases and considerations when performing a Swift security review. Many of these will be pretty standard for conducting infrastructure / application security testing.7

Security testing is governed by these 8 objectives & principles…

  • Restrict Internet access
  • Segregate critical systems
  • Reduce attack surface and vulnerabilities
  • Secure the physical environment
  • Prevent compromise of credentials
  • Manage user privileges
  • Detect anomalous activity
  • Share intelligence and devise incident response procedures

Further considerations…

  • Verify separation of duties and least privilege is enforced
  • Proper MFA enabled for jump-server between the general IT and secure zone boundary and on individual Swift applications
  • Secure zone is limited to just necessary systems and software (i.e. attack surface reduction)
  • Evaluate non-production environment to ensure it is isolated from production and not storing/processing production datasets.

Independent Assessment Framework

Resources

  1. Attacking the Swift Banking System (Packetlabs) ↩ ↩2

  2. A comprehensive approach to Swift security assessment (Vietnam Investment Review) ↩

  3. Swift Customer Security Controls Framework - Detailed Description ↩ ↩2

  4. Swift Customer Security Controls Framework - Self-Assessment Required by Year End (weaver) ↩ ↩2

  5. Swift - Security controls in international financial transactions (kirey group) ↩

  6. Testing Swift systems in a more secure world (WithSecure) ↩

  7. Swift Systems and the Swift Customer Security Program (Deloitte) ↩