Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven...

Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven

Privacy and Security by Design Methodology I

1

Privacy-by-design Methodology

Nicolas Notario. AtosAntonio Kung. Trialog

09/03/2015


Privacy-by-Design (PbD)?• Not only related to design

– Thibaud Antignac and Daniel LeMétayer (Inria) used the term Privacy-by-Construction

• We also use the term Privacy and Security by Design (PsBD)– Term discussed during CSP 2014 (www.cspforum.eu/2014)– See blog (http://www.securityengineeringforum.org/blog/show/id/27)

09/03/2015 Privacy and Security by Design Methodology I 2

Four possible definitions of PSbD

A: Approach to System Engineering which takes into account privacy and measures to protect ICT assets during the whole engineering processB: Institutionalisation of the concepts of privacy and security in organisations and integration of these concepts in the design of systemsC: Embedding privacy and security in the technology and system development from the early stages of conceptualisation and design and institutionalizing privacy and security considerations in organisationsD: Applying a set of principles from the design phase of ICT systems in order to mitigate security and privacy concerns guiding designers and implementer decisions throughout the development of the systems

http://www.cspforum.eu/2014

http://www.securityengineeringforum.org/blog/show/id/27

http://www.securityengineeringforum.org/blog/show/id/27


PRIPARE : Integration of disconnected practices

• Ontario IPC PbD principles• Privacy Impact Assessments• Privacy Management Reference

Model (PMRM)• Microsoft Security Development

Lifecycle• Risk management• Privacy Enhancing Architectures• ISO Standards (29100, 29101, 24760,

29140)


PIA

Context

Feared events

Threats (if

needed)

Risks (if needed)

Measures

PEARs


References

• PRIPARE D1.2 deliverable: Privacy and Security-by-design Methodology December 2014– http://pripareproject.eu/wp-content/uploads/

2013/11/PRIPARE_Deliverable_D1.2_draft.pdf




509/03/2015

A Analysis

A1 Functional description and

high-level privacy analysis

A2 Detailed Privacy Analysis

A3 Privacy Requirements

A4 Legal compliance

A5 Risk management

B Design

B1 Privacy enhancing

architecture design (PEAR)

B2 Privacy enhancing detailed design

B3 User-centered UI

design

C Imple-mentation

C1 Privacy implemen-

tation

D Verifica-tion

D1 Accoun-tability

D2 Security and Privacy

static analysis


dynamic analysis

E Release

E1 Create incident

response plan

E2 Create system

retirement plan

E3 Final security and

privacy review

E4 Publish PIA report

F Mainte-nance

F1 Execute incident

response plan

F2 Security and privacy verification

G Decommis-sion

G1 Execute retirement

plan

H Environment and Infrastructure

H1 Organisational privacy architecture

H2 Promote privacy awareness

Several Phases (A to H) – Many Processes


SIPOC Template:Supplier – Input –Process – Output - Customer


Process name

Suppliers Inputs Process Outputs Customers

Who supplies inputs to the process?

What specifications are placed on the inputs?

What does the process consist of

What are the requirements of the consumers?

Who are the true consumers of the outputs of the process?

Tools & Techniques

Methodologies, Practices, Standards, Patterns

Knowledge What is the knowledge needed?

Responsible Stakeholders and roles



709/03/2015

A Analysis





A4 Legal compliance

A5 Risk management

B Design




B3 User-centred UI

design

C Imple-mentation


tation

D Verification


static analysis


static analysis


dynamic analysis

E Release

E1 Create incident

response plan

E2 Create system

retirement plan


privacy review


F Mainte-nance

F5 Execute incident

response plan


G Decommis-sion


plan

H Environment and Infrastructure 5mn



Part 1 Monday (Antonio Kung)Part 2 Tuesday ( Nicolas Notario)



809/03/2015




A – Analysis

A Analysis





A4 Legal compliance

A5 Risk management

B Design




B3 User-centered UI

design

C Imple-mentation


tation

D Verifica-tion

D1 Accoun-tability


static analysis


dynamic analysis

E Release

E1 Create incident

response plan

E2 Create system

retirement plan


privacy review


F Mainte-nance

F1 Execute incident

response plan


G Decommis-sion


plan


Analysis

• The WHAT: characterize the system or business process to be built and to provide a specification of the system attributes– Goals and purpose– Components– Environment and imposed constraints by the

environment– Inputs and outputs– Interrelation between the various components– Stakeholders

• Functional perspective09/03/2015 Privacy and Security by Design Methodology I 9

A Analysis


Analysis• Two stages

– Preliminary stage: identify• Scope• Scale• Stakeholder and roles

– Principal stage: characterize the system or business process


A Analysis

A Analysis

Preliminary stage• Scope• Scale• Stakeholders and

rolesPrincipal stage• A1 Functional

description and high-level privacy analysis

• A2 Detailed Privacy Analysis

• A3 Privacy Requirements

• A4 Legal compliance

• A5 Risk management


Scope

• Depends on following parameters– Application domain

• Smart grid, Internet of things, Surveillance, …

– Legislation• France

– Context• Media awareness, Horror stories• Available initiatives

– Type of value chain– Type of architecture

• Distributed system, Local system…

– Type of system• Application (e.g. a health monitoring system)• Platform (e.g. an data storage system for health data)


A Analysis


Scale (i.e. how much Effort?)

• Depends on following parameters– TRL (Technology Readiness Level)

• TRL 1-3: Research proof of concept• TRL 4-6: Living lab experimentation• TRL 7-9: Market level deployment

– Complexity parameter• Component in a system• Integrated system

– Layer parameter• Application• Platform


A Analysis


Methodology Scale Example


Component Infrastructuree.g. wifi protocol

Infrastructuree.g. cloud operating system

TRL 1-3 Research prototype

TRL 4-6Living labproduct

TRL 7-9Marketproduct

Component in Applicatione.g. a user display

Applicatione.g. a banking application

x1x3

x4 x6x12 x18

x1 x4 x6x3 x12 x18




A Analysis


Stakeholders and Roles

• System engineers: in charge of design and development

• Privacy & security manager & officers : senior executive in charge of privacy and security

• Data protection authorities : independent body• Subjects: persons whose personal data are

collected• Project managers: senior executive in charge of

development• End users: users of the engineered system09/03/2015 Privacy and Security by Design Methodology I 14

A Analysis


A Preliminary stageResources Examples

• Lightweight– 1h meeting with minutes

from system engineer

• Medium– 4h meeting– 4h work on report– 1h review of report with

project manager

• Full– 4h meeting– 2 day work on report– 1h meeting with PSMO


Component Infrastructure

e.g. wifi protocol

Infrastructuree.g. cloud operating

system




Component in Application

e.g. a user display

Applicatione.g. a banking

application

Light

Med

Med Med

Full Full

Light Med Med

Med Full Full




A Analysis


SIPOC Summary


Analysis preliminary stage


Project managers,PSMOs,DPA

Information on project

Determine scope and methodology scale Assess PRIPARE process w.r.t organisation standards and processesDistribution of roles

ScopeMethodology scaleRoles and responsibilities

SystemEngineers, internal and external stakeholders

Tools & Techniques Methodology scale

Knowledge Methodology scale. Business domain of the project, privacy and security risks

Responsible Project manager, PSMO

A Analysis


Exercise

• Scope– Application

• Methodology scale– TRL 4-6. Living lab– Complexity: Medium

• Responsibilities and roles– System engineers: computer science project team– Privacy & security manager & officers : university dean with

the help of university lawer and academic expert on security privacy and trust

– Subjects: students– End users: students, professors, academic administration


A Analysis



1809/03/2015




A1 – Functional description and high-level privacy analysis

A Analysis

A1 Functional description and high-level privacy analysis



A4 Legal compliance

A5 Risk management


A1 Functional description andhigh-level privacy analysis

• Quickly exposes potential privacy risks and the need and scope of following privacy and security by design methodologies

• Based on OASIS/PMRM: http://docs.oasis-open.org/pmrm/PMRM/v1.0/csd01/PMRM-v1.0-csd01.pdf



http://docs.oasis-open.org/pmrm/PMRM/v1.0/csd01/PMRM-v1.0-csd01.pdf




Privacy and Security by Design Methodology I 20

Four main Activities

• Functional description– General description

• Inventory description – Level of granularity consistent with

methodology scale– Examples: Systems and subsystems, Legal

and regulatory jurisdictions, Policies, Personal information

• Criteria for conformance– Based on applicable privacy and security

policies.

• Initial privacy impact assessment– Risk assessment (e.g. simpler version of A4),

privacy maturity assessment, compliance review, accountability model assessment…

09/03/2015



Functional description

Inventory description

Criteria for compliance

Initial Privacy Impact Assessment


A1 Resources Examples• Lightweight

– 2h meeting (system engineer and project manager)

– Minutes reviewed by project manager

• Medium– 4h meeting (system engineer and project

manager)– 2 day work on report by system engineer

reviewed by project manager– 2h meeting (system engineer, project

manager, PSMO)– Minutes reviewed by PSMO

• Full– 1 day meeting (system engineer and project


reviewed by project manager– 4h meeting (system engineer, project

manager, PSM0)– Minutes freviewed by PSMO



e.g. wifi protocol


system





e.g. a user display


application

Light

Med

Med Med

Full Full

Light Med Med

Med Full Full






SIPOC Summary




Project managers,PSMOs

Interviews or workshops with stakeholders

Provide general description of system or business processProvide inventory of capabilities, applications and policy environment under reviewDefine criteria for conformance of a system or business process with applicable privacy and security policyPrepare an initial PIA

Functional descriptionInventoryPrivacy and security policy conformance criteriaPreliminary PIA

System engineers,Project managers,DPA,End users

Tools & Techniques UML, UP, RUP, OUM, user stories, interviews, narrative…

Knowledge System’s domain, applicable legislation

Responsible Project developer



Exercise

• Functional description: evaluation system• Inventory description (level of granularity

consistent with methodology scale):– Tracking system, Evaluation system

• Criteria for conformance with applicable privacy and security policy.

• Initial privacy impact assessment





2409/03/2015




A2 – Detailed Privacy Analysis

A Analysis




A4 Legal compliance

A5 Risk management



• Detailed privacy analysis in order to provide an inventory of personal data, sub-systems, etc. that may be subject to privacy or security risks

• Based on OASIS/PMRM: http://docs.oasis-open.org/pmrm/PMRM/v1.0/csd01/PMRM-v1.0-csd01.pdf







Three main Activities• Identify relevant artefacts

– Stakeholders– Systems– Domains and domain owners– Roles and responsibilities– Touch points and data flows

• Identify personal data• Specify privacy and security

controls




Relevant Artefacts

Personal Data

Privacy and Security Controls



Identify Relevant Artefacts

• Stakeholders– create, manage, interact with, or otherwise subject to personal data– e.g. student, professor, registration…

• System– collection of components organized to accomplish a specific function or set of functions– e.g. registration system

• Domain subject to the control of an owner.– physical areas (e.g. class)– logical areas (e.g. cloud computing environment)

• Roles and responsibilities– assigned to specific participants and systems within a specific privacy domain– e.g. class attendance system

• Data flows– carry personal data and privacy constraints– e.g. from user to course evaluation system

• Touch points– Data flow crossing domains– e.g. from user computer to cloud system

09/03/2015



Identify Personal Data

• Specify personal data– collected, created, communicated, processed or stored

within Privacy Domains or Systems

• Three types– Incoming

• e.g. posting picture in social network

– Internally generated• e.g. user profiling

– Outgoing• e.g. selling data




Privacy and Security (PS) Controls

• Objective: enforce PS policies associated with personal data

• Applies to all types of personal data– Incoming– Internally Generated– Outgoing personal data

• How (cheat sheet)– Consider each data protection and security principles– Identify what can be applied to personal data




Types of PS Controls

• Inherited:– inherited from Privacy Domains or Systems within privacy

domains– A social network provider should inherit consumer policy

preferences

• Internal:– mandated by internal Privacy Domain policies

• External:– those which must be exported to other privacy domains or

to systems within privacy domains– A subcontractor of a social network provider should

import its controls




A2 Resources Examples

• Lightweight– 4h meeting (system engineer and project

manager)– 2 day work on report by system engineerr– Minutes reviewed by project manager



reviewed by project manager– 2h meeting (system engineer, project manager,

PSMO)– Minutes reviewed by PSMO




PSM0)– Minutes reviewed by PSMO



e.g. wifi protocol


system





e.g. a user display


application

Light

Med

Med Med

Full Full

Light Med Med

Med Full Full






SIPOC Summary




Project Manager, Data Protection Authority, PSMOs

Use case description Use case inventory Privacy Policy Conformance CriteriaPreliminary PIA

Identify stakeholders, systems, domains and domain owners, roles and responsibilities, touch Points and data flowsIdentify personal data in Privacy Domains and SystemsSpecify Required Privacy Controls Associated with personal data

Stakeholders , Systems, Domains and Domain Owners, Roles and Responsibilities, Touch Points and Data FlowsPersonal dadaPrivacy Controls

System engineer, Data subjects, DPA

Tools & Techniques UML, UP, RUP, OUM, user stories, interviews, narrative…

Knowledge System’s domain, applicable legislation and good practices

Responsible Project developer



Exercise

• Identify relevant artefacts– Stakeholders– Systems– Domains and domain owners– Roles and responsibilities– Touch points and data flows

• Identify personal data• Specify privacy and security controls





3409/03/2015




A3 – Privacy Requirements

A Analysis




A4 Legal compliance

A5 Risk management



• This phase focuses on privacy requirement operationalisation– map high-level, legal and user

concerns into engineering requirements

• Three steps– Principles (the high level

concerns)– Guidelines (specific goals)– Privacy Controls (resulting

engineering requirements)



A3 Privacy requirements

Principles

Guidelines

Privacy controls



36

ISO 29100 Principles

09/03/2015


Consent and choice Data subject chosses whether or not to allow the processing of personal data …

Purpose legitimacy and specification Purpose(s) complies with applicable law and relies on a permissible legal basis …

Collection limitation Limiting the collection of personal data to that which is within the bounds of applicable law and strictly necessary for the specified purpose…

Data minimization Minimize the personal data which is processed and the number of privacy stakeholders and people to whom personal data is disclosed or who have access to it…

Use, retention and disclosure limitation

Limiting the use, retention and disclosure (including transfer) of personal data to that which is necessary in order to fulfil specific, explicit and legitimate purposes

Accuracy and quality Ensuring that personal data processed is accurate, complete, up-to-date…

Openness, transparency and notice Providing data subjects with clear and easily accessible information about the data controller’s policies, procedures and practices…

Individual participation and access giving data subjects the ability to access and review their personal data…

AccountabilityDocumenting and communicating as appropriate all privacy-related policies, procedures and practices…Informing data subjects about privacy breaches that can lead to substantial damage to them…

Information security Protecting personal data with appropriate controls at the operational, functional and strategic level to ensure the integrity, confidentiality and availability of the personal data

Privacy compliance Verifying and demonstrating that the processing meets data protection and privacy safeguarding requirements by periodically conducting audits …



37

PRIPARE Principles 1/2

09/03/2015


ISO 29100 PRIPARE

2 Purpose legitimacy and specification

3 Purpose specification and limitation (finality or legitimacy),

Legitimacy of processing personal data must be ensured by basing data processing on consent, contract, legal obligation, etc. Personal data must be collected for specified, explicit and legitimate purposes

4 Purpose specification and limitation sensitive data,

1 Consent and choice2 Data minimization and proportionality

Limit the processing data and ensuring data avoidance and minimisation, processing only adequate and relevant personal data;

3 Collection limitation

4 Data minimization

5 Use retention and disclosure limitation 10 Limited conservation and retention

Retention of data should be for the minimum period of time consistent with the purpose of the retention or other legal requirements

6 Accuracy and quality 1 Data qualityQuality of data and transparency need to be ensured. Data should be accurate and kept up to date.

7 Openness, transparency and notice 5 Transparency and openness Compliance with the data subject’s right to

be informed



38

PRIPARE Principles 2/2

09/03/2015


ISO 29100 PRIPARE

8 Individual participation and access

6 Right of access Compliance with the data subject’s right of access, rectification, erasure or blocking of data

7 Right to object Compliance with the data subject’s right to object

12 Right to erasureTaking all reasonable steps to have individuals' data erased, including by third parties without delay, for the personal data that was made public without legal justification.

9 Accountability 11 AccountabilityDemonstrable acknowledgement and assumption of responsibility for having in place appropriate policies and procedures, and promotion of good practices that include correction and remediation for failures and misconduct

10 Information Security

8 Confidentiality and security

Preventing unauthorised access, logging of data processing, network and transport security and preventing accidental loss of data

11 Privacy compliance

9 Compliance with notification requirements

Notification about data processing, prior compliance checking and documentation

13 Privacy and data protection by design

Data protection to be embedded within the entire lifecycle of the technology

14 Privacy and data protection by default.

privacy preferences are automatically set to its most privacy-preserving configuration.


From Principle to Guidelines

• Each principle is decomposed into a fixed, mandatory set of guidelines,

• Guidelines provides specific goals identified to meet a principle



Principle Guideline

1. Data qualityG-1.1. Ensure the quality of personal data collected, created, used, maintained and sharedG-1.2. Ensure data integrity of personal data

2. Data minimization and proportionality

G-2.1 Avoid and minimise the use of personal data along its whole lifecycleG-2.2 Minimise personal data used in pre-production systems:

3…


From Guidelines to Privacy Controls• Guidelines refined into a set of privacy controls:

technical and organisational measures incorporated into systems and organizations



Principle Guideline Privacy control

2. Data minimization and proportionality

G-2.1 Avoid and minimise use of personal data along whole lifecycle

C-2.1.1 When personal data is collected or retained, only allow those authorized and consented by the userC-2.1.2 Periodically evaluate that all the personal data is identified…C-2.1.3 When personal data is no longer needed, delete or anonymise it

C-2.1.4…

G-2.2 Minimise personal data used in pre-production systems

C-2.2.1 When doing testing, training and research: Apply procedures to minimise personal data

C-2.2.2…


PRIPARE Cheat Sheet

• See annex C of PRIPARE D1.2 deliverable: Privacy and Security-by-design Methodology December 2014– http://pripareproject.eu/wp-content/uploads/

2013/11/PRIPARE_Deliverable_D1.2_draft.pdf





• Lightweight– 4h meeting (system engineer and project

manager)– 2 day work on report by system engineerr– Minutes reviewed by project manager




PSMO)– Minutes reviewed by PSMO




