The General Data Protection Regulation (GDPR) is the new EU Data Protection Regulation [21] in charge of harmonize the regulation of Data Protection across the EU member states. At the same time, it enhances and arises business opportunities within the Digital Single Market space. However, the natural language nature of the GDPR makes most of the provisions to be expressed in generic terms and does not provide specific indication on how they should be actuated. Thus, applying and demonstrating the GDPR compliance, in order to avoid also the related penalties, becomes an important research challenge.
Many businesses today are struggling in the definition of appropriate procedures and technical solutions for their development process so as to enforce and demonstrate the GDPR compliance [1,6,13,15,24]. In particular, following the correct-by-design principle, they are looking for effective and efficacious means for increasing the software high-confidence and quality and, at the same time, reducing the cost and effort of development. Consequently, integrated solutions for designing and promptly testing their applications and systems are urgently necessary. Considering the GDPR, as for any other software requirement, a fundamental step for guaranteeing its by-design compliant realization is that the data protection concepts have to be integrated into overall software life cycle: from gathering of the requirements to deployment and subsequent maintenance of the system.
Currently, several proposals are trying to assist the organizations in the deployment of adequate fine-grained mechanisms that take into account legal requirements, such as the data usage purpose, user consent and the data retention period. In particular, research attention has been devoted to authorization systems because they are recognised, by scientific communities and private companies, as the successful elements for the development of GDPR-by-design compliant solutions [7,29,30]. However, to the best of our knowledge, most of the available proposals targets just a single aspect of authorization system development and no integrated solutions for guiding their GDPR-by-design compliant development through the entire life cycle are provided.
Therefore, the proposal of this paper: a specific, integrated GDPR focused process development life cycle for the specification, deployment and testing of adequate fine-grained authorization mechanisms able to take into account legal requirements. The idea has been inspired by the life cycle introduced in [14], which is a systematic approach to implementing authorization systems within enterprise. Even if generic, the proposal of [14] does not target explicitly the GDPR demands or any other legal framework.
Additionally, to promote the applicability of the proposed life cycle into the business and industrial context we also present its preliminary automation. More precisely, we integrated, for the first time, into a unique environment some of the available solutions for: specifying the privacy requirements, controlling personal data, processing them, and demonstrating the compliance with the GDPR in collecting, using, storing, disclosing and/or disposing of the personal data.
In line with this view, the paper focuses on the following primary objectives: OBJ 1: defining a GDPR-based life cycle for authorization systems; OBJ 2: providing an integrated environment for automatically enforcing the data protection or privacy regulations.
Section 2 presents the basic concepts used along the proposal; Section 3 describes the adopted development process and the solutions proposed for its phases; Section 4 presents the unique environment we are developing to accommodate the proposed life cycle; finally, Section 5 concludes the paper.
In this section we briefly overview the concepts and definitions adopted in the remains of this paper, focusing in particular on the GDPR and access control concepts.
General Data Protection Regulation. The GDPR [21] defines Personal Data as any information relating to an identified or identifiable natural person called Data Subject. That means that, a data subject is a Natural Person (a living human being), whose data are managed by a Controller. This regulation became into effect on May 2018 and has replaced the previous Data Protection Directive conceived in 1995. The aim of the new regulation is to strengthen the rights of the individual over their own data and at the same time to make organizations more accountable w.r.t. the previous directive. In addition, the GDPR has also the objective to eliminate all the barriers for the services to be delivered in the European Union and, therefore, to enhance business opportunities within the Digital Single Market. The GDPR will contribute to the harmonization of the previous fragmented data protection laws across the EU, so as to ensure equal protection of Human Rights of the European Citizens.
The GDPR is composed of 99 articles that represent the mandatory part of the regulation. The GDPR is applied to the processing of personal data, whether it is automated (even partially) or not. It defines, among others, the following principles and demands: Transparency, i.e., data must be processed fairly, lawfully and transparently; Purposes, i.e., data should only be collected for determined, explicit and legitimate purposes, and should not be processed later for other purposes; Minimization, i.e., the processed data must be relevant, adequate and limited to what is necessary in view of the purposes for which they are processed; Accuracy, i.e., the processed data must be accurate and up-to-date regularly; Retention, i.e., data must be deleted after a limited period; Subject explicit consent, i.e., data may be collected and processed only if the data subject has given his explicit consent.
Access Control Concepts. Access Control (AC) is a fundamental building block for secure information sharing [9], because it ensures that only the intended people can access securityclassified data and that these intended users are only given the level of access required to accomplish their tasks. Several access control models have been proposed, including models taking into account time, location, and situation [8,18,25,32] and models specific for privacysensitive data [26].
An AC is usually implemented through Access Control Mechanism (ACM), which is the system that provides a decision to an authorization request, typically based on predefined Access Control Policy (ACP). This is a specific statement of what is and is not allowed on the basis of a set of rules, defined in terms of conditions on attributes of subjects, resources, actions, and environment, and combining algorithms for establish the precedence among the rules. Attribute-Based Access Control (ABAC) [23] and its standard implementation, the eXtensible Access Control Markup Language (XACML) [27], are the widespread adopted models in the access control environment. As schematize in Figure 1(a), the main components of XACML standard are: the Policy Administration Point (PAP) is the system entity in charge of managing the policies; the Policy Enforcement Point (PEP), usually embedded into an application system, receives the access request in its native format, constructs an XACML request and sends it to the Policy Decision Point (PDP); the Policy Information Point (PIP) provides the PDP with the values of subject, resource, action and environment attributes; the PDP evaluates the policy against the request and returns the response, including the authorization decision, to the PEP.
The structure of an XACML access control policy is sketched in Figure 1 Deny) is returned, otherwise a NotApplicable decision is formulated. If an error occurs during the evaluation of a policy against a request, Indeterminate value is returned. The Policy-CombiningAlgorithm (not represented in the figure) and the RuleCombiningAlgorithm define how to combine the results from multiple policies and rules respectively in order to derive a single authorization access decision.
In literature there are several works that use access control as main means of protecting personal data. Different proposals are mainly divided into two main categories. The former uses Access Control to address specific concepts that can be related to a given law, such as consent and purpose. In this area an initial proposal for an automatically enforceable policy language is discussed in [16], whereas, a formal definition of the consent is introduced in [31]. The latter refers explicitly a given law (e.g., the EU GDPR or the US HIPAA) in using Access Control. In particular in [17] the authors have evaluated whether the XACML standard is adequate to express the constraints imposed in HIPAA, whereas in [22], the authors investigated the feasibility of translating the articles related to access control of the previous EU data protection directive. In the industrial environment, authors in [14] proposed a systematic methodology for the implementation of ABAC solutions in real contexts.
Differently from the above contributions, the proposal of this paper does not focus on a single aspect of the development process but provides a unified environment able to: model ACPs that are by-design compliant with the GDPR; test those ACPs by means of state-of-theart testing tools; and to monitors their application during the production time, and eventually to suggest possible improvements in case of deviation of the expected behaviour. Therefore, the solution proposed in this paper aims at providing, for the first time, a practical specification of the Authorization Development Life Cycle in the light of the GDPR covering all its stages.
In this section we target the first objective of this paper (OBJ 1): defining a GDPR-based life cycle for authorization systems assuring the by-design compliance to data protection regulation. As any other software application, the development of GDPR compliant authorization systems involves different stages of software development. Thus, our first objective is to formalize into a specific life cycle the required activities for: collecting and specifying legal requirements into formal representations, defining and testing data protection policies, and implementing ACbased mechanisms.
In presenting our proposal, among the different development processes, we refer to and modify the authorization policy life cycle introduced in [14], which is a systematic approach to implementing ABAC systems within enterprises. The proposed life cycle, schematized in Figure 2, does not strictly depend on any specific ABAC implementation. However, in this paper we refer to the widely industrial adopted XACML-based authorization system because it is the only available standardized specification for ABAC. As schematize in Figure 2, the modified version of the process consists of the following steps:
GDPR-based use case definition (step 1 ): i.e., define context and an achievable scope so as to establish a common base to discuss with different stakeholders. In this case, the established use cases need to be conceived according to GDPR implementation challenges; Gather authorization requirements (step 2 ): i.e., to gather all the requirements and the sources they come from. In our case, the primary source is the GDPR regulation, therefore, authorization requirements should de defined in terms of statements or natural language Figure 2: The Authorization Policy Life Cycle (adapted from [14]). authorization policies. Additionally, business requirements (e.g., working hours) and security best practices (e.g., encrypting data) need also to be defined. Identify required attributes (step 3 ): i.e., to identify the attributes used in the selected requirements and their origin so as to make easier requirement reviews. The attributes should depend on the language or functionalities of the XACML reference architecture. Author authorization policies (step 4 ): i.e., to transform the natural language statements into machine-interpretable statements, in order to eliminate any ambiguity introduced by natural language. Thus, a list of XACML policies encoding the GDPR's provisions need to be defined as well as the order in which those policies should be evaluated. Test ACPs & AC mechanisms (step 5 ): i.e., to ensure that the implemented XACML policies meet the GDPR requirements. State-of-the-art and specifically conceived testing techniques should be used according to the different purposes. This step involves also the evaluation of the adequacy of the current AC mechanisms in the context of the GDPR. Deploy the architecture (step 6 ): i.e., to define the contact point within the existing systems in order to make the different applications able to interact with authorization system. Deploy the policies (step 7 ): i.e., to deploying the authored XACML policies according to the selected (production) environment. This step is usually business dependent. Run access reviews (step 8 ): i.e., to analyse the policies against a set of attributes to determine what these attributes grant. In the context of the GDPR, this should involve the simulation of realistic scenarios according to specific application use cases. Additionally, the data coming from the testing activities could be used to assess the implemented solutions and identify possible improvements.
In order to propose an applicable and effective solution, the second objective of this paper (OBJ 2) is to provide an integrated environment for the automatic enforcing of the GDPR-based life cycle presented in the previous section. To the best of the authors' knowledge, this proposal is the first attempt to integrate, in a unique automated environment, different available solutions for extracting, implementing and testing the data protection regulation. Differently from the generic ACS architecture, in this paper we assume that the protected resources are Personal Data hosted in a specific database, the Personal Data DB component of Figure 3.
In the remainder this section, we detail how the modules have been implemented into the proposed environment and how they are related to the authorization life cycle schematized in Figure 2.
Among the solutions to tackle security issues and vulnerabilities in an efficient and effective way, the possibility of using backlogs to drive the software development work is currently taking place. Generally, a backlog is a prioritized features list describing the functionalities to be included in the final product [2]. These backlog items are often provided in the form of User Stories [3], i.e., a list of ready-made specification of items (requirements and task descriptions) useful for the implementation.
In the context of GDPR having a ready-to-use set of User Stories, focused on GDPR provisions and associated to specific ACPs, represents an important means to minimize development effort and assure high quality of the final product. Indeed, when an authorization system need to be implemented, developers could pick up the necessary predefined User Stories, and their associated ACPs, and exploit them in order to easily implement the required policies into the Access Control Mechanism.
Considering the life cycle schematized in Figure 2, the definition of the User Stories set can be reloaded as: the definition of a Data Protection Backlog that contains User Stories based on the requirements (Step 1 ); and the mapping of the GDPR provisions into User Stories (Step 2 ).
In the environment proposed in Figure 3, the definition of User Stories is in charge of the module A , and specifically of the User Stories Tool component. From a practical point of view, the methodology for defining GDPR based User Stories has been introduced in [5], and therefore the component provides an automation of the previously introduced process. More precisely, the User Stories tool component takes as input a Legal Text (the GDPR text in this case), analyses the GDPR's articles related to ACs and creates an Epic [2] for each of them. An Epic is a set of User Stories having the same conceptual purpose. For the GDPR, a total of forty-one Epics are produced: three of them concerning only AC mechanism; eight referring only ACP, and thirty articles related to both ACP and AC mechanism. Then, for each article one or more User Stories are derived and linked to the proper Epic. As an output of the User Stories Tool component, a Data Protection Backlog, i.e., a Privacy Backlog containing a set of User Stories organized in Epics, is stored into the USER Stories DB (Figure 3). In Table 1 an extract of content of the Data Protection Backlog is presented. As in the table the column Article (first column) contains the GDPR's articles, and the column User Story contains the GDPR-based User Stories defined. Through the GUI of module A in Figure 3, the User (in this case an authorization system developer) can select a set of predefined User Stories and proceed with their translation into ACPs as detailed in the next section.
Step 3 and Step 4 of the life cycle of Figure 2 aim at transforming the User Stories into machine-interpretable statements. As a result, a list of XACML policies encoding the GDPR principles is defined.
In the environment depicted in Figure 3, the Access Control Tool component of module A is in charge of automating the two steps. Hence, the component takes as input a set of User Stories selected by the User from the User Stories DB and, through the automation of the methodology introduced in [6], provides the associate GDPR-based ACPs.
In details, considering the Step 3 , first the component classifies the identified attributes into access control commonly-used entities (or categories) (see Section 2), highlights relations between them and lets the mapping into the ABAC terms. For instance, by referring to the User Story related to the Art. 15.1 (see the second row of Table 1), the component identifies and classifies the following attributes: Data Subject as a Subject, access as an Action, and Personal Data as a Resource category.
Then, the Access Control Tool component automates the translation of the selected User Stories into derived AC rules that corresponds to Step 4 of Figure 2. In particular, this step consist into the instantiation of the AC rules with actual attributes, and the translation of the resulting into a given formalism or language 1 .
As in Figure 3, the final translation requires the interaction with the User and the Personal Data DB. Specifically, the User needs to identify in the Personal Data DB the real attributes to be considered. As example, considering the Art. 15.1 (Table 1), Table 2 reports the attribute mapping for the following realistic scenario: Alice (Customer, i.e., Data Subject) provided her name, her E-mail address, and the name of the city where she has the permanent address to the ABC company (Controller). Alice in any moment can exercise her right of access pursuant the Art. 15.1.
More precisely, column Identified Attribute of Table 2 contains the identified attributes; column Attribute Category shows the classification of those attributes into a specific category; finally, column Access Control Category illustrates the classification attributes into the commonly used entities in access control. The Access Control Tool uses the derived attribute classification for mapping them into the attributes of the User Stories and deriving enforceable ACPs in a given language. As an example, by considering the attribute classification of Table 2 and the User Stories associated with Art. 15.1, Figure 4 shows the derived matching, whereas Figure 5 reports the translation into XACML-like language. Consequently, the policy is applicable to the subject Alice and contains two rules:
(1) the first rule, with RuleId equal to read-Rule, represents the AC rule starting from User Story associated with Art. 15.1 (see second row of Table 1), and guarantees that Alice can read all the information concerning her; (2) the second rule, called defaultRule, represents a standard default rule that denies all which is not allowed explicitly.
Step 5 of Figure 2 aims at testing both the developed ACPs and the current AC mechanisms. Indeed, to ensure that the implemented XACML policies meet the GDPR requirements specific testing process should be adopted. Considering the environment of Figure 3 In particular, it integrates available solutions for: assessment of test strategies, testing GDPRbased ACPs expressed in XACML 3.0 and evaluating the adequacy of AC mechanisms with respect to the GDPR's provisions. For aim of completeness we report here below the main features of the Access Control Testing Tools component. Specifically:
1. Test Case Generation: starting from the developed ACPs, it is possible to generate AC requests able to test both the ACPs and AC mechanisms through a modified version of the X-CREATE tool [12], which provides several combinatorial test strategies, and the XACMET tool [19] that provides a model-based test generation strategy;
2. Mutation Generation: mutation analysis [28]
In section we briefly provide some hints for targeting the last three phases of the proposed authorization life cycle that involve the deployment of the AC architecture (Step 6 of Figure 2), the deployment of the developed and tested policies (Step 7 ), and the final analysis of the process development data (Step 8 ).
The idea behind Step 6 is to decouple the authorization functionalities from the business logic. This enables to adapt and extend the XACML reference architecture with new features without modifying the business logic of the applications that use Personal Data. This separation of concerns helps to propose scalable, manageable and extendible authorization solutions.
Once the architecture is deployed (module B of Figure 3), Step 7 involves the deployment of the tested GDPR-based ACPs within the Policy Administration Point component of the AC system in order to assure the GDPR compliance. This allows the Policy Decision Point to retrieve and to evaluate the right ACP when the system receives an access request, from the end user (e.g., Data Subject or Controller), to the Personal Data hosted in the Personal Data DB.
Additionally, by referring to Step 8 , facilities for collecting and managing information for the GDPR compliance and audit purposes [4,15] should be included. To this purpose, module C of Figure 3 is the proposal that we are currently finalizing. The module extends with logging systems, monitoring capabilities, and reporting functionalities of the proposed environment [20], so that data mining and machine learning techniques can be adopted to construct behavioral models based on data coming from the logging and testing activities and to discover and notify unwanted behaviors.
The GDPR represents a significant breakthrough in the digital economy and brings a lot of changes to the way in which online services are offered. This scenario calls for new approaches for developing systems where legal requirements are taken into account, just like the other requirements that a system must respond to. This paper focused on data protection requirements and, in particular, on the development of authorization systems able to enforcing the GDPR provisions. The idea was to provide for the first time a specific GDPR-based life cycle, able to assure the by-design compliance of the developed access control systems. Additionally, in order to make the proposal effective and applicable in real context, we provide also a reference architecture enforcing the proposed life cycle. The general nature of the proposed GDPR-based life cycle does not constrain the environment to the specific tools selected in this paper, and different components implementations could be considered. The intention was to demonstrate the feasibility of our proposal. Therefore, this work represented a preliminary step to integrate legal requirements into a software development process and several improvements are possible. In particular, the proposals of this paper need to be thoroughly extended and validated with real case studies and the architecture finalized in order to provide a unique user-friendly environment, able to assist developers in all the stages of development.
This work is partially supported by CyberSec4Europe Grant agreement ID: 830929.