General Data Protection Regulation (GDPR) for Identity Architects

Asanka Abeysinghe, Vice President, Solutions Architecture

Prabath Siriwardena, Senior Director, Security Architecture

GDPR OVERVIEW

3

WHAT IS GDPR?

• The EU General Data Protection Regulation (GDPR) is the regulation 2016/679 of the European parliament and of the council, which replaces the Data Protection Directive 95/46/EC.

• Enforceable from 25th May 2018

4

SIX KEY PRINCIPLES

• Personal data must be processed lawfully, fairly and transparently. • Personal data can only be collected for specified, explicit and legitimate

purposes. • Personal data must be adequate, relevant and limited to what is necessary

for processing. • Personal data must be accurate and kept up to date. • Personal data must be kept in a form such that the data subject can be

identified only as long as is necessary for processing. • Personal data must be processed in a manner that ensures its security.

5

WHOSE DATA ARE PROTECTED?

• Individuals based in the EU, wherever in the world their data ends up being held or used.

• It also applies to anyone else's (even non EU residents) personal data if it is handled from the EU.

• Not about citizens!• Time of stay of the user in the EU?

– GDPR does not specifically talk about this.– Time of data processing (not decisive)– Time of data collection (decisive)

6

WHICH DATA ARE PROTECTED?

• Processing of any personal data, is protected under GDPR.

7

PERSONAL DATA

• Any information that could be used to identify the data subject is personal data, and this information can be in any format. This can encompass photographs, correspondence, physical media and so on.

• One 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.

• The regulation is not applicable to the personal data of a deceased person.

8

PERSONAL DATA (SPECIAL CATEGORIES)

• Personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union memberships.

• Data concerning health or an individual’s sex life or sexual orientation, as well as genetic data and biometric data .

9

WHAT FALLS UNDER PROCESSING?

• Any operation or set of operations that is performed on personal data, whether or not by automated means.

• Collecting, recording, organizing, structuring, storing and erasing of data.

10

WHAT BUSINESSES WILL GET IMPACTED?

• Any business inside or outside EU, which offers goods and services to data subjects in EU.

• Any business inside EU which offers goods and services to anyone in the world.

• Under the European Economic Area (EEA) Agreement, the Regulation applies throughout the EEA as well as in the 28 Member States of the EU.

• For example an Australian company does not necessarily address its goods or services to individuals in England or Scotland, just because their website is available in English.

• To fall under GDPR, any company outside EU, must intend to address European consumers.

11

DATA CONTROLLER

• The entity which determines the purposes and means of the processing of personal data.

• These will usually be the ‘public-facing’ entities that data subjects supply their information to.

• For instance, a hospital might have an online form for entering health information; even if the online form is provided by a third party, the hospital (which will determine what the data is processed for) will be the data controller.

• If the data processing involve high-risk the controller has to carry out a data protection impact assessment (DPIA) on the impact of the corresponding processing activities.

12

DATA PROCESSOR

• The entity which processes personal data on behalf of the controller.• In many cases, the data controller and the data processor will be the same

entity. • In the previous example, the organisation that provides the online form will

be a data processor because the act of collecting data is included within the definition of ‘processing’.

• A single data controller may have several data processors.• Not a third party. A third party is some other party, other than the data

subject, controller or the processor.

13

SUPERVISORY AUTHORITY

• Each member state will have its own supervisory authority.• Upon request by the supervisory authority, both the controller and the

processor are obliged to demonstrate their compliance with GDPR.• Accepts complaints from the data subjects.• Plays a key role during the data protection impact assessment (DPIA),

provides advice to the controller on a case-by-case basis.• During the DPIA if the controller finds a high risk item, the supervisory

authority needs to be consulted.• The controller has to notify the supervisory authority in case of a personal

data breach in less than 72 hrs after becoming aware of it.• The processor does not have an obligation to notify a data breach to the

supervisory authority, but to the controller.

14

DATA PROTECTION OFFICER

• Motivated by the German Data Protection Law - where DPOs have proven to be successful for more than 30 years.

• Both the controller and processor can have a designated data protection officer.

• A data protection officer can provide his/her services to multiple data controllers/processors.

• The data protection officer is the glue between the controller/processor and the supervisory authority.

• Provides advices to the controller/processor and their employees on data protection obligations.

15

REPRESENTATIVES BY NON-EU ENTITIES

• Entities do not have an establishment in EU, but still fall under GDPR, have to appoint a representative in the EU.

