Cloud security guidance

You should configure your chosen cloud platform in line with our using a cloud platform securely guidance. An important part of securing your workloads once they have been moved to the cloud is securing the platform they are deployed to. Any security holes left unchecked in the platform will also impact any hosted workloads.

When you’re investigating how to secure your chosen cloud platform, you are likely to come across the concept of a landing zone. While the definition will vary depending on the cloud provider, they roughly share the same principle of creating a secure scalable baseline for cloud resources to be deployed onto. They usually consist of a sensible organisational structure, security monitoring and logging resources, identity services, and platform guardrails. Investigate whether your chosen provider has tools to help you deploy and maintain this landing zone in line with their best practices.

You should use any migration guidance from your cloud provider or on-prem product vendor. Migration tools are also common, and these should also be used. Following supported migration paths can make it easier in the future if you need to contact support.

Access control is your responsibility, not the cloud provider’s. Only you know who needs access to your data, and who needs to be kept out.

Learn how your chosen cloud platform handles access control. Access control is essential to secure the platform hosting your resources. In order to protect the cloud platform, you’ll need to understand how identity is managed. See actions 2, 3 and 4 of the NCSC’s Using a Cloud Platform securely guidance.

Understanding access control up front:

• allows you to utilise cloud-native approaches enabling you progress beyond a simple lift and shift
• makes it easier to use modern security features (such as zero trust access mechanisms and multi-factor authentication)

Find out what you need to do to protect your data, both in-transit and at rest. In particular, take steps to prevent data being publicly accessible unless you want it to be. On a local system, it is easy to fall into the trap of associating a lack of restrictions with being accessible across the company/organisation; in the cloud, a lack of restrictions can mean the data is accessible to anyone. Further information can be found in the Access controls section of the Cloud Platform guidance.

You should understand exactly what you are planning to move. Even if the migration is being done quickly, some effort should be spent on this; you do not want to migrate something to the cloud only to realise you no longer need it (or fail to migrate something only to discover that the migrated system relies on it). This inventory will be useful when you’re identifying parts of your system that can be replaced with cloud-native equivalents. Common examples can be found in the 'Quick wins’ section.

When forming your inventory, ensure you identify operating systems or software products that are ‘end of life’ (EOL), or have known vulnerabilities. These products are at greater risk of compromise, so need additional care. You should update them to secure versions if possible, or decommission and replace them with cloud-native alternatives during the migration.

In circumstances where you are unable to retire or refactor these services, you should take extra measures to protect them by implementing strict network controls, restricting role based access and adding additional monitoring to detect unexpected behaviour.

There are security benefits to refreshing your virtual machines when moving to the cloud. Moving snapshots of existing machines to the cloud will bring with them any issues they had while on-premises. This will also include any security issues, presenting the risk of moving an already compromised system to the cloud.

You should consider recreating fresh virtual machines in the cloud instead of using snapshots. This will give you the benefits of:

• moving to a ‘known good’ system (providing you the opportunity to double check configurations and security settings are correct)
• reducing the risk of moving an already compromised system to your cloud environment

You should avoid unnecessary customisation; a cloud system is most effective when its components are treated as commodities. For example, if by keeping your services simple you can use managed alternatives, it is likely more secure than maintaining your own custom software and infrastructure.

You will get more benefit from the cloud by using something maintained by the cloud provider than by continuing with something you’ll have to maintain instead.

You will need to confirm that the security protections around your application still exist in the cloud system. This may be difficult, especially if a system has developed over time and the security boundaries are no longer clear.

Now is also a good time to design any security boundaries that should exist between your on-prem estate and your new cloud systems. These should be designed to only allow connectivity between services that need it, therefore reducing the blast radius of an incident on either platform.

It can be tempting to focus on an extremely granular deployment of the principle of least privilege. However, this can easily lead to an access control configuration that is too complex to be understood correctly, leading to errors. You should instead prioritise a permissions model that is simple and easy to use correctly.

Your local system likely started with a simple permissions model that has developed exceptions over time. Removing these exceptions (and/or absorbing them into the permissions model) will simplify the management of the existing system and make it easier to move it to the cloud.

