Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B1 – PEARS
A Analysis
B Design
C Implementation
A1 Functional
description and
high-level
privacy analysis
B1 Privacy
enhancing
architecture
design (PEAR)
C1 Privacy
implementation
A2 Detailed
Privacy Analysis
B2 Privacy
enhancing
detailed
design
C2 Security
and Privacy
static analysis
A3 Privacy
Requirements
D Verification
D1 Security
and Privacy
dynamic
analysis
E Release
F Maintenance
E1 Create
incident
response plan
F1 Execute
incident
response plan
E2 Create
system
retirement
plan
F2 Security
and privacy
verification
G Decommission
G1 Execute
retirement
plan
E3 Final
security and
privacy
review
B3 UI Centred
design
A4 Legal
compliance
E4 Publish
PIA report
A5 Risk
management
H Environment and Infrastructure
H1 Organisational privacy architecture
H2 Promote privacy awareness
10/03/2015
Privacy and Security by Design
Methodology II
1
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Privacy Enhancing Architectures
B2 PEARS
• Architecture
– Structure and behavior of system
– Global viewpoint
• Privacy Enhancing Architectures
– Everything in the architecture that relates to privacy
– Practically
• If operational service approach, figure out architecture impact
for each service
• If strategy approach, figure out architecture impact for each
strategy
10/03/2015
Privacy and Security by Design Methodology II
2
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B2 PEARS
Examples of Architecture Decisions
• Based on the strategy approach
• Resulting architecture decisions are patterns
User data confinement pattern
(Minimisation strategy)
Hippocratic
management
(Enforcement
Isolation
(Enforcement
strategy)
strategy)
10/03/2015
Privacy and Security by Design Methodology II
3
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
CMU Architecture Process
• Widely used for software architecture
• But can be used for systems in general
– Bass, Len, Clements Paul and Rick Kazman, Software
Architecture in Practice, Addison Wesley, 2003, 3rd
Edition
10/03/2015
Privacy and Security by Design Methodology II
4
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
CMU Architecture Process
• Includes the following phases
– Architecture analysis
– Architecture design
– Architecture evaluation
Data usage
Requirements
Architecturally
Significant
Requirements
ASRs
Privacy
Concerns
Analysis
10/03/2015
Architecture
Solutions
Design
Privacy and Security by Design Methodology II
Cost
Benefit
Evaluation
5
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
Architecture Tactics Examples
pseudonymization
Pseudonym
Based message
Send Message
Data collected
At vehicle level
for billing
10/03/2015
Zero-knowledge
Based proof
Data not
Collected at
Information
System level
Privacy and Security by Design
Methodology II
Anonymity
Quality
measure
Minimization
Quality
measure
8
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B2 PEARS
Privacy Tactics
CMU
Tactics for Privacy Quality Attribute
Minimization
tactics
Event
that
creates
potential
Privacy
loophole
10/03/2015
• Anonymize
credentials (e.g.
Direct
anonymous
attestation)
• Limit processing
perimeter (e.g.
client
processing, P2P
processing)
Enforcement
tactics
Accountability
tactics
• Enforce data
protection
policies
(collection,
access and
usage, collection,
retention)
• Log data
transaction
• Protect
processing (e.g.
storage,
communication,
execution,
resources)
• Protect log data
• Log
modifications
(policies, crypto,
protection)
Privacy and Security by Design
Methodology II
Modifiability
tactics
• Change Policy
• Change Crypto
Strength and
method
• Change
Protection
Strength
System
Resists,
Traces or
Recovers
9
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B2 PEARS
Functional
Requirements
10/03/2015
Privacy Tactics can Change
Functional Requirements
CMU
Architecture
Analysis
Architecture
Design
Privacy and Security by Design
Methodology II
Architecture
Evaluation
10
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
CMU Analysis: ATAM
• Architecture Tradeoff Analysis Method
– Relies on quality models
– Relies on utility trees
– Relies on attribute driven design method
10/03/2015
Privacy and Security by Design Methodology II
11
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
Quality Models
• Functions to predict the response measure
pseudonymization
Send Message
Pseudonym
Based message
Anonymity
Quality
measure
• Approaches depend on domain and attributes
– Analytic models (support quantitative analysis)
• Availability: markov models/statistical models.
• Performance: queuing theory/scheduling theory
– Heuristic models (based on cheat sheets and adhoc
metrics)
• Privacy (e.g. CNIL likelihood and severity metrics)
• Safety (e.g. safety integrity level)
10/03/2015
Privacy and Security by Design Methodology II
12
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
Utility Trees
• Level 1: Quality attributes
– e.g. minimisation
• Level 2: Attribute refinements
– e.g. amount of data revealed
• Level 3: Definition of Architecturally Significant
Requirements
– Scenario
• system can provide a proof that user is above 21 instead of
transmitting birthdate.
– Business value (high, medium, low)
– Architecture impact (high, medium, low)
10/03/2015
Privacy and Security by Design Methodology II
13
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
Attribute Driven Design Method
• Iteration-based
Choose an element of the system to design
Identify ASRs for that part
Generate a design solution (architectural views)
Inventory of remaining requirements and selection of
input for the next iterations
–
–
–
–
Requirements
10/03/2015
Iteration
Architectural Views
Privacy and Security by Design Methodology II
14
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
ATAM Output
• Concise presentation of architecture
– Views (e.g. static, dynamic, deployment)
– Quality attributes and Tactics (e.g. minimization and attribute
based credential)
• Business goals (e.g. financial, market position, legal,
competitive, quality, …)
• Utility trees
• Risks (e.g. privacy leaks)
• Sensitivity points
– architectural decisions affecting some quality attribute measure
(e.g. data better protected)
• Tradeoff points
– architectural decisions affecting several quality attributes
measures, some positively and some negatively (e.g. data better
protected but response time is not as good)
10/03/2015
Privacy and Security by Design Methodology II
15
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
ATAM
CMU
B2 PEARS
• Participants
– Evaluation team
– Project decision makers
– Architecture stakeholders
• Do not participate to entire exercise
• Phases
– Evaluation phase 1
• Involves project decision makers and evaluation team
– Evaluation phase 2
• + Architect stakeholders
10/03/2015
Privacy and Security by Design Methodology II
16
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
ATAM Steps
• Phase 1
Step 1 - Present ATAM
Step 2 - Present Business Drivers
Step 3 - Present Architecture
Step 4 - Identify Architectural Approaches (list patterns and
tactics)
– Step 5 - Generate Quality Attribute Utility Tree
– Step 6 - Analyze Architectural Approaches
–
–
–
–
• Focus on higher ranked scenarios
• Phase 2
– Step 7 - Brainstorm and Prioritize Scenarios
– Step 8 - Analyze Architectural Approaches
– Step 9 – Present results
10/03/2015
Privacy and Security by Design Methodology II
17
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B2 PEARS
Scenario
CMU
Analysis of Architectural Approach
Scenario #: 1
In-house non authorised access
Attribute(s): Protection enforcement
Environment: SMS data base of mobile phone operator
Stimulus: Attempt to access SMS log of a celebrity
Response: Access denial
Architectural Decisions Sensitivity
Tradeoff
Risk
Nonrisk
Access control
R1
N1
S1
T1
Reasoning: Non authorised accesses are detected.
Sensitivity Points Description
S1
SMS log better protected
Tradeoff Points
Description
T1
Affects flexibility of access and sometimes customer services
Risks
Description
R1
Access control may be attacked
Non-risks
Description
N1
SMS data base encryption means slower access
10/03/2015
Privacy and Security by Design
Methodology II
18
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
CMU Evaluation: CBAM
(Cost Benefit Analysis Method)
• Takes place after ATAM
• Maximize difference between
– benefit derived from system
– and cost of implementing the design
Minimization
Business
Goals
Architecture
Strategies
Enforcement
Benefit
Accountability
…
Cost
Modifiabiility
10/03/2015
Privacy and Security by Design Methodology II
19
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B2 PEARS
CMU
CBAM: Utility-Response Curves
• For each quality create a
utility-response curve
• Exemple anonymity
quality:
– Case a
• Response: K-anonymity 1
• Utility 0
– Case b
• Response: K-anonymity 3
• Utility 50
– Case c
• Response: K-anonymity 6
• Utility 90
10/03/2015
Privacy and Security by Design Methodology II
20
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CBAM: Some Metrics
CMU
B2 PEARS
• Overall Benefit of an Architectural Strategy
Bi: benefit of architectural Strategy i
Strategy i described through j scenarios
Wj: weight of scenario j
bij: change in utility caused by scenario j: Uexpected –
Ucurrent
– Bi = j(bij x Wj)
–
–
–
–
• Value for cost (VFC)
– Ci: cost of implementing architecture Strategy i
– VFC = Bi / Ci
10/03/2015
Privacy and Security by Design Methodology II
21
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CBAM Steps
CMU
B2 PEARS
• Step 1: collate scenario
– Choose the top third
• Step 2: refine scenario
– Worst case, current, desired, best case QA response level for each scenario
• Step 3: prioritise scenarios
• Step 4: assign utility for step 3 scenarios
– Worst case, Current, Desired, Best Case
• Step 5: identify architectural strategies and associated scenarios.
Determine their expected QA response level
• Step 6: Determine the utility of the expected QA response levels by
interpolation
• Step 7: Calculate total benefit obtained from an architectural strategy
• Step 8: Select architectural strategy base on VFC (compatible with cost
and schedule constraints)
• Step 9: confirm results with intuition
10/03/2015
Privacy and Security by Design Methodology II
22
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
Estimation of Resources Examples
• Lightweight
– ATAM – 1 day work system
developer
– CBAM – 2 h work system
developer
– 2 hour meeting system developer
/ project manager
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
• Medium
– ATAM - 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
10/03/2015
Infrastructure
e.g. cloud operating
system
Component
Infrastructure
e.g. wifi protocol
Light Med Med
TRL 1-3
Research
prototype
Privacy and Security by Design
Methodology II
TRL 4-6
Living lab
product
TRL 7-9
Market
product
23
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
B2 PEARS
SIPOC Summary
CMU
PEAR Design based on CMU software architecture process
Suppliers
Inputs
Process
Outputs
Customers
Knowledge
Provide initial
architecture - Identify
System
and prioritize scenarios System
characterization
Evaluate tactics, PETs, Architecture
System
Risk analysis
patterns, etc. on the
with tactics and developer
Privacy controls
scenario with privacy
solution patterns
Initial architecture risk assessment
Refine architecture
Architecture Trade-off Analysis Methods (ATAM)
Cost Benefit Analysis Methods (CBAM)
Architecture security and privacy approaches, business goals
Responsible
System Architecture
System
designer
Tools &
Techniques
10/03/2015
Privacy and Security by Design
Methodology II
24
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
Antignac
B2 PEARS
Thibaud Antignac PhD Thesis
• Formal methods for Privacy-by-design. February 25th, 2015
– Include a process proposal focusing on minimisation
– Includes a formal verification framework proposal
Functional
Requirements
Specification
Design
Stakeholder
identification
D1 Structuration
Main components
Constraints
Anonymisation needs
Service
model
•
•
•
D2 Operationalisation
• Computing localisation
• Data blurring spec
• Trust model spec
Verification
Architecture
D3 Finalisation
Security
requirements
10/03/2015
•
•
Data channel spec
Credential channel spec
Privacy and Security by Design Methodology II
25
Trialog, Atos, Trilateral, Inria , AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT , KU Leuven
CMU
B2 PEARS
Exercise
• Analysis
– Architecture significant requirements for minimization?
• Design
– Quality attributes trees
• Evaluation
– Utility
– Cost analysis
10/03/2015
Privacy and Security by Design Methodology II
26