Securing PII in a software system

This article reflects our collective experience with handling sensitive data such as PII on various projects here at ObjectStyle.

What is PII?

In cyber security terms, personally identifiable information, or PII, is data that can be used to identify a specific person. It is information like the person’s name, date of birth, email address, physical address, social security number, health records, etc. Sometimes, disparate pieces of information do not point to a concrete individual – however, when pieced together, they make an identification possible and thus become PII.

PII-related regulations

In many countries, the collection, use, and removal of PII is controlled by government laws and regulations. One such piece of legislation (applicable to the European Union and its residents) is the General Data Protection Regulation, or GDPR. GDPR requires data operators to get the user’s permission to process their PII, store it securely, and have a mechanism for removing or handing it over to the user should they request it.

Shortly after GDPR was passed, the state of California in the US passed a similar piece of legislation called CCPA, or California Consumer Privacy Act, which mimics GDPR in many ways. In the world of healthcare, there is the Health Insurance Portability and Accountability Act, or HIPAA, a government act that obliges companies that deal with protected health information to hit certain privacy and security marks.

Sensitive data states

If we look at how data is used in a software system, we’ll see that it goes through a kind of cycle. Throughout that cycle, security professionals single out these three data states:

Data in motion / transit

Any information being transferred from one place to another over a wireless or non-wireless communication is considered in transit. Data in transit is normally protected using HTTPS, TSL, and other means.

Data at rest

Data is called “at rest” when it is stored in databases. It is normally protected with file-level or entire-disk-level encryption.

Data in use

Software applications are able to manipulate encrypted data by taking the following steps: decrypt – use – encrypt. That “use” part means that the data is being processed in plaintext in RAM, CPU caches or registers. Since it is in plaintext, securing data in use has always been the weak link.

Theoretically, homomorphic encryption can be used to solve this problem. With this type of encryption, the data stays encrypted, but can be processed or manipulated at the same time – one can perform functions on encrypted information without the need to reveal its values. However, homomorphic encryption is not widely used because it is still too slow to be practical.

The three data states – data in transit, at rest, and in use – are singled out mostly for encryption purposes. The distinction helps security engineers choose an appropriate strategy in each case. When we consider all of the data states, it will help us determine where our PII lives, who has access to it, how it’s being used by authorized persons, and how to protect it.

Risk mitigation tactics

In general, the simpler your system is, the easier it is to protect. There are also certain security risk mitigation tactics that we’ve used when designing software for our clients. We normally work together with our client’s security team on this.

1. Reduce attack surface

As applied to a software environment, the attack surface is the sum total of all possible entry points and attack methods that hackers can exploit to steal your data. The fewer of those methods are available to them and the fewer entry points there are, the better.

One of our clients had a group of applications, most with their own login system. Some of those login mechanisms were legacy and did not comply with modern security standards. ObjectStyle implemented a single sign-on system for the client, moving all user profiles and credentials to a unified database. We started using a secure authentication protocol to authenticate app users, while moving sensitive data out of the apps themselves, hence reducing attack surface.

Also read: (Case Study) ObjectStyle creates a company-wide IAM system for a sports organization

2. Remember to encrypt data at rest

Security engineers tend to place a lot of emphasis on encrypting web communications with SSL or TLS, while sometimes neglecting their databases. At the same time, hackers increasingly prefer to steal data wholesale by exploiting vulnerabilities in database security.

ObjectStyle supports Apache Cayenne, an open-source object-to-relational mapping framework. Cayenne has a powerful database encryption module, Cayenne Cryptography, that allows you to encrypt your data at rest. We invite you to check it out.

3. Delegate compliance to a third party

Some cloud service providers offer pre-installed security provisions that help you stay compliant with applicable regulations. Then the onus of ensuring those measures is on the third-party provider handling your data.

We did this for one of the clients who needed to stay compliant, but realized it would be too expensive to build a high-security infrastructure on premises. So we moved our client’s apps with PII to AWS servers.

Also read: (Case Study) Ensuring compliance and implementing IaC in an enterprise environment

4. Depersonalize sensitive data

Some companies, including ourselves, have resorted to data depersonalization as a means of using data that includes PII without exposing any sensitive information. Depersonalization of data consists in encrypting data in such a way that it’s not possible to match a piece of personal information with a specific person. And it’s really important that you do it properly.

ObjectStyle does this on some projects where we need real-world data for testing, but can’t use it as-is due to privacy regulations.

5. Create an AUP and train your employees

AUP stands for Acceptable Usage Policy. It’s a legal document that defines acceptable use of your company’s resources (computers and software programs) by the company’s employees. It also describes the steps your staff should take to protect information’s privacy and integrity. There is a free template for that.

Once you have an AUP, share it with your employees and maybe make them sign a confidentiality agreement. Educating your employees about data security is especially important in the light of the already-mentioned GDPR regulation. In his conference talk titled “GDPArrrrr: Using Privacy Laws to Steal Identities,” James Pavur demonstrated how easily he could get other people’s personal information by asking random companies to fulfil their obligations under GDPR.

In Conclusion

There are different tactics that help you secure PII. Yet the strategy should involve common-sense steps like reducing the number of places where PII can be found, properly training your employees, and implementing the “principle of least privilege” – that is, limiting user permissions to the bare minimum they need to do their work.