Design

It is important to take into account the existence of threat actors that may attempt to obtain and gain access to personal data. To reduce the attack surface, it must be analysed, and the software modelled and designed to ensure a robust end product.

The target group for this activity is primarily architects, secondarily data protection officers, security advisors, and developers.

Design requirements accurately and comprehensively describe how the characteristics of each piece of software should be developed. The requirements need to describe how functionality can be implemented and distributed in a safe and secure manner. An example could be an identity and access management system where the user can see what he or she has consented to, his or her security settings and configurations, password management, and how the login process works. We have split the design requirements into two categories, data oriented and process oriented requirements, as recommended by the European Union Agency for Network and Information Security (ENISA).

Data oriented design requirements

1. Minimise and limit – The amount of personal data collected and processed should be limited to what is lawful and what is strictly necessary. The data shall be deleted when storage is no longer required for the purposes. A good rule of thumb is “Select before you collect”.
2. Hide and protect – Personal data, and their interrelationships, should not be communicated, processed, or stored in plain view. By hiding directly identifiable personal data from plain view, the risk of abuse and the scope of potential incidents is significantly reduced. Examples include pseudonymisation, encryption, and aggregation of personal data.
3. Separate – By separating the processing or storage of several sources of personal data that belong to the same person, the possibility of creating complete profiles of one person is reduced. For example, personal data can, based on their purpose, be stored in separate databases, units, components and areas. Separation is also an effective means to achieve purpose limitation and to avoid linkability between different data sets. A fixed time should be set for automatic deletion in tables containing personal data. This can be done by access control to tables containing personal data, splitting database tables, and distinguishing between components, units and areas with a high level of trust and those with a lower level of trust.
4. Aggregate – In order to safeguard the protection of the data subject’s rights, personal data should be collected and processed with as much aggregation as possible. You should avoid detailed personal data as much as possible, within the limitations of what can still have business value, and what is relevant to the purpose of collection and use. Examples include reducing the detail and sensitivity of personal data concerning individuals, and by removing unnecessary or excessive information whenever possible. To illustrate general trends or values, you can combine statistical data about large numbers of people without identifying individuals.
5. Data protection by default – All settings should, by default, be configured to the most privacy-friendly setting. The user should make a conscious choice to change any setting that would result in a less privacy-friendly configuration. When installing an app, the default configuration should be that the app does not track the user’s location, or share the user’s data with others. If the user wishes to use such features, he or she must actively choose to change the settings.

Process oriented design requirements

1. Inform – The software should be designed and configured so that the data subject is sufficiently informed on how the software works and how personal data is processed. When profiling or automated decision-making of personal data are being conducted the data subject should be informed on how it is being done. It is important to remember that special requirements apply if the software is aimed at children. For example, the software should, using clear and plain language, provide information about what personal data will be used for. Images, icons, and symbols may be used to make the information clearer and more intelligible. Animation, video, and sound may be good tools for customising information to the user’s level of understanding.
2. Control – The data subject has the right to control their own personal data. This includes a right to access, update, and/or delete their own data. Where automated decision-making is taking place, or decisions are being made without human intervention, the data subject can demand manual processing. The software should be designed so that the data subject can exercise these rights as easily as possible. One example might be that the user could use a menu or a separate page within the program to give and withdraw consent, allow to view, block, update, and delete their own personal data.
3. Enforce – The software should be designed so that it may facilitate documenting how it safeguards the data subject’s rights. The documentation should cover accountability and how the data protection regulation is enforced. It should be available for audits and inspections of the processing. This also includes artificial intelligence, profiling, and automated decision-making. One example would be to have a data protection or privacy policy describing how the software ensures the enforceability of the data subject’s rights, how you comply with data protection regulation, and what technical measures are in place to protect personal data. Technical measures might include access control and encryption.
4. Demonstrate – The controller must be able to document compliance with the data protection regulation and security of processing. The software must be designed and developed so that the controller can document and demonstrate how the requirements of the data protection regulation have been implemented. Examples include documentation demonstrating that the software has been developed using a methodology that ensures data protection by design and information security (SSDLC - Secure Software Development Life Cycle), reports from security audits, vulnerability scanning, security tests such as penetration testing, and reports on exercising data breach management.

Reduce opportunities to exploit vulnerabilities

Analyse the attack surface of the designed software to reduce attack vectors and opportunities to exploit weak points and vulnerabilities. In a design review, both communication and data flow, input and output should be analysed through the eyes of an attacker. You should also always investigate whether the same type of information is being collected or stored in multiple locations (duplicated functionality) and assess whether this functionality can be simplified. By keeping the design simple, and eliminating unnecessary features and complexity, the likelihood of errors will be reduced.

In this sort of analysis, you should use the assessments of both security risks and data protection impacts that were completed during the requirement activity. If a vulnerability is revealed, mitigating measures must be implemented to achieve acceptable risk level for data protection and security. The tolerance/risk level should be set in the requirement activity. Analysis and reduction of the attack surface should be documented.

Threat modelling Threat modelling involves the analysis of components, access points, data flow, and process flow within the software. Those involved should analyse how someone could misuse the software in different scenarios. You should review each scenario to see how the design can be improved to avoid any threats that are identified. This is done by implementing vulnerability-reducing measures, resulting in a more robust end product.

As a follow-up, you should carry out a risk assessment of any vulnerabilities that remain, and which must be mitigated using other measures. These vulnerabilities should be entered into a risk log.

Download

Example of a checklist for content in the design activity (pdf)