trialog, atos, trilateral, inria, aup, gradiant, upm, uulm, fraunhofer sit, wit, ku leuven...
TRANSCRIPT
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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)
09/03/2015 Privacy and Security by Design Methodology I 3
PIA
Context
Feared events
Threats (if
needed)
Risks (if needed)
Measures
PEARs
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 4
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
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
D3 Security and Privacy
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Template:Supplier – Input –Process – Output - Customer
09/03/2015 Privacy and Security by Design Methodology I 6
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
709/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-centred UI
design
C Imple-mentation
C1 Privacy implemen-
tation
D Verification
D1 Security and Privacy
static analysis
D2 Security and Privacy
static analysis
D3 Security and Privacy
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
F5 Execute incident
response plan
F6 Security and privacy verification
G Decommis-sion
G7 Execute retirement
plan
H Environment and Infrastructure 5mn
H1 Organisational privacy architecture
H2 Promote privacy awareness
Part 1 Monday (Antonio Kung)Part 2 Tuesday ( Nicolas Notario)
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
809/03/2015
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
A – Analysis
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
D3 Security and Privacy
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Analysis• Two stages
– Preliminary stage: identify• Scope• Scale• Stakeholder and roles
– Principal stage: characterize the system or business process
09/03/2015 Privacy and Security by Design Methodology I 10
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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)
09/03/2015 Privacy and Security by Design Methodology I 11
A Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 12
A Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Methodology Scale Example
09/03/2015 Privacy and Security by Design Methodology I 13
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
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
A Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 15
Component Infrastructure
e.g. wifi protocol
Infrastructuree.g. cloud operating
system
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
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
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
A Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Summary
09/03/2015 Privacy and Security by Design Methodology I 16
Analysis preliminary stage
Suppliers Inputs Process Outputs Customers
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 17
A Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
1809/03/2015
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
A1 – Functional description and high-level privacy analysis
A Analysis
A1 Functional description and high-level privacy analysis
A2 Detailed Privacy Analysis
A3 Privacy Requirements
A4 Legal compliance
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 19
A1 Functional description and high-level privacy analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
A1 Functional description and high-level privacy analysis
A1 Functional description and high-level privacy analysis
Functional description
Inventory description
Criteria for compliance
Initial Privacy Impact Assessment
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
manager)– 5 day work on report by system engineer
reviewed by project manager– 4h meeting (system engineer, project
manager, PSM0)– Minutes freviewed by PSMO
09/03/2015 Privacy and Security by Design Methodology I 21
Component Infrastructure
e.g. wifi protocol
Infrastructuree.g. cloud operating
system
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
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
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
A1 Functional description and high-level privacy analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Summary
09/03/2015 Privacy and Security by Design Methodology I 22
A1 Functional description and high-level privacy analysis
Suppliers Inputs Process Outputs Customers
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
A1 Functional description and high-level privacy analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 23
A1 Functional description and high-level privacy analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
2409/03/2015
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
A2 – Detailed Privacy Analysis
A Analysis
A1 Functional description and high-level privacy analysis
A2 Detailed Privacy Analysis
A3 Privacy Requirements
A4 Legal compliance
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed Privacy Analysis
• 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
09/03/2015 Privacy and Security by Design Methodology I 25
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 26
A2 Detailed Privacy Analysis
A2 Detailed Privacy Analysis
Relevant Artefacts
Personal Data
Privacy and Security Controls
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I 27
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
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 28
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 29
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 30
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Resources Examples
• Lightweight– 4h meeting (system engineer and project
manager)– 2 day work on report by system engineerr– Minutes reviewed by project manager
• Medium– 4h meeting (system engineer and project
manager)– 4 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
manager)– 4 day work on report by system engineer
reviewed by project manager– 4h meeting (system engineer, project manager,
PSM0)– Minutes reviewed by PSMO
09/03/2015 Privacy and Security by Design Methodology I 31
Component Infrastructure
e.g. wifi protocol
Infrastructuree.g. cloud operating
system
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
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
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Summary
09/03/2015 Privacy and Security by Design Methodology I 32
A2 Detailed Privacy Analysis
Suppliers Inputs Process Outputs Customers
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
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 33
A2 Detailed Privacy Analysis
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
3409/03/2015
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
A3 – Privacy Requirements
A Analysis
A1 Functional description and high-level privacy analysis
A2 Detailed Privacy Analysis
A3 Privacy Requirements
A4 Legal compliance
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy Requirements
• 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)
09/03/2015 Privacy and Security by Design Methodology I 35
A3 Privacy Requirements
A3 Privacy requirements
Principles
Guidelines
Privacy controls
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
36
ISO 29100 Principles
09/03/2015
A3 Privacy Requirements
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 …
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
37
PRIPARE Principles 1/2
09/03/2015
A3 Privacy Requirements
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
38
PRIPARE Principles 2/2
09/03/2015
A3 Privacy Requirements
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.
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
From Principle to Guidelines
• Each principle is decomposed into a fixed, mandatory set of guidelines,
• Guidelines provides specific goals identified to meet a principle
09/03/2015 Privacy and Security by Design Methodology I 39
A3 Privacy Requirements
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…
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
From Guidelines to Privacy Controls• Guidelines refined into a set of privacy controls:
technical and organisational measures incorporated into systems and organizations
09/03/2015 Privacy and Security by Design Methodology I 40
A3 Privacy Requirements
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…
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 41
A3 Privacy Requirements
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Resources Examples
• Lightweight– 4h meeting (system engineer and project
manager)– 2 day work on report by system engineerr– Minutes reviewed by project manager
• Medium– 4h meeting (system engineer and project
manager)– 4 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
manager)– 4 day work on report by system engineer
reviewed by project manager– 4h meeting (system engineer, project manager,
PSM0)– Minutes reviewed by PSMO
09/03/2015 Privacy and Security by Design Methodology I 42
Component Infrastructure
e.g. wifi protocol
Infrastructuree.g. cloud operating
system
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
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
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
A3 Privacy Requirements
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Summary
09/03/2015 Privacy and Security by Design Methodology I 43
A2 Detailed Privacy Analysis
Suppliers Inputs Process Outputs Customers
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
A3 Privacy Requirements
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Exercise
• Guidelines• Privacy controls
09/03/2015 Privacy and Security by Design Methodology I 44
A3 Privacy Requirements
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
4509/03/2015
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
A4 – Legal Compliance
A Analysis
A1 Functional description and high-level privacy analysis
A2 Detailed Privacy Analysis
A3 Privacy Requirements
A4 Legal compliance
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 46
A4 Legal compliance
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A4 Resources Examples
• 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
09/03/2015 Privacy and Security by Design Methodology I 47
Component Infrastructure
e.g. wifi protocol
Infrastructuree.g. cloud operating
system
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
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
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
A4 Legal compliance
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Summary
09/03/2015 Privacy and Security by Design Methodology I 48
A2 Detailed Privacy Analysis
Suppliers Inputs Process Outputs Customers
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Exercise
• European legislation• …
09/03/2015 Privacy and Security by Design Methodology I 49
A4 Legal compliance
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
5009/03/2015
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
A5 – Risk Management
A Analysis
A1 Functional description and high-level privacy analysis
A2 Detailed Privacy Analysis
A3 Privacy Requirements
A4 Legal compliance
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 51
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 52
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
STRIDE Security Threats Cheat Sheet
09/03/2015 Privacy and Security by Design Methodology I 53
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
LINDDUN Privacy Threats Cheat Sheet
09/03/2015 Privacy and Security by Design Methodology I 54
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CNIL Viewpoint (Feared Events)
09/03/2015 Privacy and Security by Design Methodology I 55
From CNIL methodology document
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Risk = f(Severity, Likelihood)
09/03/2015 Privacy and Security by Design Methodology I 57
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
• 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
09/03/2015 Privacy and Security by Design Methodology I 58
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
LINDDUN Methodology
09/03/2015 Privacy and Security by Design Methodology I 59
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Step 1: Define Data Flow Diagram
09/03/2015 Privacy and Security by Design Methodology I 60
1. User
2. Attendance
Manager
3. Attendance data
Entity
Process
Data store
Data flow
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Step 2: Map privacy threats to DFD elements
09/03/2015 Privacy and Security by Design Methodology I 61
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Step 3: Identify threats scenarios(e.g. using privacy threat tree patterns)
09/03/2015 Privacy and Security by Design Methodology I 62
From https://people.cs.kuleuven.be/~kim.wuyts/private/ERISE/
A5 Risk management
Attendance data storenot encrypted?
No Access protection?
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Other steps
• Step 4: Assign priorities– E.g. use CNIL formulas
• Step 5: Extract privacy requirements
09/03/2015 Privacy and Security by Design Methodology I 63
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Resources Examples
• 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
09/03/2015 Privacy and Security by Design Methodology I 64
A5 Risk management
Component Infrastructure
e.g. wifi protocol
Infrastructuree.g. cloud operating
system
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
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
TRL 1-3 Research prototype
TRL 4-6Living labproduct
TRL 7-9Marketproduct
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Summary
09/03/2015 Privacy and Security by Design Methodology I 65
Risk Analysis
Suppliers Inputs Process Outputs Customers
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015 Privacy and Security by Design Methodology I 66
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Exercise
• Some privacy threats– Anonymity– Confidentiality of attendance data
• Some security threats– Integrity of data
09/03/2015 Privacy and Security by Design Methodology I 67
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
6809/03/2015
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
B – Design
A Analysis
A1 Functional description and high-level privacy analysis
A2 Detailed Privacy Analysis
A3 Privacy Requirements
A4 Legal compliance
A5 Risk management
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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)
09/03/2015 Privacy and Security by Design Methodology I 69
B Design
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I 70
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I 71
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Operational Service Approach• Example cheat sheet
09/03/2015 Privacy and Security by Design Methodology I 72
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I 73
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I 74
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)
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
That’s all Folks for today
09/03/2015 Privacy and Security by Design Methodology I 76
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy and Security by Design Methodology I
7709/03/2015
Pripare Educational Material by Pripare Project is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.