Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Как создать GDPR-compliant-продукт

Как создать GDPR-compliant-продукт

Доклад Сергея Горохова (EPAM Systems) для PDUG-секции на PHDays 9.

More Decks by Positive Development User Group

Other Decks in Programming

Transcript

  1. Заголовок ptsecurity.com GDPR and security: how to make a GDPR-

    compliant product Security Architect EPAM Systems Сергей Горохов
  2. Заголовок 2 • About 20 years in Software Development •

    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
  3. Заголовок 3 • What is GDPR and what is it

    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 
  4. Заголовок 4 From Wikipedia: “The General Data Protection Regulation (EU)

    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?
  5. Заголовок 6 What GDPR is about? • Software? Wrong! •

    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
  6. Заголовок 7 GDPR Structure (260 pages overall) – 1/2 Chapter

    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”
  7. Заголовок 8 GDPR Structure (260 pages overall) – 2/2 Chapter

    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)
  8. Заголовок 10 From GDPR: “'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;” What is PII? – can be pretty much anything
  9. Заголовок 11 • Information to be provided to the Data

    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
  10. Заголовок 12 • Right to restriction of processing • Notification

    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
  11. Заголовок 13 From GDPR: • 'controller' means the natural or

    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)
  12. Заголовок 14 From GDPR: “'processing' means any operation or set

    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?
  13. Заголовок 16 • GDPR is about Human rights to control

    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
  14. Заголовок 17 • GDPR does not direct us how to

    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
  15. Заголовок 18 • Again - this is not correct •

    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
  16. Заголовок 19 • No software can make an Organisation (Controller)

    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
  17. Заголовок 20 • Same comment: no tool can make an

    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
  18. Заголовок 21 Example: Azure and GDPR – nobody is saying

    Azure “GDPR-compliant” https://www.microsoft.com/en-us/TrustCenter/CloudServices/Azure/GDPR
  19. Заголовок 22 • This is not that strict • Penalties

    (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
  20. Заголовок 24 From GDPR: “Taking into account the state of

    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)
  21. Заголовок 25 • GDPR does not give us any direct

    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)
  22. Заголовок 26 • Notifications about breaches of the Authority and

    Data Subject Security part of GDPR (Chapter III, Section 2, Article 33/34)
  23. Заголовок 27 • User trusts us with personal data –

    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
  24. Заголовок 28 Full Picture: Responsibility of Software Security within GDPR

    Controller Human Rights Consent Control over PII Protection of PII Software Security Infrastructure Security Secure Operations Business Processes Physical Security
  25. Заголовок 29 Inconsistency makes the whole work useless Controller’s IT

    Ecosystem: should be GDPR-consistent Controller System 1 Human rights Security System 2 Human Rights Security System N Human Rights Security
  26. Заголовок 30 • Organisational vs technical mechanisms • Business processes

    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
  27. Заголовок 33 • Remove yourself from the GDPR equation if

    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!
  28. Заголовок 34 • Put PII in the center of the

    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
  29. Заголовок 35 • Ask Questions – how human rights are

    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
  30. Заголовок 36 • Reuse – maybe somebody in Controller’s Ecosystem

    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)
  31. Заголовок 37 • How other systems in the Controller’s Ecosystem

    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)
  32. Заголовок 38 • Reuse approaches of other systems in Controller’s

    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)
  33. Заголовок 39 • Reuse how other systems in Controller’s Ecosystem

    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)
  34. Заголовок 40 • Plan your code and code your plan

     - 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
  35. Заголовок 41 • Security Testing as usual • Test regularly

    • Consider Both External AND Internal Attackers • Test not only security vulnerabilities, but also GDPR features Security Testing
  36. Заголовок 42 • If you formulate requirements – right them

    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
  37. Заголовок 43 • GDPR is NOT about Security, it’s about

    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