A Call to Protect Personally Identifiable Information

2015 was a record year for data breaches. At risk are the millions of vulnerable confidential files and data points known collectively as personally identifiable information. The good news is that there is a proven solution for protecting PII: tokenization.

A Call to Protect Personally Identifiable Information      

For data breaches, every year continues to be record breaking. According to Risk Based Security,1

more than 736 million records were exposed in 2015. 238 million records were exposed in four hacking incidents alone. Headlines kept breaches top of mind and they were read as real life cautionary tales. Countless articles accounted companies’ disastrous financial and reputational fallouts following accidental records misplacements and raids by foreign cybercriminals. What were the costs? According to the Ponemon Institute,2 the average total organizational cost of a data breach has risen to $6.53 million, an 18% increase since 2013. Every malicious attack carries the price tag of $217 per compromised record2. A recent study3 states that 25% of companies would be willing to pay a ransom in order to prevent the public release of stolen records, and 14% of those would consider paying $1 million or more. One must also consider the intangible costs. How does a company quantify the impact to its brand? For every 100 customers a brand loses, what will be the cost of reacquiring those customers? Beyond the costs to companies, consider the human element affected by a breach. At risk are the millions of vulnerable confidential files and data points that belong to customers and employees of companies that acquire, process, and store this information on a regular basis. One of the biggest takeaways here is that a person’s data points—known collectively as personally identifiable information (PII)—are enormously vulnerable. If someone wanted to gather the data of a person and use it for malicious purposes, he could do it easily and quickly with the right tools.

Just consider how much data is not only readily available through public government records, but is also openly transferred via social media. Combine that with a person’s sensitive data that is held by companies, and it can be frightening to envision ways in which PII can be used and to what ends. The good news is that there is a proven solution for protecting PII: tokenization. But first, it is important here to better understand PII and its current protections.

PII defined When referenced in relation to information security, personally identifiable information (PII) includes any information used singularly or paired with other data to identify an individual. This data takes multiple forms—from the obvious, such as name, Social Security number, and drivers license number to the less evident such as age, city of residence, salary, race, and even an IP address. Now, it is common knowledge that a person’s identity exists within the magnetic strip of a credit card or among the nine digits of a Social Security number. But what is less known is the fact that just a few data points can be used to accurately reveal an identity. According to the US General Accounting Office,4 87 percent of the US population can be uniquely identified using only gender, date of birth and zip code.

Who possesses PII? In a broad sense, any industry that relies on, utilizes, or collects an individual’s personal information

A Call to Protect Personally Identifiable Information  

 

possesses PII. That means CIOs and CTOs in virtually every sector should be hypersensitive to and bear the responsibility of data protection. When we drill down, PII is particularly relevant to the healthcare and pharmaceutical industries, business to consumer (B2C)-oriented channels, and human resources departments in all corporations charged with managing their employees’ confidential information, as well as others. Healthcare and pharmaceuticals

In the healthcare and pharmaceutical industries, for example, confidential data is gathered, transferred, and stored every minute of the day. In these industries, a patient’s PII is known as protected health information (PHI), which is electronic data such as patient names, medical records, addresses, Social Security numbers, and email addresses. Unlike PII, PHI is addressed specifically by the HIPAA and HITECH acts at a federal level. As healthcare professionals more widely adopt electronic health records, that data is at risk to hackers and other cybercriminals. A single compromised healthcare record on average costs $3985, more than any other sector5. Thus, the necessity for PHI security is greater than ever before. Business to consumer

Another obvious industry affected by PII is the B2C market, where the primary source of PII is consumer payment and customer-related data. Bank account/ACH data, customer name and address, and credit rating data are all rich with PII, but only credit card data is truly directly addressed, with an obvious heavy emphasis on PCI-DSS (Payment Card Industry Data Security Standards). With sensitive data transferred and stored with every transaction, protection is imperative. Well-known brands—which have spent decades of time and billions of dollars on their brand reputation—especially have the most to lose in the wake of a data breach. Human resources

The third area where PII management is crucial is not an industry per se, but rather a vital department within any corporation: human resources. This is the hub where employees’ personal information is stored and handled, and CIOs of any large

corporation must continually have a secure plan in practice for keeping that information protected.

A PII threat: Data in motion and at rest Methods of data access will continue to grow in popularity because the benefits of greater interaction with data are too great, and this directly impacts how data is communicated and how and where it is stored. The healthcare industry uses electronic data as a tool for reaping huge financial gains. Companies also continue to relocate mass amounts of data. A 2015 study6 by the Cloud Security Alliance found that 58 percent of organizations already transfer, or plan to transfer, sensitive or confidential data into the cloud environment. The same report states that 65 percent of IT leaders believe the cloud is more secure than any on-premise software. Of course, the increase in data access methods and communication makes PII more vulnerable and susceptible to compromise while the data is in transit. However, CIOs must continue to be aware that arguably the greatest liability for a company regarding PII is protecting data that is sitting in storage, also known as data at rest. Imagine a company has the Social Security and bank account numbers of 10,000 employees sitting in a file or server or in a database somewhere, and someone—either accidentally or maliciously—walks off with that data. Last year, 749 incidents were due to inside threats exposing information7. Think of the potential damage that could be done with that amount of collective data to the employee base and relationship between the company and employee. Which presents a question: Who would walk off with data like that?