PSM0)– Minutes reviewed by PSMO



e.g. wifi protocol


system





e.g. a user display


application

Light

Med

Med Med

Full Full

Light Med Med

Med Full Full






SIPOC Summary




Project Manager.Data Protection Authority.PSMOs.Business & System analysts.

Functional description of the system.Stakeholders, Systems, Domains and Domain owners, Roles and Responsibilities, Touch Points and Data Flows. Privacy principles.

Identify principles and guidelines.Determine applicability of privacy controls.

Stakeholders, Systems, Domains and Domain Owners, Roles and Responsibilities, Touch Points and Data Flows.Personal data.Privacy Controls.

System designer.Project managers.

Tools & Techniques Family of guidelines and privacy controls

Knowledge Guidelines, privacy controls, and mapping from principles to those.

Responsible Business & System analysts



Exercise

• Guidelines• Privacy controls





4509/03/2015




A4 – Legal Compliance

A Analysis




A4 Legal compliance

A5 Risk management


A4 Legal Compliance

• Checks whether proposed system or business process complies with legislation.

• Requires an analysis of the project and the information flows and potential risks

• Measures whether the project or technology is compliant with privacy principles in relevant data protection legislation


A4 Legal compliance



• Lightweight– 1h meeting (project manager and PSMO)– Minutes provided by PSMO

