How to Make Working With Personal Data Less Risky
When assessing risk in your organization, the first step is to define the scope of your information assets, especially those which could impact the confidentiality, integrity and accessibility of information within your company. That includes any risks that affect assets that process, store and transmit personal data. You can reduce and nullify these risks with security controls.
The risks we’re going to consider are:
- Access management
- Data security
- Development and testing
- Device security
- Data transfer
A key way to reduce risks when working with personal information is to define the systems, network and network components responsible for storing and processing it. You need to be crystal clear about which assets contain all personal data and shift them to a separate security framework.
Doing so will allow you to dismiss threats that are applicable to other IT assets in your infrastructure and could directly or indirectly affect the systems and environment that contain personal data.
How to Make Your (Security) Life Easier
When talking about working with personal information, we often forget that we don’t always need to use the personal data itself. You can make your job a damn sight easier and minimize risks by using unique identifiers for your customers (users) instead.
Simply put, you can take the name of your customer—say, John Smith—his telephone number and address and replace it with something like UserID_1. If you need to keep different parts separate in a table, you could set John’s unique IDs as:
- Name — name_uid_
- Telephone — ph_uid_1
- Address —ad_uid_1
The above values will be enough for your internal processes (analytics, statistics, batch queries, etc.), and you won’t have personal data running amok in your systems; just the identifiers. Doing so will mean that you can set up your security so that only one set system has access to or can request access.
Another best practice is to organize your system so that it separates the types of personal data stored, with each type having its own namespace.
For example, separating:
- Employee and customer information
- Users whose personal data is a name, telephone and address and users who also provide additional identification like a passport scan
- Decryption keys for different types of data (e.g. those from a key management system)
An additional tip: Keeping decryption keys separate will give you greater control over access management and the ability to set key usage for different data requests.
No People? No Problem
Limiting access to personal data is the key point, here. The fewer people, services and systems that have access, the simpler it is to formalize and monitor everything—and the more secure that data will be.
Additionally, understanding who can access personal data and how they access it will allow you to correctly set up your incident response processes. This alone will bring down your response and investigation time, not to mention lowering business expenses for incident management processes.
Encryption
Personal data should be encrypted for storage and transmission. By making it impossible for third parties to decrypt the data, you will reduce risks associated with unauthorized access to personal data and data breaches as a whole.
As an alternative, you can obfuscate the personal data (as is the norm for payment data in PCI DSS) or tokenize it.
You can tokenize things like IP addresses completely. This will mean that third-party services won’t be able to access the source IP address but instead can learn which users have the same IP as their tokens.
Only use Personal Data in Production Environments
Even if your test environment is secured and protected at the same level as your production environment, you should never use real personal data when testing. I mean, if you have given your devs access to real personal data in the first place, this creates its own set of risks that will need to be controlled (e.g. monitoring the devs, integrity control, protection against breaches caused by unauthorized parties gaining access, insider threats, etc.).
Device Security
If you’re not a large or established business and you don’t yet have formalized policies and processes for end-user device security, (or you think that basic Windows and macOS security is good enough) make sure that you secure all virtual workspaces for employees that have access to systems which contain personal data. In fact, it would be better to secure these systems using a jump host.
An alternative to this would be to use something like Amazon Appstream or similar, which will cover your risks for devices that don’t have additional security software installed on them.
Push, Not Pull
If you need to transfer personal data—and, of course, you should be doing this through a secure channel and/or in encrypted format—to third parties, make sure you are transferring the information (push model) and they are not taking it from you (pull model).
It may seem arbitrary; that there is no difference or that this hinders efficiency, but think about it this way: If you leave data open to be pulled, then you run the risk of having much more data taken (or more requests than you anticipated). Now, imagine that the third-party service is compromised; you see where I am going with this?
The alternative is to use anonymized data where possible. Set up an anonymization service that is able to maximally depersonalize data at the web/mobile app entry point by tokenizing all the information using an open algorithm.
Data anonymization in practice
Reducing Data Risks
Reducing risks is quite different from eliminating them. It’s always worth remembering that you should create a separate environment every time people or systems will work with critical data (especially when security requirements for this data are regulated by GDPR or other compliance mandates). By doing so, you will make your security job a whole lot easier. This doesn’t just mean avoiding fines or bad publicity, but also reducing the costs of supporting your security overall, even when taking into account the additional costs of extra infrastructure to store and process the personal data.