Last year, 749 incidents were due to inside threats

exposing information—accidently or maliciously.

A Call to Protect Personally Identifiable Information  

 

Who and why

The media has enlightened us to the cybercriminals who prey on identities and specialize in credit card theft. Government and private sector reports have recently fingered Chinese hackers for trying to break into the US defense computer networks as well as for stealing data from 100 American companies. And despite the fact that federal prosecutors last year indicted a ring of Russian and Ukrainian hackers for stealing more than 160 million credit card numbers and hundreds of millions of dollars from large US corporations, the attacks continue. But what about data breaches and compromises to PII that are enacted by internal or accidental means, not malicious? Another Ponemon study states that 32 percent of data breaches were caused by system glitches and 19 percent came from employee negligence8. This could be as innocent a mistake as someone printing a document with a list of employees’ Social Security numbers on it and leaving it on the printer too long, or in the interest of the environment, absentmindedly tossing the confidential document into the recycling bin. While it may seem like a minor mistake, it could lead to a major liability issue should this data fall into the wrong hands.

Protecting PII: A movement from encryption to tokenization Considering the prevalence of PII and the threats it attracts, one of the most powerful solutions a company has for protecting the storage and transfer of confidential PII is a process called tokenization. It works by intercepting the data that enters into an enterprise system or application and replaces it with a surrogate value known as a token. A token is a unique ID created to reference the actual data associated with the encrypted data. Before tokenization, the go-to solution for protecting PII was encryption. We have found, however, that encryption is costly and brings with it its own problems. Each system (an ERP, for example) requires not only its own encryption, but also management and rotation of the encryption keys. Experience shows that over time, in many organizations and systems, it lapses. Can it protect

PII? Yes. Is it practical? No, very often not. That is where tokenization enters the conversation. It is a practical solution that removes significant overhead surrounding sensitive data protection. It is important to note that tokenization of sensitive data in the enterprise and especially in ERP systems was originally developed as a way for organizations to address the PCI-DSS. As part of the standard, any merchant that processes, stores, or transmits cardholder data is required to protect that data. As a tool applied within a compliance-sensitive environment, tokenization, its accompanying controls, and appropriate solution architecture have matured to withstand review and audit. Tokenization has proven its value as security analysts and even members of card associations like Visa have endorsed its use and have correlated the adoption of the technology with “best-in-class” results. It is a flexible technology solution and can be easily adapted to protect any type of PII in any enterprise system or application.

How tokenization works Tokenization works by replacing a sensitive data value with a surrogate value, or token, ensuring sensitive data is no longer present but rather is represented by the token. A token is a unique ID created to reference the actual data with encrypted data, while the actual data is encrypted and stored in a secure data vault.

An organization no longer has to store the sensitive data in-place, but instead stores tokens, reducing the liability of protecting that sensitive information and the associated risk of doing so.

A Call to Protect Personally Identifiable Information  

 

 Paymetric’s PII tokenization solution and data protection securely intercepts, transfers and stores any sensitive customer

data in a PII PCI–compliant, data vault.

 

Tokenization reduces the amount of sensitive data that is stored in an application or environment, and reduces risk, based on the reduced or eliminated feasibility of determining the original raw data from the token alone, as a token must not be mathematically reversible. To be complete, a tokenization solution cannot protect stored data in isolation from data entry and access, and as a result a comprehensive solution must include secure data entry and secure access to the original data under appropriate and verifiable controls. Tokenization is not a silver bullet, but applied within a larger security framework and architecture, it is effective and practical. Practicality is derived through a number of factors that contribute to a simplified solution, such as:

• Removing an encryption and key management layer.

• Tokens can be passed between systems as-is.

• Flexible token formats ease integration into less flexible applications and legacy systems and databases.

• Imbedded usable data retains usable parts of the sensitive data within the token and supports business processes without the need to access the original sensitive data.

In the example of a credit card number, the last 4 digits of the card number can be included in the token so that a user or processor can identify enough of the card number to support a customer service representative (CSR) interaction or receipt generation.

• Multi-use token data integrity, where the same sensitive data transforms to the same token; the protected application is able to run queries and metrics without change to existing logic and without any update to the stored data. Take the scenario of a CSR fielding a customer inquiry into a charge on their credit card statement. The CSR securely captures the credit card number and runs a search for associated records; without tokenization the system performs multiple encryption and decryption steps to identify the entries, but with tokenization the card number is tokenized and an optimized query executed directly against the database can now retrieve the matching tokenized entries.

Tokens are typically multi-system but single site, meaning that multiple systems within an organization share the same pool of tokens and a different organization or partner has its own pool of tokens. There are valid reasons to limit individual