• Medium– 1h meeting (project manager and PSMO)– 4h meeting (system engineer and project

manager)– Report written by project manager– 1h meeting (project manager and PSMO)– Minutes provided by PSMO

• Full– 1h meeting (system engineer, project

manager and PSMO)– 2 day work(system engineer)– PIA Report provided by system engineer– 4h meeting (system engineer and project

manager)– 1h meeting (project manager and PSMO)– Minutes provided by PSMO



e.g. wifi protocol


system





e.g. a user display


application

Light

Med

Med Med

Full Full

Light Med Med

Med Full Full




A4 Legal compliance


SIPOC Summary




Project managers,legal staff,PSMOs/Data protection authorities

Project descriptionRelevant legislationSoft law

Analysing the project to make sure it is compliant, including ‘soft law’ e.g. EDPS and Article 29

Compliance analysisProject manager, system engineer

Tools & Techniques Privacy principle checklist/table threats, vulnerabilities, risks & solutions

Knowledge Knowledge and understanding of relevant privacy legislation, Article 29 opinions, EDPS opinions, national legislation

Responsible Project manager supported by legal staff

A4 Legal compliance


Exercise

• European legislation• …


A4 Legal compliance



5009/03/2015




A5 – Risk Management

A Analysis




A4 Legal compliance