Giving everyone full permissions is a bad idea, even if it might make administration simpler. Similarly, locking all accesses down so tightly that your support staff are inundated with access requests is also a bad idea, even if it might be more secure in theory. You will need to find your own balance between least privilege in one direction and a straightforward configuration in the other. Usability must be excellent; security just needs to be ‘good enough’.

By simplifying your permissions model, it will allow you to implement aspects of our Secure Systems Administration guidance, such as ‘just in time’ administration. For further information, see the section on ‘Apply access controls’ in the Cloud Platforms Guidance.

You should avoid exposing legacy management protocols such as SSH or RDP to the internet. If it is not possible to replace them with a secure access mechanism from the cloud provider, they should be placed behind a VPN or similarly isolated. Further details can be found in our Secure administration guidance and Using a cloud platform securely guidance (Protect networked services).

Automating maintenance is a large part of moving the maintenance burden from you to the cloud provider.

Automatic patching

Use tools or services that can automate patching of IaaS architectures. Not only does this remove the burden of keeping systems patched, it reduces the risk of overlooking a system and leaving it unpatched. For further information, refer to the Using a cloud platform securely guidance (Use automation to enforce security).

Labelling resources

Tag (label) cloud resources from the start. While this does not have an immediate effect, tagging makes it easier to keep track of assets and costs over time. These will be useful as more services are migrated to the cloud as it will allow you to identify which teams own which resources. For more information on tagging, refer to the Using a cloud platform securely guidance (Establish observability).

Use logging and security features

Turn on the cloud logging, monitoring, and alerting tools offered by your cloud provider. These will usually display their results on one or more ‘dashboards’. Crucially, ensure someone is monitoring these dashboards. If you are already using a security dashboard, see if it can be integrated with the cloud provider’s own tools.

These dashboards can warn you when something has been left insecure. Mistakes are most likely to be made during that first move to the cloud, so this is valuable from the start. Resolve any warnings unless you are certain the warning is harmless.

For further information on monitoring and incident management, see actions 9, 10, and 13 of the Using a cloud platform securely guidance.

Replace simple generic components so you can concentrate on the more complex ones.

Replace NAT boxes, packet firewalls, and load balancers

There should be no need to create a discrete virtual machine purely to act as a packet firewall or to perform NAT (Network Address Translation) or load balancing. These are all simple functions that can be maintained by the cloud provider.

Replace any NAT boxes and simple packet firewalls with network access controls on a virtual network. This will centralise the logging and remove the need to maintain discrete firewall devices. A cloud provider may go further than this and offer an entire managed firewall service.

Replace basic load balancers with the cloud’s native equivalent.

Replace single-function machines with services

Machines that implement simple unspecialised tasks like DHCP or DNS servers can often be replaced with the cloud provider’s own services, transferring a generic overhead to the cloud provider. This may not be applicable if you have a specific reason to use a particular service, such as government systems using PDNS.

Edge services

Consider whether to use the cloud provider’s edge services. These can include DDoS (Distributed Denial of Service) protection and TLS termination. These can improve both security and performance in the cloud. If you are already using your own solution for any of these, see if it can be replaced with the cloud provider’s equivalent.

Availability is an aspect of security that is easily overlooked until an important system goes down. This is true of the cloud as well as local systems. While in the cloud you’re no longer responsible for things like replacing hardware, in a lift and shift architecture you won’t automatically gain the availability benefits of moving to the cloud, and it will need to be architected into your IaaS implementation.

Some clouds are divided into geographic 'regions’. Use a region located in your own country unless you’re already dealing with the complications of international data transfer. These regions are further sub-divided into ‘zones’. Zones are important for resiliency as they usually represent distinct data centres.

If your system can take advantage of multiple servers fronted by a load balancer, it can probably make use of further ways of improving availability. Infrastructure-as-code makes these availability improvements easier and more practical.

Note that:

