Written by Meyer Potashman
On May 25, 2018, the EU General Data Protection Regulation (GDPR) went into effect. In preparation, Akamai, like every other company that does business with or interacts in any way with individuals in the EU, needed to re-evaluate our approach to data protection and privacy to ensure that we are compliant with the new law. Since GDPR requires that companies evaluate the privacy practices of their suppliers and subcontractors, customers have been asking us about how we protect the personal data on our platform from both a privacy and security perspective. In this blog post, we discuss how our InfoSec team approaches some of these considerations.
We like to see ourselves as platypuses, since like those animals, we don't fit into any normal classification systems. While they have bills and lay eggs like birds, they also have hair and are mammals. Similarly, our services and business model make us a cross between software, hardware, platform, and other "as a service" cloud providers.
This often makes it challenging for Akamai to address customers' GDPR and risk management questions head on, because the questions are often intended for typical cloud service or application vendors.
Akamai's services don't often fit into the categories that the customers ask us about. Our core services involve content delivery and security. These services leverage our Intelligent Platform, with over 240,000 servers in over 130 countries within more than 1,700 networks around the world. For the most part, we deliver customer content and our security solutions scan that content for potential attacks. We don't, however, generally host, or permanently store the content (with the exception of our Netstorage service). We typically have no direct relationship with the end users whose privacy the GDPR is intended to protect.
Since Akamai is always growing, and expanding our reach around the world, our approach to security differs from more typical cloud providers. For example, we do not have a "primary" and a "backup" datacenter that we could lock down in a traditional way. Instead, we deploy our standardized servers everywhere we can, monitor them remotely from our Network Operations Command Center (NOCC), and embed security controls in our deployments themselves and across our operations. Our platform security, therefore, needs to focus more on how to deliver content quickly and safely across the world, and less on the risks associated with storing our customers' personal information.
The GDPR, together with privacy laws in many countries outside the US, takes a broad view of the types of data that must be protected. Article 4 of the GDPR defines "Personal data" as "any information relating to an identified or identifiable natural person." This includes everything from highly sensitive information such as credit cards, Social Security numbers, and the like, to less sensitive information such as social media profiles, news articles about specific individuals, and other information that may relate to individuals. Furthermore, it may include non-identifying information such as web logs containing IP addresses for devices operated by covered individuals.
At Akamai, we handle four major categories of personal data: (i) customer content that we deliver and protect (credit card information, social media images, web sites, etc.); (ii) customer and prospect contact data in our customer portal, marketing tools, and Salesforce database; (iii) HR data for our employees and applicants; and (iv) web and security log data from our servers containing IP addresses of user devices and URLs with query strings and other potentially identifying information. Since we use industry standard approaches to protect HR and customer employee data, this post will focus on customer content and log data.
The GDPR is a privacy law focused on how personal data is handled. Security is just one of the many aspects of how personal data is handled that the GDPR addresses. Article 32 spells out at a high level how personal data must be secured:
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.
It is clear from this language that there is no single, secure standard for protecting all kinds of personal data. Rather companies must weigh various factors such as cost and risk to the individuals who may be impacted in determining the security controls needed to protect different types of information. The most sensitive personal data, such as financial and health information, has a potentially greater impact upon individuals and should be protected in accordance with strict industry standards such as PCI DSS and the like. To the extent that IP addresses are personal data, it is of course impossible to encrypt them at all times, since the internet requires this information to be public to move traffic around the world. However, to the extent possible and appropriate, log data with this information can and should nevertheless be protected.
As our customers conduct their vendor risk assessments required by the GDPR, they often provide us with questionnaires or contract language that assumes that personal data of all kinds should be treated equally. These questions tend to consider only the personal data in their content, and not the full spectrum of personal data.
For example, we are often asked whether all personal data is encrypted at rest and in transit.
To address this question, and in accordance with Article 32 (discussed above), we need to weigh the risks and benefits of various forms of protection for each type of personal data that we process, and we arrive at different conclusions for different types of data, in light of the nature and scope of our platform and the potential risk to the people involved.
Akamai's core business is delivering and protecting our customers websites and applications that transit our Intelligent Platform. For sites that handle sensitive data, such as e-commerce, banking and healthcare sites, we deliver that content via our Secure CDN. All of this content is encrypted in transit, and the sites are configured so that the sensitive data is never at rest on our platform. It is decrypted in volatile RAM, analyzed for security and routing purposes, and forwarded as necessary without anyone at Akamai needing access to the information. Content that customers choose to cache on our platform, however, is intended to be publicly available and is not encrypted at rest in order to be readily available for delivery to end users. Even if this information is personal information (cached profile photos, for example), it is protected by a variety of physical and security access controls that we apply to all of our Secure CDN servers.
Customer content that is neither sensitive nor dynamic on our platform is treated similarly. Customers choose whether to encrypt their information in transit over HTTPS, and we deliver that content however they choose. This information is also not encrypted at rest to aid in the delivery process. We rely on our customers to determine how they wish to distribute the personal information that they send over our platform. Akamai does not store any of this content other than as instructed by our customers.
Given that Akamai servers regularly experience upwards of 60 million hits per second, the amount of log data that we process across our platform can be immense. Our log collection system collects and aggregates the logs from across our platform for use by our services and for internal service administration. For example, our billing department uses log data for billing purposes, our Log Delivery Service distributes customer-specific versions to our respective customers, technical teams use the data to improve service mapping and delivery, and our Cloud Security Intelligence team analyzes security data from these logs to improve our cloud security services and help protect ourselves and our customers. Log data is stored only so long as needed for these purposes and is deleted within 100 days.
Akamai weighs the security risks to itself and to end users, the technical requirements for delivery of the services, as well as the costs of handling massive amounts of data on its platform, in deciding how best to protect the personal information on our platform in accordance with all applicable laws and obligations, including the GDPR. The fact that our network is massively distributed significantly reduces the risk to end users. Akamai does not typically store any personal data on our edge servers for any extended period of time, and at any given time, neither Akamai personnel or outsiders know whether the data of any particular customer or end user is on any particular Akamai server. This makes us a less valuable target for adversaries looking to find and use the personal data of any particular target.
We also evaluate the risks and benefits of encrypting drives that may contain personal data that is not sensitive in nature. Disk encryption certainly provides security benefits, primarily when the computer it is associated with is not logged in and actively decrypting data, or when the drive is removed entirely (or stolen) from the computer. Akamai servers are typically actively in use, and our logical access controls help prevent unauthorized logical access. So to evaluate whether to encrypt server drives, we consider the risk to individuals if an adversary were to walk off with an unencrypted edge server drive. As discussed, the adversary would have no way of knowing in advance whose information is on that drive. No sensitive content is stored to disk, but there could be various cached content and log data on the drive. Cached content is already publicly available, so there is minimal risk there. In this case, the person with the drive may be able to view reams of log data with virtually no identifiable information. There may be some IP addresses or URLs listed, but no account data, and without the involvement of a relevant ISPs, it is generally difficult for the person to associate this data with any individual. All that said, while no responsible company can ever say that there is zero risk when processing personal information, we believe the risk to end users posed by our processing of log data is comparatively low.
The cost of disk encryption, however, may be substantial. Our edge servers are used primarily to cache, analyse and deliver customer content, and encrypting all of this data at rest could have a considerable impact on performance and cost, resulting in more expensive, and less effective, services for our customers. Akamai has determined (for now at least) that the cost of encrypting cached data and logs on our edge servers outweighs the benefits in light of the small risk to end users.
Of course, even without disk encryption, Akamai has extensive access controls to limit access to the data on our platform and back-end systems such as those that analyze logs to those who need access to them. No person has direct access to these servers; people are given limited grants for specific time periods based on their role. All access is logged and monitored as well.
We hope this is a useful overview of some of the considerations we make at Akamai about how to best balance security and privacy concerns with respect to the various types of data we use at Akamai. We are committed to protecting the availability, confidentiality and integrity of all kinds of personal data and to compliance with the GDPR, while acknowledging that each of the various types of personal data that we process may require a different solution. A "one size fits all" solution to securing personal data can dramatically increase costs to everyone involved, and may have the effect of discouraging companies from implementing security controls that are tailored to the specific risks involved. Please see Akamai's Privacy Trust Center for more on our approach to the GDPR and data protection.