A5 Risk management


Risk management

• Risk management is the identification, assessment, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives)

• A generic process– identify, characterize threats– assess the vulnerability of critical assets to specific threats– determine the risk (i.e. the expected likelihood and

consequences of specific types of attacks on specific assets)– identify ways to reduce those risks– prioritize risk reduction measures based on a strategy


A5 Risk management


Risk management

• There are many risk management processes and standards– ICT security risk: confidential business data is revealed

• EBIOS, TVRA…

– Disaster risks: a tsunami threatens a powerplant• Bow-tie…

– Privacy risk: picture of user is made public• CNIL, LINDDUN

• They use the same generic process but– Use different knowledge references or cheat sheets (e.g.

STRIDE, LINDDUN…)– Take different viewpoint: threat viewpoint, feared viewpoint


A5 Risk management


STRIDE Security Threats Cheat Sheet


Property Description Threat

AuthenticationThe identity of users is established (or you’re willing to accept anonymous users).

Spoofing

IntegrityData and system resources are only changed in appropriate ways by appropriate people.

Tampering

NonrepudiationUsers can’t perform an action and later deny performing it. Repudiation

ConfidentialityData is only available to the people intended to access it. Information disclosure

AvailabilitySystems are ready when needed and perform acceptably. Denial Of Service

