199

Privacy threat modeling should be done frequently throughout development and production to be able to quickly mitigate threats. Yet, it can also be a very time-consuming activity. In this paper, we use an enhanced code property graph to partly automate the privacy threat modeling process: It automatically generates a data flow diagram from source code which exhibits privacy properties of data flows, and which can be analyzed semi-automatically via queries. We provide a list of such reusable queries that can be used to detect various privacy threats. To enable this analysis, we integrate a taint-tracking mechanism into the graph using privacy-specific labels. Since no benchmark for such an approach exists, we also present a test suite for privacy threat implementations which comprises implementations for 22 privacy threats in multiple programming languages. We expect that our approach significantly reduces time consumption of threat modeling and show that it also has potential beyond the threat categories defined by LINDDUN, e.g. to detect privacy anti-patterns and verify compliance to privacy policies.

Cloud systems are dynamic environments which make it difficult to keep track of security risks that resources are exposed to. Traditionally, risk assessment is conducted for individual assets to evaluate existing threats-their results, however, are quickly outdated in such a dynamic environment. In this paper, we propose an adaptation of the traditional risk assessment methodology for cloud infrastructures which loosely couples manual, in-depth analyses with continuous, automatic application of their results. These two parts are linked by a novel threat profile definition that allows to reusably describe configuration weaknesses based on properties that are common across assets and cloud providers. This way, threats can be identified automatically for all resources that exhibit the same properties, including new and modified ones. We also present a prototype implementation which automatically evaluates an infrastructure as code template of a cloud system against a set of threat profiles, and we evaluate its performance. Our methodology not only enables organizations to reuse their threat analysis results, but also to collaborate on their development, e.g. with the public community. To that end, we propose an initial open-source repository of threat profiles.

Research and development of privacy analysis tools currently suffers from a lack of test beds for evaluation and comparison of such tools. In this work, we propose a benchmark application that implements an extensive list of privacy weaknesses based on the LINDDUN methodology. It represents a social network for patients whose architecture has first been described in an example analysis conducted by one of the LINDDUN authors. We have implemented this architecture and extended it with more privacy threats to build a test bed that enables comprehensive and independent testing of analysis tools.

In this paper, we present the Cloud Property Graph (CloudPG), which bridges the gap between static code analysis and runtime security assessment of cloud services. The CloudPG is able to resolve data flows between cloud applications deployed on different resources, and contextualizes the graph with runtime information, such as encryption settings. To provide a vendorand technology-independent representation of a cloud service's security posture, the graph is based on an ontology of cloud resources, their functionalities and security features. We show, using an example, that our CloudPG framework can be used by security experts to identify weaknesses in their cloud deployments, spanning multiple vendors or technologies, such as AWS, Azure and Kubernetes. This includes misconfigurations, such as publicly accessible storages or undesired data flows within a cloud service, as restricted by regulations such as GDPR.

As cloud services become central in an increasing number of applications, they process and store more personal and business-critical data. At the same time, privacy and compliance regulations such as the General Data Protection Regulation (GDPR), the EU ePrivacy regulation, and the upcoming EU Cybersecurity Act raise the bar for secure processing and traceability of critical data. Especially the demand to provide information about existing data records of an individual and the ability to delete them on demand is central in privacy regulations. Common to these requirements is that cloud providers must be able to track data as it flows across the different services to ensure that it never moves outside of the legitimate realm, and it is known at all times where a specific copy of a record that belongs to a specific individual or business process is located. However, current cloud architectures do neither provide the means to holistically track data flows across different services nor to enforce policies on data flows. In this paper, we point out the deficits in the data flow tracking functionalities of major cloud providers by means of a set of practical experiments. We then generalize from these experiments introducing a generic architecture that aims at solving the problem of cloud-wide data flow tracking and show how it can be built in a Kubernetes-based prototype implementation.

Many organizations are still reluctant to move sensitive data to the cloud. Moreover, data protection regulations have established considerable punishments for violations of privacy and security requirements. Privacy, however, is a concept that is difficult to measure and to demonstrate. While many privacy design strategies, tactics and patterns have been proposed for privacy-preserving system design, it is difficult to evaluate an existing system with regards to whether these strategies have or have not appropriately been implemented. In this paper we propose indicators for a system's non-compliance with privacy design strategies, called privacy smells. To that end we first identify concrete metrics that measure certain aspects of existing privacy design strategies. We then define smells based on these metrics and discuss their limitations and usefulness. We identify these indicators on two levels of a cloud system: the data flow level and the access control level. Using a cloud system built in Microsoft Azure we show how the metrics can be measured technically and discuss the differences to other cloud providers, namely Amazon Web Services and Google Cloud Platform. We argue that while it is difficult to evaluate the privacy-awareness in a cloud system overall, certain privacy aspects in cloud systems can be mapped to useful metrics that can indicate underlying privacy problems. With this approach we aim at enabling cloud users and auditors to detect deep-rooted privacy problems in cloud systems.

When cooperating enterprises want to build a community cloud and don't want to burden only a single partner with the provisioning of the cloud infrastructure, they need an architecture that combines the cloud resources from different sites to form a single community cloud. While the idea is similar to grid computing the control over how the resources are used does not stay with the site, but is transferred to the user. Assuming that the IT infrastructures of the enterprises at least partly evolve towards a private cloud, the challenges we face become similar to those posed by the Intercloud. The architecture we present in this paper shows how clouds from different administrative domains can be linked together in a secure way. We also present a policy mechanism that allows users to control how their applications are distributed among the distributed architecture. This way it is possible to scale out parts of a distributed application, while other sensitive parts remain in the local cloud.