About 14 years at EPAM Systems • Started as a Developer (C++, .NET) • Solution Architect • AppSec Architect, Security Practice • I’m NOT a Lawyer or a legal person • Also a Freediver – that’s another story About Speaker
not? • Common misconceptions about GDPR • Security in GDPR • How Security can help in GDPR journey? Agenda and Disclaimer Too much text and too boring – sorry for that! Don’t read everything! I’ll explain anyway! It’s still better than to read GDPR itself
2016/679 ("GDPR") is a regulation in EU law on data protection and privacy for all individuals citizens of the European Union (EU) and the European Economic Area (EEA). It also addresses the export of personal data outside the EU and EEA areas. The GDPR aims primarily to give control to individuals over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU.[1] Superseding the Data Protection Directive 95/46/EC, …“ What is GDPR?
Security? Wrong! • Encryption of PII? Wrong! It’s about Human Rights and how Organizations exercise them! # of entries for keywords: Encryption – 4 times Pseudonymisation – 15 times Security – 53 times Rights – 179 times Encryption Pseudonymisati on Security Rights # of entries for keywords 4 15 53 179 0 20 40 60 80 100 120 140 160 180 200 Название оси # OF ENTRIES FOR KEYWORDS
Size Description Recitals with explanatory remarks 106 pages (2-107) Supporting explanations, not regulation I: General Provisions 9 pages (108-116) Definitions etc II: Principles 12 pages (117-128) Principles of processing: Lawfulness – consent, good reason, legal obligations, etc III: Rights of Data Subject 21 pages (129-149) Self-explanatory IV: Controller and processor 35 pages (150-184) What are they and what is their liability. Only 4 pages here are about security! V: Transfers of personal data to third countries or international organisations 14 pages (185-198) “All animals are equal, but some animals are more equal than the other”
Size Description VI: Independent supervisory authorities 14 pages (199-212) Who can help in case of doubts and will investigate complaints VII: Cooperation and consistency 25 pages (213-237) How Supervisory Authorities collaborate VIII: Remedies, liability and penalties 11 pages (238-248) IX: Provisions relating to specific processing situations 6 pages (249-254) X: Delegated acts and implementing acts 2 pages (255-256) XI: Final provisions 4 pages (257-260)
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;” What is PII? – can be pretty much anything
Subject (when PII is collected) • Rights of access by the Data Subject (e.g. get a copy of PII) • Right to rectification • Right of erasure (“right to be forgotten”) Human (Data Subject) Rights – 1/2
obligation regarding rectification, erasure, restrictions (to any other recipient of personal data) • Right of data portability • Right to object (of further processing, including direct marketing) Human (Data Subject) Rights – 2/2
legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, … • 'processor' means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller; Controller (not us) vs Processor (us)
of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction; “ Please forget that you see me now – you’re violating my rights! What is Processing?
their PII • Security is only a logical and necessary part of it • It means one cannot become GDPR compliant through security GDPR is about security of PII
protect PII • It just mentions recommendations and best practices – more of it later • It’s up to us to decide what makes sense in our case • But if data is leaked – you’ll have to answer awkward questions about adequacy of your security measures We MUST encrypt all PII at rest and in-transit
It only encourages us to use measures adequate for our risks • There’s no one “right” way to do GDPR in terms of security GDPR clearly directs how to protect PII
GDPR compliant: • Compliance includes organizational structure, people, business processes along with many IT systems that make an Organisation • We can address certain aspects on our level as agreed with the Organisation or we can help with defining a “reference model”, but it’ll cover much more than just cyber-security of the software We can build “GDPR-compliant software” But software can definitely be built in a way that violates GDPR
Organisation GDPR compliant • But 3rd party products can help with certain aspects: • Consent management • Data protection • Segregation of Duties (e.g. Secret Management, BYOK) • Etc • Examples: Azure and GDPR, AWS and GDPR, SQL Server and GDPR We can buy a “magic” GDPR-compliant tool
(Article 83) • Violation of security rules (articles 32, 33, 34) – up to 10 millions Euro or up to 2% of revenue • Violation of rights – up to 20 millions or up to 4% of revenue • There’re examples of GDPR charges so far – they’re very modest Penalty for GDPR violation is 20 mln of Euro
the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia (among other things) as appropriate:” • Pseudonymisation and encryption • Ability to ensure the ongoing CIA of processing systems and services • Ability to restore after technical incidents • A process of regular testing and assessing of technical and organizational security measures Security part of GDPR (Chapter III, Section 2, Article 32)
rules that must be implemented in terms of security, just examples of best practices • Adherence to code of conduct or approved certification may be used • No physical person with access to PII should process data beyond what is instructed Security part of GDPR (Chapter III, Section 2, Article 32)
don’t distribute it further • How you do it – it’s your (or Controller’s) responsibility; • If you failed in point 1 – notify Data Subject and Authority Security Part of GDPR: Summary
Controller Human Rights Consent Control over PII Protection of PII Software Security Infrastructure Security Secure Operations Business Processes Physical Security
to exercise Human rights (providing information, capturing consent, rectification/removal, restrictions etc) • One company – many IT systems (IT ecosystem), all need to be in- line in terms of GDPR compliance Controller (Organization) defines how to comply, not us
possible • If you’re a software vendor – you’re NOT a Processor by default • Unless you have access to production PII After that you can help with secure implementation of any GDPR requirement (as any other requirement) Step 0: Take care of yourself – Avoid being a Processor!
Risk Assessment then build the rest around this assumption • Categorization of PII • Appropriate protection measures • Level of access to any people who can access PII – external and internal • Stay consistent with other products in this ecosystem (if any) – even if not produced by you Step 1: PII-centric Secure SDLC and Secure Operations
exercised by a Controller and how your product can help • Design “Human Rights”-features according to Secure SDLC: • Secure Feature (as opposed to Security Feature) Step 2: Help in implementation of “Human Rights”-features
has already done Risk Assessment for the controller and you can use results • Protect What? Risk-based approach – PII categorization • Protect from whom? GDPR is about TOTAL protection of PII – consider both External and Internal Attackers • Mind geo-location – this is where real world meet the cyber world, not all animals are equal • Politics, social/criminal situation, technological level Requirements – protect PII (security reqs)
implemented it? • Maybe you don’t have to implement them • Or just reuse their solutions • What are business processes around those features and how they’re envisioned to be working? • Potential areas: • Consent – gathering, storing, withdrawal • Right to be forgotten • Export of PII and handling to a Data Subject • Detection of the breach Requirements – Implement “Human Rights” features (non-security reqs)
Ecosystem • Be consistent in implementing security measures (“Reference Security Architecture”) • PII protection • Who should have access? Including Operation Teams • Access Control Lists (ACLs) • Tokenization, obfuscation, data masking • Encryption (hardware, file system, data storage, app levels) • Don’t forget Risks identified on the Requirements stage to define “adequacy” • Multi-level Security as usual (defense in depth) • Work with Controller’s AppSec and SecOps Teams on reusable centralized solutions Architecture and Design – PII protection (security features)
implement them • Implement them securely (Secure Feature vs Security Feature) • Consent? – new Sensitive Asset in terms of Consistency • Right to be forgotten? • Where this command comes from? • Operational databases • Data lakes etc (data storages for reporting) • Archives/backups • What is SLA of total “forgetting”? • Automated notification about breaches or access changes? • SIEM, Intrusion Detection Architecture and Design – “Human Rights”-features (non-security features)
- follow Threat Model and planned mitigations • Follow “best practices” -> they’re just reflection of “natural” mitigations that are always needed. • GDPR-compliant SAST is a myth Implementation
down • If you design for GDPR sake – document your decisions, trace them back to requirements • Document your Access Control Lists • If you test – keep your reports ready Document all GDPR-related efforts, decisions and activities
Human Rights • Software cannot make Organisation GDPR-compliant • Avoid being a Processor if possible • Implement PII-centric Secure SDLC • Help securely implement GDPR-related features Key Take-aways
pdugslides
seike460
masayaaoyama
hollycummins
sugi_0000
onihusube
kwakeuijin
okuzawats
chrisbanes
kentatada
dunglas
fabpot
ttskch
destraynor
ammeep
sergeychernyshev
thekraken
chrisshort
jcasabona
iamctodd
addyosmani
chriscoyier
jacobian
vanstee
aki_iinuma
