AWS Public Sector Blog

How UK public sector customers can implement NCSC security principles to protect data transfers to AWS

To drive innovation and optimise operations in the Amazon Web Services (AWS) Cloud, UK public sector organizations need to transfer data quickly and safely, in accordance with the National Cyber Security Centre (NCSC)’s guidance on how to configure, deploy, and use cloud services securely. The NCSC provides security guidance for protecting government systems, planning for cyber incidents, and more.

In this post, we cover how you can configure AWS services—like AWS DataSync, AWS Storage Gateway, and AWS Transfer Family—to align your data transfer solution with the NCSC’s cloud security principles. Understanding these configurations is important to protect data and meet requirements for local force accreditation.

1. Data in transit protection

The first NCSC cloud security principle, “Data in transit protection,” advises that organizations must protect data in transit from unauthorised access like tampering or eavesdropping. The NCSC recommends specific Transit Layer Security (TLS) configurations to make sure TLS provides adequate protection.

I. AWS services for NCSC-recommended TLS configuration

The following AWS services can be used for data transfer and configured to align with the NCSC TLS recommendations:

AWS DataSync is a secure online service that automates and accelerates moving data between on-premises and AWS storage services. DataSync customers deploy an appliance that connects to existing server message block (SMB) or network file system (NFS) shares and then transfers data to Amazon Simple Storage Service (Amazon S3) using the Amazon S3 API encrypted in transit with TLS.

AWS Storage Gateway is a set of hybrid cloud services that gives customers on-premises access to virtually unlimited cloud storage. Customers use Storage Gateway to integrate AWS Cloud storage with existing onsite workloads so they can simplify storage management and reduce costs for key hybrid cloud storage use cases.

AWS Transfer Family lets customers deploy service endpoints in their AWS account. Then, they configure Transfer Family clients to connect to the endpoints over TLS. Transfer Family is a secure cloud service to scale customers’ recurring business-to-business file transfers to Amazon S3 and Amazon Elastic File System (Amazon EFS) using SFTP, FTPS, and FTP protocols. In this blog post, we focus on FTPS.

With Storage Gateway and DataSync, AWS controls the client TLS negotiation, whereas with FTPS, the customer controls the client negotiation. This is important to understand as it changes where the security configuration responsibility lies in context of the AWS Shared Responsibility Model. With Storage Gateway and DataSync, AWS is responsible for the TLS configuration, whereas with FTPS, the client connecting to the service is responsible for providing the TLS configuration that can be supported.

II. TLS cipher suites recommended by the NCSC

The NCSC recommends the use of TLS versions 1.2 or 1.3. AWS services support TLS 1.2, so for the rest of this blog post we will focus on the configuration of TLS 1.2.

The NCSC recommends configuring the following specific ciphers with TLS 1.2:



For DataSync and Storage Gateway, it isn’t possible to enforce specific ciphers to connect to Amazon S3. This means that customers cannot enforce a specific cipher and must rely on how AWS has configured the service. However, analysis with AWS CloudTrail, which tracks activity and API usage across an organization’s AWS infrastructure, shows that currently ECDHE-RSA-AES128-GCM-SHA256 is negotiated by DataSync and Storage Gateway. So, though there is no action required by the customer, this information will be needed when looking at accrediting services for operations.

Figure 1. AWS CloudTrail log showing negotiated cipher suite.

Figure 1. AWS CloudTrail log showing negotiated cipher suite.

If your accreditation requires validation of the cipher used, you can create an Amazon CloudWatch alarm that will launch if the cipher suite changes from the configuration specified above. Follow this guide on creating CloudWatch alarms.

For FTPS, it’s possible to select specific transfer security policies that will enforce a specific set of ciphers. With this configuration, the recommended NCSC ciphers are supported:



In this scenario, it’s important to understand that the client negotiates the cipher with the service. With DataSync and Storage Gateway, AWS manages that client negotiation; however, with FTPS, customers are responsible for the client so customers need to make sure to configure it to negotiate recommended ciphers.

III. Avoid known insecure TLS features

The NCSC provides additional guidance about how to avoid known insecurities with TLS versions 1.2 and below. The table below reviews these recommendations in the context of the Amazon S3 data API used to upload and download data. There are no specific configuration changes you need to make; however, this information will be used during your local force accreditation.

Configuration Amazon S3 (DataSync and Storage Gateway upload) FTPS
Disable TLS insecure renegotiation Pass – disabled The FTPS does not disable renegotiation; however, since customers are in control of the client connecting to the service, it is possible to disable renegotiation at the client level.
Disable TLS insecure protocol downgrade Only required if TLS 1.1 is supported. Mitigated by enforcing TLS 1.2. Only required if TLS 1.1 is supported. Mitigated by only supporting TLS 1.2.
Disable TLS record compression Pass – all enabled ciphers have TLS compression disabled. Pass – All enabled ciphers have TLS compression disabled.
Disable export key generation by ensuring EXPORT ciphers are disabled Pass – disabled Pass – disabled
Disable support for secure sockets layer (SSL) 2, as it can be used to attack stronger connections. Only relevant to SSL 2. Mitigated by enforcing TLS 1.2. Only relevant to SSL 2. Mitigated by FTPS only supporting TLS 1.2.

