Assessing the impact of security services
•Download as PPTX, PDF•
0 likes•1,065 views
A presentation from the Jisc security conference 2018 by Andrew Cormack, chief regulatory adviser, Jisc technologies
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Assessing the impact of security services
Similar to Assessing the impact of security services (20)
More from Jisc
More from Jisc (20)
Recently uploaded
Recently uploaded (20)
Assessing the impact of security services
- 1. Assessing the impact of security services Andrew Cormack chief regulatory adviser, Jisc technologies, Jisc.
- 2. Why assess DP impact?
- 3. Why assess DP impact? Legal requirement? •GDPR Art.35 Data Protection Impact Assessment (DPIA) •“if likely to result in a high risk to the rights and freedoms of natural persons”
- 4. Why assess DP impact? Legal requirement? •GDPR Art.35 Data Protection Impact Assessment (DPIA) •“if likely to result in a high risk to the rights and freedoms of natural persons” Regulator recommendation? •ICO Legitimate Interests Assessment (LIA) •“if relying on legitimate interests”
- 5. 5 But mostly… To reassure us, members, customers and users that we’re creating privacy/security benefits, not risks!
- 6. Factors likely to require DPIA (Art29WP/EDPB) Match 2 or more => Usually need DPIA •Evaluation or scoring •Automated decision-making •Systematic monitoring •Sensitive (or highly-personal) data •Data processed on large scale •Matching/combining datasets •Vulnerable data subjects •Innovative use or new technological/organisational solutions •Processing prevents data subject exercising right/using service/contract
- 8. Jisc security services… Security operations centre (SOC) •Large scale •Applies to all Janet traffic •Passive monitoring •Mostly by machine •Some automation (e.g. DDoS) => DPIA
- 9. Jisc security services… Security operations centre (SOC) •Large scale •Applies to all Janet traffic •Passive monitoring •Mostly by machine •Some automation (e.g. DDoS) => DPIA Penetration testing service •Small scale •Commissioned by organisation • Limited scope: systems and people •Active attacks/social engineering => LIA
- 10. 10 SOC DPIA
- 11. DPIA process NOT based on ICO guide – it hadn’t been published 11
- 12. DPIA process NOT based on ICO guide – it hadn’t been published •So derive from GDPR text and CNIL (very) detailed approach •Structured interviews: service managers/operators/DPO + follow-up Q&A 12
- 13. DPIA process NOT based on ICO guide – it hadn’t been published •So derive from GDPR text and CNIL (very) detailed approach •Structured interviews: service managers/operators/DPO + follow-up Q&A •User consultation •Annual consultation recently completed, don’t really want another 13
- 14. DPIA process NOT based on ICO guide – it hadn’t been published •So derive from GDPR text and CNIL (very) detailed approach •Structured interviews: service managers/operators/DPO + follow-up Q&A •User consultation •Annual consultation recently completed, don’t really want another •ICO (now) suggests cyclic DPIA process • Consultation apparently before own risk/mitigation assessment? • Surely more efficient to ask users for issues you didn’t spot? 14
- 15. DPIA process NOT based on ICO guide – it hadn’t been published •So derive from GDPR text and CNIL (very) detailed approach •Structured interviews: service managers/operators/DPO + follow-up Q&A •User consultation •Annual consultation recently completed, don’t really want another •ICO (now) suggests cyclic DPIA process • Consultation apparently before own risk/mitigation assessment? • Surely more efficient to ask users for issues you didn’t spot? •So use 1st round DPIA report for 2nd round consultation (~18 months) 15
- 16. ICO DPIA cycle 16 Identify need Describe process Consult? Nec. and Prop. Identify risks Identify controls Record and Sign off Integrate actions into plan Review
- 17. DPIA data gathering/reporting Based on GDPR structure 17
- 18. DPIA data gathering/reporting Based on GDPR structure •Description of operations and purpose •Controllers, processors, recipients, purpose/legal basis… •What data, how, where, how long… 18
- 19. DPIA data gathering/reporting Based on GDPR structure •Description of operations and purpose •Controllers, processors, recipients, purpose/legal basis… •What data, how, where, how long… •Assessment of necessity and proportionality •Individual rights/principles fit here too 19
- 20. DPIA data gathering/reporting Based on GDPR structure •Description of operations and purpose •Controllers, processors, recipients, purpose/legal basis… •What data, how, where, how long… •Assessment of necessity and proportionality •Individual rights/principles fit here too •Assessment of risks to rights and freedoms (see later) •Measures to address risks, and demonstrate compliance (see later) 20
- 21. DPIA data gathering/reporting Based on GDPR structure •Description of operations and purpose •Controllers, processors, recipients, purpose/legal basis… •What data, how, where, how long… •Assessment of necessity and proportionality •Individual rights/principles fit here too •Assessment of risks to rights and freedoms (see later) •Measures to address risks, and demonstrate compliance (see later) •Conclusions •Are risks mitigated? Recommendations 21
- 23. DPIA risk management Assess impact •Think data and processing 23
- 24. DPIA risk management Assess impact •Think data and processing •Effect of breach/misuse •On confidentiality/integrity/availability •Ignoring (for now) cause 24
- 25. DPIA risk management Assess impact •Think data and processing •Effect of breach/misuse •On confidentiality/integrity/availability •Ignoring (for now) cause •What harm results? •Personal, financial, … •Rights and freedoms •Impact: high/medium/low 25
- 26. DPIA risk management Assess impact •Think data and processing •Effect of breach/misuse •On confidentiality/integrity/availability •Ignoring (for now) cause •What harm results? •Personal, financial, … •Rights and freedoms •Impact: high/medium/low 26 Manage likelihood •Think causes •Internal (accident/malicious) • External (accident/malicious) • Environment (accident)
- 27. DPIA risk management Assess impact •Think processing and data •Effect of breach/misuse •On confidentiality/integrity/availability •Ignoring (for now) cause •What harm results? •Personal, financial, … •Rights and freedoms •Impact: high/medium/low 27 Manage likelihood •Think causes •Internal (accident/malicious) • External (accident/malicious) • Environment (accident) •Think mitigations • Most of which reduce likelihood • Some reduce impact too •How to monitor/maintain compliance?
- 28. DPIA conclusions •All risks mitigated to (well) below high •Automated processing itself a significant mitigation •Some new opportunities for controls/monitoring • See https://ji.sc/SOC-DPIA 28
- 30. LIA process Based on ICO light-touch risk assessment… 30
- 31. LIA process Based on ICO light-touch risk assessment… •Structured interviews with service managers/operators + follow-up Q&A 31
- 32. LIA process Based on ICO light-touch risk assessment… •Structured interviews with service managers/operators + follow-up Q&A •What is legitimate interest? [Site improving security of key DP processes] •Who benefits? How? How much? Ethical/Legal Issues? 32
- 33. LIA process Based on ICO light-touch risk assessment… •Structured interviews with service managers/operators + follow-up Q&A •What is legitimate interest? [Site improving security of key DP processes] •Who benefits? How? How much? Ethical/Legal Issues? •Necessity: any less intrusive way to do it? [No] 33
- 34. LIA process Based on ICO light-touch risk assessment… •Structured interviews with service managers/operators + follow-up Q&A •What is legitimate interest? [Site improving security of key DP processes] •Who benefits? How? How much? Ethical/Legal Issues? •Necessity: any less intrusive way to do it? [No] •Balance benefits vs harms •What is relationship with individuals? What is possible impact? •Will you explain it? Will they object/feel intrusion? •What safeguards can you provide? Can they opt-out? 34
- 36. LIA conclusions •Technical pentests have strong safeguards/minimisation 36
- 37. LIA conclusions •Technical pentests have strong safeguards/minimisation •Social engineering can cause harm to a few individuals 37
- 38. LIA conclusions •Technical pentests have strong safeguards/minimisation •Social engineering can cause harm to a few individuals •Targets are in positions of authority/responsibility; significant risks to others •Organisations must support/explain what was done and why •And provide guidance, training, etc. so they don’t fall for a real attack 38
- 39. LIA conclusions •Technical pentests have strong safeguards/minimisation •Social engineering can cause harm to a few individuals •Targets are in positions of authority/responsibility; significant risks to others •Organisations must support/explain what was done and why •And provide guidance, training, etc. so they don’t fall for a real attack •Organisations must fix vulnerabilities, otherwise no benefit to justify risk! • See https://ji.sc/PENTEST-LIA 39
- 40. References • DPIA • Art.29 https://ji.sc/DPIA-art29 • CNIL https://ji.sc/CNIL-PIA-guides • [ICO https://ji.sc/ICO-DPIA] • https://ji.sc/SOC-DPIA • LIA • ICO https://ji.sc/ICO-legitimate-interests • https://ji.sc/PENTEST-LIA 40
- 41. Get in touch… Except where otherwise noted, this work is licensed under CC-BY Andrew Cormack chief regulatory adviser Andrew.Cormack@jisc.ac.uk
Editor's Notes
- UK ICO adds Risk of Physical Harm, Tracking, Invisible Processing; deletes large scale, automated decision-making, arguably systematic monitoring (which may be a superset of “tracking”); interestingly the EDPB pushes back against such modifications… Maybe it *is* harmonising?