Shifting Left - An Information Privacy Perspective (Part 1)
Privacy regulations are taking centre stage around the world, and stiff penalties have been mandated for failure to adhere to these regulations. South Africa is no exception, with the Protection of Personal Information Act (POPIA) becoming law from 1 July 2021.
The software development world has had a couple of distinct transitions, but the following two stand out in terms of overall impact:
- The increasing power of computers in the 1960s led to multiple software projects being undertaken. Many had substantial quality issues and generally were over-budget. This was realised and discussed in the first North Atlantic Treaty Organisation (NATO) Software Engineering Conference in 1968, where it was concluded that an engineering approach was necessary to improve the status quo. Over the succeeding years, this resulted in various approaches/methodologies to bring order to the software quality problem.
- Fast-forward a couple of decades from the NATO Software Engineering Conference. Although software quality had improved, many people realised that network perimeter and other host-level security controls were insufficient in stemming the tide of security defects that applications contributed to. It became another moment to pause and reflect on the situation, with the realisation of the importance of building security into the software development process.
Nowadays, the “building security in” principles, as opposed to treating security as an afterthought, have largely taken root, and there is consensus to the bottom-line benefits of such approaches. Figure 1 below illustrates the relative costs of fixing software security defects relative to the phase in the development lifecycle.
Figure 1: Relative costs to fix bugs
This realisation has led to the “shifting left” principle, where security is considered across all phases of the Software Development Life Cycle (SDLC) with specific emphasis on the early stages. This has brought significant benefits in reducing software security risk. It is furthermore believed that the same benefits can be accrued from a privacy perspective.
Information Privacy – The Concerns
Regardless of the different types of privacy regulations, a central theme that stands out is as follows:
- Any entity collecting and using personal information must ensure that the applicable regulatory provisions centred around preventing or reducing privacy ‘harms’ from the perspective of the data subject are adhered to. Fines do apply for failure to ensure the required provisions.
Some of the privacy ‘harms’ that may result are as follows:
- The use or dissemination of inaccurate or misleading personal information about a data subject.
- The use of personal information in ways that were not explicitly authorised by the data subject.
- The resulting stigmatisation of an individual when personal information is linked to a specified identity.
The realisation of these and other privacy ‘harms’ would adversely affect the data subject. This is what should be prevented by ‘baking in’ privacy principles into the software development lifecycle. Should these concerns be addressed as early as possible, there would be a reduction of the costs in fixing defects further down the line.
Just as security benefits have been realised for ‘shifting left”, it has been observed that similar benefits also apply to information privacy.
The table below (Table 1) summarises information privacy practices that may be included within the SDLC:
Table 1: information privacy practices that may be included within the SDLC
This article addresses the first two phases, namely, within Table 1; Requirements and Design.
A standard template should be used for collecting privacy requirements, and for each requirement, the following minimum information should be captured:
- Requirement ID – Unique identifier for the requirement.
- Requirement Statement – Statement of the requirement to be met.
- Regulatory Compliance – Cross-reference to the clauses in the privacy regulation that drive the need for the specific requirement.
- Scenario Description – Description of applicable scenarios where the requirement will need to apply within the application context.
An example follows for codifying the need for obtaining consent before the collection of personal information:
Table 2: Example for codifying the need for obtaining consent before the collection of personal information
Templates will need to be created to easily reference applicable privacy clauses and reduce rework. Care needs to be taken to ensure that all the required provisions are taken into consideration, and Privacy Engineers will be instrumental in ensuring this. An approach for performing completeness checks involves; documenting how a piece of personal information will be handled across the entire data lifecycle (Collection, Processing, Usage, Archiving, Destruction) and mapping the relevant regulatory provisions for all the phases of the lifecycle.
If this process is properly executed, the system design phase will have appropriate guidance on how the design elements of the system can be structured to ensure the preservation of the data subject’s privacy. It is also important that the requirements document contains a glossary of the terminology used to ensure common understanding across all the stakeholders.
For organisations that have adopted agile methodologies, privacy requirements can be captured as user stories to ensure their treatment during the scrums.
The two major privacy assurance activities performed during the design phase are as follows:
a) Privacy Risk Assessment – Identify adverse privacy scenarios that can occur in the system due to the handling of personal information.
b) Ensuring Traceability of Privacy Requirements into System Architecture – Validation of system architecture’s ability to support identified privacy requirements.
Privacy risk analysis seeks to identify adverse scenarios that can be realised when certain entities interact with the personal information collected and processed by the application. This effectively lists potential privacy ‘harms’, each linked to a specific threat actor and each rated in terms of the magnitude of its projected impact and the likelihood of its realisation.
There are various methodologies for this process, including LINDDUN and the NIST Privacy Risk Assessment Methodology. Regardless of what methodology is chosen, the main objective is to ensure that all the relevant privacy ‘harms’ which can be realised are factored into the analysis.
The following workflow can be used for privacy risk assessment:
Figure 2: Workflow for privacy risk assessment
In determining the privacy risk levels (inherent or residual), the OpenFAIR Methodology could be used to allow for the use of quantitative factors instead of qualitative ordinal scales. The output of this process will be a set of prioritised privacy risk scenarios that will need to be treated accordingly. The treatment actions chosen will affect the final design of the system. Ensuring traceability of all the privacy requirements into the system architecture will also be a key activity in this phase and will be linked to the privacy threat model.
Part 2 will discuss the privacy touchpoints for the remaining phases – Implementation, Testing and Deployment.
- LINDDUN - https://www.linddun.org/
- NIST Privacy Risk Assessment Methodology - https://www.nist.gov/privacy-framework/nist-pram
- OpenFAIR - https://www.fairinstitute.org
No posts found