6 results
Now showing1 - 6 of 6
- Some of the metrics are blocked by yourconsent settings
Item type:Publication, Access status: without files , MASC: Modelling architectural security concerns(IEEE, 2015-05); ; ; ; Security decisions are an important part of software architecture design, and thus deserve to be explicitly represented in the design documentation. While UML is the best-known language for creating such documentation, it lacks security specific notations, which makes it difficult to represent the effect of the security decisions. Several security extensions for UML exist in the literature, but they represent security concerns at a lower level of abstraction, or only support a limited subset of security concerns. We propose a new notation, MASC, to model security concerns at the architectural level. It has been designed as an extension of UML, and is based on recurring security concepts that have been distilled from well-known security principles, goals, and patterns. By using our notation, a designer obtains a technique to express security concerns more explicitly in the architectural design documentation.Publicationtype: Conference Paper15 - Some of the metrics are blocked by yourconsent settings
Item type:Publication, Access status: without files , Empirical assessment of security requirements and architecture: lessons learned(Springer, 2014); ; ; ; Over the past three years, our groups at the University of Leuven and the University of Trento have been conducting a number of experimental studies. In particular, two common themes can be easily identified within our work. First, we have investigated the value of several threat modeling and risk assessment techniques. The second theme relates to the problem of preserving security over time, i.e., security evolution. Although the empirical results obtained in our studies are interesting on their own, the main goal of this chapter is to share our experience. The objective is to provide useful, hands-on insight on this type of research work so that the work of other researchers in the community would be facilitated. The contribution of this chapter is the discussion of the challenges we faced during our experimental work. Contextually, we also outline those solutions that worked out in our studies and could be reused in the field by other studies.Publicationtype: Book part27 - Some of the metrics are blocked by yourconsent settings
Item type:Publication, Access status: without files , Change patterns: Co-evolving requirements and architectureChange, such as in the requirements or the assumptions of a system, has a far-reaching impact across several software artifacts. This paper argues that patterns of co-evolution (or change patterns) can be observed between intertwined 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. The approach is empirically validated by means of a controlled experiment involving 12 subjects, and a case study involving an industrial partner.Publicationtype: Journal Article27 - Some of the metrics are blocked by yourconsent settings
Item type:Publication, Access status: without files , Least privilege analysis in software architecturesDue to the lack of both precise definitions and effective software engineering methodologies, security design principles are often neglected by software architects, resulting in potentially high-risk threats to systems. This work lays the formal foundations for understanding the security design principle of least privilege in software architectures and provides a technique to identify violations against this principle. The technique can also be leveraged to analyze violations against the security design principle of separation of duties. The proposed approach is supported by tools and has been validated in four case studies, two of which are presented in detail in this paper.Publicationtype: Journal Article14 - Some of the metrics are blocked by yourconsent settings
Item type:Publication, Access status: without files , Composition of least privilege analysis results in software architectures(Association for Computing Machinery (ACM), 2011-05); ; Security principles are often neglected by software architects, due to the lack of precise definitions. This results in potentially high-risk threats to systems. Our own previous work tackled this by introducing formal foundations for the least privilege (LP) principle in software architectures and providing a technique to identify violations to this principle. This work shows that this technique can scale by composing the results obtained from the analysis of the sub-parts of a larger system. The technique decomposes the system into independently described subsystems and a description listing the interactions between these subsystems. These descriptions are thence analyzed to obtain LP violations and subsequently composed to obtain the violations of the overall system.Publicationtype: Conference Paper11 - Some of the metrics are blocked by yourconsent settings
Item type:Publication, Access status: without files , Security in context: analysis and refinement of software architecturesSecurity analysis methods can provide correct yet meaningless results if the assumptions underlying the model do not conform to reality. We present an approach to analyze the security of software-intensive system architectures that focusses on making these underlying assumptions explicit, so that they can be taken into account. Starting from an Alloy model of a software architecture, a set of constraints is elicited by leveraging model relaxation techniques. These constraints form a minimal but sufficient condition that the system must meet in order to realise its security requirements. As the approach starts from the minimal guarantees that the system environment offers, it does not depend on an explicit attacker model and can take arbitrary attacker behaviour into account. As it is iterative, it is possible to constructively integrate the approach in a secure software development life cycle. Our results are illustrated by means of a case study.Publicationtype: Conference Paper24