Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Engineering Privacy Engineering

1,254 views

Published on

One of the many challenges of privacy is that it has not sufficiently penetrated software engineering to same degree as performance and security. The tools for understanding our systems from both an information and privacy standpoint already exist and need to be applied. Presented from an engineer’s point of view, this session will help you gain a better understanding of privacy information and its flow around and between systems. Privacy controls within information systems need to be engineered, rather than dictated through high-level policies and requirements. Without reference to the fundamentals of creating and developing software and taking into account the human factors and attitudes toward development, difficulties will inevitably arise. Through this session, you will gain a better understanding of how information systems behave with respect to the information they are carrying, how to classify that information, how to reason about it, and how to measure and manage it.

Published in: Internet
  • Be the first to comment

Engineering Privacy Engineering

  1. 1. .. Engineering Privacy Engineering Dr. Ian Oliver Security Research Nokia Networks 16 April 2015 1 © Nokia Solutions and Networks
  2. 2. A confession... 2 © Nokia Solutions and Networks
  3. 3. I am an engineer 3 © Nokia Solutions and Networks
  4. 4. This Talk An appreciation about how an engineer conceptualises a system engineering problem or How do we bring engineers and privacy professionals together? or How do we make privacy engineering a discipline? 4 © Nokia Solutions and Networks
  5. 5. Question You have a data breach - of any kind - whose fault was it? ..1 the privacy officer? 5 © Nokia Solutions and Networks
  6. 6. Question You have a data breach - of any kind - whose fault was it? ..1 the privacy officer? ..2 the privacy policy itself? 5 © Nokia Solutions and Networks
  7. 7. Question You have a data breach - of any kind - whose fault was it? ..1 the privacy officer? ..2 the privacy policy itself? ..3 the engineers for not complying? 5 © Nokia Solutions and Networks
  8. 8. Question You have a data breach - of any kind - whose fault was it? ..1 the privacy officer? ..2 the privacy policy itself? ..3 the engineers for not complying? ← HINT! 6 © Nokia Solutions and Networks
  9. 9. Question - Why? Was your data breach due to: ..1 A failure in security? (typical RCA result) ..2 Bad programming? ..3 Bad design? ..4 Wrongly worded privacy policy? ..5 Miscommunication? 7 © Nokia Solutions and Networks
  10. 10. Speaking with Engineers ..1 Conversation 1 • Privacy Officer: “Does your system collect PII?” • Engineer: “No!” 8 © Nokia Solutions and Networks
  11. 11. Speaking with Engineers ..1 Conversation 1 • Privacy Officer: “Does your system collect PII?” • Engineer: “No!” ..2 Conversation 2 • Privacy Officer: “Does your system collect GPS coordinates?” • Engineer: “Maybe...” 8 © Nokia Solutions and Networks
  12. 12. Speaking with Engineers ..1 Conversation 1 • Privacy Officer: “Does your system collect PII?” • Engineer: “No!” ..2 Conversation 2 • Privacy Officer: “Does your system collect GPS coordinates?” • Engineer: “Maybe...” ..3 Conversation 3 • Privacy Officer: “What is that struct{float x, float y} thing?” • Engineer: “OK, you got me!” 8 © Nokia Solutions and Networks
  13. 13. Complexity • DNT • 0 or 1 9 © Nokia Solutions and Networks
  14. 14. Complexity • DNT • 0 or 1 • Cookies • Context, Usage and Type vs Bytes 9 © Nokia Solutions and Networks
  15. 15. Complexity • DNT • 0 or 1 • Cookies • Context, Usage and Type vs Bytes • Cloud • Alan Turing and his Turing Machines • Encryption and Key Management • Deletion Semantics 9 © Nokia Solutions and Networks
  16. 16. Complexity • DNT • 0 or 1 • Cookies • Context, Usage and Type vs Bytes • Cloud • Alan Turing and his Turing Machines • Encryption and Key Management • Deletion Semantics • Notice and Consent 9 © Nokia Solutions and Networks
  17. 17. Complexity • DNT • 0 or 1 • Cookies • Context, Usage and Type vs Bytes • Cloud • Alan Turing and his Turing Machines • Encryption and Key Management • Deletion Semantics • Notice and Consent • Policies • Legalese vs Mathematics • POLICY ∈ P { Type × Usage × Purpose × Provenance × . . . } − ∅ • TY PE =def ({⊤, ⊥, Fin, Hlt, Id, . . . }, ≤, . . .}) • SY STEM |= POLICY • . . . 9 © Nokia Solutions and Networks
  18. 18. Towards a Solution • Terminology and Semantics • Modelling and Context • Requirements • Risk • Compliance and Auditing 10 © Nokia Solutions and Networks
  19. 19. The Semantics of PII 11 © Nokia Solutions and Networks
  20. 20. Understanding PII/Personal Data 12 © Nokia Solutions and Networks
  21. 21. Terminology • Terminological or Ontological Structures • Security classification • Information type (versus machine type or PII/personal data) • Provenance, Jurisdiction • Usage, Purpose • Controller, Processor and Data Subject • Identity and Authority, Notice and Consent • Requirements and Risk 13 © Nokia Solutions and Networks
  22. 22. Terminology • Terminological or Ontological Structures • Security classification • Information type (versus machine type or PII/personal data) • Provenance, Jurisdiction • Usage, Purpose • Controller, Processor and Data Subject • Identity and Authority, Notice and Consent • Requirements and Risk • System Architecture, as a data flow • Data Processing and Storage, Environment and Breaches • Data Subject • Data Transformation • Architectural Partitioning and System Boundaries • Boundary Crossings 13 © Nokia Solutions and Networks
  23. 23. Terminology • Terminological or Ontological Structures • Security classification • Information type (versus machine type or PII/personal data) • Provenance, Jurisdiction • Usage, Purpose • Controller, Processor and Data Subject • Identity and Authority, Notice and Consent • Requirements and Risk • System Architecture, as a data flow • Data Processing and Storage, Environment and Breaches • Data Subject • Data Transformation • Architectural Partitioning and System Boundaries • Boundary Crossings • Inference Rules and Calculi • ⋄ ( x : MachineAddress ⊢ x : Location ) • Policy Calculation, Refinement and Compliance Checking 13 © Nokia Solutions and Networks
  24. 24. Modelling The purpose of any model is to explore and answer questions about a system or So you really want to talk to an engineer? 14 © Nokia Solutions and Networks
  25. 25. Modelling 15 © Nokia Solutions and Networks
  26. 26. Notices and Consent 16 © Nokia Solutions and Networks
  27. 27. Requirement Aspect 17 © Nokia Solutions and Networks
  28. 28. Requirement Structure 18 © Nokia Solutions and Networks
  29. 29. Risk after Solove, Anton-Earp, et al 19 © Nokia Solutions and Networks
  30. 30. Analysing The Model • Let C be the set of components of a system,. . . 20 © Nokia Solutions and Networks
  31. 31. Analysing The Model • Let C be the set of components of a system,. . . • Let I be the set of interconnections {(c1, c2)}, c1, c2 ∈ C,. . . 20 © Nokia Solutions and Networks
  32. 32. Analysing The Model • Let C be the set of components of a system,. . . • Let I be the set of interconnections {(c1, c2)}, c1, c2 ∈ C,. . . • Let S be a system with the signature (C, I),. . . 20 © Nokia Solutions and Networks
  33. 33. Analysing The Model • Let C be the set of components of a system,. . . • Let I be the set of interconnections {(c1, c2)}, c1, c2 ∈ C,. . . • Let S be a system with the signature (C, I),. . . • Audit(c : C,…) → B ∪ {⊥}, c ∈ S • Unfortunately doesn’t always produce the correct answers, even when C refers to the whole system • Why?! 20 © Nokia Solutions and Networks
  34. 34. Analysing The Model • Let C be the set of components of a system,. . . • Let I be the set of interconnections {(c1, c2)}, c1, c2 ∈ C,. . . • Let S be a system with the signature (C, I),. . . • Audit(c : C,…) → B ∪ {⊥}, c ∈ S • Unfortunately doesn’t always produce the correct answers, even when C refers to the whole system • Why?! • CalcPolicy(ds : DataSubject) → Policy =∑ {(InfoType.ds.endpoints × Usage.ds.endpoints × . . .)} • Can be compared against the ‘official’ privacy policy • Overconstrained system • Weakening implies additional risk 20 © Nokia Solutions and Networks
  35. 35. Metricisation • Risk → (Cost × V alue), Cost ∝ V alue 21 © Nokia Solutions and Networks
  36. 36. Metricisation • Risk → (Cost × V alue), Cost ∝ V alue • Requirements → Risk 21 © Nokia Solutions and Networks
  37. 37. Metricisation • Risk → (Cost × V alue), Cost ∝ V alue • Requirements → Risk • ( InformationType × Usage × . . . ) → Requirements ⇔ POLICY 21 © Nokia Solutions and Networks
  38. 38. Metricisation • Risk → (Cost × V alue), Cost ∝ V alue • Requirements → Risk • ( InformationType × Usage × . . . ) → Requirements ⇔ POLICY • Policy ⊑ Architecture ⊑ Design ⊑ Code 21 © Nokia Solutions and Networks
  39. 39. Quick Summary • Terminology is the key - no more talking about PII in isolation 22 © Nokia Solutions and Networks
  40. 40. Quick Summary • Terminology is the key - no more talking about PII in isolation • Infomation Type, Usage, Purpose, Provenance etc 22 © Nokia Solutions and Networks
  41. 41. Quick Summary • Terminology is the key - no more talking about PII in isolation • Infomation Type, Usage, Purpose, Provenance etc • Model your system 22 © Nokia Solutions and Networks
  42. 42. Quick Summary • Terminology is the key - no more talking about PII in isolation • Infomation Type, Usage, Purpose, Provenance etc • Model your system • Formalise requirements - polices are too abstract 22 © Nokia Solutions and Networks
  43. 43. Quick Summary • Terminology is the key - no more talking about PII in isolation • Infomation Type, Usage, Purpose, Provenance etc • Model your system • Formalise requirements - polices are too abstract • Risk management through metrics derived from the system model 22 © Nokia Solutions and Networks
  44. 44. Quick Summary • Terminology is the key - no more talking about PII in isolation • Infomation Type, Usage, Purpose, Provenance etc • Model your system • Formalise requirements - polices are too abstract • Risk management through metrics derived from the system model • System model as a data flow becomes the binding and communication medium 22 © Nokia Solutions and Networks
  45. 45. Putting it all Together ? 23 © Nokia Solutions and Networks
  46. 46. Putting it all Together Culture 24 © Nokia Solutions and Networks
  47. 47. Lessons - Privacy as a Safety Critical Aspect • Aviation • Medicine: Surgery, Anaesthesia • Civil Engineering 25 © Nokia Solutions and Networks
  48. 48. The End Thankyou 26 © Nokia Solutions and Networks

×