Nowadays, organizations are undertaking increasingly complex projects in globalized, uncertain and dynamic environments [1]. Some of the factors that increase or generate project complexity are the emergence of new technologies [2], the growing sophistication of software project scopes characterized by challenging technical, time and cost requirements [3] and the increasing number of stakeholders involved [4]. Thus, to assure a successful software project [5], it is particularly important to stress concepts such as data and information security in all phases of the software development life cycle (SDLC) [6]. Software errors can be introduced by disconnections and miscommunications during planning, development, testing and maintenance of the components [7].
So, in order to satisfy security requirements, it becomes necessary to identify the key elements associated to the privacy and security-oriented software development, and to support decision making in all phases of the software life cycle.
Accordingly, this paper presents the key elements for privacy-oriented software development formalized in a knowledge base and a collaborative tool that integrates these elements. The tool supports decision making in all the software development lifecycle phases in order to integrate privacy and security requirements.
The paper is organized as follows. Section 2 discusses related works. Section 3 describes the tool and Section 4 reports the evaluation of collaborative tool and the obtained results. Finally, conclusions are given in Section 5.
SEBD 2021: The 29th Italian Symposium on Advanced Database Systems, September 5-9, 2021, Pizzo Calabro (VV), Italy EMAIL: mariateresa.baldassarre@uniba.it (A. 1); vita.barletta@uniba.it (A. 2); danilo.caivano@uniba.it (A. 3); giovanni.dimauro@uniba.it (A. 4); antonio.piccinno@uniba.it (A. 5) ORCID: 0000-0001-8589-2850 (A. 1); 0000-0002-0163-6786 (A. 2); 0000-0001-5719-7447 (A. 3); 0000-0002-4120-5876 (A. 4); 0000-0003-1561-7073 (A. 5)
Software development requires integration of security and privacy to address threats related to cyberattack [8]. So, for secure software development, it is particularly important to stress concepts such as data and information security in project activities which deal with or target aspects such as integrity, availability, and confidentiality [9,10]. This imposes, see for example the provisions on the subject dictated by the GDPR, "General Data Protection Regulation" [11], the adoption of processes and tools to mitigate the risks related to security and data privacy.
Privacy by Design [12] is a fundamental concept for software development as it requires data protection and the implementation of technical and organizational measures to protect the rights of users [13]. Confidentiality, integrity, availability, unlikability, transparency and intervenability are considered the six protection goals that provide a common scheme for addressing the legal, technical, economic and social dimension of privacy and data protection in complex IT systems [14].
The methodologies include two categories, Security-based adaptations, i.e., Privacy Engineering methodologies that are based and originated from security engineering methodologies, and Privacy-Friendly systems that aim to embed privacy into every step of the software development life cycle [15]. Therefore, a number of privacy requirements methodologies have been introduced in order to assist system designers and developers to analyze and elicit privacy requirements for different software systems and in different architectures [16].
LINDDUN [17] is a privacy threat modeling methodology that supports analysts in systematically eliciting and mitigating privacy threats in software architectures. The identified privacy threats are mapped with the existing privacy-enhancing technologies (PETs) [18]. PriS methods describes the effect of privacy requirements on business processes and facilitate the identification of the system architecture that best supports the privacy-related business processes [19]. SQUARE [20] security quality requirements engineering methodology supports the elicitation of privacy requirements at the early stages of software life cycle. It consists of nine steps which include what techniques will be used to elicit security requirements then categorize, prioritize, and inspect the requirements. STRAP [21] is a light-weight structured analysis of privacy vulnerabilities into the software development cycle. RBAC [22] method considers privacy requirements as constraints on permissions and user roles in order to define access control policies. PRIPARE introduces how privacy requirements should be incorporated into the software development life cycle [23].
Reviewing each of these methodologies, privacy requirements are addressed during the first phases of the SDLC, but never in all the phases. Therefore, it is necessary to integrate privacy in all phases of the development. Considering this need, the research work presents a tool to support the development team in all phases of the SDLC.
Starting from the work illustrated in [24], the tool has been improved to overcome the limitations highlighted in the first experiment. It integrates the formalization of the privacy key elements in order to support decisions and choices in all phases of the software development (Figure 1). The five elements identified are Privacy by Design Principles, Privacy Design Strategies, Privacy Patterns, Vulnerabilities and Context. [12] that describe the privacy model, each of which specify actions and responsibilities:
1. anticipate and prevent privacy-invasive events before they happen (Proactive not Reactive); 2. build privacy measures directly into any given ICT system or business practice by default (Privacy as the Default); 3. embed privacy into the design and architecture (Privacy Embedded in to Design); 4. accommodate all legitimate interests and objectives in a positive-sum manner, not through a zero-sum approach involving unnecessary trade-offs (Full Functionality); 5. ensure secure life-cycle management of information (End-to-End Lifecycle Protection);
to user and providers alike (Visibility and Transparency); 7. respect and protect interests of the individual, above all (Respect for User Privacy). [25] that help IT architects to support Privacy by Design early in the software development life cycle. They are divided in two different categories:
• Data-Oriented Strategies focus on the privacy-friendly processing of the data (Minimize, Hide, Separate, Abstract). • Process-Oriented Strategies focus on the process surrounding the responsible handling of personal data (Inform, Control, Enforce, Demonstrate).
Privacy Pattern [26] that underline the concept of pattern and can be used in all those situations where privacy is violated, and a user's personal data is no longer secure. Patterns are a literary format with which to capture the knowledge and experience of security experts, resulting in a structured document in the form of a template to which the security experts' knowledge is transferred [27,28].
Vulnerabilities within the code allow a malicious user to attack the application [7].
Context, that integrates Architectural Requirements to determine the flow of data within the system, components, roles and responsibilities; Use Cases and Scenarios to define all interactions within the system and protect the data from unauthorized reading and manipulation; and Privacy Enhancing Technologies (PETs) to protect the personal information handled by the applications.
The collaborative tool supports the team's choices in all the software development phases in order to integrate security and privacy. At each stage of the SDLC, knowledge and skills are required to be able to develop a product that respects the principles of privacy and security by design. But many times, within the team certain knowledge are not present, such as knowing step by step the basic points of the GDPR [11] in order to provide a software product that is compliant. In order to overcome this limitation and provide operational guidelines to the development team, the tool allows you to select the necessary elements to be able to introduce privacy and security requirements throughout the software lifecycle. For example, starting from the vulnerabilities identified in the static code analysis the developer in addition to viewing a brief description of the vulnerability and an example, can also look at the privacy by design principles violated and view the privacy patterns that allow to mitigate the vulnerability and implement privacy strategies to correct the architectural flaws.
In Figure 2 are reported that OWASP Top 10 -2017 [29], and the detail of Sensitive Data Exposure vulnerability. In addition, for each pattern identified for a particular vulnerability, it is shown how to implement it within a particular architecture chosen by the developer and on which he is working. If, for example, a privacy pattern or any other element of the knowledge base is not present, the team has the possibility to insert it in order to extend it. Figure 3 shows the addition of a pattern where it requires the title, which privacy strategy it implements, the context, the problem, the solution, the UML diagram, the vulnerability it mitigates, and the architecture.
To evaluate the potential benefits of the tool in order to integrate privacy and security in software, we conducted a pilot experiment with 8 bachelor students in computer science, software engineering curriculum.
The students have taken the traditional software engineering course and have no expertise in both software development and in applying privacy oriented methodologies. The average is 22 years old. They were divided into 2 groups and asked to re-engineer a system developed by their colleagues in previous years during the software engineering course.
The system called "Civic Sense" allows a citizen to report failures, problems, malfunctions and, in general, events relevant to an entity that provides services or manages infrastructure of public interest (electricity, roads and streets, urban safety, etc.).
As in the previous study in which we involved junior developers [24], the tasks assigned to the two groups are the following:
• Task 1: Identify the principles of Privacy by Design violated by vulnerability.
• Task 2: Identify the Privacy Design Strategies to be implemented in the system to respect the principles of Privacy by Design. • Task 3: Identify the privacy patterns that substantiate the Privacy Design Strategies.
• Task 4: Identify the Data Strategies Component to implement in Target Architecture in order to re-engineer the system from a privacy point of view. • Task 5: Identify the Processes Component Strategies to implement in Target Architecture in order to re-engineer the system from a privacy point of view. In order to perform the required tasks, each group was provided with a security report containing the list of vulnerabilities identified during the static code analysis of the system (Issue ID, Category, Severity, Short Description). The following is an example of the Privacy Violation category.
Abstract: The file loginn.php mishandles confidential information on line 12, which can compromise user privacy and is often illegal. Explanation: Privacy violations occur when: 1. Private user information enters the program. 2. The data is written to an external location, such as the console, file system, or network. Example: The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored is the return value from the getPassword() function that returns user-supplied plaintext password associated with the account.
<?php $pass = getPassword(); trigger_error($id . ":" . $pass . ":" . $type . ":" . $tstamp); ?> The code in the example above logs a plaintext password to the application eventlog. Although many developers trust the eventlog as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern. Private data can enter a program in a variety of ways: -Directly from the user in the form of a password or personal information -Accessed from a database or other data store by the application -Indirectly from a partner or other third party Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publiclyavailable mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.
Then, starting from the security report, the students carried out each task in order. Each task was done in different sessions, one for each task, and each session was done in parallel. This was done to prevent the two groups from communicating with each other and knowing in advance the task to be performed. In addition, each group was observed by a researcher.
Keeping in mind that the research goal is to support the development team in all phases of the security and privacy oriented software lifecycle, we did not set out to investigate the developers' productivity. The focus was to observe the interaction with the tool to operationally implement guidelines in privacy-oriented software development and collect information to improve the tool.
Table 1 and Table 2 present the results obtained using the tool in re-engineering Civic Sense. All tasks were done correctly although Task 4 of Group A was not accomplish by the time limit. In each session, it was critical to observe task execution to understand user behavior in being able to retrieve the information needed in reengineering the system.
The students' feedback was positive in being able to use a single tool that would allow them to view all the information needed to integrate privacy and security requirements operatively. Figure 4 shows an example of the architecture with the identification of privacy patterns that implement the privacy design strategies.
And this was confirmed by the SUS [30] [31] questionnaire conducted after at the end of the five sessions and the execution of the various tasks. The SUS score obtained was 89,9.
In this research work, we analyzed the potential benefits of a collaborative tool that supports developers in order to integrate privacy and security in software development. The tool integrates the key elements identified in privacy-oriented software development (Principles of Privacy Design, Privacy Design Strategies, Privacy Patterns, Vulnerabilities, Context) and formalized in a knowledge base. The knowledge base shows that it is able to translate best practices for both secure application development and data privacy, into operational guidelines, software architectures and code structures to be used.
The tool allows to provide all the information needed to integrate privacy and security requirements during each stage of the re-engineering process. Students in the experimentation were positively supported despite not having specific skills in security by design and privacy by design. Indeed, the results demonstrate that the proposed tool supports developers in collaborative contexts integrating privacy and security in software development processes.
The positive results obtained by this study with bachelor students and the previous one with junior developers, encouraged us to plan for further case studies and evaluate developer's productivity with the collaborative tool.