AuthorizationUsers are explicitly allowed or denied access to resources. Elevation of privilege

A5 Risk management


LINDDUN Privacy Threats Cheat Sheet


Type Property Description Threat

Hard privacy

UnlinkabilityHiding the link between two or more actions, identities, and pieces of information. Linkability

AnonymityHiding the link between an identity and an action or a piece of information Identifiability

Plausible deniabilityAbility to deny having performed an action that other parties can neither confirm nor contradict

Non-repudiation

Undetectability and unobservability

Hiding the user’s actvities Detectability

Security ConfidentialityHiding the datacontent or controlled release of data content

Disclosure of information

Soft Privacy

Content awareness User’s consciousness regarding his own data Unawareness

Policy and consent compliance

Data controller to inform the data subject about the system’s privacy policy, or allow the data subject to specify consents in compliance with legislation

Non compliance

A5 Risk management


CNIL Viewpoint (Feared Events)


From CNIL methodology document

A5 Risk management



56

CNIL Risk Analysis

• For each feared event– LI: Level of identification

• Negligible = 1• Limited = 2• Significant = 3• Maximum = 4

– PE: Prejudicial effect• Negligible = 1• Limited = 2• Significant = 3• Maximum = 4

– LI+PE: Severity• Negligible < 5• Limited = 5• Significant = 6• Maximum > 6

