Search

—Threat modeling allows potential security threats to be identified and mitigated at design time. Countermeasures in current threat modeling approaches are mostly modeled as a boolean: either they are implemented, or they are not. This does not allow to take into account potential design flaws for the countermeasure itself. A considerable number of security issues is, however, related to the wrong or incomplete application of common security tactics. For example, the effectiveness of audit logs drops if the data written to the logs is not sanitized. In this paper, we describe our novel approach which aims to systematically and automatically identify common security design flaws., The poster was accepted at the 7th IEEE European Symposium on Security and Privacy (Euro S&P 2022) and presented in the poster session. Original poster: https://ieeeeurosp.github.io/2022/posters/

Additional file 2: Coding tree.

Recurring solutions to software engineering problems are often captured in patterns, which describe, in a generic but reusable manner, a specific problem and a corresponding solution. This thesis develops a deeper understanding about how pattern catalogs can help a software architect to reconcile the software's requirements and the architecture in the context of security. To achieve this goal, we follow an empirical approach.Two aspects of development are taken into account, namely (1) the construction of the software, and (2) its evolution over time. An analysis of the security patterns landscape shows that sufficient security patterns exist for the construction of secure software, but organization is needed to make them more usable. With a controlled empirical experiment, we investigate the effect of such organization from the viewpoint of the software architect.Regarding patterns for secure co-evolution, we observe that no patterns have been defined. Therefore, we propose a framework for precisely describing such patterns (called change patterns), together with a process for applying them. We illustrate the concepts with patterns for handling evolving trust requirements and access control. The approach is validated by means of two empirical studies, and implemented in a proof of concept tool. status: published

Emerging classes of systems are more and more subject to changes in their requirements and environment assumptions. Such changes have a far-reaching impact across several artifacts. This paper argues that patterns of co-evolution (or change patterns) can be observed between ``privileged'' pairs of artifacts, like the requirements specification and the architectural design. The paper introduces change patterns as a precise framework to systematically capture and handle change. The approach is based on model-driven engineering concepts and is accompanied by a tool-supported process. Changing trust assumptions are presented as an example of security-related evolution, and are used to illustrate the approach. ispartof: CW Reports nrpages: 24 status: published

When designing a secure software architecture, the architect must take possible evolution of the system and its environment into account. Inevitably, during the lifetime of the application, changes will occur that reduce the security of the system. It is crucial that these changes are anticipated, and that they can be accomodated with minimal impact on the architecture. This report introduces the concept of `change patterns', providing guidance to the architect to achieve this goal. A change pattern guides the architect in designing an architecture that is resistant against certain foreseen evolutions of the requirements and assumptions. It explicitly records the change of requirements or assumptions it supports. After the architect has selected appropriate change patterns, applying a pattern consists of two steps. First, the architecture needs to be prepared up-front for the evolution (even though it has not yet occurred), based on a likelihood and importance analysis of the evolution. Second, once the evolution occurs, the architect is triggered to perform the necessary steps to update the application such that it conforms to the new situation. These two steps are reflected in the solutions that belong to the change pattern: architectural patterns for the up-front preparation, and change guidance for performing the actual update of the application. This report contains a description of a change pattern, an outline of a process to use change patterns, and a catalogue of eight change patterns for evolving trust relationships, and an illustration of their use. ispartof: CW Reports nrpages: 54 status: published

Reusing time-tested solutions rather than inventing ad-hoc quick fixes is a well-known security principle. Architectural and design patterns represent proven techniques to package knowledge from software engineering experts in a reusable format. More importantly, the solution proposed by a pattern is known to be sound because it is time-tested -- its strengths, weaknesses and possible drawbacks are known in advance. Therefore, in software security engineering, security patters have been considered to be a very promising means to increase the quality of secure design and make security more accessible to software engineers. However, their adoption does not live up to their potential. To understand why this is so, this paper analyzes the literature of security patterns published over the last ten years and outlines existing gaps. ispartof: CW Reports nrpages: 24 status: published

Security patterns, as domain-independent expert knowledge packaged in a reusable format, are able to offer significant guidance to the software engineer in developing secure systems. However, the overabundance of published security patterns complicates the process of finding the right pattern to solve the problem at hand. This is due to three reasons. First, not all security patterns are relevant to the software engineer. Second, the domain independence of patterns sometimes complicates finding a solution to a domain specific problem. Third, patterns exist on different levels of abstraction. Not all patterns can be applied to every step in the development process of a system. This report proposes a method to facilitate the selection of a suitable set of security patterns to realize a specific set of security requirements. It is comprised of two parts. First, additional structure is superimposed on this collection. Second, a methodology is proposed that, given this structured inventory of patterns, guides the software engineer from the security requirements to an appropriate solution using patterns, taking into account various trade-offs and relations between patterns. ispartof: CW Reports nrpages: 26 status: published

ispartof: pages:1-10 ispartof: Eleventh international workshop on aspect-oriented modeling (AOM@MODELS 2007) pages:1-10 ispartof: International conference on model driven engineering languages and systems (MODELS 2007) location:Nashville, Tennessee, USA date:30 Sep - 5 Oct 2007 status: published

Security and privacy are long recognized as key concerns in the development of software systems. Despite their recognized importance, much of the attention is focused only on the code-level implementation of these principles. However, the design-level consideration of these principles is instrumental to fully realize secure and privacy-preserving software and avoid costly design flaws. Avoiding these security and privacy flaws requires support for analyzing the software design for security and privacy threats. A common design representation used in this context is the Data Flow Diagram (DFD). Security and privacy threat modeling approaches use this DFD representation to identify security and privacy threats. However, these analyses involve extensive manual effort and quickly lead to an explosion of threats to resolve. This makes the analyses effort-intensive and error-prone. It hinders their reproducibility and overburdens the evaluation of design alternatives. This thesis addresses the automation of security and privacy threat analysis and thus supports security and privacy by design. The automated threat analysis is enabled through: (i) an extension to the DFD representation of software systems to support the inclusion of essential information on security and privacy solutions, considering the effects of these solutions in mitigating security and privacy threats, and (ii) extending model-based security and privacy design analysis activities to enable the elicitation of security and privacy threats using model queries and the prioritization of the identified security and privacy threats using risk indicators. These extensions are validated and integrated in the SPARTA tool prototype to realize comprehensive and automated security and privacy threat analyses. The implementation provides a foundation for further exploring and realizing automation opportunities in the construction of system designs, the evaluation of security and privacy design alternatives, and the integration as an automated analysis activity in contemporary continuous integration and deployment practices. status: published