199

Abstract Organizations creating software commonly utilize software development lifecycles (SDLCs) to structure development activities. Secure development lifecycles (SDLs) integrate into SDLCs, adding security or compliance activities. They are widely used and have been published by industry leaders and in literature. These SDLs, however, were mostly designed before or while cloud services and other hosted solutions became popular. Such offerings widen the provider's responsibilities, as they not only deliver software but operate and decommission it as well. SDLs, however, do not always account for this change. Security maturity models (SMMs) help to assess SDLs and identify improvements by introducing a baseline to compare against. Multiple of these models were created after the advent of hosted solutions and are more recent than commonly referenced SDLs. Recent SMMs and SDLs may therefore support hosted solutions better than older proposals do. This paper compares a set of current and historic SDLs and SMMs in order to review their support for hosted solutions, including how support has changed over time. Security, privacy, and support for small or agile organizations are considered, as all are relevant to hosted solutions. The SDLs analyzed include Microsoft's SDL, McGraw's Touchpoints, the Cisco's SDL, and Stackpole and Oksendahl's SDL 2 . The SMMs reviewed are OWASP's Software Assurance Maturity Model 2 and DevSecOps Maturity Model. To assess the support for hosted solutions, the security and privacy activities foreseen in each SDLC phase are compared, before organizational compatibility, activity relevance, and efficiency are assessed. The paper further demonstrates how organizations may select and adjust a suitable proposal. The analyzed proposals are found to not sufficiently support hosted solutions: Important SDLC phases, such as solution retirement, are not always sufficiently supported. Agile practices, such as working in sprints, and small organizations are often not sufficiently considered as well. Efficiency is found to vary based on the application context. A clear improvement trend from before the proliferation of hosted solutions cannot be identified. Future work is therefore found to be required.

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.

IoT devices generate large amounts of data that is often processed in cloud backends. This data, however, is often personal and sensitive. At the same time, IoT devices often communicate via edge devices that allow to pre-process the devices' data before it is sent to the cloud. To facilitate the privacy-preserving communication between IoT devices and cloud backends, we propose a framework that can be deployed on edge devices and which allows the application of Privacy Enhancing Technologies (PETs) and other computational tasks. It is designed as a practical tool for service providers supporting the privacy-friendly design and operation of edge-based services. It supports various stakeholder requirements, e.g. extendibility and auditability, as well as legal requirements which result from the General Data Protection Regulation (GDPR), e.g. data minimization. We also present an example application using the AWS IoT service and its Greengrass software to show how the framework can be used in a car-sharing service.

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.

Current research on cloud service certification is working on techniques to continuously, i.e. automatically and repeatedly, assess whether cloud services satisfy certification criteria. However, traditional certifications are conducted following static processes which are not designed to meet the requirements of continuous certification techniques. In this paper, we address this gap by redesigning the traditional certification process and adding suitable tooling to support continuous certification of cloud services. To that end, we analyze and generalize traditional certification processes and, on this basis, develop a novel, executable process model to detect ongoing changes of cloud services and adapt continuous certification techniques accordingly. We present our prototype which implements the process model and show how it allows us to automatically reconfigure continuous certification techniques according to changes observed in the target of certification as well as to continuously report certification results.