The General Data Protection Regulation: Requirements, Architectures, and Constraints

The General Data Protection Regulation (GDPR) in the European Union is the most famous recently enacted privacy regulation. Despite of the regulation's legal, political, and technological ramifications, relatively little research has been carried out for better understanding the GDPR's practical implications for requirements engineering and software architectures. Building on a grounded theory approach with close ties to the Finnish software industry, this paper contributes to the sealing of this gap in previous research. Three questions are asked and answered in the context of software development organizations. First, the paper elaborates nine practical constraints under which many small and medium-sized enterprises (SMEs) often operate when implementing solutions that address the new regulatory demands. Second, the paper elicits nine regulatory requirements from the GDPR for software architectures. Third, the paper presents an implementation for a software architecture that complies both with the requirements elicited and the constraints elaborated.Comment: Forthcoming in the 27th IEEE International Requirements Engineering Conference (RE'19), Jeju Island, IEE

A Case Study on Software Vulnerability Coordination

Context: Coordination is a fundamental tenet of software engineering. Coordination is required also for identifying discovered and disclosed software vulnerabilities with Common Vulnerabilities and Exposures (CVEs). Motivated by recent practical challenges, this paper examines the coordination of CVEs for open source projects through a public mailing list. Objective: The paper observes the historical time delays between the assignment of CVEs on a mailing list and the later appearance of these in the National Vulnerability Database (NVD). Drawing from research on software engineering coordination, software vulnerabilities, and bug tracking, the delays are modeled through three dimensions: social networks and communication practices, tracking infrastructures, and the technical characteristics of the CVEs coordinated. Method: Given a period between 2008 and 2016, a sample of over five thousand CVEs is used to model the delays with nearly fifty explanatory metrics. Regression analysis is used for the modeling. Results: The results show that the CVE coordination delays are affected by different abstractions for noise and prerequisite constraints. These abstractions convey effects from the social network and infrastructure dimensions. Particularly strong effect sizes are observed for annual and monthly control metrics, a control metric for weekends, the degrees of the nodes in the CVE coordination networks, and the number of references given in NVD for the CVEs archived. Smaller but visible effects are present for metrics measuring the entropy of the emails exchanged, traces to bug tracking systems, and other related aspects. The empirical signals are weaker for the technical characteristics. Conclusion: [...

A Mixed Methods Probe into the Direct Disclosure of Software Vulnerabilities

Software vulnerabilities are security-related software bugs. Direct disclosure refers to a practice that is widely used for communicating the confidential information about vulnerabilities between two parties, vulnerability discoverers and software producers. Building on software vulnerability life cycle analysis, this empirical paper observes the qualitative and quantitative characteristics of direct disclosure practices, focusing particularly on the historical problem related to producers’ reluctance to participate in the practices. According to the results, the problem was still present in the 2000s and early 2010s—and likely is still present today. By presenting this empirical result about the under researched phenomenon of direct disclosure of software vulnerabilities, the paper contributes to the research domain of vulnerability life cycle modeling in general and the subdomain of empirical vulnerability disclosure research in particular.</p

Extracting LPL privacy policy purposes from annotated web service source code

Privacy policies are a mechanism used to inform users of the World Wide Web about the processing of their personal data. Such processing has special requirements, since personal data are regulated by data protection legislation. For example, a consent or another legal basis is typically needed. Privacy policies are documents used, among other things, to inform the data subject about processing of their personal data. These are formally represented by privacy languages. In this paper, we present a technique for constructing Layered Privacy Language policy data from web service code bases. Theoretically, we model the purposes of processing within web services by extending the privacy language with composition. We also present a formal analysis method for generating privacy policy purposes from the source code of web services. Furthermore, as a practical contribution, we present a static analysis tool that implements the theoretical solution. Finally, we report a brief case study for validating the too

Security in agile software development: A practitioner survey

Context: Software security engineering provides the means to define, implement and verify security in software products. Software security engineering is performed by following a software security development life cycle model or a security capability maturity model. However, agile software development methods and processes, dominant in the software industry, are viewed to be in conflict with these security practices and the security requirements. Objective: Empirically verify the use and impact of software security engineering activities in the context of agile software development, as practiced by software developer professionals. Method: A survey (N=61) was performed among software practitioners in Finland regarding their use of 40 common security engineering practices and their perceived security impact, in conjunction with the use of 16 agile software development items and activities. Results: The use of agile items and activities had a measurable effect on the selection of security engineering practices. Perceived impact of the security practices was lower than the rate of use would imply: This was taken to indicate a selection bias, caused by e.g. developers’ awareness of only certain security engineering practices, or by difficulties in applying the security engineering practices into an iterative software development workflow. Security practices deemed to have most impact were proactive and took place in the early phases of software development. Conclusion: Systematic use of agile practices conformed, and was observed to take place in conjunction with the use of security practices. Security activities were most common in the requirement and implementation phases. In general, the activities taking place early in the life cycle were also considered most impactful. A discrepancy between the level of use and the perceived security impact of many security activities was observed. This prompts research and methodological development for better integration of security engineering activities into software development processes, methods, and tools.</p