Security Requirements Engineering is emerging as a branch of Software Engineering, spurred by the realization that security must be dealt with early on during the requirements phase. Methodologies in this field are challenging, as they must take into account subtle notions such as trust (or lack thereof), delegation, and permission; they must also model entire organizations and not only systems-to-be. In our previous work we introduced Secure Tropos, a formal framework for modeling and analyzing security requirements. Secure Tropos is founded on three main notions: ownership, trust, and delegation. In this paper we refine Secure Tropos introducing the notions of at-least delegation and trust of execution; also, at-most delegation and trust of permission. We also propose monitoring as a security design pattern intended to overcome the problem of lack of trust between actors. The paper presents a semantics for these notions, and describes an implemented formal reasoning tool based on Datalog. 1

The last years have seen a number of proposals to incorporate Security Engineering into mainstream Software Requirements Engineering.

It is generally accepted that early determination of the stakeholder requirements assists in the development of systems that better meet the needs of those stakeholders. General security requirements frustrate this goal because it is difficult to determine how they affect the functional requirements of the system. This paper illustrates how representing threats as crosscutting concerns aids in determining the effect of security requirements on the functional requirements. Assets (objects that have value in a system) are first enumerated, and then threats on these assets are listed. The points where assets and functional requirements join are examined to expose vulnerabilities to the threats. Security requirements, represented as constraints, are added to the functional requirements to reduce the scope of the vulnerabilities. These requirements are used during the analysis and specification process, thereby incorporating security concerns into the functional requirements of the system.

Developing security-critical systems is difficult and there are many well-known examples of security weaknesses exploited in practice. Thus a sound methodology supporting secure systems development is urgently needed. We present an extensible verification framework for verifying UML models for security requirements. In particular, it includes various plugins performing different security analyses on models of the security extension UMLsec of UML. Here, we concentrate on an automated theorem prover binding to verify security properties of UMLsec models which make use of cryptography (such as cryptographic protocols). The work aims to contribute towards usage of UML for secure systems development in practice by offering automated analysis routines connected to popular CASE tools. We present an example of such an application where our approach found and corrected several serious design flaws in an industrial biometric authentication system.

Assumptions are frequently made during requirements analysis of a system-to-be about the trustworthiness of its various components (including human components). These trust assumptions can affect the scope of the analysis, derivation of security requirements, and in some cases how functionality is realized. This paper presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the Secure Electronic Transaction (SET) specification. 1.

Integrating security concerns throughout the whole software development process is one of today's challenges in software and requirements engineering research. A challenge that so far has proved difficult to meet. The major difficulty

Assumptions are frequently made during requirements analysis of a system about the trustworthiness of its various components (including human components). These trust assumptions, whether implicit or explicit, affect the scope of the analysis, derivation of security requirements, and in some cases how functionality is realized. This paper presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the secure electronic transaction specification.

Service-based software systems are a useful concept recently developed to support the development of systems offering functions (the so-called services) which may be interrelated or may mutually depend on each other. Although appealing from a practical point of view, the development of service-based software for security-critical systems is, unfortunately, not well understood. Services may easily interact with each other in a way which may have unforeseen consequences on the various security properties provided. In this work, we propose a method for facilitating the development of security-critical service-based software systems using the computer-aided systems engineering tool AutoFocus based on the formal method Focus. We explain our method at the example of a service-based system from the automotive domain.

Assumptions about the trustworthiness of the various components of a system (including human components) can have a significant effect on the specifications derived from the system’s requirements. This position paper presents some early efforts to understand the relationships between general requirements, security requirements, and trust assumptions made during problem analysis. An outline of an approach for reasoning about security requirements and trust assumptions is provided. 1.

A number of recent proposals aim to incorporate security engineering into mainstream software engineering. Yet, capturing trust and security requirements at an organizational level, as opposed to an IT system level, and mapping these into security and trust management policies is still an open problem. This paper proposes a set of concepts founded on the notions of ownership, permission and trust and intended for requirements modeling. It also extends Tropos, an agent-oriented software engineering methodology, to support security requirements engineering. These concepts are formalized and are shown to support the automatic verification of security and trust requirements using Datalog. To make the discussion more concrete, we illustrate the proposal with a Health Care case study.