The term Personally Identifiable Information (PII) will be familiar to organizations who are required to comply with regulatory standards such as PCI-DSS.
NIST Special Publication 800-122[4] defines PII as “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.”
Some examples of PII include:
- Name
- Personal identification numbers: social security number (SSN), passport number, driver’s license number, taxpayer identification number, patient identification number, financial account number or credit card number
- Personal address information: street address or email address
- Personal telephone numbers
- Personal characteristics: photographic images (particularly of face or other identifying characteristics), fingerprints, or handwriting
- Asset information: Internet Protocol (IP) or Media Access Control (MAC) addresses that consistently link to a particular person
For some regulatory standards based in the EU, this scope has been expanded to include any data element that can be potentially identified by correlating additional attributes.
This is sometimes referred to as quasi-identifiers. When combined, Quasi-identifiers constitute PII.
The notion of pseudo-identifiers has been formalized in the EU based General Data Protection Regulation (EU-GDPR), which will go into effect on May 25 2018.
As stated in Article 4 of EU-GDPR: ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
To help comply with regulatory standards, an organizations critical data assets should be mapped and identified as part of a risk assessment process. This process should document where the data is stored and accessed, what level of risk exposure exists, and critically, whether the data contains PII.
The potential impact of exposed PII can result in reputational harm to the individual whose privacy has been breached. In addition, when an organization is the victim of a breach that exposes PII data, the company may be mandated to publicly report the breach, incurring significant reputational and financial cost.
To address this risk, all sensitive PII data should be encrypted both in transit, as well as when the data is at rest.
A plethora of tools is currently available to help identify PII data stored an organizations traditional IT assets such as servers, databases, file systems etc.
Data Loss Prevention solutions can also be leveraged to prevent the exfiltration of sensitive data from an organization.
The Container PII in The Sky
One area that is typically not visible to these tools is when the data is stored within containerized applications. Indeed, as container adoption becomes ubiquitous, new solutions will need to address container specific threats that can potentially expose confidential data such as PII.
To demonstrate this risk, we will use an example.
ACME Corp has migrated its monolithic application to a micro-services model and plans to leverage Docker containers to help achieve this goal.
From a regulatory compliance vantage point, the existing security and compliance tools deployed at ACME Corp do not have visibility into the data used by containerized applications.
Specifically, Docker images may contain or access PII data, potentially leading to non-compliance and exposure of sensitive data to third parties.
An auditor or compliance officer has no visibility into which container-based assets contain PII data. This could lead to non-compliance and a financial penalty for ACME Corp.
How Aqua Protects PII
To address this use-case, we introduced in Aqua 2.5 the ability to create custom compliance checks that enable customers to identify security and compliance risks embedded in Docker images.
The new compliance checks are included in Aqua’s Image Assurance module, which manages the integrity, security, and compliance of container images from inception until deployment in production. This holistic approach provides comprehensive security and visibility throughout the CD/DI pipeline.
Aqua will block and alert on any image that does meet the security and compliance requirements. This security control is enforced both in the CI pipeline and at runtime once the container is deployed into production.
Let’s review how we would configure this in the Aqua Security Platform console.
To have Aqua search for PII data in ACME Corp’s Docker images, we create an image assurance policy and select the custom checks menu.
When selecting Import, we are provided with multiple compliance and security checks that can be used.
As we can see above, there are some PCI-DSS specific checks, security checks (e.g., search for files with SUID permissions set), and the PII-Finder check.
We have assigned the PII-Finder to all images associated with the PCI label.
Pursuant to applying this policy, any image that contains PII will be blocked by Aqua and an alert will be sent to the SecOps or Compliance team detailing the compliance violation.
Here we can see the security posture of the bpdockerlab/pii-data:1.0 image.
Note that while no known vulnerabilities or blacklisted packages were identified in this image, the image was automatically prevented from running due to the compliance check identifying PII data within the image.
The “Actions Needed” tab displays the (demo) data that was identified as well as the location of the offending file, in this case /tmp/customers.txt which contains the PII data.
As noted, the compliance checks are conducted both within the CI pipeline and at runtime.
Let’s try and instantiate a new container based on the bpdockerlab/pii-data image that was disallowed by the Aqua Enforcer.
The user is prevented from running the container as it does not comply with the custom compliance policy we defined.
In addition, an alert is sent to the SecOps team detailing the context of the compliance violation
For more information regarding the Aqua Security Platform 2.5 see our PCI Compliance Guide.
