Guide

Personally Identifiable Information

Suggest Edits

Personally Identifiable Information (PII) marks content covered by the current rule as sensitive, personally identifiable information that needs to be treated as secure and private. Examples might include a rule that includes a behavior that sets a particular cookie or attaches PDFs of individual statements.

How it works

Private information shouldn't be cached either in ​Akamai​ edge servers or in client caches other than the individual belonging to the information. The information shouldn't be logged and therefore available for purposes other than those for which it was intended.

Thus, the following behaviors in any rule that might result in serving the same content would potentially create a vulnerability:

  • Caching. Using Cache or Honor Origin (that is, settings other than no-store or bypass cache)

  • Downstream Caching. Using Allow caching or Allow caching, require revalidation options without also sending the private directive

  • Downstream Caching. Using Pass cacheability headers from origin or Don't send cacheability headers options.

  • Log Request Details. Logging cookies using Log all cookies or Log some cookies option.

With PII enabled, if one of these potential vulnerabilities exists in the configuration, a validation message warning will appear.

🚧

This feature cannot catch all potential vulnerabilities. It doesn't warn you if you are, for example, including secure information in a query string or writing secure information to an origin folder. At this time, this feature cannot warn you if you aren't using SSL protocol for the communication of the data. It is your responsibility to make sure that you are using features and practices that do not create vulnerabilities with personally identifiable information.

What is PII?

PII is "any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information."

Examples of PII

For example, directly identifiable information could be a Social Security number, passport number or driver's license. Linked / linkable information could be a name coupled with a ZIP code, the last 4 digits of Social Security number, and so on.

Source: Handbook for Safeguarding Sensitive Personally Identifiable Information by DHS

Impact of PII exposure

Breaches involving PII are hazardous to both individuals and organizations. Individual harms may include identity theft, embarrassment, or blackmail. Organizational harms may include a loss of public trust, legal liability, or remediation costs. Breach of PII could also lead to regulatory and legal issues.

Configuring solutions while accounting for PII

PII will manifest itself as:

  1. Sensitive content like order confirmation pages, bank statement

  2. Sensitive cookies that may contain user IDs, email or similar information

  3. User profile / contact information page

  4. URL path / query strings containing email, contact number, etc.

When configuring a solution, be careful about PII for the following functionality:

  1. Ensure that content that includes personal information is never cached on ​Akamai​ network in such a way that it could expose the PII data. Specifically, this would apply for:

    • cached base pages

    • caching dynamically generated PDF reports

    • caching dynamically generated images

  2. Following extensions shouldn't be cached if there is any uncertainty. Such documents could risk PII exposure if cached improperly:

    • pdf, doc, docx, xls, xlsx, ppt, pptx, csv, txt, dat, rtf, odt, wp, wpd, msg, wps, efx, pages, qif

  3. It's a warning/red flag when a configuration with the default extensions 7-days caching rules, or a "host" match caching the entire property.

  4. POST request/response is generally a part of work-flow and tends to hold PII information.

    • Avoid POST caching

    • Enable POST caching only if customer is sure that the POST body and response do not hold any PII information.

    • Disable POST re-tries. This happens only when Sureroute for Failover (SR4F) is used.

  5. 302s can be cached on our network. Turn off 302 caching, if the URL could potentially hold PII information.

    • Downstream caching: These are the instances when the content is cached with wrong downstream TTL headers on the browsers / downstream proxies

    • Netstorage: Never store PII data on Netstorage. This includes:

      • Netstorage POST files

      • Assets stored on Netstorage

  • Request URLs: In the event that PII is a required to carry information in the URL, it is advisable to investigate alternatives, such as using encrypted or hashed values instead.

  • SSL/TLS: PII data should always be transmitted over secure channels (SSL/TLS).

  • Logging:

    • logging of cookies,

    • logging of personal information in the custom log field,

    • logging of personal information in the Download Receipts (Edge Logging) that is stored on NetStorage,

    • logging of personal information as a Download Receipt (Edge Logging) over an insecure channel (DLR via HTTP).

Updated about 3 years ago