Requirement 2 - Reduce attack surface and vulnerabilities

Internal data flow security

The internal data flow security control objective can be accomplished by securing server-to-server traffic using authentication with one-way Transport Layer Security (TLS), or two-way TLS. This control is applicable for the communications between all applications, messaging interfaces, and database connections. The communication between SWIFT applications, Alliance Messaging Hub (AMH), Alliance Access (SAA), Alliance Gateway (SAG), and SWIFTNet Link (SNL), have the mechanism enforced in the application configuration. From the AWS perspective, here is the list of guidance by architecture components:

Security updates

Leveraging container services greatly simplifies the security updates process for many customers. By using Amazon MQ and Amazon RDS for Oracle in the SWIFT secure zone, you do not need to worry about maintaining and patching the underlying EC2 instances. AWS is responsible for maintaining updates for the underlying EC2 instances for AWS Managed Services. In this model, it is your responsibility to upgrade the Amazon MQ broker version and Amazon RDS for Oracle major and minor versions. Refer to the following diagrams:

You are responsible for maintaining security updates for the EC2 instances in the SWIFT secure zone. You can opt to use immutable infrastructure and blue/green deployment strategy for deploying security updates for EC2 instances. In this topology, you would have a “golden” AMI pipeline to create the up-to-date operating system (OS) image, and another AMI pipeline to bundle the golden image with SWIFT applications and third-party libraries. The updated AMI is deployed and tested in the Dev / Test environment, and is subsequently promoted to the production environment. This testing and promotion process can be orchestrated in a pipeline created with AWS CodePipeline, or your existing CI / CD pipeline.

System hardening

Customers are responsible for maintaining the security configuration standards for their resources provisioned on AWS. These standards must be consistent with industry- accepted system hardening standards, and include the customer’s configuration of AWS services. AWS has published extensive security guides for the platform and individual services. The base set of these are:

There are various options to archive this control objective. For example, you can launch the pre-hardened EC2 instance using a CIS-provided AMI in the AWS Marketplace.

Another option is to leverage the AMI pipeline to build the hardened EC2 AMI. If you are using EC2 Image Builder for the AMI pipeline, EC2 Image Builder provides EC2 Image Builder STIG components for EC2 hardening.

Back-office data flow security

This control objective is similar to Internal data flow security, but this is an advisory control and primarily focuses on the edge connection to the secure zone. A backend payment application on-premises connecting to the Amazon MQ that resides in the SWIFT secure zone VPC is an example for such a connection. The principles and the requirements of the two controls are the same, so the guidance is the same as 2.1.

If you use a hybrid architecture, such as one in which the back-office applications reside in an on-premises data center and the SWIFT secure zone is on AWS, consider using an internet protocol security (IPsec) VPN tunnel or Media Access control Security (MACsec) to encrypt the networking traffic in between. Refer to:

Besides encryption in transit using IPsec and MACsec, it is important to use Security Groups and Network ACLs (NACLs) to control the connection to the edge of the SWIFT secure zone. For example, if the entry point of the secure zone is Amazon MQ, the Security Group for Amazon MQ should allow incoming connections from the on- premises IP CIDR range, while other components in the secure zone should not allow incoming connection from the same range. NACLs can be applied in addition to Security Groups to provide an additional layer of access control.

External transmission data protection

AWS KMS is a managed service that makes it easy for you to create and control AWS KMS keys (CMKs), the encryption keys you can use to encrypt your data. AWS KMS CMKs are protected by hardware security modules (HSMs) that are validated by the FIPS 140-2 Cryptographic Module Validation Program, except in the China (Beijing) and China (Ningxia) Regions.

This control objective concerns the compromising of trusted backup data and loss of sensitive data confidentiality.

In an AWS environment, data backup is automatically encrypted by the same Key Management Service (KMS) encryption key as your data store. For more information, refer to Encryption for backups in AWS. Encryption of the data stores in the SWIFT secure zone (such as RDS Oracle and EBS volumes) can satisfy this requirement.

Operator session confidentiality and integrity

There are two aspects to consider for meeting control objectives:

When AWS Systems Manager Session Manager is used in place of the jump server for operator access, the first implementation guidance is satisfied. All AWS-provided services, including AWS Systems Manager Session Manager, require authentication, and the traffic is required to be encrypted using TLS. Choose one of the options for logging session activity in your AWS account with the appropriate encryption mechanism enabled.

In addition to providing information about current and completed sessions in the Systems Manager console, Session Manager provides you with options for logging session activity in your AWS account. This enables you to:

AWS System Manager Session Manager supports idle session timeout. It enables you to specify the amount of time to allow a user to be inactive before a session ends. By default, sessions time out after 20 minutes of inactivity. You can modify this setting to specify that a session times out between one and 60 minutes of inactivity.

Vulnerability scanning

You can employ Amazon Inspector to help you achieve the vulnerability scanning control objective. Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. Amazon Inspector automatically assesses applications for exposure, vulnerabilities, and deviations from best practices. With Amazon Inspector, you can automate security vulnerability assessments throughout your development and deployment pipelines, or on EC2 instances. Amazon Inspector also offers an agent that you can install on Linux or Windows EC2 instances to scan for vulnerabilities. The Amazon Inspector agent also monitors the behavior of the EC2 instances, including network, file system, and process activity.

In addition, there are many AWS Partner solutions available in this space which you can use.

Application hardening

Guidance for securing Messaging and Communication interfaces for SWIFT applications (AMH, SAA, SAG, SNL) are in SWIFT Knowledge Centers.