Data Privacy Failures 

The last couple of years has seen a turning point regarding the increased awareness that people have of how organisations use their data and the responsibilities that come with holding personal data.

Recent Examples

Following some significant failings of companies to protect data privacy:

• Equifax Data Breach One Year Later
• Marriott Breach Exposes More Than Data
• Cathay Pacific faces probe over massive data breach

These breaches have lead to increased public awareness of the importance and value of personal data.  Governments have also taken notice of the increasing impacts of personal data breaches and have been introducing legislation such as GDPR and mandatory data breach notification laws.

Governments and citizens alike are increasingly questioning how companies are collecting, using (and misusing) people’s data.

Designing for Data Privacy

The obligation for appropriate privacy and security controls also extends to solution architects and designers. Solutions that collect or consume individual’s data need to consider and include suitable protective measures to protect the individual’s privacy.

When we design solutions, we are guided by the functional & non-functional requirements, the technology landscape and the organisational roadmap. Data privacy should not be conveniently de-scoped, omitted or left as an afterthought from the non-functional requirements. The solution architect needs to consider the impact of data privacy as a key foundation of solution design. An MVP solution still needs to provide adequate security controls as maintaining data privacy should always be in the MVP scope.

Solution architects have a role to play to ensure the solution owner is aware and considers the need to invest in a solution that protects user data privacy. Taking a secure by design approach is increasingly important.

The Basics

From a solution view, there are the traditional methods of controls that most solutions will focus on:

• Authenticating users, hopefully with something more robust than just a username, password, i.e. multi-factors, password strength checks
• Authenticating integration end points and application of integration security policies
• Securing data in flight and at rest
• Logging user events and data changes.

But whilst these types of controls address scenarios of access and identity there are other scenarios that need consideration. Not all security threats of compromise data privacy come from external sources. We must acknowledge that there is no foolproof solution. We need to consider what would happen if a solutions security mechanisms are breached or data is exposed through neglect or mistake. What happens if an organisation’s security fails or is taken over, will the data controls be maintained? What would happen if user data is exposed through neglect?

Recent history has many examples of companies large and small that can fall victim to not adequately protecting their customer’s data. See

• List of data breaches in Australia 2018-2019
• Saudi caller ID app exposes 5 million users
• 21 biggest data breaches if 2018

Designing with data security in mind

Learning from these examples should be taken into your solution designs as well as the operational security controls. Taking a “secure by design” principle is an important aspect to strengthen the overall ability to protect your customer’s data:

• Only storing personal data that is critical to a business process. Do you really want to expand your risks of user impact by harvesting and storing data you do not actually need?
• Implementing controls and schedules for destroying data when it is no longer needed
• De-identifying data when user identity is not needed, e.g. analytics,
• Active monitoring of logs for suspicious activities (internal and external)
• Making sure production data does not make its way into being used for test data.
• Compartmentalisation and partitioning of data stores so each can be encrypted separately using different keys or algorithms and mitigating impacts of a single data store breach.
• Mechanisms for periodic updating of encryption keys and re-encrypting data.
• Do you really need to have or store personal identifiable data? Can surrogate data be used to classify a user rather than identify them?
• Is the solution owner aware of their obligations under the Australian Privacy Principles?

Solutions emerging today make increasing use of the flexibility and economics of cloud platforms to operate on larger data sets. The growth of connected IoT devices feeding data into solutions, combined with the potential use of machine learning to correlate disparate data sets reinforces the need to actively consider how the solution protects user’s data privacy.

People are waking up to the importance and value in their data privacy. The blanket T&C agreement check box is not an excuse to ignore privacy from solution designs or to accept requirements that do not consider data privacy.

Putting the real data owner in charge

Ultimately, the individual should be the only owner of their private data and with that ownership be provided the controls over who holds their data and how it is used. We need solutions to consider how they can put the user in control of their data. This will increasing become mandatory customer expectation as legislation like GDPR, CDR and impacts of data breaches and violation of trust continue to have high visibility in mainstream channels.

Imagine a solution where the individual maintains their own private data platform. The user must have easy to use controls to generate limited data access keys to selected individuals and organisations and can revoke data access keys as needed or within a specified time period.

This sounds a lot like an OAuth OpenID Connect approach with the user owning the data platform that houses their private data. Depending on your view of trust, this could be a public platform like Facebook, but I suspect there is potential for an easy to use, consumer oriented private data platform service that puts the individual in control of their data sharing and access.

Once you have granted access (even if limited) to an organisation there is no technical means of preventing them then from then storing and re-distributing your data without your permission. There still remains the need for suitable government controls and penalties for data misuse.

Lower technology barriers of entry do not lower obligations 

Cloud platforms provide both a rich set of capabilities whilst at the same time lowering the cost of entry to smaller organisations. This brings large data sets with advanced data matching and processing functions into the reach of smaller companies that may operate with a small head count that does not include people in distinct risk & compliance roles. This does not remove their obligations to protect data privacy and for the solution architect amplifies the need to ensure privacy is addressed as an inherent element of the solution design.

Conclusion

The enabling capabilities of solutions built using cloud platform services and the increasing ease of integrating across digital channels provides us the ability to build feature rich solutions at lower cost than past traditional on premise solutions. This reduces barriers of entry but also increases the importance for architects to carefully and pro-actively consider data privacy controls and security during design.