Configuring AWS VPN for UK public sector use
In this post, we explain the United Kingdom (UK) National Cyber Security Centre (NCSC)’s guidance on VPN profiles configuration, and how the configuration parameters for the AWS Virtual Private Network (AWS VPN) align with the NCSC guidance. At the end of the post, there are links to code to deploy the AWS VPN in line with those parameters.
Many public sector organizations in the UK need to connect their existing on-premises facilities, data centers, or offices to the Amazon Web Services (AWS) cloud so they can take advantage of the broad set of services AWS provides to help them deliver against their mission.
This can be achieved using the AWS VPN service. However some customers find it difficult to know the exact configuration parameters that they should choose when establishing the VPN connection in-line with guidance for the UK public sector.
AWS VPN services enable organizations to establish secure connections between their on-premises networks, remote offices, and client devices and the AWS global network. AWS VPN comprises two services: AWS Site-to-Site VPN and AWS Client VPN. Together, they deliver a highly available, fully managed, elastic cloud VPN solution to protect your network traffic.
For the purposes of this post, we focus on the Site-to-Site VPN configuration, not Client VPN because the NCSC guidance we’re discussing is specifically related to site-to-site VPNs. This post covers two areas:
- An overview of the current guidance for VPN configurations for the public sector.
- Recommendations on how to configure AWS VPN to meet or exceed the current guidance.
VPN guidance for UK public sector organizations
The starting point for security guidance for the UK public sector is often the NCSC. The role of the NCSC includes:
- Protecting government systems and information.
- Planning for and responding to cyber incidents.
- Working with providers of critical national infrastructure to improve the protection and computer security of such infrastructure against cyber-borne threats.
Specifically, for guidance on the configuration of VPNs for the UK public sector to support data at OFFICIAL, the NCSC has created detailed guidance on the technical configurations to support two different profiles: PRIME and Foundation. These two profiles provide different technical implementations to support different equipment and are both suitable for use with OFFCICIAL data. Beyond these technical differences, NCSC also documents that Foundation is expected to provide suitable protection for OFFICIAL information until at least December 31, 2023, while PRIME has no review date specified at the time of writing.
This guidance is available in Using IPsec to protect data.
Let’s start by debunking a few myths.
Myth 1: I have to adhere exactly to the NCSC technical configuration or I cannot use a VPN for OFFICIAL data
It’s a common misconception that a public sector organization must adhere exactly to the configuration of either PRIME or Foundation in order to use a VPN for OFFICIAL data, even if other configuration options available—such as a longer key length—offer a higher security baseline.
Note that the NCSC isn’t mandating the use of the configuration in their guidance. They’re offering a configuration that provides a useful baseline, but you must assess your use of the NCSC guidance in context of the risks. To help with these risk-based decisions, the NCSC has developed a series of guidance documents to help organizations make risk-based decisions. A common consideration that might require deviating from the guidance would be supporting interoperability with legacy systems where the suggested algorithms aren’t supported. In this case, a risk-based decision should be made—including accounting for other factors such as cost.
It’s also worth noting that the NCSC creates guidance designed to be useful to as many organizations as possible. The NCSC balances adopting the latest possible configurations with backwards compatibility and vendor support. For example, the NCSC suggests AES-128 where—in theory—AES-256 could also be a good choice. Organizations need to be aware that if they choose to adopt devices that support only AES-256 and later need to connect in devices capable of only AES-128, there could be significant investment to replace the legacy devices with ones that support AES-256. However, AWS provides both AES-128 and AES-256, so if the remote device supports it, AWS would recommend opting for AES-256.
The NCSC also tries to develop advice that has some longevity. For example, the guidance suggesting use of AES-128 was created in 2012 with a view to providing solid guidance over a number of years. This means customers can choose different configuration parameters that offer increased levels of security if both sides of the VPN can support it.
It’s possible for a customer to choose options that might lower the security of the connection, provided that risks are identified and appropriately managed by the customers assurance team. This might be needed to support interoperability between existing systems where the cost of an upgrade outweighs the risk.
Myth 2: Foundation has been deprecated and I must use PRIME
Another common misconception is that Foundation has been deprecated in favor of PRIME. This is not the case. The NCSC has stated that Foundation is expected to provide suitable protection for OFFICIAL information until at least December 31, 2023. The security provided by both solutions provides commensurate security for accessing data classified as OFFICIAL. One of the main differences between PRIME and Foundation is the choice of signature algorithm: RSA or ECDSA. This difference can be helpful in enabling an organization to choose which profile to adopt. For example, if the organization already has a private key infrastructure (PKI), then the decision regarding which signature algorithm to use is based on what existing systems support.
Myth 3: I can’t use Foundation for accessing OFFICIAL SENSITIVE data
A final point that often causes confusion is the classifying of data at OFFICIAL SENSITIVE because it isn’t a classification, but a handling caveat. The data would be classified as OFFICIAL and marked as OFFICIAL SENSITIVE, meaning that systems handling the data need risk-appropriate security measures. A system that can handle OFFICIAL data might be appropriate to handle sensitive information. Hence Foundation could be suitable for accessing OFFICIAL SENSITIVE data, depending on the risks identified.
Deep-dive into the technical specifications
Now that you know a little more about how the guidance should be viewed, let’s look more closely at the technical configurations for each VPN profile.
The following table shows the configuration parameters suggested by the NCSC VPN guidance discussed previously.
|IKEv* – Encryption||IKEv1 – AES with 128-bit keys in CBC mode (RFC3602)||IKEv2 – AES-128 in GCM-128 (and optionally CBC)|
|IKEv2 – Pseudo-random function||HMAC-SHA256||HMAC-SHA256|
|IKEv2 – Diffie-Hellman group||Group 14 (2048-bit MODP group) (RFC3526)||256 bit random ECP (RFC5903) Group 19|
|IKEv2 – Authentication||X.509 certificates with RSA signatures (2048 bits) and SHA-256 (RFC4945 and RFC4055)||X.509 certificates with ECDSA-256 with SHA256 on P-256 curve|
|ESP – Encryption||AES with 128-bit keys in CBC mode (RFC3602)
|AES-128 in GCM-128
Recommended AWS VPN configuration for public sector
Bearing in mind these policies, and remembering that the configuration is only guidance, you must make a risk-based decision. AWS recommends the following configuration as a starting point for the configuration of the AWS VPN.
|Technical detail||AWS configuration||Adherence|
|IKEv* – Encryption||IKEv2 – AES-256-GCM||Suitable for Foundation and PRIME|
|IKEv2 – Pseudo-random function||HMAC-SHA256||Meets Foundation and PRIME|
|IKEv2 – Diffie-Hellman group||Group 19||Suitable for Foundation and matches PRIME|
|IKEv2 – Authentication||RSA 2048 SHA2-512||Suitable for Foundation|
|ESP – Encryption||AES-256-GCM||Suitable for PRIME and Foundation|
In the table above, we use the term suitable for where the protocol doesn’t match the guidance exactly but the AWS configuration options provide equivalent or stronger security—for example, by using a longer key length.
With the configuration defined above, the AWS VPN service is suitable for use under the Foundation profile in all areas. It can also be made suitable for PRIME in all areas apart from IKEv2 encryption. The use of RSA or ECDSA is the main difference between the AWS VPN and PRIME configurations. This makes the current AWS VPN solution closer to Foundation than PRIME.
When considering which options are available to you, the starting point should be the capabilities of your current—and possible future—VPN devices. Based on its capabilities, you can use the NCSC guidance and preceding tables to choose the protocols that match or are suitable for the NCSC guidance.
- The NCSC provides guidance for the VPN configuration, not a mandate.
- An organization is free to decide not to use the guidance, but should consider risks when they make that decision.
- The AWS VPN meets or is suitable for the configuration options for Foundation.
After reviewing the details contained in this blog, UK public sector organizations should have the confidence to use the AWS VPN service with systems running at OFFICIAL.
If you’re interested in deploying the AWS VPN configuration described in this post, you can download instructions and AWS CloudFormation templates to configure the AWS VPN service. The AWS VPN configuration can be deployed to either connect directly to a single Amazon Virtual Private Cloud (Amazon VPC) using a virtual private gateway, or to an AWS Transit Gateway to enable its use by multiple VPCs.
If you’re interested in configuring your AWS VPN tunnel options manually, you can follow Modifying Site-to-Site VPN tunnel options.
If you have feedback about this post, submit comments in the Comments section below.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.