• For each threat– AV: Asset vulnerability

• Negligible = 1• Limited = 2• Significant = 3• Maximum = 4

– CE: Capability to exploit• Negligible = 1• Limited = 2• Significant = 3• Maximum = 4

– AV+CE: Likelihood• Negligible < 5• Limited = 5• Significant = 6• Maximum > 6

09/03/2015

A5 Risk management


Risk = f(Severity, Likelihood)


Absolutely avoided or

reduced

Must be avoided or

reduced

Must bereduced

These risks may be taken

NegligibleLikelihood

LimitedLikelihood

SignificantLikelihood

Maximum Likelihood

NegligibleSeverity

LimitedSeverity

SignificantSeverity

MaximumSeverity

A5 Risk management


• Feared event: Alice attendance is made public – Level of identification

• Maximum = 4

– Prejudicial effect• Significant = 3

– Severity• Maximum = 7

• Threat: Some one hacks into the attendance management system and retrieves the log of attendance– Asset vulnerability

• Significant = 3

– Capacity to exploit• Significant = 3

– Likelihood• Significant = 6

Example


Absolutely avoided or

reduced

Must be avoided or

reduced

Must bereduced

These risks may be taken

NegligibleLikelihood

LimitedLikelihood

SignificantLikelihood

Maximum Likelihood