• This representative acts as the point of contact between the non-EU controller/processor and the supervisory authority.

• Does not applicable for the companies which do occasional processing of personal data, no large scale processing on special categories of personal data and unlikely to result in a risk to the rights and freedom of individuals.

16

GDPR ORGANIZATIONAL STRUCTURE

DATA SUBJECT’S RIGHTS

18

• The data subject must be informed of the existence of any processing operations on its personal data.

• The controller must provide minimum information on processing to the data subject.

• During the data collection, the controller has to provide its identity and contact details

– Also where applicable the contact details of the data protection officer.• The controller must share the purpose and legal basis for data collection

and processing.

THE RIGHT TO ACCESS / BE INFORMED (1/2)

19

THE RIGHT TO ACCESS / BE INFORMED (2/2)

• The controller must share the details of the recipients of the personal data.• Need to specify the intention of the controller (if any) to transfer data to a

third country.• The period for which the personal data is stored.• The information about the data subject’s rights.

– The right to withdraw a given consent– The right to lodge a complaint with the supervisory authority

• The controller is obliged to respond to a request by the data subject within 1 month of receipt of the request.

20

THE RIGHT TO RECTIFICATION

• The data subject has the right to rectify processing of incomplete personal data .

• The right to rectification helps to correct or prevent negative effects on the rights and freedom of data subjects.

21

THE RIGHT TO ERASURE

• Ground for erasure– The personal data are no longer necessary in relation to the purpose for

which they were processed.– The data subject withdraws consent on which the processing is based,

and there is no other legal ground for the processing.– The personal data has been unlawfully processed– The personal data has to be erased for compliance with a legal

obligation under EU or EU member state law.• The data subject has the right to demand from the controller the erasure of

personal data.

22

THE RIGHT TO ERASURE

• Erasing data means, it should not be possible to restore the data without excessive efforts.

• Examples:– Search engines which index personal data– Social networking sites

23

THE RIGHT TO RESTRICTION OF PROCESSING

• Grounds for restriction of processing– The accuracy of data is contested by the data subject.– Processing is unlawful, and the data subject opposes the erasure of its

personal data and requests the restriction of their use instead.– Controller does not require the data for the purpose the data was

collected - but the data subject requires them for defence of legal claims.

– Data subject objects for data processing

24

THE RIGHT TO DATA PORTABILITY

• Provides the possibility to transmit data subject’s personal data from one controller to another.

• In this regard, the legislator primarily targeted the operators of social networks.

• Strengthen the competition among service providers.• Any data that has been generated by the controller as part of processing,

such as by a personalization or recommendation process is not covered by the right to data portability.

IAM DESIGN PRINCIPLES AND

BEST PRACTICES

26

DECOUPLE PERSONAL DATA FROM TRANSACTIONAL/BUSINESS DATA

• Personal data can be the data provided by the subject or the raw data provided to the controller by other means.

• Limit the personal data stored under IAM system - and let other business applications store business specific data.

• For example IAM system should not worry about following data.– If it’s a bank, the transaction history of the data subject or the credit

history.– Data related to background checks about employees. – Performance ratings– Buying patterns

• Decouple biometrics from other personal data.

27

IMMUTABLE PRIVATE IDENTIFIERS / MUTABLE PUBLIC IDENTIFIERS

• Use an immutable private identifier (pseudonym) to identify a user. • Never use personal data in audit logs - rather the pseudonym.• Capture and record all the analytics against the pseudonym.

28

DECLARE AND GET THE USER CONSENT FOR THE IAM COOKIE POLICY

• Use cookies only to manage user sessions and identify user preferences.• Explain the user the usage of cookies - and the options to reset.• Do not save any data in cookies, even encrypted.• Do not track the behavior of anonymous users via cookies.• Upon registration - or during the login process get the user’s consent to the

cookie policy.

29

DECLARE AND GET THE USER CONSENT FOR THE IAM PRIVACY POLICY

• Explain briefly how personal data are maintained - and the security policy.• Specify explicitly if personal data are exported to a non-EU country for

processing.

30

PSEUDONYMISED SYSTEM IDENTIFIERS

• Never push IP addresses / device ids to audit logs or analytics systems.• Create pseudonyms for all system identifiers and maintain a mapping table.

31

COLLECT ONLY THE MINIMAL REQUIRED DATA

• During the user onboarding process collect only the required minimal set of personal data - with the user consent.

