Using Akamai EdgeDNS with PCI DSS Environments

Overview

The PCI DSS scoping guidance indicates that common shared services that provide services to the CDE, such as DNS, can be in scope and must be assessed for PCI DSS compliance.

This post discusses the application of this scoping guidance to the external authoritative DNS servers and provides an overview of DNS operation on the internet. It also outlines some common threats to the DNS infrastructure and respective compensating controls from the perspective of the PCI DSS, providing a detailed explanation of why Akamai EdgeDNS internet authoritative DNS service is an out-of-scope system for PCI DSS.

DNS Infrastructure and Akamai EdgeDNS

The internet DNS infrastructure was developed in the 1980s without a strong security consideration.

Let’s consider a common scenario where a PCI DSS-compliant web application is published on the internet using the domain name www.akamai.com, with the web server located at the IP 104.117.251.150 (see Figure 1).

Figure 1

For the server to be found by users on the internet by its domain name, the name needs to be registered in the respective DNS registry. This is normally done with the help of a DNS registrar. As part of the name registration, among other things, it’s necessary to provide the details of the authoritative DNS servers that would host the DNS zone record.

Akamai’s EdgeDNS is an excellent choice as a primary authoritative DNS, as it’s highly scalable and has a 100% availability SLA.

Next, let’s consider how the clients will resolve the domain names into IP addresses with this scenario: A client is located in a large convention center with a sizeable guest Wi-Fi network. The venue uses an ISP to provide its guests access to the internet and uses DNS servers of the ISP to resolve domain names. The DNS request to resolve www.akamai.com from the client in this case might work as follows:

• The client on the convention center’s Wi-Fi network will send a request to the DNS Resolver1, which is the venue’s DNS recursive resolver
• The DNS Resolver1 will look into its cache, find no suitable records, and send a request further to the ISP’s resolver
• The ISP DNS Resolver2 is a recursive resolver, and it will look into its cache as well — if there are no suitable records, it will (refer to Figure 1):
  1. Go to the root DNS servers, which will redirect to the appropriate TLD DNS servers, and the DNS Resolver2 will …
  2. Go the appropriate TLD DNS servers and ask for the authoritative DNS server name that contains the relevant zone record. Once the authoritative DNS server name is obtained, it will …
  3. Go to the EdgeDNS authoritative DNS server, as instructed by the TLD DNS servers, and ask to resolve www.akamai.com. The authoritative DNS server will resolve the domain name and return the appropriate IP address.
  4. DNS Resolver2 will store the response in its cache in accordance with the TTL and pass the response further to the DNS Resolver1.
  5. DNS Resolver1 will also store the response in the cache and respond back to the client.

Now the client has the correct IP address for www.akamai.com and can send an HTTP request.

What Can Go Wrong: DNS Threats

There are a number of things that can potentially go wrong with the DNS. In this context, typically it is about affecting either the availability of the web application or trying to redirect internet users to a malicious internet resource. Consider the following:

DNS recursive resolver cache poisoning. One particular type of this category is also known as the Kaminsky attack. The cache of the DNS Resolver1 and DNS Resolver2 can be poisoned and can resolve www.akamai.com into an incorrect IP address, so the client will try to establish an HTTP connection with a rogue WWW server (see Figure 1).

DNS hijacking. This attack can take many forms using multiple vectors. It can be an ISP, deliberately manipulating the DNS responses, or it can be malicious DNS registry changes. In the worst-case scenario, this attack will allow malicious actors to not only redirect the traffic to a rogue WWW server, but also potentially allow them to issue a valid DV certificate.

DDoS of the DNS infrastructure. This is one of the common attacks that can lead to the unavailability of the authoritative DNS and, as a result, unavailability of the web application service.

Even if the authoritative DNS server complies with the PCI DSS requirement, there are many places on the internet, as demonstrated above, where things can go wrong — and DNS responses can be manipulated and domains can be hijacked.

Compensating Controls for DNS Threats

In the internet communication scenario above, one of the main compensating controls for the outlined DNS threats is ensuring that HTTP is run over TLS. It is essential that the web application server uses a valid TLS certificate, uniquely identifying the web server and providing a one-way authentication of the connection.

As shown in Figure 1, even if the DNS response is manipulated and the client is redirected to a rogue WWW server, without the proper TLS certificate the browser will identify this connection as invalid and risky.

Without the proper TLS certificate and the private key, the DNS attacks will unlikely lead to the compromise of the HTTPS connections.

Therefore, monitoring and controlling the records in the DNS registry is of critical importance — if the DNS record in the registry is maliciously updated, a rogue TLS DV certificate could be issued. This is a responsibility of the web server owner who leased the domain name for it from the DNS registry.

Although DNSSEC was designed to overcome many DNS security shortcomings, this suite of IETF specifications is still not commonly adopted. APNIC estimates that only about 20% of internet DNS recursive resolvers use DNSSEC. Most resolvers on client computers also don’t currently use it at all.

As for the DNS DDoS threat, Akamai’s EdgeDNS service is an excellent mitigation against it, ensuring the domain names can be properly resolved under such attacks and the business continues operating.

Should EdgeDNS Be in PCI DSS Scope?

Version 1 of guidance for PCI DSS scoping¹ and network segmentation provides the following chart (Figure 2) to determine whether a system is in or out of scope of the PCI DSS assessment.

Figure 2

Let’s consider the requirements one by one.

Firstly, Akamai’s EdgeDNS service does not process or store any cardholder data (CHD) or sensitive authentication data (SAD). It stores DNS zone records and responds to DNS requests from DNS resolvers on the internet. Akamai EdgeDNS is also not located on the same network segment as systems that store or process CHD and SAD. Based on these criteria, EdgeDNS cannot be included into cardholder data environment (CDE) and considered in the PCI DSS attestation’s scope.

The scoping document lists DNS servers as common shared services, providing services to the systems in the CDE and other system components across the organization’s enterprise — namely, domain name resolution service.

Akamai’s EdgeDNS, however, is not such a DNS server. It is not a connected or security-impacting system, as it does not:

• directly connect to the CDE — EdgeDNS is not involved in any information exchange with the systems in the CDE, directly or indirectly; it is not a “connected-to” shared service, and is an external authoritative DNS service
• impact configuration or security of the CDE; EdgeDNS is a DNS service and does not adversely impact the security of the CDE, provided the controls for the DNS threats are in place as explained above
• provide segmentation of the CDE from the out-of-scope systems
• indirectly connect to the CDE
• provide security services to the CDE; EdgeDNS does not provide security controls in the PCI DSS context, such as network firewall, IDS/IPS, anti-malware or authentication service

The compromise of the EdgeDNS will not lead to the compromise of the CDE, as the systems are completely separate. Given the above, Akamai EdgeDNS service is considered as an out-of-scope system and does not need to be assessed against the PCI DSS criteria.

Reference

1. Guidance for PCI DSS Scoping and Network Segmentation: https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Gennadiy Belenkiy. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/xnGbzVVmV3Q/using-akamai-edge-dns-with-pci-dss-environments.html