Privacy by design: where security meets usability

Ask anyone and they will probably have a story of a not so great user experience regarding security. If there is a product that is consistently used the wrong way without instructions, the problem is the system design and not the user. Using products and systems should be intuitive.

Usable security interfaces enable more users to maximise their security level. A good example of this is fingerprint or facial scanners in mobile phones versus entering your passcode every time you open your phone. If the latter would be the only option on offer, many mobile phone users would opt out of using it. By doing this they would leave their devices and data vulnerable.

Privacy by design principles are a central cure to this ailment. They ensure that you get working systems that do not forget the end user perspective. These principles are also mandatory if you wish to be compliant with current EU-wide laws such as GDPR. The principles are divided into seven different points.

1. Preventative methods for securing private data

First of all, there is a need to plan what data is gathered and how to store it securely. Also, tracking who has access to the data needs to be planned. It is important to note for the future that this tracking data is private data and it needs to be protected. This principle puts privacy at the center of design.

In practice, when system requirements are written there are both separate system security requirements and then system security is also taken into account for other requirements. In the Agile world where systems need to be built fast, requirements are often missing. This leads to issues because how can you comply with requirements if there are none? Or if they’re vague at best.

2. Privacy as a default method of operation

Privacy should be chosen as a default method of operation. Keeping sensitive data private is the foundation of design and upkeeping efforts. Also, consider the amount of data that is kept. The less data there is, the less data is susceptible to loss in the case of a data breach.

Systems should provide the maximum level of security that is reasonably achievable. Opt-in for service usage should be made explicit. The end user is asked for permission to use personal data and is given a description of what data is collected and why.

3. Privacy embedded into design

One option is the use of class leading solutions to ensure functional security. Class leading applications have business reasons to keep their products up-to-date both functionality and security wise.

When these products are selected as a base for system design it can be expected that there will be an update path, support and follow up for issues encountered. These solutions also raise interest in white hat (ethical) hacking scenes and therefore they are well scrutinised for their security.

One option is to select a service to provide a thought out selection of software to choose from. Figure 1 is a reference architecture of the Eficode ROOT DevOps Platform with software options. This setup is for different types of code development projects.

Figure 1: Eficode ROOT Reference Architecture

4. Privacy by design allows for secure products and it also creates a business advantage

Customers need to be engaged in data ownership as they own the data you collect. That creates trust in the service provider and brings in extra revenue.

As noted in the beginning, privacy by design is also enforced by EU law and data breaches can have serious financial consequences. Violators of these laws may be fined up to €20 million, or up to 4% of the annual worldwide turnover of the preceding financial year (whichever is greater). Negative publicity can further drive customers to use different service providers.

5. End to end security – Protection for the full lifecycle of the system

A perfect system can be planned and executed for needs that take into account privacy needs too. But the system is only kept that way if you rigorously update the software components of it. There needs to be a plan into how to keep the systems updated.

This plan can include using internal resources to administer the updates or using a service provider that takes care of the updates as part of the service agreement.

Let’s give an example. Jira security vulnerability CVE-2019-11581 included Jira Server and Jira Data Center. The vulnerability had been open until release of 8.2.4 version and fix versions for legacy systems. It exploited the "Contact Administrators Form" for template injection if a SMTP mail server was configured. This fix is still not implemented in many organisations.

6. Visibility and transparency of the organisation

As a part of building trust, there should be a trace in the organisation website that has more knowledge of the privacy practises in the organisation. There should be a clear communication channel to report and address the problems discovered.

If the end user agreed to have their personal data saved by the organisation, and they clearly own the data: wouldn’t it be easy if data could be used the way we wish?

7. User-centric design: users own the data they are entering into the system

Service provider should make sure in the beginning of the service that they are:

• Collecting this data from the end user
• For this purpose
• The end user can see the information gathered and also remove this information if they choose to

Sounds simple but many service providers could benefit from privacy by design principles.