Living in GDPR world

Data security is an important issue and the introduction of GDPR has added even more requirements. But how can one live in a demanding environment? How can one secure data and make sure that the right people can see the right data? In this talk, I'm showing tools and extensions to stay GDPR-complaint working with PostgreSQL database.

Transcript

1. Living in GDPR world Pavlo Golub Senior Database Consultant pavlo.golub@cybertec.at @PavloGolub 1
2. Specialized in Data services About CYBERTEC Inhouse Development Owner-managed since 2000 International team of developers 2
3. CYBERTEC Worldwide AUSTRIA Wiener Neustadt ESTONIA Tallinn URUGUAY Montevideo SWITZERLAND Zurich 3
4. Client sectors ▪ University ▪ Industry ▪ Administration ▪ Government ▪ Finance ▪ Trade ▪ Automotive ▪ etc. 4
5. PostgreSQL Database Services 24/7 Support Performance Tuning Consulting High Availability Training Setup Development Replication Cloud 5
6. DATA Services ▪ Artificial Intelligence ▪ Machine learning ▪ BIG DATA ▪ Business Intelligence ▪ Data Mining 6
8. Intro 8
11. What the GDPR is? • General Data Protection Regulation • Applied from 25 May 2018 • Adopted in 2016 replacing 1995 Data Protection Directive • Regulation in EU law on data protection and privacy for all individuals within the European Union • Personal data means any information relating to an identified or identifiable natural person ('data subject') 11
12. Do we have something similar? • HIPAA ◦ Health Insurance Portability and Accountability Act of 1996 ◦ USA • PCI-DSS ◦ Payment Card Industry Data Security Standards ◦ Organizations 12
13. But what the difference? • Citizen from US and EU visit Israel for healthcare • GDPR can still apply ✅ ◦ because this is a consumer-centric regulation ◦ any organization across the world is liable to adhere to these stringent regulations when they deal with data pertaining to citizens from the EU. 13
14. But what the difference? • Citizen from US and EU visit Israel for healthcare • HIPAA cannot apply ❌ ◦ is an organization-centric regulation ◦ any data handled by organizations outside the US do not come under the purview of HIPAA. 14
15. Entities • Data Controller – determines the purposes and means of the processing of personal data • Data Processor - processes personal data on behalf of the controller • ‍♀ Supervising Authority - monitor and enforce the Regulation 15
16. Personal Data means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; 16
17. Penalties • Light – up to 10M€ ◦ or 2% of annual global turnover • Heavy - up to 20M€ ◦ or 4% of annual global turnover 17
18. Penalties According to the European Data Protection Board, 281,088 cases were logged by supervisory authorities in the first year of the GDPR’s application: • 144,376 related to complaints and • 89,271 related to data breach notifications by data controllers. 18 https:/ /www.itgovernance.co.uk/dpa-and-gdpr-penalties
19. Penalties July 2018 The ICO’s first action under the GDPR. An enforcement notice was issued to AggregateIQ Data Services Ltd as part of its investigation into the Cambridge Analytica scandal. 19 https:/ /www.itgovernance.co.uk/dpa-and-gdpr-penalties
20. Penalties September 2018 The first fine issued under the GDPR. The Austrian DSB fined a sports betting café €5,280 for installing a CCTV camera that recorded passers-by. 20 https:/ /www.itgovernance.co.uk/dpa-and-gdpr-penalties
21. Penalties November 2018 German supervisory authority, LfDI Baden-Württemberg, fined the social media platform Knuddels €20,000 for storing passwords in plaintext. This resulted in a data breach compromising approximately 330,000 users’ personal data. 21 https:/ /www.itgovernance.co.uk/dpa-and-gdpr-penalties
22. Penalties January 2019 The first major fine under the new law. France’s CNIL fined Google €50 million for failing to obtain a valid legal basis for processing personal data for ad personalisation. This breached the GDPR’s requirements for transparency and specific, unambiguous consent. 22 https:/ /www.itgovernance.co.uk/dpa-and-gdpr-penalties
23. Penalties July 2019 ICO announced its intention to fine: • British Airways £183.39 million for a 2018 breach compromising the personal data of approximately 500,000 customers. • Marriott International £99,200,396 when “a cyber incident” exposed approximately 339 million customer records. 23 https:/ /www.itgovernance.co.uk/dpa-and-gdpr-penalties
24. How are GDPR fines applied? ◦ The nature, severity and duration of the GDPR infringement. ◦ The infringement was caused intentionally or by negligence. ◦ Any action taken by the organisation to mitigate the damage. ◦ Technical and organisational measures that have been implemented by the organisation. ◦ Any previous infringements by the organisation. ◦ The cooperation with the regulator to remedy the infringement. ◦ The types of personal data involved. ◦ How the regulator found out about the infringement, and the extent of any notification by the controller or processor. ◦ Adherence to approved codes of conduct or certification schemes. 24 https:/ /www.itgovernance.co.uk/dpa-and-gdpr-penalties
25. GDPR is here to stay GDPR affects the whole world, not EU only The question is not whether we like it or not The question is: How can we cope with it? What is the future of GDPR 25
26. Legislation 26
27. What is your data? Your company has a list of all types of personal information it holds, the source of that information, who you share it with, what you do with it and how long you will keep it https:/ /gdprchecklist.io 27
28. Where is your data? Your company has a list of places where it keeps personal information and the ways data flows between them https:/ /gdprchecklist.io 28
29. How to process data? Your company has a publicly accessible privacy policy that outlines all processes related to personal data. https:/ /gdprchecklist.io 29
30. Why you need data? Your privacy policy should include a lawful basis to explain why the company needs to process personal information https:/ /gdprchecklist.io 30
31. Accountability & management • Your company has appointed a Data Protection Officer (DPO) • Create awareness among decision makers about GDPR • Make sure your technical security is up to date • Train staff to be aware of data protection • You have a list of sub-processors • Your privacy policy mentions your use of this sub-processor • You have appointed a representative within the EU • Report data breaches to the authority and to the people involved • There is a contract with any data processors you share data with https:/ /gdprchecklist.io 31
32. New rights • Customers can easily request access to their personal information • Customers can easily update their own personal information • You automatically delete data business no longer has any use for • Customers can easily request deletion of their personal data • Customers can easily request that you stop processing their data • Customers can easily request their data be delivered to themselves or a 3rd party • Customers can easily object to profiling or automated decision making that could impact them https:/ /gdprchecklist.io 32
33. Consent • Where processing is based on consent, such consent must be freely given, specific, informed, and revocable • Privacy policy should be written in clear and understandable terms • It should be as easy for your customers to withdraw consent as it was to give it in the first place • If you process children's personal data, verify their age and ask consent from their legal guardian • When you update your privacy policy, you inform existing customers https:/ /gdprchecklist.io 33
34. GDPR consists of 99 articles Сhecklist for management Сhecklist for engineers Checklist for secutiry GDPR Consultancy HOW to be GDPR compliant 34
35. Technical part 35
36. WHAT PostgreSQL can do for you? • Security • Encryption • Anonymization 36
37. Security 37
38. PG_PERMISSION Gaining an overview • Before we get started: ◦ Let us get an overview of what we have? ◦ Which permissions are there? ◦ Which ones SHOULD be there? • pg_permission can help in this case • https:/ /github.com/cybertec-postgresql/pg_permission 38
39. PG_PERMISSION Deep insights... 39
40. PG_PERMISSION Desired permissions vs. reality • What you want is often not what you got • Compare “reality” to “should be” • Declarative permissions can help 40
41. PG_PERMISSION Desired permissions vs. reality INSERT INTO public.permission_target (role_name, permissions, object_type, schema_name) VALUES ('appuser', '{SELECT,INSERT,UPDATE,DELETE}', 'TABLE', 'appschema'); INSERT INTO public.permission_target (role_name, permissions, object_type, schema_name) VALUES ('appuser', '{SELECT,INSERT,UPDATE,DELETE}', 'VIEW', 'appschema'); 41
42. PG_PERMISSION Detecting weakspots... 42
43. pg-need-to-know Mandatory Access Control • Designed to be used as a REST API in conjunction with postgrest ◦ For users: ownership, insight and consent-based usage ◦ For admins: fine-grained access control, audit information ◦ For developers: a rich REST API, with a built-in auth model • https:/ /github.com/leondutoit/pg-need-to-know • https:/ /youtu.be/ZvJIam7SybI 43
44. pg-need-to-know Mandatory Access Control • “module” - really just a set of tables, views, and functions • implements Mandatory Access Control • more limited approach than SEPostgreSQL • written in PL/pgSQL • Row-Level Security policies to implement MAC • designed to be used via a REST API 44
45. Encryption 45
46. Transparent Data Encryption: Securing data on disk • PostgreSQL can: ◦ encrypt data transfer between client and server • PostgreSQL can not: ◦ encrypt data on disk • Cybertec data-at-rest-encryption can ◦ encrypt data on disk 46
47. WHY ENCRYPT ON DISK: • In some cases encryption is required: ◦ Regulations ◦ Internal ◦ Requirements ◦ Customer wishes 47
48. HOW it works • We encrypt in block level • Encryption/decryption happens in I/O 48
49. Transparent Data Encryption: Benchmarking Workload Without encryption With encryption Penalty Bulk insert (pgbench init on scale 200, ~2.6GB of data) 32s 75s 134% Read only from shared_buffers 21657 TPS 21462 TPS 0.9% Read-write (1:3 ratio) fitting into shared buffers 3600 TPS 3154 TPS 12% Read-only not fitting into shared buffers 19876 TPS 12328 TPS 38% Read-write (1:3 ratio) not fitting into shared buffers 3418 TPS 2685 TPS 21% 49
50. Encryption off-loading: External crypto comparator • FDE does not protect against OS-level attacks ◦ rogue sysadmin ◦ someone gaining remote access to the box or backups • Nor does FDE protect against database-level attacks • In case of `pgcrypto` the database has to know the keys ◦ http:/ /momjian.us/download/pgcryptokey/ • https:/ /blog.2ndquadrant.com/databases-vs-encryption/ 50
51. HOW it works • Crypto component performs operations on behalf of a database • It receives encrypted values, decrypt, compare them, and return -1/0/1 just like regular comparator 51
52. Encryption off-loading: Proof of Concept • `ccnumber` extension implements a custom data type • offloads comparisons to component, either over TCP or IPC • encryption is done using libsodium • https:/ /github.com/tvondra/ccnumber 52
53. Anonymization 53
54. Anonymization The key benefits: • Anonymous data is not personal data for the purposes of GDPR • You don’t need to get consent to process it • You can use it for other purposes than the ones it was collected for ◦ You can even sell it! ◦ You can ever print and burn it! • It can be stored for an indefinite period of time • It can be exported internationally 54
55. Anonymization The prove of efforts: • part of a privacy by design strategy • part of a risk minimization strategy • a way to prevent personal data security breaches • part of a data minimization strategy 55
56. HOW 87% of the American population can be uniquely identified by a combination of just their ZIP code, gender, and date of birth! © Latanya Sweeney, 2000 important anonymization is 56
57. DATA MASKING: Providing test data • Do you want to pass a full copy of all your data to developers? ◦ In many cases not ... • Provide an obfuscated copy to developers ◦ Define an obfuscation model ◦ Create a “backup user” ◦ “Special” dump has “obfuscated” data • Product available to support customers of Cybertec 57
59. Anonymization How to measure effectiveness: • Singling out - the possibility to isolate some or all records which identify an individual in the dataset • Linkability - the ability to link at least two records concerning the same data subject or a group of data subjects (either in the same database or in two different databases) • Inference - the possibility to deduce, with significant probability, the value of an attribute from the values of a set of other attributes • 59
60. DATA MASKING: 1. Suppression aka Nullification UPDATE people SET name = '<CONFIDENTIAL>'; UPDATE people SET address = NULL; 60
61. DATA MASKING: 2. Random Substitution UPDATE people SET name = md5(random()::text); UPDATE people SET salary= 100000*random(); 61
62. DATA MASKING: 3. Variance UPDATE people SET salary = salary * (1+(2*random()-1)* 0.25) ; 62
63. DATA MASKING: 4. Encryption CREATE EXTENSION pgcrypto; UPDATE people SET name = crypt('name', gen_salt('md5')); 63
64. DATA MASKING: 5. Shuffling UPDATE people SET salary = (SELECT salary FROM people ORDER BY random() LIMIT 1); 64
65. DATA MASKING: 6. Faking aka Mocking UPDATE people SET name = fake_name('he_IL'), address = fake_address('25006', 'UA'); 65
66. DATA MASKING: 7. Partial Suppression UPDATE people SET phone = overlay(phone placing 'XXXX' from length(phone)/2 for 4); 66
67. DATA MASKING: 8. Generalization SELECT id, int4range(age/10*10, (age/10+1)*10) AS age FROM people; 67
68. postgresql_anonymizer Hide your data • work mainly on shuffling, variance, faking and dynamic masking • goal is to extend the DDL syntax • project is at an early stage of development • https:/ /gitlab.com/dalibo/postgresql_anonymizer 68
69. Thinking Out Loud 69
70. Right to be forgotten • when the data is no longer necessary ◦ you should delete it ▪ then you want partitioning ▪ faster than DELETE … FROM ▪ no need for VACUUM ◦ you should anonymize it • consider contest withdrawal as well 70
71. Right to be forgotten • what to do with backups? ◦ nobody knows ▪ you might want to provide delete procedure after restore ▪ your data may be encrypted, so just throw away the keys • what to do with logs? ◦ do not log sensitive data 71
72. Right for portable data • XML • JSON • CSV • pg_dump --inserts 72
73. • GDPR compliance is not only a technical issue • PostgreSQL can help with it • You should produce docs, checklists, roadmaps etc. • Consider hiring DPO or consultants SUMMARY 73
74. • https:/ /gdprchecklist.io • https:/ /github.com/cybertec-postgresql/pg_permission • https:/ /gitlab.com/dalibo/postgresql_anonymizer/ • https:/ /github.com/leondutoit/pg-need-to-know • https:/ /blog.2ndquadrant.com/databases-vs-encryption/ LINKS I have some 74
75. QUESTIONS 75
76. Living in GDPR world Pavlo Golub Senior Database Consultant pavlo.golub@cybertec.at @PavloGolub 76