NegligibleSeverity

LimitedSeverity

SignificantSeverity

MaximumSeverity

A5 Risk management


LINDDUN Methodology


1 Define Data Flow Diagram

2 Map privacy

threats to DFD

elements

3 Identify threat

scenarios

4 Threat prioritisati

on

5 Extract privacy

requirements

Select correspond

ing PETS

A5 Risk management


Step 1: Define Data Flow Diagram


1. User

2. Attendance

Manager

3. Attendance data

Entity

Process

Data store

Data flow

A5 Risk management


Step 2: Map privacy threats to DFD elements


A5 Risk management

Threat Target L I N D D U N

Data store

Attendance data x x x x x x

Data flow

User data stream x x x x x X

Data base data stream x x x x x X

Process Attendance manager x x x x x X

Entity Userx x x


Step 3: Identify threats scenarios(e.g. using privacy threat tree patterns)


From https://people.cs.kuleuven.be/~kim.wuyts/private/ERISE/

A5 Risk management

Attendance data storenot encrypted?

No Access protection?


Other steps

• Step 4: Assign priorities– E.g. use CNIL formulas

• Step 5: Extract privacy requirements


From LINDUN tutorial

A5 Risk management

Threats (misuse cases)

Caused by (leaf nodes)

Mitigated by (requirements)

Attempting access to attendance data

Data is intelligible because it is not encrypted

Encryption

No protection for access

Password based access



• Lightweight– 2 day work– Review by project manager

• Medium– 2 week work– In-depth review by project

manager– Review by PSMO

• Full– 2 month effort– Several reviews by project

manager – In-depth review by PSMO


A5 Risk management


e.g. wifi protocol


system





e.g. a user display


application

Light

Med

Med Med

Full Full

Light Med Med

Med Full Full





SIPOC Summary


Risk Analysis


Project managers,PSMOs,DPA

ContextAssets at stake

Step 1: identify feared eventsStep 2: identify threatsStep 3: identify risksStep 4: identify measures

Feared eventsFeared threatsInitial risksPrivacy & Securitycontrols (measures)Remaining risks

SystemdeveloperPSMOsSystemowner

Tools & Techniques

CNIL ReferenceLINDDUN Reference

Knowledge Risk analysis methodologies, privacy threats

Responsible Privacy expert

54 Risk management


References

• CNIL (French data protection agency - 2012)– http://www.cnil.fr/fileadmin/documents/en/CNIL-

ManagingPrivacyRisks-Methodology.pdf

• LINDDUN (PhD work from Kim Wuyts – Jan 2015)– https://people.cs.kuleuven.be/~kim.wuyts/

LINDDUN/LINDDUN.pdf


A5 Risk management


Exercise

• Some privacy threats– Anonymity– Confidentiality of attendance data

• Some security threats– Integrity of data


A5 Risk management



6809/03/2015




B – Design

A Analysis




A4 Legal compliance

A5 Risk management


Design

• The HOW– a plan or drawing produced to show the look and

function or workings of a building, garment, or other object before it is made (Oxford dictionary)

