Biblio

The presence of experts, such as a data protection officer (DPO) and a privacy engineer is essential in Privacy Requirements Engineering. This task is carried out in various forms including threat modeling and privacy impact assessment. The knowledge required for performing privacy threat modeling can be a serious challenge for a novice privacy engineer. We aim to bridge this gap by developing an automated approach via machine learning that is able to detect privacy-related entities in the user stories. The relevant entities include (1) the Data Subject, (2) the Processing, and (3) the Personal Data entities. We use a state-of-the-art Named Entity Recognition (NER) model along with contextual embedding techniques. We argue that an automated approach can assist agile teams in performing privacy requirements engineering techniques such as threat modeling, which requires a holistic understanding of how personally identifiable information is used in a system. In comparison to other domain-specific NER models, our approach achieves a reasonably good performance in terms of precision and recall.

In this extended abstract, we outline an approach for security certification of products or services for modern commercial systems that are characterized by agile development, the integration of development and operations, and high dynamics of system features and structures. The proposed scheme rather evaluates the processes applied in development and operations than investigates into the validity of the product properties itself. We argue that the resulting claims are still suitable to increase the confidence in the security of products and services resulting from such processes.

Agile methods frequently have difficulties with qualities, often specifying quality requirements as stories, e.g., "As a user, I need a safe and secure system." Such projects will generally schedule some capability releases followed by safety and security releases, only to discover user-developer misunderstandings and unsecurable agile code, leading to project failure. Very large agile projects also have further difficulties with project velocity and scalability. Examples are trying to use daily standup meetings, 2-week sprints, shared tacit knowledge vs. documents, and dealing with user-developer misunderstandings. At USC, our Parallel Agile, Executable Architecture research project shows some success at mid-scale (50 developers). We also examined several large (hundreds of developers) TRW projects that had succeeded with rapid, high-quality development. The paper elaborates on their common Critical Quality Factors: a concurrent 3-team approach, an empowered Keeper of the Project Vision, and a management approach emphasizing qualities.

Digitization has increased exposure and opened up for more cyber threats and attacks. To proactively handle this issue, enterprise modeling needs to include threat management during the design phase that considers antagonists, attack vectors, and damage domains. Agile methods are commonly adopted to efficiently develop and manage software and systems. This paper proposes to use an enterprise architecture repository to analyze not only shipped components but the overall architecture, to improve the traditional designs represented by legacy systems in the situated IT-landscape. It shows how the hidden structure method (with Design Structure Matrices) can be used to evaluate the enterprise architecture, and how it can contribute to agile development. Our case study uses an architectural descriptive language called ArchiMate for architecture modeling and shows how to predict the ripple effect in a damaging domain if an attacker's malicious components are operating within the network.

Context: While successful conventional software development regularly employs separate testing staff, there are successful agile teams with as well as without separate testers. Question: How does successful agile development work without separate testers? What are advantages and disadvantages? Method: A case study, based on Grounded Theory evaluation of interviews and direct observation of three agile teams; one having separate testers, two without. All teams perform long-term development of parts of e-business web portals. Results: Teams without testers use a quality experience work mode centered around a tight field-use feedback loop, driven by a feeling of responsibility, supported by test automation, resulting in frequent deployments. Conclusion: In the given domain, hand-overs to separate testers appear to hamper the feedback loop more than they contribute to quality, so working without testers is preferred. However, Quality Experience is achievable only with modular architectures and in suitable domains.