• Do not collect data for the future anticipated use.• Keep the ability collect more personal data as and when needed.• Have an expiration policy for each attribute - by default keep no expiry.

32

SHARE PERSONAL DATA WITH USER CONSENT

• Irrespective of the identity federation protocol in use - never share personal without user consent.

• In non-federation scenarios, when releasing personal data to other applications via APIs, make sure those applications have recorded the user consent.

• Let the business applications manage their own consent on how the personal data are processed at the application level.

• Maintain user consent by attribute by application - with an expiry.• The IAM system can offload the consent management from each application

- and provide an API to record consent centrally against those.

33

SELF CARE PORTAL

• Provide a portal, where users can login and export their personal data.– IAM system should only worry about giving an option to export the

personal data it collected from the user.– IAM system can decide, in addition to the above what other personal

data available to export.• The portal should provide consent management facility.

– Users can view, update and revoke a consent already provided.• The portal should have an option execute data subject rights to

– Request to rectify any issues with the personal data.– Request to restrict processing of personal data.– Request to delete the account

34

USER OFFBOARDING

• Delete the user personal data.• Remove the mappings to all pseudonyms to the corresponding user.• The above will make all the audit logs and analytics anonymous - which is

safe under GDPR.• Notify all the upstream applications, where the corresponding user’s

personal data already being shared.

35

PRIVACY BY DESIGN ~ PRIVACY BY DEFAULT

• Make sure TLS 1.2 is used to protect all the data in transit with cipher suites supporting perfect forward secrecy.

• Protect the data at rest for integrity and confidentiality.• Rely on open standards.• Follow the best practices defined by Financial APIs working group under

OpenID Foundation to secure APIs.• Use message level encryption for bearer tokens - while sharing personal

data.• Follow digital identity guidelines defined in NIST SP 800-63.• Enable MFA for user login - a must for administrators.

ARCHITECTURE GUIDELINES

37

ARCHITECTURE CONSIDERATIONS

• Build an architecture to;– collect data { transaction | analytics }– control the usage of data { transaction | analytics }– store and manage the data { transaction | analytics }

38

GATEWAY PATTERN

• Route your incoming and outgoing traffic through a set of ‘Gateways’

– API Gateway – B2B Gateway – File Gateway – …..

• Enforce quality of services at the Gateway – Security – Analytics – Governance (mainly data and

runtime governance)

39

APIs

• Single source to access the data and business processes

• Internal and external APIs• Ability to expose different kind of

APIs– Business, application and data – Usage and analytics

40

STANDARDIZE BUSINESS OBJECTS

• Message/event payloads using schemas• Classify data• References to look-up data (registry)• Enforce usage policies • Include GDPR headers/fields if required (mandate it) • Annotate (info for pre/post-process of data) • Version • Introduce using APIs

41

ANALYTICS

• Usage data • Activity logs • Dashboards for various stakeholders

( including DPO )

42

GOVERNANCE

• Policy bases execution ( not only security policies ) • Workflows • Observability & surveillance

43

GENERAL (architecture) GUIDELINES

• Iterative architecture– Segment architecture

• Reuse existing technologies • Continuous-* • Use open standards • Open interoperability• Event-driven• Use patterns, templates

more info: https://www.slideshare.net/secret/4rRq0k7fqRkTxs

44

REFERENCE ARCHITECTURE - generic

Analytics

Continuous-*

Security & Access Management

API / Service discovery

Dev tools Devops tools

Service router

API Gateway

Core Microservices Data

Container(s)

Delivery channels Digital Products

Messaging Channels Integration MicroservicesExisting Services

Other Gateways

4545

Continuous-*

Security & Access Management API / Service discovery

Dev tools Devops tools

Service router

API Gateway

Core Microservices Data

Container(s)

Delivery channels Digital Products

Messaging Channels Integration MicroservicesExisting Services

Analytics

Analytics

Analytics

Analytics

Analytics

RUNTIME

46

COMPONENT ARCHITECTURE

47

OPEN TECHNOLOGY http://wso2.com

Build internal and external developer ecosystems with an API marketplace.

Manage identity, security, and

privacy across your digital

business.

Make mobile and IoTdevices integral to

your digital business.

Create real-time, intelligent, actionable business insights and data products.

Platform enable your digital business with “micro-services”

and “micro-integrations”.

48

UPCOMING WEBINAR

wso2.com

49