EU GDPR and Security Compliance for the DBA Santa Clara, California | April 23th – 25th, 2018
Meet Your Presenters Tyler Duzan Jeff Sandstrom • Product Manager for MySQL • Product Manager for MongoDB Software at Percona Software at Percona • Prior to joining Percona was an • Jeff has been a Product Manager Operations Engineer for more for over ten years, first in the than twelve years contact center space, then enterprise voice, and now open • Background in security and source databases. He's a compliance, specifically PCI, business nerd who loves tech. HIPAA/HITECH, HITRUST, SOC, and FEDRAMP & FISMA. 2
Disclaimer • We are not Attorneys, we are Product Managers • Nothing within this presentation should be construed as legal advice • You should consult with an attorney to understand and mitigate any compliance risk for your organization • This presentation is not all-inclusive, we are discussing specific selected Articles of the GDPR we think are especially relevant 3
Outline 1. General Overview of Compliance 2. GDPR Key Terminology 3. EU GDPR Articles a DBA Should Know • Article Overview • Articles of Particular Interest to DBAs • Deep Dive into Article 17, Article 25, Article 32-35, and Article 44 4. How Does Percona Software Help to Solve This? 5. Open Questions for DBAs to Consider 6. Q&A 4
General Overview of Compliance
Compliance Objectives • Build a secure infrastructure and know where sensitive data resides • Implement consistent security and data-handling standards across the enterprise • Design and implement effective controls for access to sensitive data • Provide a pathway to audit the organization • Reduce risk to the organization from data breaches • Protect your customers and partners who have entrusted you • Protect shareholder value 6
Why Compliance Matters to the DBA • Datastores across the enterprise may likely contain sensitive data • Databases are a primary target for malicious actors attempting a data breach • Most compliance regulations specifically prescribe methods and techniques that must be used for datastores • The DBA is often the primary responsible party for implementing compliance controls and technical measures for protecting data 7
How Has Compliance Changed? • Compliance regulations began by targeting specific industry verticals such as healthcare, finance, and government. • The focus of early compliance was really on mitigating broad organizational risk, typically when handling data that had large financial risk implications or national security implications • Later compliance regulations began focusing on the safety of consumer data as technology became integral to our daily existence • Many of these regulations limited coverage to situations where the consumer might be directly financially impacted by a breach and where a clear and direct customer relationship existed 8
How Has Compliance Changed? • Lately compliance regulations have shifted because of a shifting environment both in technology and economics. • Current compliance regulations must take into account the existence of cloud providers, the ubiquity of Software-as-a-Service (SaaS) applications for both businesses and consumers, and the rise of sophisticated attacks. • We now exist in a world where great harm can be caused at scale using data that was previously thought to be innocuous. Many of these are first of their kind attacks. • EU GDPR seeks to address many of these concerns by emphasizing that fundamental ownership of data resides with the person whom that data is about. 9
GDPR Key Terminology
Terminology • Data Controller • The entity that is determining the purposes and means of processing the data. - Example: A social media application collecting user information, a manufacturing company collecting personal data about employees, etc. • Data Processor • The entity that processes data on behalf of the Data Controller. - Example: A payroll company that is issuing paychecks for a manufacturing company’s employees, a cloud service provider storing personal data • Data Processing • Any automated or partially automated operation performed on personal data 11
Terminology • Data Subject • A natural person whose personal data is processed by a Controller or Processor • Personal Data • Any information that can directly or indirectly identify the Data Subject - Examples: • Biometric data • Health data • Online identifiers • Geolocation data • PII (name, address, government ID number, etc) • Profiling • Any data processing intended to evaluate, analyze, or predict the behavior of a Data Subject 12
GDPR Articles DBAs Should Know
GDPR Articles Overview • Chapter 1: General Provisions • Chapter 5: Transfer of personal data to third countries of • Article 1-4 international organizations • Chapter 2: Principles • Article 44-50 • Article 5-11 • Chapter 6: Independent • Chapter 3: Rights of the Data Supervisory Authorities Subject • Article 51-59 • Article 12-23 • Chapter 7: Cooperation and • Chapter 4: Controller and Consistency Processor • Article 60-76 • Article 24-43 14
GDPR Articles Overview • Chapter 8: Remedies, Liabilities, • Chapter 11: Final Provisions and Sanctions • Article 94-99 • Article 77-84 • Chapter 9: Provisions relating to specific data processing situations • Article 85-91 • Chapter 10: Delegates Acts and Implementing Acts • Article 92 & 93 15
Articles of Particular Interest to DBAs • Article 17 • Article 32 • “the (…) controller shall have the • Security of data processing obligation to erase personal data • Article 33 & 34 without undue delay, especially in • Notification of a personal data relation to personal data which are breach to the supervisory authority collected when the data subject was a child, and the data subject shall • Communication of a personal data have the right to obtain from the breach to the data subject controller the erasure of personal • Article 35 data concerning him or her without undue delay.” • Data protection impact assessment • Article 25 • Article 44 • Data protection by design and by • General principles for transfers default 16
General Areas of Concern in GDPR • Change Management • Data Discovery and Classification • Environmental Evaluation • Establishing Appropriate Internal Processes • Auditability • Internally defining ethical walls • Tracking location of data by user / Data Mapping 17
Article 17 • Establishes a legislative structure which resides ownership of data with the Data Subject • Establishes the “Right to be Forgotten” as EU Law • “the (…) controller shall have the obligation to erase personal data without undue delay, especially in relation to personal data which are collected when the data subject was a child, and the data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay”. • Expands deletion requirements to now include the obligation for the Data Controller to inform anyone else who has the Personal Data when a deletion request is received, extending to Data Processors or copies of that data 18
Article 25 • Enshrines the concept of data protection by design and default • Requires that controls must be in place to ensure that • Personal Data cannot be attributed to an identified or identifiable Data Subject • Only the Personal Data necessary for a specific purpose can be processed • Only the Personal Data necessary for a specific purpose is collected • Data that is no longer needed should be deleted • Implies strongly specific technical requirements, which in some cases are defined elsewhere • Data minimization, data masking, data pseudonymization • Implementing strict ethical walls and access controls within your organization for seeing Personal Data • Utilizing best practice methods for protecting Personal Data when stored 19
Article 32 • Requires both Data Controllers and Data Processors to implement certain technical and organizational measures • These measures help to prescribe how to handle the philosophical basis of EU GDPR • Technical examples • Encryption for data that is both “at rest” and “in motion” • Monitoring and auditing access to Personal Data • Data masking for applications which access Personal Data • Organizational examples • Maintaining data accessibility and planning for a response to a breach • Testing and evaluating the effectiveness of your controls • Auditability of your environment 20
Article 33 and 34 • Establishes the requirements for informing regulators (Supervisory Authority) and users (Data Subjects) when a breach occurs • Data Controllers must inform the appropriate Supervisory Authority within 72 hours of a data breach occurring or provide a substantial reason for any delay • Data Processors must notify Data Controllers immediately as soon as they become aware of a breach • If a data breach presents risk to users Data Controllers and Data Processors must individually notify affected Data Subjects, without undue delay . • If it’s not possible to provide all required information initially, it can be provided in phases through multiple notifications 21
Recommend
More recommend
