Ultimate Privacy by Design Data Protection Course(GDPR,LGPD)

In this lesson we will discuss shortly about privacy by design history of adoption. In 2009, Dr. Cavoukian, former information and privacy commissioner of Ontario in Canada, finalizes her 7 Foundational Principles of Privacy by Design,a concept she had been refining over her previous decade as commissioner.

Privacy must be a forethought in any product, service, system or process. Privacy considerations should help drive the design, not the reverse.

Privacy-friendly defaults are commonly associated with the concept of opt-in versus opt-out, mostly in the area of future contacts, such as through email marketing. The idea being the baseline is not to contact an individual unless they have affirmatively assented to that contact (through an opt-in selection).

Privacy should be so integrated into the design that the system or process wouldn’t function without the privacy-preserving functionality. This principle, perhaps more than others, is used by critics to point out that privacy by design does not contain concrete proposals but is self-referential

Privacy and other design requirements should not be treated as a trade-off. Designers must develop creative win-win solutions.

Privacy and other design requirements should not be treated as a trade-off. Designers must develop creative win-win solutions.

Privacy by design has faced challenges in the past decade. Most of those challenges concern the high-level nature of the principles and the lack of specificity in terms of action items or checklists

People value their privacy. Unfortunately, most people feel their privacy is out of their control and are helpless to do anything about it. They have resigned the loss of their privacy. But it may not be their fault. There are structural and psychological reasons why people are not in a position to protect their own privacy.

In this section, I develop an abstract privacy model consisting of the relevant actors, potential privacy violations, and potential controls to mitigate those violations in whatever product, service or process is being modeled. From this generic model, one can construct a use-case-specific privacy model.

In any given use-case model, there may be an obvious class of individual, whose privacy we’re concerned, such as a customer, user or job candidate. What I propose here is a more practical approach to identifying sensitive populations based on historical examples and legal protections.

Any party who interacts with an individual or their information represents a potential threat. This could be a party who has a relationship with the individual, directly interacts with the individual, or indirectly interacts with the individual through processing their data.

The use-case privacy model must demonstrate the relationships between the individual and threat actors and the threat actors to each other.

Lets take as a first example, an interactive online multi-player game.

Human resources department vetting job candidates through an online skill-testing service

Political activist website

Privacy suffers from an abstraction problem. If I say, “My privacy has been invaded” or “I violated your privacy,” those phrases say little of the events that have transpired

Watching, listening to, or recording of an individual’s activities. Surveillance, these days, comes in many forms, not just the stuff of spy novels, though government surveillance remains a hot topic

Aggregation, Insecurity, Identification

Secondary Use and Exclusion

Breach of confidentiality, disclosure, exposure, increased accesibility

Blackmail, Appropriation, Distorsion

Intrusion, Decisional interference

A control is a countermeasure to minimize privacy violation risks.  In the privacy model, a control reduces a threat actor’s access to the individual, information about the individual, or governs the threat actor’s behavior through either technical, administrative and operational means.

Identifiability can be defined as the degree to which data can be directly attributed to an individual.

Separate the processing of personal data as much as possible to prevent correlation.

Limit as much as possible the processing of personal data. Data minimization is a core tenet of many data privacy frameworks, though it is rarely exercised in practice.

In this lesson we will discuss about the last 3 tactics from Minimize strategy: Select, Strip, Destroy

In this lesson we will discuss HIDE, the 3rd strategy, and 4 of the tactics, including Restrict, Mix, Obfuscate and Dissociate.

In this lesson we will discuss about ABSTRACT, the 4rd strategy and the last data-oriented one.

ABSTRACT means limiting as much as possible the detail in which personal data is processed.

Enforce means commiting to processing personal data in a privacy-friendly way, and enforce this.

The process-oriented strategies, beginning with Enforce, are generally about organizational (or sometimes administrative) measures being applied to reduce privacy risks.

In this lesson we will discuss about DEMONSTRATE, a strategy related to the processing of personal data in a privacy-friendly way. Controls are often categorized as preventative, detective or remedial. While policy controls are meant to be preventative, they aren’t completely effective. What they do is reduce the probability that a threat actor will act.

In this lesson we will discuss about INFORM and means informing data subjects about the processing of their personal data. Providing notice to individuals about the collection and use of data has been a pinnacle of privacy principles for decades. Unfortunately, transparency has dissolved into lengthy legalese documents on websites that do little to provide information to individuals.