– process of defining the hardware and software architecture, components, modules, interfaces, and data for a system to satisfy specified requirements (http://en.wikipedia.org/wiki/Systems_design)


B Design

http://en.wikipedia.org/wiki/Systems_design

http://en.wikipedia.org/wiki/Systems_design



Design Process• Two phases

– Architecture• Structure and behavior of system• Global viewpoint

– Detailed Design:• Techniques used• Local viewpoint

09/03/2015

B Design

B1 Privacy Enhancing Architectures

B2 Privacy Enhancing Detailed Design

B Design



How to Structure Process• Need for smaller grains of concern• Operational service approach

– Privacy concerns categorised into services– For each service figure out technical

solutions– Example : PMRM

• Strategy approach– Privacy concerns categorised into strategies– For each strategy figure out technical

solutions– Examples

• Antonio Kung. PEARs: Privacy Enhancing ARchitectures. In Privacy Technologies and Policy – Second Annual Privacy Forum, APF 2014, Athens, Greece, May 20-21, 2014. Proceedings, pages 18–29, 2014

• Jaap-Henk Hoepman. Privacy design strategies. In ICT Systems Security and Privacy Protection - 29th IFIP TC 11 International Conference, SEC 2014, Marrakech, Morocco, June 2-4, 2014. Proceedings, pages 446–459, 2014

09/03/2015

Design Approach

Operational Services (e.g. PMRM, Pripare)

Strategies (e.g. Kung, Hoepman)

B Design


Operational Service Approach• Example cheat sheet


B Design

Service Purpose

From OASIS PMRM

Agreement Management of permissions and rulesUsage Controlling personal data usageValidation Checking personal dataCertification Checking stakeholders credentialsEnforcement Monitor operations and react to exceptionsSecurity Safeguard privacy information and operationsInteraction Information presentation and communicationAccess Data subject access to their personal data

From PRIPARE Accountability Log and audit management



Strategy Approach

• Example cheat sheet (Kung)

09/03/2015

B Design

Strategy Tactics Examples

1 MinimizationCollection of personal information should be kept to a strict minimum

• Anonymize credentials (e.g. Direct anonymous attestation)

• Limit processing perimeter (e.g. client processing, P2P processing)

2 Enforcement Provide maximum protection of personal data during operation

• Enforce data protection policies (collection, access and usage, collection, retention)

• Protect processing (e.g. storage, communication, execution, resources)

3 Transparency and accountability

Maximum transparency provided to stakeholders on the way privacy preservation is ensured

• Log data transaction• Log modifications (policies, crypto, protection)• Protect log data

4 Modifiability Cope with evolution needs• Change Policy• Change Crypto Strength and method• Change Protection Strength



Strategy Approach

• Example cheat sheet (Hoepman)

09/03/2015

B Design

Strategy Patterns Examples

1 Minimization Amount of processed personal data restricted to the minimal amount possible

• select before you collect • anonymisation / pseudonyms

2 Hide Personal data, and their interrelationships, hidden from plain view

• Storage and transit encryption of data• mix networks• hide traffic patterns• attribute based credentials• anonymisation / pseudonyms

3 Separate Personal data processed in a distributed fashion, in separate compartments whenever possible • Not known

4 AggregatePersonal data processed at highest level of aggregation and with least possible detail in which it is (still) useful

• aggregation over time (used in smart metering)• dynamic location granularity (used in location based services)• k-anonymity• differential privacy

5 Inform Transparency • platform for privacy preferrences• Data breach notification

6 Control Data subjects provided agency over the processing of their personal data

• User centric identity management• End-to-end encryption support control

7 Enforce Privacy policy compatible with legal requirements to be enforced

• Access control• Sticky policies and privacy rights management

8 Demonstrate Demonstrate compliance with privacy policy and any applicable legal requirements

• privacy management systems• use of logging and auditing

• Example cheat sheet (Hoepman)



75

Comparing Kung and Hoepman

09/03/2015

B Design

Hoepman Kung

1 Minimization 1 Minimization

2 Hide 2 Enforcement

3 Separate 1 Minimization

4 Aggregate 1 Minimization

5 Inform 3 Transparency and accountability

6 Control 3 Transparency and accountability

7 Enforce 2 Enforcement

8 Demonstrate 3 Transparency and accountability

Kung Hoepman

1 Minimization1 Minimization3 Separate4 Aggregate

2 Enforcement 2 Hide7 Enforce

3 Transparency and accountability

5 Inform6 Control7 Demonstrate

4 Modifiability


That’s all Folks for today




7709/03/2015

Pripare Educational Material by Pripare Project is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.

http://pripareproject.eu/

http://creativecommons.org/licenses/by-nd/4.0/

http://creativecommons.org/licenses/by-nd/4.0/

Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven...

Documents

Transcript of Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven...