Modules for Model Driven Engineering: Personal Data Detector Code Validation Privacy Data Protection by Design

1. Methods and Tools for GDPR Compliance through
Privacy and Data
Protection 4 Engineering
Gabriel Pedroza (CEA)
Julien Signoles (CEA)
Victor Muntés-Mulero (Beawre)
Yod Samuel Martin (UPM)
Model-driven Engineering Tool and Method
for Privacy and Data Protection by Design
(WP5)

2. Outline
 Introduction and objectives
Privacy and Data Protection by Design (PDPbD): context and challenges
 Proposed method for PDPbD
 Tool support for the method
Personal Data Detector Module
Module for Privacy Model-driven design
Module for Code Validation
 Summary of achievements
29/06/2021 2 PDP4E WP5

3. Context
Design engineers’ ecosystem:
 Several stakeholders and actors
 Variety of needs and objectives
 Solution for conflicting goals/reqs.
Designer’s questions to address:
 Which privacy-aspects introduce
during systems design?
 How identified concerns can be
considered at early design steps?
 How privacy-by-design can be
effectively realized?
Data
Industry
Developers
Individuals
Policy
makers
Attackers
Wistleblowers
Engineers
Dark/hidden
actors
Image borrowed from https://www.digitalvidya.com/
Privacy and Data Protection by Design
29/06/2021 3 PDP4E WP5

4. Introduction & Objectives
 WP5 Methods and tools for privacy and data protection by design
 Participants: CEA (leader), BAW, UPM, Trialog
 Duration: M8 – M33
 Objectives:
 Methods and tools to realize GDPR and privacy precepts « by design »
 Integrate existing knowhow on systems and software engineering (modelling, formal methods)
 Integrate knowledge on privacy and data protection (properties, protections against threats)
 Integrate provisions of regulations, like GDPR, and standard recommendations, like ISO/IEC 27550
 Outputs:
 Deliverables:
o Specification of the method and modules: D5.1, D5.2 and D5.3
o Method releases: D5.4 and D5.5
o Modules releases: D5.6 and D5.7
 Tool support:
o Personal Data Detector
o Privacy Model-driven designer
o Module for code verification
29/06/2021 4 PDP4E WP5

5. PDP by Design Method
Main characteristics:
Combined bottom-up and top-
down approaches:
 From data structures to data and
data-flow (process) models
 Allocation over an architecture
model
 Architecture refinement towards
code
Identification of personal data
Models improved by Privacy-by-
design strategies (ISO/IEC 27550)
Validation of properties at code
level
29/06/2021 5 PDP4E WP5

6. Tool support for the PDPbD method
PDPbD Framework
1) Personal Data Detector
- Data structures
- Identified
personal data
- Confidence
scores
Code validation and
verification
- Privacy flaws
- Code improvement
2) Privacy Model-driven designer
3) Module for Code Validation
Target of Validation
- Components
- Pointers to code
- Privacy properties
29/06/2021 6 PDP4E WP5

7. Interactions with other PDP4E tools
Tool support for the PDPbD method
WP5
WP3
WP4
WP6
Requirements engineering:
• GDPR generated requirements
• Integrating aspects from ISO/IEC 29100
Risks analysis:
• Privacy threats conditions
• DFD elements involved
Assurance process:
• Reqs. Fulfillment
• Targets of validation
• V&V cases/outcomes
Personal Data Detector
• SQL data
• Scores on SQL data
• Exporting SQL data and
scores
Papyrus Data Models
• Instances of imported SQL
data
• Abstract representation of
imported SQL data
• Extension of UML class
diagrams
Papyrus Process Models
• Processes involving data
• Associations to abstract
representation of data
• Extension of UML Activity
diagrams (DFD)
Papyrus Architecture Models
• Non-automated allocation/mapping to target functional architecture
• Functional architecture : UML Composite Structure diagrams
• Components architecture: UML Composite Structure diagrams
Code Validation
• Requirements/properties
• Frama-C
• SecureFlow
• Extensions for PDP
29/06/2021 7 PDP4E WP5

8. PDPbD Framework
1. Personal Data Detector Module
Victor Muntés (Beawre)
Victor.Muntes@beawre.com
29/06/2021 8 PDP4E WP5

9. PDD Overview
Attribute
(Intentional)
Attribute
(Extensional)
Table
Level
Database
Level
Open data
Level
Attribute
(Extensional)
Table
(Inter-column)
Database
(Inter-table)
Open data
Level
Onion model
DB Annotated
with scores
29/06/2021 9 PDP4E WP5

10. PDD Output
Every column is scored for each level:
(sintensional ,sextensional , stable , sdatabase , sopendata)
Score based on
column schema
information
Score based on
column schema
and actual data
information
Score based on
table level
information
(inter-column
relationships)
Score based on
information
extracted from
open linked data
sources
Score based on
data base level
information
(inter-tables
information)
Likelihood (of PD) * Confidence (of Attr Type)
29/06/2021 10 PDP4E WP5

