Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca
In this installment of the SharePoint, Security and Compliance series, we’ll look at the topic of Personally Identifiable Information (PII) and SharePoint. PII is fundamental to security compliance for IT systems. We’ll answer these common questions relating to PII and SharePoint:
What is PII?
What regulations impact the creation, storage, and use of PII?
Do I have PII in my SharePoint sites, and if so, how did it get there, and what do I need to do about it?
What are the impacts to my organization of having PII in SharePoint sites?
Personally identifiable information is information about individuals that uniquely identifies a person, and is generally defined as including these data elements:
- Full name (if not common)
- National identification number
- IP address (in some cases)
- Vehicle registration plate number
- Driver’s license number
- Face, fingerprints, or handwriting
- Credit card numbers
- Digital identity
- Date of birth
- Birthplace
- Genetic information
It may also include these elements, which, although not specific to a person, may be combined with other personal information to identify an individual.
- First or last name, if common
- Country, state, or city of residence
- Age, especially if non-specific
- Gender or race
- Name of the school they attend or workplace
- Grades, salary, or job position
- Criminal record
Numerous regulations in various industries regulate the collection and protection of PII. These include Gramm Leach Bliley (US financial services), PCI DSS in credit card/retail, and HIPAA/HITECH (US healthcare). Over forty-five states in the US have enacted some form of data breach law, and internationally, data privacy laws and regulations exist in the EU, Japan, Canada, and elsewhere. Requirements vary, but all of these laws and regulations seek to require security protections for consumer PII, and in many cases they require organizations experiencing security breaches to notify affected individuals and in some cases to make public disclosures. With the cost for security breaches averaging ~$6M in the past few years, it is obviously better (and more cost effective) to protect PII rather than experience a breach, and suffer the direct costs and brand damage associated with recovery.
SharePoint makes it easy for users to share and store information of all sorts. This convenience is a double-edged sword when it comes to sensitive, confidential, or regulated data. Users can easily pull PII out of your organizations systems of record, analyze the data, save it in spreadsheets or documents, and store/share them in SharePoint. How do you know if you have PII in your SharePoint sites? The answer seems simple- you need to look for it! Scan your SharePoint sites regularly looking for PII data patterns. A free SharePoint content scan utility is available here. With it, you can perform scans of files in your SharePoint sites and find PII including credit card data, customer financial information, social security numbers, and other data patterns associated with PII.
Let’s assume you’ve scanned your SharePoint sites, and found files containing PII. What do you need to do about it? The answer depends on what sort of PII, whether it is in SharePoint be design or by accident, and how much control you can apply through policy to your SharePoint user’s behavior. Some organizations that we run across simply write policy telling users to not store PII on SharePoint. The old cold war adage “trust but verify” can (and should in most organizations) be applied to using security policy to try and control user behavior regarding storage of sensitive and regulated content in SharePoint. Even if you’ve written security policy governing the storage of PII in SharePoint, it’s a good idea to occasionally scan your sites and determine whether reality matches your policy.
NIST publishes a guide on dealing with PII that is worth reviewing, Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122).
Among their recommendations are advice on minimizing the use, collection, and retention of PII. In terms of recommended security controls for protecting PII, NIST calls out many of the security controls from SP 800-53, including the following:
- access enforcement
- separation of duties
- least privilege
- limiting remote access
- protecting information at rest through the use of encryption
If your SharePoint use case calls for the platform to collect, process, and store PII, then you should carefully design the security controls for your SharePoint site (along the lines suggested by NIST) to securely accommodate this information.
In our next article, we’ll focus on connecting the dots between security and compliance for SharePoint.
Mike Fleck