A Call to Protect Personally Identifiable Information

Tokenization reduces the amount of sensitive data that is stored in an application or

environment.

systems to their own pools of tokens, but in the majority of cases there is business benefit in having logically connected enterprise systems share tokens in the same way they share the records where the data is stored.

Tokenization is typically deployed in a holistic approach, applying the principle of tokenization at the edges and creating a secure envelope of internal systems to benefit from storing or communicating the tokens internally. Data inbound There are delivery and integration methods for tokenization that enable the capture of sensitive data very early in the life cycle. In some cases this can occur early enough in the work- flow that it intercepts the raw data prior to touching an underlying application or corporate environment. A common instance that illustrates this well is the use of redirect and transparent redirect approaches for capturing a card number during checkout in an ecommerce site. In this approach, the card number is intercepted at the browser level and tokenized before it flows to the underlying web server. This ability to intercept raw data prior to touching an application has clear applications in web scenarios, but also in call center and internal use cases as well as for batch/flat-file/XML scenarios.

Data outbound

The same holistic approach focused on early and secure tokenization must also include a complete and secure detokenization model. Every use case where the business identifies tokenized data being needed in its detokenized form should be reviewed to understand the business purpose, specific task, system and technology (e.g., batch process, report, screen), and consumer of the data (e.g., specific user/role, internal, external).

Many detokenization use cases can often be de-

scoped, where the business function does not need the full original data value and can be supported by an imbedded portion of the original data; an example might be using the imbedded last four digits of a Social Security Number instead of the full number. Where a credit card is involved and tokenized payment calls are being made to the same service provider as the token service provider, then detokenization can be entirely eliminated from the protected application. The same is true for data passed to a business partner where the token service provider might act as a proxy in the communication of data to the partner; in this case the protected application passes tokenized data to the provider, where it is detokenized and then securely forwarded to the partner. The remaining, and hopefully few, detokenization use cases then require comprehensive documentation and must undergo thorough solution design in terms of business process definition, access control, physical control, and authentication related to both the user/function as well as system detokenization request.

Because this critical data is now tokenized and stored outside of the protected system, it is vital that both the communications and the tokenization provider are secure, hardened, and redundant. Likewise, it is fundamental to ensure appropriate internal and external protocols are in place related to the authentication of inbound service requests, intrusion detection and scans, site and geographic redundancy, logging, failover, load balancing, latency/RPO/RTO SLAs, and depending on the delivery model also carrier redundancy, SSAE-16, company financials/reputation/experience, and similar.

PracticalityOur world is driven by information technology and big data. Unfortunately, the sobering and frightening truth is that it can all be compromised in an infinite number of ways, exposing PII to people who intend to use it maliciously. Tokenization is the safeguard and a PII protection solution that is not just technically appropriate, but also practical.

A Call to Protect Personally Identifiable Information

improve reduce eading on only integrated,

by leader recognized support

their products herein registered herein

About the Author Stewart Comrie is VP of Solutions and Business Development at Paymetric. He has extensive payment card and security experience, integrating with some of the first ever SAP® encryption technologies through to present-day payment card security solutions. He has authored articles and best practices, is a patent holder in the space and a regular presenter on topics of payment card processing, payment card security, and sensitive data protection in enterprise systems. He may be reached at scomrie@paymetric.com.

1 Risk Based Security, “2015 Data Breach QuickView” – https://www.riskbasedsecurity.com/reports/2015-YEDataBreachQuickView.pdf. 2 Ponemon Institute, “2015 Cost of Data Breach Study: United States” 2015 – http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH&infotype=SA&htmlfid=SEW03055USEN&attachment=SEW03055USEN.PDF. 3 Cloud Security Alliance, “The Cloud Balancing Act for IT: Between Promise and Peril” 2015 – http://info.skyhighnetworks.com/rs/274-AUP214/images/WP%20CSA%20Survey%20Cloud%20Balancing%20Act%200116.pdf. 4 Latanya Sweeney, PhD, “Standards of Privacy of Individually Identifiable Health Information,” US Department of Health and Human Services, 2003 –http://www. hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/introdution.html. 5 Ponemon Institute, “2015 Cost of Data Breach Study: United States” 2015 – http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH&infotype=SA&htmlfid=SEW03055USEN&attachment=SEW03055USEN.PDF 6 Cloud Security Alliance, “The Cloud Balancing Act for IT: Between Promise and Peril” 2015 – http://info.skyhighnetworks.com/rs/274-AUP-214/images/WP%20CSA%20Survey%20Cloud%20Balancing%20Act%200116.pdf.

7 Risk Based Security, “2015 Data Breach QuickView” – https://www.riskbasedsecurity.com/reports/2015-YEDataBreachQuickView.pdf. 8 Ponemon Institute, “2015 Cost of Data Breach Study: United States” 2015 – http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH&infotype=SA&htmlfid=SEW03055USEN&attachment=SEW03055USEN.PDF.