Assessing Impact of Security Services
•Transferir como PPTX, PDF•
0 gostou•1,065 visualizações
A presentation from the Jisc security conference 2018 by Andrew Cormack, chief regulatory adviser, Jisc technologies
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Assessing Impact of Security Services
Semelhante a Assessing Impact of Security Services (20)
Mais de Jisc
Mais de Jisc (20)
Último
Último (20)
Assessing 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
Notas do Editor
- 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?