• You can use auto-scaling features to automatically add or remove resources as your system load changes, reducing the impact of sudden surges in load. Your system might need to be redesigned to handle the addition and subtraction of resources. A system that isn’t expecting resources to be continually replaced could end up in broken state. Since the added resources are not free, auto-scaling should not be used as a replacement for DDoS protection. Using it for DDoS protection would allow an attacker to increase your cloud costs at will, which is sometimes known as an economic denial of service attack.
• You can replicate your system into multiple zones so it keeps running during outages in any one zone. Your system might need to be redesigned to detect and handle failover, simply replicating your existing system across zones could cause other issues. Testing should be completed to ensure your system reacts in a way you expect it to.
• You can deploy a new version of a resource in parallel with an old version and gradually route traffic to it, avoiding the need for an outage. This is sometimes called ‘blue-green deployment’. The resource could be anything from a single server to your entire infrastructure.

Blue-green deployment is a useful technique when moving to the cloud. You can test the cloud deployment by routing some traffic to it while the existing system handles the rest, and gradually increase the proportion of traffic that is handled by the cloud until you are confident the cloud deployment can replace the existing system.

With lift and shift, the entire system ends up sharing a single set of resources. There is a security benefit to giving different parts of the system their own isolated resources. Further information can be found in actions 6 and 7 of the Using a cloud platform securely guidance.

The cloud provider usually provides guidance on how to set up resource isolation, often with tools to make it easier. This is where the earlier advice to identify security boundaries helps, as this should have identified areas that can be easily isolated. For example:

• isolating logging ensures forensic evidence is left if an attacker exploits the system (so you can fix the vulnerability when the system is restored from backups)
• isolating development, test and production environments means a faulty development build cannot affect the live system or production data (and that testing cannot accidentally rely on features only available to the development build)

Replace more services with cloud-native equivalents
The ‘quick wins’ section involved replacing the easy-to-replace features. Becoming more cloud-native means widening this to include services that will require more work to replace.

Common services with cloud-native equivalents include:

• static web hosting services
• databases (relational and non-relational)
• bulk data storage
• logging services
• backup services
• cryptographic key management services

More information can be found in the ‘Adapt to the cloud section’ of the Using a cloud platform securely guidance.

Infrastructure-as-code (IaC) is a way of scripting or templating the creation of cloud infrastructure. This has many benefits:

• it formally documents the infrastructure
• it allows the infrastructure to be restored quickly after a disaster
• it helps when rolling back an infrastructure change that has caused a problem
• it supports the resiliency improvements listed above
• tools can scan the IaC templates and identify security problems without needing a running system

Implementing IaC during the lift and shift stage might seem like extra work to begin with. However, it will provide benefit in the future. Trying to retrospectively convert your deployment method to IaC will be time consuming, and could introduce deployment errors.

Infrastructure-as-code also makes it easier to integrate with CI/CD pipelines to create a secure automated deployment environment. For more information refer to the ‘Use automation to enforce security’ section of the Using a cloud platform securely guidance.

Repeat the previous sections (‘Quick wins’ and ‘Moving towards a more cloud-native architecture’), only this time applying the advice to parts of the system that were skipped the first time around, and iterate towards a cloud-native solution. Ideally, you want to reduce your maintenance to just the parts that make your system unique. However, diminishing returns may set in before achieving this.

You might notice that some of your custom services won’t have cloud-native replacements. In this case you should refactor these to use cloud-native approaches. Examples could include:

• containerising workloads and moving them to a Platform-as-a-service (PaaS) offering
• moving appropriate workloads to Function-as-a-service (FaaS) offerings

Doing this will remove some of the maintenance burden that comes with IaaS, as these cloud-native alternatives are maintained by the cloud provider. For broader context see the ‘Adapt to the cloud’ section from the Using a cloud platform securely guidance.

While refactoring is the best course of action in an ideal world, we recognise that there may be situations where you can’t refactor systems due to compliance or legacy reasons, or where the cloud service won’t meet your needs. For example if the service doesn’t provide strict enough security controls to meet your requirements.

Finally, follow a newsfeed or similar for the cloud provider’s major announcements so you can take advantage of new services and features. This is explored fully in the ‘Maintain security over time’ section from the Using a cloud platform securely guidance.