IV. Data integrity in transit

Storage Gateway and FTPS both validate the data when it is uploaded to Amazon S3; however, if the file is above 5GB, it is split into multiple parts. Each part is validated after the transfer, but the reconstitution of the file on Amazon S3 is not validated in its entirety. However, DataSync allows customers to configure the service to not only validate individual parts but also perform a complete validation of the reconstituted file. See the configuration option VerifyMode for more details.

2. Asset protection and resilience: Data at rest protection

The NCSC principle, “Asset protection and resilience,” specifies that stored user data, and the assets storing or processing it, must be protected against physical tampering, loss, damage, or seizure. So once data has been uploaded into the cloud, customers need to make sure it remains protected from unauthorised access while stored in AWS. To help customers achieve this, DataSync, Storage Gateway, and Transfer Family fully support encryption at rest.

Customers can also use AWS Key Management Service (AWS KMS) to create encryption keys within their AWS account. They can choose to have AWS manage the keys or manage the keys themselves. These cryptographic keys control user access across a wide range of AWS services in customer applications. We recommend that customers use customer managed keys to encrypt their data, which adds another point of control as users not only need permission in their IAM role but also separate authorisation to explicitly use the encryption key.

With DataSync, Storage Gateway, and Transfer Family, it’s possible to enforce default encryption in Amazon S3 to automatically encrypt the transferred data. If customers choose to manage their own keys, the key policy must allow the service role (used by the service to transfer data to Amazon S3), to generate and decrypt AWS KMS data keys. Additionally, Storage Gateway allows customers to enable AWS KMS encryption configuration directly against the file share within the service instead of having to configure it within Amazon S3.

3. Separation between users and authentication

Per the NCSC security principle, “Separation between users,” a malicious or compromised user of an organization’s service should not be able to affect the service or data of another. Customers can create separation between users on AWS with AWS Identity and Access Management (IAM). AWS operates on a model of least privilege that requires pre-defined permissions to be assigned to specific functions, so users and services only have access to the resources they need to perform their designated role.

Storage Gateway allows users pre-defined granular access to the local SMB or NFS it makes available on premises. DataSync can be configured to allow users to run pre-existing tasks which will transfer new data written to previously defined SMB or NFS shares on-premises to AWS. FTPS can be configured to allow users granular access to specific directories to transfer data to Amazon S3.

4. Monitoring for operational security

According to the NCSC “Operational security” principle, a public sector service needs to be operated and managed securely in order to impede, detect, or prevent attacks through good operational practices, such as vulnerability management and threat detection.

Organizations should consider that with the AWS Shared Responsibility Model, AWS is responsible for the security and infrastructure of the cloud, and customers are responsible for the security and operations of their workloads in the cloud, like implementing threat detection and continual compliance.

Customers can use Amazon GuardDuty, an intelligent threat detection service, to continually monitor workloads for malicious activity, and AWS Config, a service that assesses and audits the configuration of AWS resources, to track configuration changes and enforce compliance. Customers can configure GuardDuty to monitor Amazon S3 data events to protect data stored in Amazon S3. Finally, DataSync, Storage Gateway, and Transfer Family can integrate with Amazon CloudWatch, allowing customers to gain insight into the operational performance of their data transfer solution.

5. Audit information for users

The NCSC principle “Audit information for users” dictates that organizations should provide the audit records needed to monitor access to their services and the data held within them. With data auditing, organizations can capture audit logs to detect and respond to inappropriate or malicious activity.

AWS CloudTrail allows users to audit all activity undertaken within an AWS account, including access to the data stored in Amazon S3. We recommend that these audit logs are available both locally in the account where the service is running and also forwarded to a separate AWS account that only the security team has access to. There should be preventative controls stopping local administrators from disabling the forwarding. Additionally, if customers are using Storage Gateway with SMB and active directory (AD) integration, they can enable SMB access logging.

AWS-managed solutions that support NCSC guidance

Many of the best practices detailed in this document can be programmatically enabled through specific AWS solutions, such as AWS Control Tower and the AWS Secure Environment Accelerator (ASEA), which extends AWS Control Tower’s capabilities, like adding rich network automation. For example, the configuration of separate AWS accounts for separation of duties between audit logs and monitoring, the enablement of security services such as preventative, detective security controls, and services.

For our UK law enforcement customers, AWS has developed the AWS Police Assured Landing Zone (PALZ), a set of configurations, code, security models, and design decision rationale artefacts created specifically for policing workloads. PALZ implements a set of nationally assured baselines that help mitigate common risks identified with law enforcement data. This can be accessed through the Police Digital Services and the national standards site.


At AWS, we want to support customers in implementing the appropriate security measures they need for data protection. Customers should continue to follow the NCSC guidance, undertake risk assessments, and implement security controls to mitigate them. However, they can use the guidance in this post to help them quickly identify and implement security measures that support the NCSC guidance.

If you would like to discuss your workload in more detail or use of AWS, you can reach out to the AWS Justice and Public Safety team or the AWS Public Sector Sales team.

Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.

Please take a few minutes to share insights regarding your experience with the AWS Public Sector Blog in this survey, and we’ll use feedback from the survey to create more content aligned with the preferences of our readers.