Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy-by-design Methodology
Nicolas Notario. Atos
Antonio Kung. Trialog
09/03/2015
Privacy and Security by Design
Methodology I
1
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)
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 process
B: Institutionalisation of the concepts of privacy and security in organisations and
integration of these concepts in the design of systems
C: 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 organisations
D: 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
09/03/2015
Privacy and Security by Design Methodology I
2
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)
Measures
Context
Risks (if
needed)
Feared
events
Threats
(if
needed)
09/03/2015
Privacy and Security by Design Methodology I
3
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
References
• PRIPARE D1.2 deliverable: Privacy and Securityby-design Methodology December 2014
– http://pripareproject.eu/wpcontent/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
Several Phases (A to H) – Many Processes
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
5
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
SIPOC Template:
Supplier – Input –Process – Output - Customer
Process name
Suppliers
Inputs
Who supplies What
inputs to the specifications
process?
are placed on
the inputs?
Process
Outputs
What does the process
What are the
consist of
requirements of
the consumers?
Customers
Who are
the true
consumers
of the
outputs of
the
process?
Tools
& Methodologies, Practices, Standards, Patterns
Techniques
Knowledge
What is the knowledge needed?
Responsible
Stakeholders and roles
09/03/2015
Privacy and Security by Design
Methodology I
6
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Part 1 Monday (Antonio Kung)
Part 2 Tuesday ( Nicolas Notario)
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
D Verification
C1 Privacy
implementation
E Release
F Maintenance
D1 Security
and Privacy
static analysis
E1 Create
incident
response plan
F5 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F6 Security
and privacy
verification
B3 Usercentred UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G7 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure 5mn
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
7
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A – Analysis
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
8
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A Analysis
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 perspective
09/03/2015
Privacy and Security by Design Methodology I
9
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A Analysis
• Two stages
Analysis
– Preliminary stage: identify
• Scope
• Scale
• Stakeholder and roles
– Principal stage: characterize
the system or business
process
A Analysis
Preliminary stage
• Scope
• Scale
• Stakeholders and roles
Principal stage
• A1 Functional description and
high-level privacy analysis
• A2 Detailed Privacy Analysis
• A3 Privacy Requirements
• A4 Legal compliance
• A5 Risk management
09/03/2015
Privacy and Security by Design Methodology I
10
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Scope
A Analysis
• 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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015
Privacy and Security by Design Methodology I
12
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A Analysis
Methodology Scale Example
Application
e.g. a banking application
Component in Application
e.g. a user display
Infrastructure
e.g. cloud operating system
Component Infrastructure
e.g. wifi protocol
09/03/2015
x3
x1
x12
x4
x18
x6
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
x3
x1
x12
x4
x18
x6
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
Privacy and Security by Design
Methodology I
13
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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 system
09/03/2015
Privacy and Security by Design Methodology I
14
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A Analysis
A Preliminary stage
Resources 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
Application
e.g. a banking
application
Med
Full
Full
Component in
Application
e.g. a user display
Light
Med
Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
Med Full
Full
Infrastructure
e.g. cloud operating
system
Component
Infrastructure
e.g. wifi protocol
Privacy and Security by Design
Methodology I
Light Med Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
15
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A Analysis
SIPOC Summary
Analysis preliminary stage
Suppliers
Inputs
Process
Outputs
Customers
Project
managers,
PSMOs,
DPA
Determine scope and
methodology scale
Assess PRIPARE process
Information w.r.t organisation
on project standards and
processes
Distribution of roles
Tools &
Techniques
Methodology scale
Knowledge
Methodology scale. Business domain of the project, privacy and security
risks
Responsible
Project manager, PSMO
09/03/2015
Scope
Methodology scale
Roles and
responsibilities
Privacy and Security by Design
Methodology I
System
Engineers,
internal and
external
stakeholders
16
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Exercise
A Analysis
• 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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A1 – Functional description and high-level privacy analysis
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
18
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A1 Functional
description and highlevel privacy analysis
A1 Functional description and
high-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.oasisopen.org/pmrm/PMRM/v1.0/csd01/PMRM-v1.0csd01.pdf
09/03/2015
Privacy and Security by Design Methodology I
19
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A1 Functional
description and highlevel privacy analysis
Four main Activities
• Functional description
– General description
• Inventory description
A1 Functional
description and highlevel privacy analysis
– 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
Privacy and Security by Design Methodology I
Functional description
Inventory description
Criteria for compliance
Initial Privacy Impact
Assessment
20
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A1 Functional
description and highlevel privacy analysis
•
Lightweight
–
–
•
2h meeting (system engineer and project
manager)
Minutes reviewed by project manager
Medium
–
–
–
–
•
A1 Resources Examples
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
Application
e.g. a banking
application
Med
Full
Full
Component in
Application
e.g. a user display
Light
Med
Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
Med Full
Full
Infrastructure
e.g. cloud operating
system
Component
Infrastructure
e.g. wifi protocol
Privacy and Security by Design
Methodology I
Light Med Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
21
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A1 Functional
description and highlevel privacy analysis
SIPOC Summary
A1 Functional description and high-level privacy analysis
Suppliers
Inputs
Process
Outputs
Project
managers,
PSMOs
Provide general description of
system or business process
Provide inventory of capabilities,
applications and policy environment
Interviews or
under review
workshops with
Define criteria for conformance of a
stakeholders
system or business process with
applicable privacy and security
policy
Prepare an initial PIA
Tools &
Techniques
UML, UP, RUP, OUM, user stories, interviews, narrative…
Knowledge
System’s domain, applicable legislation
Functional
description
Inventory
Privacy and
security policy
conformance
criteria
Preliminary PIA
Customers
System
engineers,
Project
managers,
DPA,
End users
Responsible Project developer
09/03/2015
Privacy and Security by Design
Methodology I
22
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A1 Functional
description and highlevel privacy analysis
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 – Detailed Privacy Analysis
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
24
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
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.oasisopen.org/pmrm/PMRM/v1.0/csd01/PMRM-v1.0csd01.pdf
09/03/2015
Privacy and Security by Design Methodology I
25
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
Three main Activities
• Identify relevant artefacts
–
–
–
–
–
Stakeholders
Systems
Domains and domain owners
Roles and responsibilities
Touch points and data flows
A2 Detailed
Privacy Analysis
• Identify personal data
• Specify privacy and security
controls
09/03/2015
Privacy and Security by Design Methodology I
Relevant Artefacts
Personal Data
Privacy and Security Controls
26
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
•
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
Privacy and Security by Design Methodology I
27
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
•
Lightweight
–
–
–
•
4h meeting (system engineer and project
manager)
2 day work on report by system engineerr
Minutes reviewed by project manager
Medium
–
–
–
–
•
A2 Resources Examples
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
–
–
–
–
09/03/2015
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
Application
e.g. a banking
application
Med
Full
Full
Component in
Application
e.g. a user display
Light
Med
Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
Med Full
Full
Infrastructure
e.g. cloud operating
system
Component
Infrastructure
e.g. wifi protocol
Privacy and Security by Design
Methodology I
Light Med Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
31
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
SIPOC Summary
A2 Detailed Privacy Analysis
Suppliers
Inputs
Process
Outputs
Stakeholders ,
Systems,
Domains and
Domain Owners,
Roles and
Responsibilities,
Touch Points and
Data Flows
Personal dada
Privacy Controls
Project
Manager,
Data
Protection
Authority,
PSMOs
Use case
description
Use case
inventory
Privacy Policy
Conformance
Criteria
Preliminary PIA
Tools &
Techniques
UML, UP, RUP, OUM, user stories, interviews, narrative…
Knowledge
System’s domain, applicable legislation and good practices
Identify stakeholders, systems,
domains and domain owners, roles
and responsibilities, touch Points
and data flows
Identify personal data in Privacy
Domains and Systems
Specify Required Privacy Controls
Associated with personal data
Customers
System
engineer,
Data
subjects,
DPA
Responsible Project developer
09/03/2015
Privacy and Security by Design
Methodology I
32
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A2 Detailed
Privacy Analysis
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 – Privacy Requirements
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
34
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
A3 Privacy Requirements
• This phase focuses on
privacy requirement
operationalisation
– map high-level, legal and user
concerns into engineering
requirements
A3 Privacy
requirements
Principles
• 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
Guidelines
Privacy controls
35
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
ISO 29100 Principles
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…
Accountability
Documenting 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 …
09/03/2015
Privacy and Security by Design
Methodology I
36
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
ISO 29100
2 Purpose legitimacy and
specification
PRIPARE Principles 1/2
PRIPARE
3 Purpose specification and limitation
(finality or legitimacy),
4 Purpose specification and limitation
sensitive data,
1 Consent and choice
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
2 Data minimization and
proportionality
Limit the processing data and ensuring data
avoidance and minimisation, processing
only adequate and relevant personal data;
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 quality
Quality 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
3 Collection limitation
4 Data minimization
5 Use retention and
disclosure limitation
09/03/2015
Privacy and Security by Design
Methodology I
37
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
ISO 29100
PRIPARE Principles 2/2
PRIPARE
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 erasure
Taking 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 Accountability
Demonstrable 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
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 privacypreserving configuration.
8 Individual
participation and
access
11 Privacy compliance
09/03/2015
Privacy and Security by Design
Methodology I
38
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
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 quality
G-1.1. Ensure the quality of personal data collected,
created, used, maintained and shared
G-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 lifecycle
G-2.2 Minimise personal data used in pre-production
systems:
3…
09/03/2015
Privacy and Security by Design Methodology I
39
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
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
C-2.1.1 When personal data is collected or retained,
only allow those authorized and consented by the user
2. Data
minimization
and
proportionality
G-2.1 Avoid and
minimise use of
personal data along
whole lifecycle
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
09/03/2015
C-2.1.2 Periodically evaluate that all the personal data
is identified…
C-2.2.1 When doing testing, training and research:
Apply procedures to minimise personal data
C-2.2.2…
Privacy and Security by Design Methodology I
40
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
PRIPARE Cheat Sheet
• See annex C of PRIPARE D1.2 deliverable: Privacy
and Security-by-design Methodology December
2014
– http://pripareproject.eu/wpcontent/uploads/2013/11/PRIPARE_Deliverable_D1.2_
draft.pdf
09/03/2015
Privacy and Security by Design Methodology I
41
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Resources Examples
A3 Privacy
Requirements
•
Lightweight
–
–
–
•
Medium
–
–
–
–
•
4h meeting (system engineer and project
manager)
2 day work on report by system engineerr
Minutes reviewed by project manager
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
–
–
–
–
09/03/2015
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
Application
e.g. a banking
application
Med
Full
Full
Component in
Application
e.g. a user display
Light
Med
Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
Med Full
Full
Infrastructure
e.g. cloud operating
system
Component
Infrastructure
e.g. wifi protocol
Privacy and Security by Design
Methodology I
Light Med Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
42
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A3 Privacy
Requirements
SIPOC Summary
A2 Detailed Privacy Analysis
Suppliers
Project
Manager.
Data
Protection
Authority.
PSMOs.
Business &
System
analysts.
Tools &
Techniques
Knowledge
Inputs
Functional description
of the system.
Stakeholders, Systems,
Domains and Domain
owners, Roles and
Responsibilities, Touch
Points and Data Flows.
Privacy principles.
Process
Outputs
Stakeholders, Systems,
Domains and Domain
Identify principles and Owners, Roles and
guidelines.
Responsibilities, Touch
Determine applicability Points and Data Flows.
of privacy controls.
Personal data.
Privacy Controls.
Customer
s
System
designer.
Project
managers.
Family of guidelines and privacy controls
Guidelines, privacy controls, and mapping from principles to those.
Responsible Business & System analysts
09/03/2015
Privacy and Security by Design
Methodology I
43
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Exercise
A3 Privacy
Requirements
• Guidelines
• Privacy controls
09/03/2015
Privacy and Security by Design Methodology I
44
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A4 – Legal Compliance
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
45
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A4 Legal
compliance
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A4 Legal
compliance
•
Lightweight
–
–
•
1h meeting (project manager and PSMO)
Minutes provided by PSMO
Medium
–
–
–
–
–
•
A4 Resources Examples
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
Application
e.g. a banking
application
Med
Full
Full
Component in
Application
e.g. a user display
Light
Med
Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
Med Full
Full
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
Infrastructure
e.g. cloud operating
system
Component
Infrastructure
e.g. wifi protocol
Light Med Med
TRL 1-3
Research
prototype
09/03/2015
Privacy and Security by Design
Methodology I
TRL 4-6
Living lab
product
TRL 7-9
Market
product
47
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A4 Legal
compliance
SIPOC Summary
A2 Detailed Privacy Analysis
Suppliers
Inputs
Project
managers,
Project description
legal staff,
Relevant legislation
PSMOs/Dat
Soft law
a protection
authorities
Process
Outputs
Analysing the project
to make sure it is
compliant, including
Compliance analysis
‘soft law’ e.g. EDPS and
Article 29
Customer
s
Project
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
09/03/2015
Privacy and Security by Design
Methodology I
48
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A4 Legal
compliance
Exercise
• European legislation
• …
09/03/2015
Privacy and Security by Design Methodology I
49
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 – Risk Management
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
50
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015
Privacy and Security by Design Methodology I
51
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
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
09/03/2015
Privacy and Security by Design Methodology I
52
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
STRIDE Security Threats Cheat Sheet
Property
Threat
The identity of users is
established (or you’re willing to
accept anonymous users).
Spoofing
Data and system resources are
only changed in appropriate ways
by appropriate people.
Tampering
Nonrepudiation
Users can’t perform an action
and later deny performing it.
Repudiation
Confidentiality
Data is only available to the
people intended to access it.
Information disclosure
Systems are ready when needed
and perform acceptably.
Denial Of Service
Users are explicitly allowed or
denied access to resources.
Elevation of privilege
Authentication
Integrity
Availability
Authorization
09/03/2015
Description
Privacy and Security by Design Methodology I
53
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
LINDDUN Privacy Threats Cheat Sheet
Type
Property
Description
Unlinkability
Anonymity
Hard privacy
Plausible deniability
Hiding the link between two or more actions,
identities, and pieces of information.
Linkability
Hiding the link between an identity and an
action or a piece of information
Identifiability
N
Ability to deny having performed an action that
onother parties can neither confirm nor contradict repudiation
Undetectability and
Hiding the user’s actvities
unobservability
Security
Confidentiality
Hiding the data
content or controlled release of data content
Content awareness User’s consciousness regarding his own data
Soft Privacy
09/03/2015
Threat
Detectability
Disclosure of
information
Unawareness
Data controller to inform the data subject about
Policy and consent the system’s privacy policy, or allow the data
on
compliance
subject to specify consents in compliance with compliance
legislation
N
Privacy and Security by Design Methodology I
54
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
CNIL Viewpoint (Feared Events)
From CNIL methodology document
09/03/2015
Privacy and Security by Design
Methodology I
55
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
CNIL Risk Analysis
• For each feared event
– LI: Level of identification
•
•
•
•
09/03/2015
•
•
•
•
Negligible = 1
Limited = 2
Significant = 3
Maximum = 4
– CE: Capability to exploit
Negligible = 1
Limited = 2
Significant = 3
Maximum = 4
– LI+PE: Severity
•
•
•
•
– AV: Asset vulnerability
Negligible = 1
Limited = 2
Significant = 3
Maximum = 4
– PE: Prejudicial effect
•
•
•
•
• For each threat
•
•
•
•
Negligible = 1
Limited = 2
Significant = 3
Maximum = 4
– AV+CE: Likelihood
Negligible < 5
Limited = 5
Significant = 6
Maximum > 6
•
•
•
•
Privacy and Security by Design
Methodology I
Negligible < 5
Limited = 5
Significant = 6
Maximum > 6
56
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
Risk = f(Severity, Likelihood)
Maximum
Severity
Significant
Severity
Must be
avoided or
reduced
Absolutely
avoided or
reduced
These risks may
be taken
Must be
reduced
Limited
Severity
Negligible
Severity
Negligible
Likelihood
09/03/2015
Limited
Likelihood
Significant
Likelihood
Privacy and Security by Design
Methodology I
Maximum
Likelihood
57
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
Example
• Feared event: Alice
attendance is made public
– Level of identification
• Maximum = 4
Maximum
Severity
Must be
avoided or
reduced
– Prejudicial effect
• Significant = 3
Significant
Severity
– Severity
Absolutely
avoided or
reduced
• 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
09/03/2015
Limited
Severity
Negligible
Severity
These risks may
be taken
Negligible
Likelihood
Privacy and Security by Design
Methodology I
Limited
Likelihood
Must be
reduced
Significant
Likelihood
Maximum
Likelihood
58
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
1 Define
Data Flow
Diagram
09/03/2015
LINDDUN Methodology
2 Map
privacy
threats to
DFD
elements
3 Identify
threat
scenarios
4 Threat
prioritisation
Privacy and Security by Design
Methodology I
5 Extract
privacy
requirements
Select
corresponding
PETS
59
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
Step 1: Define Data Flow Diagram
1. User
Entity
2.
Attendance
Manager
Process
Data store
Data flow
3. Attendance
data
09/03/2015
Privacy and Security by Design
Methodology I
60
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
Step 2: Map privacy threats to DFD elements
Threat Target
L
I
N
D
D
Attendance
data
x
x
x
x
x
x
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
User
x
x
Data
store
Data
flow
09/03/2015
Privacy and Security by Design
Methodology I
U
N
x
61
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
Step 3: Identify threats scenarios
(e.g. using privacy threat tree patterns)
No Access protection?
Attendance data store
not encrypted?
From https://people.cs.kuleuven.be/~kim.wuyts/private/ERISE/
09/03/2015
Privacy and Security by Design
Methodology I
62
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
Other steps
• Step 4: Assign priorities
– E.g. use CNIL formulas
• Step 5: Extract privacy requirements
Threats (misuse
cases)
Attempting access
to attendance data
Caused by (leaf
nodes)
Mitigated by
(requirements)
Data is intelligible
because it is not
encrypted
Encryption
No protection for
access
Password based
access
From LINDUN tutorial
09/03/2015
Privacy and Security by Design Methodology I
63
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
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
Application
e.g. a banking
application
Med
Full
Full
Component in
Application
e.g. a user display
Light
Med
Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
Med Full
Full
Infrastructure
e.g. cloud operating
system
Component
Infrastructure
e.g. wifi protocol
Privacy and Security by Design
Methodology I
Light Med Med
TRL 1-3
Research
prototype
TRL 4-6
Living lab
product
TRL 7-9
Market
product
64
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
54 Risk
management
SIPOC Summary
Risk Analysis
Suppliers
Project
managers,
PSMOs,
DPA
Inputs
Context
Assets at
stake
Process
Step 1: identify feared
events
Step 2: identify threats
Step 3: identify risks
Step 4: identify
measures
Outputs
Feared events
Feared threats
Initial risks
Privacy & Security
controls (measures)
Remaining risks
Knowledge
CNIL Reference
LINDDUN Reference
Risk analysis methodologies, privacy threats
Responsible
Privacy expert
Tools &
Techniques
09/03/2015
Privacy and Security by Design
Methodology I
Customers
System
developer
PSMOs
System
owner
65
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
References
• CNIL (French data protection agency - 2012)
– http://www.cnil.fr/fileadmin/documents/en/CNILManagingPrivacyRisks-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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
A5 Risk
management
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B – Design
A Analysis
B Design
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
A2 Detailed
Privacy Analysis
A3 Privacy
Requirements
C Implementation
C1 Privacy
implementation
D Verification
E Release
F Maintenance
D1 Accountability
E1 Create
incident
response plan
F1 Execute
incident
response plan
B2 Privacy
enhancing
detailed
design
D2 Security
and Privacy
static analysis
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
B3 Usercentered UI
design
D3 Security
and Privacy
dynamic
analysis
E3 Final
security and
privacy
review
A4 Legal
compliance
G Decommission
G1 Execute
retirement
plan
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
09/03/2015
Privacy and Security by Design
Methodology I
68
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B Design
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
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B Design
• Two phases
Design Process
B Design
– Architecture
• Structure and behavior of system
• Global viewpoint
– Detailed Design:
• Techniques used
• Local viewpoint
B1 Privacy
Enhancing
Architectures
B2 Privacy
Enhancing
Detailed Design
09/03/2015
Privacy and Security by Design Methodology I
70
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
How to Structure Process
B Design
• 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
•
•
09/03/2015
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
Privacy and Security by Design Methodology I
Design
Approach
Operational
Services (e.g.
PMRM, Pripare)
Strategies (e.g.
Kung, Hoepman)
71
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B Design
Operational Service Approach
• Example cheat sheet
From OASIS
PMRM
From PRIPARE
09/03/2015
Service
Purpose
Agreement
Management of permissions and rules
Usage
Controlling personal data usage
Validation
Checking personal data
Certification
Checking stakeholders credentials
Enforcement
Monitor operations and react to exceptions
Security
Safeguard privacy information and operations
Interaction
Information presentation and communication
Access
Data subject access to their personal data
Accountability Log and audit management
Privacy and Security by Design Methodology I
72
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B Design
Strategy Approach
• Example cheat sheet (Kung)
Strategy
1 Minimization
Tactics Examples
Collection 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)
Enforce data protection policies (collection, access
and usage, collection, retention)
Protect processing (e.g. storage, communication,
execution, resources)
2 Enforcement
Provide maximum protection of
personal data during operation
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
Cope with evolution needs
•
•
•
Change Policy
Change Crypto Strength and method
Change Protection Strength
4 Modifiability
09/03/2015
•
Privacy and Security by Design Methodology I
73
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Strategy Approach
B Design
• Example cheat sheet (Hoepman)
Patterns Examples
Strategy
• Example cheat sheet (Hoepman)
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 Aggregate
Personal data processed at highest level of
aggregation and with least possible detail in
which it is (still) useful
•
•
•
•
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
1 Minimization
09/03/2015
aggregation over time (used in smart metering)
dynamic location granularity (used in location based services)
k-anonymity
differential privacy
Privacy and Security by Design Methodology I
74
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B Design
Comparing Kung and Hoepman
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
09/03/2015
Kung
Hoepman
1 Minimization
1 Minimization
3 Separate
4 Aggregate
2 Enforcement
2 Hide
7 Enforce
3 Transparency and
accountability
5 Inform
6 Control
7 Demonstrate
4 Modifiability
Privacy and Security by Design
Methodology I
75
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
Pripare Educational Material by Pripare
Project is licensed under a Creative
Commons Attribution-NoDerivatives
4.0 International License.
09/03/2015
Privacy and Security by Design
Methodology I
77