In this lesson we will discuss about CONTROL, meaning providing data subjects control over the processing of their personal data.

In this lesson we will try to create a conclusion for all the strategies and tactics discussed before.

All the architectural system characteristics, as discussed earlier, can be expressed in terms of the strategies and tactics outlined in this section

We’re now going to add two additional layers on top of the privacy model — domains and information flow — that will provide more guidance about the controls.

Domains are spheres of control, so the user domain is what’s within the user’s (aka individual’s) control, and the service domain is what’s within the service provider’s control. But within a given system, there may be many domains, many service providers, with clear or sometimes unclear roles.

Our example - the city pothole app

this section exercises

Risk analysis is nothing new in the privacy space. Most efforts at privacy risk analysis have suffered from three principle deficiencies that we will discuss in this lesson. An absence of controls is commonly mislabeled a risk, where the controls are meant as a preventative measure against the actual underlying risk

In this lesson we will discuss about FAIR methodology. FAIR decomposes risk into constituent parts that can be further decomposed into their constituent parts. THe purpose is to find factors that can be calculated or reasonably estimated, thus building up an estimate of the overall risk

Action Frequency is the probable frequency, given a time frame, that a threat actor acts toward an individual in a way that is a potential privacy violation.

In this lesson we will discuss about vulnerability, the probability that a threat actor’s acts will succeed.

Vulnerability can be viewed in terms of two factors: capability of the threat actor to commit the act and how difficult it is for them

Violation Magnitude is the probable extent to which the potential privacy violation constitutes an actual privacy violation for the affected population and the adverse consequential risks to that population from that privacy violation.

In this lesson we will discuss about Controls. The risk definitions provide a guide to what types of controls will be effective and where. Some controls will be generated externally (such as imposed by law or contract), while some will be applied by the actors themselves.

In this lesson we will continue with Applying Controls

You might be wondering why I’ve approached risk from an individual rather than the more typical organizational perspective. As I mentioned in the beginning of this section, I think a strictly organizational risk approach has led to a myopic view limited to the fiduciary interest of organizations to their investors.

In the following 2 lessons we will dive a bit into numbers again

In many cases, you won’t need to perform a quantitative analysis. You have known risks associated with what you’re doing, and you put in place some mitigating controls. The risk framework shows the interplay between the controls and the risks without resorting to numbers, in most cases.

Risk, Population Magnitude, Adverse Consequence Risk

Our city pothole app example

This section exercises

In this section we will explore the Strategic Privacy by Design process. Guided by the model of the product, service or process being developed, with an understanding of the risks to individuals, you can now begin your design and development work.

In this lesson we will discuss about the quality attributes.

System engineers often talk in terms of functional versus nonfunctional requirements (or quality attributes). Functional requirements specify what the system must do. Nonfunctional requirements define how the system should be, such as reliable, consistent, and secure.

In this lesson we will discuss about the next stage in the process - to identify the information necessary to meet the stated purpose. Gürses, Troncoso and Diaz, in their paper “Engineering Privacy by Design Reloaded,” describe this approach as contrasting with the compliance-by-design approach. Compliance by design seems more prone to collecting everything and then winnowing it down by removing any legally prohibited or toxic data. By toxic, I mean data that, while not prohibited, is highly regulated or highly risky, imposing significant burdens on the collector or processor.

Now that the initial-use-case privacy model has been built with the additional layers of domains, subdomains and anticipated information, we can begin looking at the control set to suggest a design that minimizes privacy risks

I’ve assumed within this discussion that we are Trails4u designing this. More complicated systems may involve multiple parties that haven’t always designed their services in a privacy-friendly way

Online behavioral advertising, in which individuals are tracked and profiled for ad targeting, has been a hot topic of late as the technology has grown more pervasive and invasive.

As we’re talking about such a variety of situations in which privacy can be designed in, this section isn’t going be specific to any one methodology but should hopefully guide you in how to insert privacy into any development process.

I’m going to conclude the course by showing that this methodology, does, in fact, meet the principles. Some of the principles map one-to-one onto the controls; some map to other areas of the methodology; some do not. As I stated, I don’t claim the methodology presented in the course is the only way to meet these principles, but it is a way

Last discussion about our pothole app example - under the methodology

Final exercises

Follow the learning plan

Enroll for more content weekly