When migrating servers, services, applications, or data to cloud environments, it's critical to use secure encrypted communication channels. This ensures sensitive information is protected in transit. Only the most up-to-date and approved protocols should be used.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full Cloud Controls Matrix (CCM) from the Cloud Security Alliance website: https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4

The CCM is a cybersecurity control framework for cloud computing. It provides a detailed understanding of security concepts and principles aligned to the Cloud Security Alliance guidance in 16 domains.

For more information on securing data in transit, see the AWS whitepaper: https://docs.aws.amazon.com/whitepapers/latest/aws-overview-security-processes/data-protection-in-transit.html

Who should care?

This control is relevant for:

• Cloud architects designing migration plans to the cloud
• DevOps engineers executing cloud migrations
• Security engineers overseeing cloud migrations
• Compliance officers auditing cloud migrations

What is the risk?

Insecure communication channels used during cloud migrations could allow adversaries to intercept sensitive data in transit. This could lead to data breaches exposing customer records, trade secrets, or regulated information.

Man-in-the-middle attacks exploiting weak encryption could allow tampering of data being migrated, compromising its integrity.

Use of outdated or deprecated protocols with known vulnerabilities could allow adversaries to break encryption and access data.

What's the care factor?

For most organizations, securing data in transit during cloud migrations should be a high priority. The risks of data exposure are significant given the volume of information typically migrated.

Even a temporary exposure during the migration period could be catastrophic. Regulations like GDPR and HIPAA have strict encryption requirements for data in transit.

However, for data that is already public or non-sensitive, the urgency is lower. Internal migrations of non-critical workloads may also have more tolerance for risk.

When is it relevant?

This control applies any time you are migrating servers, services, applications or data from:

• On-premises to public cloud
• Public cloud to public cloud
• Private cloud to public cloud

It is less relevant for:

• Migration within the same datacenter
• Migration of non-sensitive, public data
• Migration of encrypted data that will remain encrypted

What are the trade-offs?

Implementing secure, encrypted communication channels does require additional effort compared to using plaintext.

There are performance overheads to encryption that can increase migration times. More CPU is required for encryption/decryption.

Troubleshooting can be more difficult due to encryption obscuring details in packet captures. Encryption also prevents caching and compression in transit.

Some legacy systems may not support modern encryption protocols, requiring upgrade or replacement to migrate.

How to make it happen?

1. Inventory all servers, services, applications and data in-scope for migration. Classify sensitivity levels.
2. Design a migration plan specifying approved secure communication channels:

• Application-layer: TLS 1.2+, SSH-2
• Network-layer: IPsec with ESP, IKEv2
• Link-layer: MACSec 802.1AE

3. Configure migration tools to use only the approved protocols. For example:

• Use HTTPS with TLS 1.2+ for web app migrations
• Use SCP or SFTP instead of FTP
• Use secure VPN with IPsec for network-layer encryption

4. Migrate using secure protocols with encryption enforced. Validate encryption is active.
5. Perform testing to verify no data is transmitted in plaintext.
6. Document protocols used for audit logging.

What are some gotchas?

• Ensure all migration endpoints support the approved protocols. Don't allow fallback to insecure protocols.
• Use proper certificate validation for TLS. Don't allow self-signed certs or insecure cipher suites.
• Migration tools defaults may not be secure. Double-check configuration before migrating.
• Permissions to change encryption settings may be restricted:
  • IAM: Update-SSH-Public-Key
  • IAM: Update-IPsec-Tunnel-Option
• Client-side encryption is still recommended for highly sensitive data.

What are the alternatives?

If the migration is within the same trusted environment, you may be able to rely on physical network segregation for security instead of encryption. However, this is not recommended for cloud migrations.

An alternative is to encrypt the data at rest before migration, keeping it encrypted in transit. This still requires securing the small amount of metadata and headers not encrypted though.

Explore Further

• CIS Controls v8 3.10 (Encrypt Sensitive Data in Transit)
• CIS Controls v8 12.2 (Establish and Maintain a Secure Network Architecture)
• CIS Controls v8 12.8 (Establish and Maintain Dedicated Computing Resources for All Administrative Work)
• NIST SP 800-52 Rev 2 (Guidelines for the Selection, Configuration, and Use of TLS Implementations)
• AWS Whitepaper: Securing Data in Transit with IPsec https://docs.aws.amazon.com/whitepapers/latest/ipsec-vpns-protecting-data/ipsec-vpns-protecting-data.pdf

?