1. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven 10/03/2015 Privacy and Security by Design Methodology II 1 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 UI Centred design C Imple- mentation C1 Privacy implemen- tation C2 Security and Privacy static analysis D Verifica- tion D1 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 architectureH2 Promote privacy awareness B1 – PEARS

2. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Privacy Enhancing Architectures 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/2015Privacy and Security by Design Methodology II2 B2 PEARS

3. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Examples of Architecture Decisions Based on the strategy approach Resulting architecture decisions are patterns 10/03/2015Privacy and Security by Design Methodology II3 User data confinement pattern ( Minimisation strategy) Hippocratic management ( Enforcement strategy) Isolation ( Enforcement strategy) B2 PEARS

4. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven 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, 3 rd Edition 10/03/2015Privacy and Security by Design Methodology II4 B2 PEARS CMU

5. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven CMU Architecture Process Includes the following phases – Architecture analysis – Architecture design – Architecture evaluation 10/03/2015Privacy and Security by Design Methodology II AnalysisDesignEvaluation Privacy Concerns Architecturally Significant Requirements ASRs Architecture Solutions Cost Benefit Data usage Requirements 5 B2 PEARS CMU

6. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Architecture Analysis Objective of Architecture Analysis – Transform concerns into Architecturally Significant Requirements (ASRs) Two types of requirements – Functional requirements (what a system does) – Quality requirements or non functional requirements (how well it does it) Execution qualities: security, usability, dependability Evolution qualities: testability, maintainability, scalability Business qualities: time to market, cost 10/03/2015Privacy and Security by Design Methodology II6 B2 PEARS CMU

7. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Architecture Design Objective of architecture design – Transform ASRs into architecture solutions Impact of functional requirements – Defining appropriate set of responsibilities Impact of quality requirements – Structures and behaviors of the architecture – How design decisions are taken: through architecture tactics Privacy and Security by Design Methodology II10/03/2015 Stimulus Tactics to control response Environment Response Resulting Quality measure 7 B2 PEARS CMU

8. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Architecture Tactics Examples 10/03/2015 Privacy and Security by Design Methodology II 8 Send Message pseudonymization Pseudonym Based message Anonymity Quality measure Data collected At vehicle level for billing Zero-knowledge Based proof Data not Collected at Information System level Minimization Quality measure B2 PEARS CMU

9. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Tactics for Privacy Quality Attribute Minimization tactics Enforcement tactics Accountability tactics Event that creates potential Privacy loophole System Resists, Traces or Recovers 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) Modifiability tactics Log data transaction Log modifications (policies, crypto, protection) Protect log data Change Policy Change Crypto Strength and method Change Protection Strength Privacy Tactics 10/03/2015 Privacy and Security by Design Methodology II 9 B2 PEARS CMU

10. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Privacy Tactics can Change Functional Requirements 10/03/2015 Privacy and Security by Design Methodology II Functional Requirements Architecture Analysis Architecture Design e.g. Birth date e.g. Data minimisation e.g. Proof > 21 year old Architecture Evaluation 10 B2 PEARS CMU

11. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven CMU Analysis: ATAM Architecture Tradeoff Analysis Method – Relies on quality models – Relies on utility trees – Relies on attribute driven design method 10/03/2015Privacy and Security by Design Methodology II11 B2 PEARS CMU

12. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Quality Models Functions to predict the response 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) Privacy and Security by Design Methodology II10/03/201512 Send Message pseudonymization Pseudonym Based message Anonymity Quality measure B2 PEARS CMU

13. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven 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/2015Privacy and Security by Design Methodology II13 B2 PEARS CMU

14. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven 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 Privacy and Security by Design Methodology II10/03/201514 Requirements Iteration Architectural Views B2 PEARS CMU

15. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven 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/2015Privacy and Security by Design Methodology II15 B2 PEARS CMU

16. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven ATAM 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 Privacy and Security by Design Methodology II10/03/201516 B2 PEARS CMU

17. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven 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 Privacy and Security by Design Methodology II10/03/201517 B2 PEARS CMU

18. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Scenario 10/03/2015 Privacy and Security by Design Methodology II 18 Analysis of Architectural Approach Scenario #: 1In-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 DecisionsSensitivityTradeoffRiskNonrisk Access controlS1T1R1N1 Reasoning: Non authorised accesses are detected. Sensitivity PointsDescription S1SMS log better protected Tradeoff PointsDescription T1Affects flexibility of access and sometimes customer services RisksDescription R1Access control may be attacked Non-risksDescription N1SMS data base encryption means slower access B2 PEARS CMU

19. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven CMU Evaluation: CBAM (Cost Benefit Analysis Method) Takes place after ATAM Maximize difference between – benefit derived from system – and cost of implementing the design Privacy and Security by Design Methodology II Business Goals Architecture Strategies Minimization Enforcement Accountability Modifiabiility Benefit Cost … 10/03/201519 B2 PEARS CMU

20. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven 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 Privacy and Security by Design Methodology II10/03/201520 B2 PEARS CMU

21. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven CBAM: Some Metrics Overall Benefit of an Architectural Strategy – B i : benefit of architectural Strategy i – Strategy i described through j scenarios – W j : weight of scenario j – b ij : change in utility caused by scenario j: U expected – U current – B i =  j (b ij x W j ) Value for cost (VFC) – C i : cost of implementing architecture Strategy i – VFC = B i / C i Privacy and Security by Design Methodology II10/03/201521 B2 PEARS CMU

22. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven CBAM Steps 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 Privacy and Security by Design Methodology II10/03/201522 B2 PEARS CMU

23. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Estimation of Resources Examples Lightweight – ATAM – 1 day work system developer – CBAM – 2 h work system developer – 2 hour meeting system developer / project manager 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 Privacy and Security by Design Methodology II 23 Component Infrastructure e.g. wifi protocol Infrastructure e.g. cloud operating system TRL 1-3 Research prototype TRL 4-6 Living lab product TRL 7-9 Market product Component in Application e.g. a user display Application e.g. a banking application Light Med Full LightMed Full TRL 1-3 Research prototype TRL 4-6 Living lab product TRL 7-9 Market product B2 PEARS CMU

24. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven SIPOC Summary 10/03/2015 Privacy and Security by Design Methodology II 24 PEAR Design based on CMU software architecture process SuppliersInputsProcessOutputsCustomers System designer System characterization Risk analysis Privacy controls Initial architecture Provide initial architecture - Identify and prioritize scenarios Evaluate tactics, PETs, patterns, etc. on the scenario with privacy risk assessment Refine architecture System Architecture with tactics and solution patterns System developer Tools & Techniques Architecture Trade-off Analysis Methods (ATAM) Cost Benefit Analysis Methods (CBAM) Knowledge Architecture security and privacy approaches, business goals Responsible System Architecture B2 PEARS CMU

25. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Thibaud Antignac PhD Thesis Formal methods for Privacy-by-design. February 25 th, 2015 – Include a process proposal focusing on minimisation – Includes a formal verification framework proposal 10/03/2015 Privacy and Security by Design Methodology II 25 B2 PEARS Antignac Functional Requi- rements SpecificationDesignVerification Architecture Stakeholder identification Service model Security requirements D1 Structuration Main components Constraints Anonymisation needs D2 Operationalisation Computing localisation Data blurring spec Trust model spec D3 Finalisation Data channel spec Credential channel spec

26. Trialog, Atos, Trilateral, Inria, AUP, Gradiant, UPM, UUlm, Fraunhofer SIT, WIT, KU Leuven Exercise Analysis – Architecture significant requirements for minimization? Design – Quality attributes trees Evaluation – Utility – Cost analysis 10/03/2015Privacy and Security by Design Methodology II26 B2 PEARS CMU