11. Leveraging Open Linked data:
Graph Creation
Person
1
Person
2
Person
3
isA
DB
entity 4
DB
entity 1
DB
entity 3
DB
entity 2
isA
isA
OPEN
LINKED
DATA
SYSTEM
DATA
linkableTo
isA
Class
1
Class
4
isA linkableTo isA
Class
2
Class
3
Class
5
linkableTo
isA
linkableTo
DB
entity 5
Class
5 isA
isA
FK
FK
FK
29/06/2021 11 PDP4E WP5

12. Leveraging Open Linked data:
Graph Creation
Person
1
Person
2
Person
3
isA
DB
entity
4
DB
entity
1
DB
entity
3
DB
entity
2
isA
isA
OPEN
LINKED
DATA
SYSTEM
DATA
linkableTo
isA
Class 1
Class 4
isA linkableTo
isA
Class 2
Class 3
Class 5
linkableTo
isA
linkableTo
DB
entity
5 Class 5
isA
isA
FK
FK
FK
29/06/2021 12 PDP4E WP5

13. User-Guided Likelihood Analysis DB Annotated
with scores
IDENTIFY LINK ASSESS
Original table
name
Originally proposed concept by
Wikidata
Chosen by user
address address (Q338075) postal address (Q319608)
owner master (Q19357897) Propietor (Q16869121)
registration registration (Q2399307) UNCHANGED
authorized_vehicle Emergency vehicle (Q1308737) vehicle (Q42889)
certificate certificate (Q196756) digital certificate (Q274758)
authority authority (Q174834) certificate authority (Q196776)
key key (Q132041) key (Q471771)
frame frame (Q1324888) UNCHANGED
vehicle vehicle (Q42889) UNCHANGED
Original table
name
Related persons
address personal data -> person property -> person
address personal data -> personal identifiable
information -> human -> natural person
owner legal person -> agent
registration N/A
authorized_vehic
le
vehicle operator -> person
certificate N/A
authority N/A
key N/A
frame N/A
vehicle vehicle operator -> person
Automatically detected classes from open data are
processed and refined by the user Related persons are recalculated from new concepts
refined by the user
User is allowed to decide the likelihood of an attacker to
connect entities in the DB with external data subjects
29/06/2021 13 PDP4E WP5

14. Demonstration
29/06/2021 14 PDP4E WP5

15. PDPbD Framework
2. Privacy model-driven designer
Gabriel Pedroza (CEA)
gabriel.pedroza@cea.fr
29/06/2021 15 PDP4E WP5

16. Privacy model-driven designer
Implementation
2. Develop a data-oriented model
3. Built-in privacy techniques for data-oriented models
4. Develop a process-oriented model
5. Built-in privacy techniques for process-oriented models
Continue the development cycle
DesignOK
DesignNotOK
1. Select GDPR requirements to be satisfied
29/06/2021 16 PDP4E WP5

17. 1. Select GDPR requirements
 Goal: select GDPR requirements to be fulfilled or analysed at the design phase
 A model-driven interface amenable to:
 Reuse outcomes from PDP4E-Req tool
 Keep traceability of requirements to be fulfilled (functional, GDPR)
Model-driven tool support: interoperable MDE interfaces requirements-design
 Feature 1: set links to allocate GDPR requirements to design (dependencies)
 Feature 2: set links for satisfiability <<satisfy>>
 Feature 3: set links for unitary test cases <<verify>>
29/06/2021 17 PDP4E WP5

18. 1. Select GDPR requirements
 Overview of selected requirements
29/06/2021
GDPRReq. When the <CITSFrame> breach is likely to result in a high risk to
the rights and freedoms of <VehicleOwner>, the <RSUServiceProvider> shall
communicate the <CITSFrame> breach to the <VehicleOwner> without
undue delay.
PDP4E-Req model 
Selected GDPR requirement 
Notifications. This feature is meant to ensure the respect of
the Data Subject rights, in particular, the right to be informed
by the respective Controllers (or Processors) whenever a
privacy breach impacting her/his Personal Data occurs.
Privacy concern 
18 PDP4E WP5

19. 2. Develop data-oriented model
 Goal: capture the data structures under study to analyse conformity w.r.t.
privacy precepts
 A modeling language amenable to:
 Reuse outcomes from the PDD: scores for classifying personal (non-personal) data
 Enrich, decompose, refine data structures
Model-driven tool support: a UML Class-like diagram to model data structures
 Feature 1: several built-in data types : Generic, Composite, Table, Data links, Opaque data
 Feature 2: user defined data structures (suitable for framework customization)
 Feature 3: full compatibility with PDP4E-Req models
 Feature 4: inherited traceability with GDPR requirements (PDP4E-Req tool)
29/06/2021 19 PDP4E WP5

20. 2. Data-oriented model overview
 Overview of a data-oriented model
User-defined data type 
29/06/2021 20 PDP4E WP5

21. 3. Strategy for data-oriented model
 Goal: apply known strategies to ensure data protection
 Data-oriented strategies proposed by ENISA, ISO/IEC-27550
 Minimize
 Separate
 Abstract
 Hide
Model-driven tool support: catalogue of strategies
 Feature 1: strategies to Abstract data ; K-anonymity
 Feature 2: strategies to Minimize data ; α-anonymity
 Feature 3: import data structures, e.g., raw tables
 Feature 4: import data from schema, e.g., data base schema
29/06/2021 21 PDP4E WP5

22. 3. Strategy for data-oriented model
 Overview of data-oriented strategies
WP4
Application of the strategy Strategy outcomes
29/06/2021 22 PDP4E WP5

23. 4. Develop process-oriented model
 Goal: capture the data flows and processes under study to analyse conformity
w.r.t. privacy precepts
 A modeling language amenable to:
 Support Data Flow Diagrams (DFD)
 Incorporate aspects related to privacy and data protection by design
Model-driven tool support: UML Activity-like diagram to model processes & data
 Feature 1: DFD profile: External Entity, Process, Data flow, Data storage, Ports
 Feature 2: Reusability of data-oriented structures (to type Ports)
 Feature 3: Full compatibility with PDP4E-Req models (inherited traceability)
 Feature 4: Leverage GDPR profile
29/06/2021 23 PDP4E WP5

24. 4. Process-oriented model overview
 Overview of a process-oriented model
29/06/2021
DFD profile
24 PDP4E WP5

25. 5. Apply process-oriented strategy
 Goal: apply known privacy strategies to improve DFD model
 Process-oriented strategies proposed by ENISA, ISO/IEC-27550
 Inform
 Control
 Enforce
 Demonstrate
Model-driven tool support: catalogue of strategies
 Feature 1: strategies to Control ; Consent pattern
 Feature 2: strategies to Inform ; Data breach notification
 Feature 3: import/export DFD models from Privacy Risk Management (PRM) tool
 Feature 4: dedicated profile to support privacy threat conditions (PRM)
29/06/2021 25 PDP4E WP5

26. 5. Apply process-oriented strategy
 Overview of process-oriented strategies
29/06/2021
Application of the strategy 
Outcome of the strategy
26 PDP4E WP5

27. PDPbD Framework
2019/12/03
3. Module for code validation
Julien Signoles (CEA)
Julien.signoles@cea.fr
27 PDP4E WP5

28. Specifying Privacy Properties with Hilare
 Module for Code Validation is based on Frama-C
 Frama-C provides several tools for analyzing and verifying C source code
 It comes with ACSL, a formal specification language for expressing properties at code level
 ACSL is not suitable for verifying privacy properties (too close to the source code)
Hilare: extension of ACSL for expressing high-level specifications at code level, such as
privacy properties
/*@ // only authorized users can read high confidentiality pages
meta prop,
name(confidential_read),
targets(diff(ALL, init)),
context(reading),
forall_page(p,
page_allocated(p) && user_level < page_level(p) ==>
hidden(page_data(p))
); */
29/06/2021 28 PDP4E WP5

29. Verifying Privacy Properties with MetACSL
 MetACSL: Frama-C extension for
generating ACSL specifications from
Hilare
 Allow to reuse existing Frama-C
verification tools for verifying Hilare
specifications
 Demo
 Page manager system that could store
public and secret keys of the connected
vehicle pilot’s PKI
29/06/2021 29 PDP4E WP5

30. PhD Thesis still in progress
 Refining system-level privacy properties to code-level is still missing
 ongoing PhD thesis on this topic (mid-term)
 design of a formal language for expressing privacy properties at system-level
 refine such properties to MetACSL, so to the code
 the PhD’s main results will come in the coming year
29/06/2021 30 PDP4E WP5

31. Summary of achievements
PDPbD modules released as open-source:
 Privacy designer:
 https://git.eclipse.org/c/papyrus/org.eclipse.papyrus-privacydesigner.git/
PDPbD framework implements the methodology to realize “privacy by design”:
 Method to incorporate knowledge from three domains:
 Systems engineering
 Privacy and Data Protection
 Regulations like GDPR and standards like ISO/IEC 27750
 Tool support for the method via three modules:
 Personal Data Detection
 Privacy model-driven designer
 Code validation
29/06/2021 31 PDP4E WP5

32. Acknowledgements
29/06/2021
This project has received funding from the European Union’s Horizon 2020 research and innovation
programme under grant agreement No 787034.
Purpose and IPR Notice: the material in this support has been mostly prepared by CEA and Beawre in the scope of PDP4E for
explanatory and training purposes. Any partial or full usage of this material in a different context requires written and explicit
consent from the respective partners. The property of the contents herein referred (including methods, tools and trademarks)
belongs to the respective IPR and copyright holders.
PDP4E 32
WP5

33. Methods and Tools for GDPR Compliance through
Privacy and Data
Protection 4 Engineering
For more information, visit:
www.pdp4e-project.org
Thank you for your attention
Questions?
WP Leader: CEA
gabriel.pedroza@cea.fr
julien.signoles@cea.fr
victor.muntes@beawre.com