1. Section Two: Security Requirements Frameworks This section surveys the existing approaches to eliciting, modeling, and analyzing

security requirements. The goal of this survey is to investigate the main factors for driving security requirements such as critical assets, potential threats, and vulnerabilities. In addition, we study the role of conceptual modeling notations in elicitation and analysis of security requirements. We study how different approaches to deriving and expressing security requirements result in different expressions of requirements.

1.1 Anti-Model ApproachLamsweerde [18] proposes a goal-oriented framework for generating and resolving

obstacles to goal satisfaction. The malicious obstacles, called anti-goals, are set up by the attackers to threaten security goals. The anti-goals are refined to form a threat tree, in which the leaf nodes are either software vulnerabilities or anti-requirements. New security requirements are then obtained as countermeasures.

The general idea in this framework is to build two models iteratively and concurrently. The first model of the system-to-be, and the second model is the anti-model, derived from the model that exhibit how specifications of model elements could be maliciously threatened, why, and by whom.

In this approach, first, application-specific instances of generic specification patterns such as confidentiality, availability, and privacy defined. The specification pattern is formalized in a first-order, real-time linear temporal logic with security-related predicates. Then, obstacle trees are built based on the goal negation, since the author asserts that it is easier to concentrate on what is desired rather than what is not. Anti-models are models that capture attackers, their goals and capabilities, and software vulnerabilities. Anti-model includes anti-goals, which are attacker’s own goals, and malicious obstacles to security goals. Finally, the alternative countermeasures to various vulnerabilities and anti-requirements are found, based on the severity and likelihood of the corresponding threat, and non-functional goals that have been identified in the primal goal model.

However, the framework does not consider assets as a main concept for eliciting and elaborating security requirements. In addition, it is not clear how the security goals should be decided in the initial steps. It is not described why the vulnerabilities are identified as part of the anti-goal mode development, while vulnerabilities exist even without the threat of the attacks.

1.2 Strategic Social Actors ApproachLiu et al. [19] propose employing explicit modeling of relationships among strategic

actors in order to elicit, identify, and analyze security requirements. In this approach, first generic role dependency patterns between actors in the domain are identified. This model can be elaborated to express whether the roles in the dependency relationship have trust, security, or privacy expectation on each other. Then the roles that attackers can potentially play are considered, and attacks to the system are modeled as negative contributions to dependency link.

The agent-oriented analysis continues with elaborating the role-agent hierarchy and modeling the dependency derivation. This helps to find out if one of the roles plays as the

Depth Oral ReportSection Two: Security Requirements Framework

attacker what dependencies are inherited to the attacker as well. In this approach, security requirements are originated from specifying security goals that actors expect from each other.

Goal analysis helps to analyze the attackers’ intentions and possible means of attack. This helps the analysts to put on the shoes of attackers to look into their intentions and means of attacks. The model expresses the impact of attacks on other goals and dependencies, and countermeasures are sought. The goal-oriented analysis helps decision making by providing a structure for modeling and deciding about dependability and trustworthiness goals.

However, the approach does not explicitly describe how countermeasures need to be incorporated into the models and what are their impacts on attacks and other goals. Detecting the attackers is limited to analyzing what roles in the system can impose threat on the dependencies, which ignores analyzing external random attackers.

In a similar approach, Liu et al. [14] analyze attackers, dependency vulnerabilities among actors, countermeasure, and access control. In this contribution, all actors are assumed potential attacker, which inherit capabilities, intentions, and social relationships of the corresponding legitimate actor. The basic idea of dependency analysis is that dependency relationships bring vulnerabilities to the system and the depending actor. The dependency vulnerability analysis, aims to find which dependency relationship is vulnerable to attacks. In this regard, the actors in the basic dependency model is substituted with its corresponding attacker, and then the impact of the attack to the dependency relationship is traced to the dependency network of other actors.

The authors state that the necessary factors for the success of an attack are attacker’s motivations, vulnerabilities of the system, and the attacker’s capabilities to carry out the attack. The framework suggests adding attacks as hypothetical threats inside the boundary of the depending actors, and adding denial or satisfaction labels to the goals that are affected. In the countermeasure analysis, security countermeasures to the threats and their impact are added to the model.

However, this framework does not provide a systematic approach for incorporating external attackers either. In addition, vulnerability analysis is limited to the vulnerabilities that dependencies bring, while goals, mechanisms and resources can bring vulnerabilities as well. The countermeasure analysis does not consider which player should employ the countermeasures and the countermeasures are placed inside the boundary of the victim actor.

1.3 Ownership, Permission and Delegation ApproachThe contribution in [20] introduces the Secure Tropos, a formal framework for

modeling and analyzing security requirements based on the concept of ownership, permission, and delegation. The ownership, trust, and delegation concepts are dealt within the normal functional requirements model. The paper suggests security and trust requirements need to be derived by exploring vulnerabilities in the interface between the organization and the information system.

In this framework, ownership is defined as the relationship between an actor and a service if an agent is the legitimate owner of a service. Trust among two actors and a service means that the actor A trusts the actor B on a certain goal G. The authors assert that we are often forced for pragmatic reasons to delegate services and permissions to

2

Depth Oral ReportSection Two: Security Requirements Framework

people we do not trust. Delegation among two actors and service means that the actor A explicitly delegates to the actor B a goal or the execution of a task or the access to a resource. This framework defines two types of delegation relations: delegation of execution and delegation of permission. The former indicates that one actor delegates the responsibility of a service to the other actor, and the latter indicates that one actor delegates the permission of a service to the other one. The corresponding meta model of the notation is presented as part of the i* meta model in [31].

The semantic framework of the proposed notation is specified using Datalog predicates. The predicates correspond to the relationships that the requirements engineer can actually draw during analysis. A group of the predicates are used to define properties that are used in formal analysis. The framework can help the analysts to express the ownership relationships, who is entitled with permission or execution delegation, which actor trusts on what to other actors.

The formal analysis procedure gets a formally specified ownership, delegation and trust of execution, and delegation and trust of permission model, and checks for the possible violations according to permission or execution delegation and trust. The formal analysis verifies if actors have assigned permission and obligation to actors that they trust, if actors have assigned duties to actors that have capabilities and permission to achieve the goals, and if actors have only the permission necessary to achieve their duties, etc.

However, modeling and analyzing trust, ownership, and delegation relationships and dependencies among entities and actors are not enough for expressing security requirements and concerns. While in security engineering, an important concern is analyzing possible threats imposed by unknown and external entities that stakeholders may not depend. In addition, the concept of vulnerabilities is a main concern in analyzing security aspects of the system, which this framework does not address. While it is obvious that delegating permissions to untrusted parties poses security threats, there exists circumstances, such as the Internet global scenario, that interacting parties have to delegate permissions while they do not trust each other. Therefore, it is necessary to analyze how the untrusted parties can compromise the system to decide between alternative security countermeasures.

1.4 Misuse Case and Abuse Case ApproachWe described the notion of misuse case [16] and abuse case [3] in the previous part.

The process of eliciting security requirements by misuse cases consists of 5 steps: it starts with identifying critical assets. Then security requirements for each asset are defined. In the third step, threats to each security requirements are defined and expressed as misuse cases. In the fourth step, risks of threats are identified and analyzed, and finally, security requirements for the threats are defined as either security use cases or in the mitigation field of misuse case description. Security requirements are either defined as security use cases or as mitigation in misuse case description.

Looking at system from a misuser perspective increases the chance of discovering threats that would otherwise have been ignored. The authors assert that the visualization of links between use cases and misuse cases help organize the requirements specification and tracing requirements to threats that motivated them. However, the security requirements elicitation process does not consider why and how security goals are

3

Depth Oral ReportSection Two: Security Requirements Framework

defined without analyzing what may threaten the assets. In addition, the targets of threats are not only security goals, and threats may target an asset or service rather than a security goal. The notion of misuse case cannot express due to what kind of vulnerability a misuse threatens a use case, why a misuser attacks the system, and what is the impact of a security use case on other use cases.

1.5 Security Requirements Framework for Representation and AnalysisHaley et al. [15] propose a security requirement engineering framework for

expressing and analyzing security requirements as constraints on functional requirements. The paper is based on three main contributions: definition of security requirements, considering assumption and specially trust assumption about the system context, and finally, satisfaction arguments.

This proposed framework distinguishes the security goals and security requirements. Security goals aim to assets from harm, and operationalized into security requirements, which are constraints on the system’s functional requirements. The framework introduces four main activities to move from functional goals to final arguments that if the security requirements are satisfied. The activities start with identifying functional requirements. In the second step, security goals are identified, then, security requirements are identified, and finally, satisfaction arguments are constructed. A set of security requirements core artifacts is introduced that are developed during the activities, which mainly consists of documenting application and security goals, assets, management control principles, functional, quality, and security requirements, and system architecture.

While security goals is in form of a desire, such as confidentiality, security requirements are in form of restricting statements such as “The system shall provide service X only to authorized personnel”. Once the security requirements are gathered, one must validate that security requirements satisfy the security goals, using the satisfaction arguments. Satisfaction arguments consist of a formal outer argument and an informal inner argument. The outer argument uses claims about the system behavior to show that security requirements are satisfied. The inner argument uses Toulmin argument approach to support claims and capture relationship between domain properties, by developing a tree-like structure, where the leaf nodes of argument tree are unsupported. Such statements are trust assumption about the behavior or properties of the world that the system lives within.

However, the impact of possible attacks in the context of the system is missed in the proposed framework. Assets and the harms that compromising the asset may pose is considered to elicit the security constraints. However, potential attacks and their impact on the functional and non functional requirements are not analyzed explicitly. In contrast to several approaches that focus on attacks, the proposed framework does not related the security goals to any threatening attacks and attackers. In addition, system vulnerabilities, such as buffer overflow and password losses, are not considered in satisfaction arguments.

The proposed framework deals with security requirements as constrains on the functional requirements is intuitive. However, this constraint needs to be transformed to an operationalization. However, it is not studied if designing and implementing requirements in form of a constraint is more intuitive or functional representation of the

4

Depth Oral ReportSection Two: Security Requirements Framework

security requirements, like “the system should first authenticate the users to provide the service” is more useful.

A typical security requirement would be like “The system shall provide service X only to authorized personnel”. Then, it is left to the designer to find a solution to satisfy this requirement. The designer choice might be password-based authentication, while this introduces new vulnerabilities and potential attacks against the system, and consequently, the designer needs to introduce new solutions to protect the password which may affect other functional and non-functional (including security) requirements. Although the authors of the framework points to the use of Twin Peak model in the proposed requirements engineering approach, the framework does not explicitly deal with the iterative impact of requirements, design, and attacks in each other.

1.6 Crosscutting Threat Descriptions ApproachHaley et al. [21] state that security requirements frustrate early determination of

stakeholders requirements because it is difficult to determine how security affects the functional requirements. This paper suggests using threats as crosscutting concerns to determine the impact of security requirements on the functional requirements. Functional requirements describe how objects are transformed in the system. These objects are assets because they need to be protected. A threat is the potential for abuse of an asset that will cause harm in the context of the problem, and threat description describes relationships between objects and threats. A threat description is a descriptive phrase of the form “performing action X on/to asset Y could cause harm Z”. Vulnerabilities are weaknesses in the system that an attack exploit, and are found in join points of threat descriptions and functional requirements. Security requirements are constraints on functional requirements intended to reduce the scope of vulnerabilities. The resulting advice of analysis is a set of security requirements that reduce the size of the vulnerability and protect the assets. Security requirements can be expressed as constraints on functionalities or trust assumptions. Problem frames are used as the tool during the problem analysis. In this way, problems are described by the interaction of domains that exist in the world.

The security requirements analysis iterations start with identifying objects in the problem context that might participate in a threat and describing threats. In the next step, threat description is crosscut with the subproblem to determine which threats apply to a given subproblem. In this regard, threats are composed with subproblems looking for vulnerabilities that may be used to exploit a threat. If vulnerabilities are found, security requirements are generated to reduce the vulnerability. For this aim, a list of critical assets in a subproblem is gathered and the tuples of (asset, subproblem) are combined with a threats against assets using a natural joint.

The proposed approach employs problem frames, in which problems (and subproblems) are described by interaction of domains that exist in the world. However, problem frames, as the modeling approach employed in the introduced framework, does not provide any facilitator for understanding the threats and their relation to assets, vulnerabilities, and functional requirements. Although the idea of crosscutting is interesting, to have a full trade-offs analysis, we need crosscut both threats and safeguards with assets and subproblems to evaluate the impact of both threats and alternative safeguards on vulnerabilities, threats, and security requirements, other quality requirements and functional requirements.

5

Depth Oral ReportSection Two: Security Requirements Framework

1.7 Security Requirements Elaboration based on Trust Assumption The idea of analyzing the trust assumption and threats on security requirement

expressed as constraints are discussed in [21, 26, 27]. The contributions in [26, 27] focus on analyzing the trust assumption on deriving security requirements using problem frames. In this approach, assets and security goals for protecting assets are considered as key factors for eliciting security requirements. The authors assert that although not required derivation of security requirements can be facilitated by the postulation of the existence of an attacker, since threat descriptions assist with locating potential vulnerabilities.

The focal point of this contribution is the argument that trust assumptions can have a fundamental important impact on how the system is realized. In this regard, trust is defined as the quantified belief by a trustor with respect to the competence, honesty, security and dependability of a trustee within a specified context. By considering trust assumptions a requirements engineer believes and accepted that the domain holds some certain properties and specification.

To incorporate the trust assumption into the problem frames models, the notation is extended with an arc from domain to a dotted oval describing the properties assumed to be true. By adding trust assumption the model works as a documentation about the way that requirements engineer trust the behavior of the domain, and the scope of the analysis is limited to the domain.

Although trust assumptions work as the restrictions, and even security constraints or requirements which is assumed that is already satisfied, the modeling approach does not provide a way to express why and how those assumptions are considered to be valid. In other word, there is no explicit way to relate the assumption to the threats and vulnerabilities, and express that that it is believed that those vulnerabilities will not be exploited and those attacks will no occur. Therefore, the approach does not provide a way to analyze if the trust assumptions are valid o invalid.

1.8 UMLsec: Extending UML for Secure System DevelopmentUMLsec [12] is an extension to UML that allows expressing security relevant

information within UML diagrams. The main uses of such approach are first, to encapsulate knowledge and make it available to developers in form of a widely-used design notation, and secondly, to provide formal evaluation to check if the constraints associated with the UMLsec stereotypes of fulfilled in a given specification.

The extensions are suggested in form of UML stereotypes, tags, and constraints that can be used in various UML diagrams such as activity diagrams, statecharts, and sequence diagrams. For a security analysis of the UMLsec subsystem specification, potential adversary behavior needs to be modeled. For this purpose, a function of Threat is defines which takes an adversary type and a stereotype and returns a subset of {delete, read, insert} which changes a state of the subsystem.

The stereotypes and tags encapsulate the knowledge of recurring security requirements of distributed object-oriented systems, such as secrecy, fair exchange, and secure communication link. By assigning a stereotype and tag to part of a model, and retrieving the threats, the behavior of the subsystem can be analyzed to check the impact of the threat.

6

Depth Oral ReportSection Two: Security Requirements Framework

The general high level idea of adding security stereotypes, tags, and constraints to the UML models is useful for expressing security related information. The formal definition of semantics of the UMLsec extensions is useful for doing security evaluations. The defined security requirements are high level and general. On the one hand, this increases the reusability of the extensions in various contexts. On the other hand, the security requirements and other stereotypes such as Internet and LAN are too high level, and the default threats (and semantics of the requirements or stereotype) may not be valid in every context.

It is true that the impact of any security threat is finally deleting, reading, or inserting data in an authorized way. However, security attacks in existing taxonomies, guidelines, and standards are not categorized in this way, and a designer may know more about attacks expressed as SQL injection, viruses, man in the middle, etc. In addition, the notion of {Delete, Read, Insert} is not useful for expressing the impacts of attacks such as Denial of Service.

In an example, the author discusses how UMLsec can be used to evaluate a security protocol specified in a statechart diagram. However, it is not clear how the cryptographic operation and message exchanges are related to the <<data security>> stereotype. The author argues that UML is a widely used notation in analysis and design of software systems and developers already know UML modeling notation, and the notation is well defined. However, this does not provide sufficient justification for modeling and analyzing security requirements using extensions to UML. One may argue that security concerns involve aspects that UML diagrams are not able to grasp. Finally, UML is not a requirements engineering notation. The only diagram that focuses on the system functionalities and expectations from the system from the users’ point of view is the use case diagram, while the formal semantic defined for the use cases is limited.

1.9 Risk-Based Security Requirements Engineering FrameworkThe risk-based security requirements engineering framework in [24] is concerned

about integrating requirements engineering practices with security engineering with intertwining between requirements and architecture design adopting risk analysis practices as a key activity. This approach aims to analyze the impacts of threats on the business by linking the risk impacts with the business value. The focal idea is to align the IT security with business goals, and for this aim, the impacts of risks on the business assets are analyzed, risks are related to the threats the pose and vulnerabilities in the architecture, and security requirements mitigate the risks, while risks. This analysis is an iterative approach since when modifying any requirements or architecture model element produced by the Requirements Engineering or Architecture Engineering activity, this may cause major modifications in the models of security engineering.

The proposed approach employs i* as the requirements and architecture modeling framework, and adapts risk analysis to the early security engineering approach. In this approach, four main security engineering activity is defined. They have defined 4 main activities for security engineering: 1) Context analysis and assets identification, 2) Security goal determination for identifying the security goals needed protect each asset.”, 3) Security requirements elicitation, which is refinement of security goals, and finally, 4) Countermeasures selection. In order to align the countermeasures with business, risk analysis needs to be done. Since countermeasures may result in the introduction of new

7

Depth Oral ReportSection Two: Security Requirements Framework

additional assets, goals or requirements, their costs must be evaluated against the initial business purposes.

Generally, risk is defined as the combination of the probability of occurrence of harm and the severity of that harm. In this approach, IT risk are further decomposed into three components: Risk = Threat * Vulnerability * Impact. In this way, risk is characterized by the opportunity of exploiting one of multiple vulnerabilities, from one or many entities, by a threatening element using an attack, causing an impact on business assets. In this approach, risk analysis is the activity of analyzing threat, vulnerability and impact on each component of the system.

The risk analysis is an iterative process which starts with coarse value analysis of business assets. Then, the probability of attacks and cost of countermeasures are considered. For representing threats and their impacts and countermeasures using the i* notation, new extensions to the i* are introduced. In the extended i* models, threats, and the vulnerability that the threat uses are modeled. The impact of the threats and the relation of the vulnerability with elements of the model are expressed in the models.

However, the risk analysis approach is not yet systematically aligned with the model development. The resulting models do not capture the impacts of the threats either quantitatively or qualitatively. In addition, the cost benefit analysis for the risk analysis is limited to the budget-related costs, while threats and countermeasures can have direct impacts on functional and non-functional requirements and indirect costs.

The security and requirements engineering process introduced in [24] does not consider attacks and vulnerabilities, and postpones analyzing them to the risk analysis activity. In this way, security goals are identified without relating business assets that may be threatened by attacks. In addition, countermeasures are selected without considering that the goal of countermeasures are patching a vulnerability or preventing an attack.

1.10 Discussion and Conclusions Although employing different modeling notations, existing security requirements

engineering frameworks consider similar concerns for driving and deciding on security requirements.

1. Several approaches consider assets and valuable objects as the main starting point for driving security requirements [16, 15, 21 , 26, 24].

2. A major group of frameworks consider analyzing potential threats and attackers’ behavior for detecting security requirements and analyzing the risks of the threats [14, 16, 3, 15, 21, 26, 18, 24].

3. Several approaches consider security as a social concern that arises from interactions and dependencies among actors [14, 20].

4. A number of approaches consider trust relationships and trust assumption as one of the main factors for driving and analyzing security requirements [20, 15, 21, 26].

5. Few of the frameworks consider the notion of vulnerabilities for deriving security requirements, however, the current approaches do not provide a systematic way for detecting, modeling, and analyzing vulnerabilities and relating them to attacks and security countermeasures.

8

Depth Oral ReportSection Two: Security Requirements Framework

6. In the contributions mostly developed by Haley et al. [15, 21, 26] security requirements are dealt as constraints on the functional requirements.

7. Several security requirements frameworks [24, 18, 26, 15, 16, 14] consider the concept of security goals and refine them to extract and specify security requirements in further details.

8. A number of frameworks [18, 24] expand the requirements engineering process to analyze alternative security countermeasures for satisfying security requirements.

9. A few of frameworks [24, 21, 16] consider analyzing security risks for driving security requirements and deciding on security countermeasures.

10. Existing security requirement engineering frameworks and modeling notations mostly focus on identifying security requirements and evaluating if a certain system design can satisfy those requirements. However, some approaches such as [12] focus on encoding requirements and design in system level details (Figure T).

Figure T Summary of security requirements analysis using UMLsec [12]

Figure T to y summarizes and compares similarities and differences of the existing security requirements frameworks. Figure x summarizes the security requirements framework described in [15, 21, 26].

9

Depth Oral ReportSection Two: Security Requirements Framework

Figure x comparison of three similar approaches developed based on the idea of crosscutting threats, trust assumption, and iterative requirement engineering and architecture design

Figure z compares two agent- and goal-oriented security requirements approaches developed by Liu et al. [14] and Giorgini et al. [20].

Figure z Comparison of two agent- and goal-oriented security requirements engineering approaches [14] and [20].

Figure w compares two security requirements frameworks (anti-goals [18] and misuses [16]) which the inverted models are the focal points of the frameworks.

10

Depth Oral ReportSection Two: Security Requirements Framework

Figure w Comparison of two security requirements modeling and analysis approach base on the notion of inverted models: anti-goals [8] and misuse cases [16].

Finally, figure y depicts the security requirements engineering framework in [24] based on a risk analysis approach.

Figure y Summary of the risk-based security requirements framework [24]

Surveying several security requirements engineering frameworks shows that each approach has a different view to the system, security, and requirements. For example, some approaches view system as a network of strategic and social actors that may (not) trust each other and delegate services to the other actors [14, 20]. In approaches such as [12, 15, 21, 26], the system-to-be and the environment are modeled by focusing on the different aspects of the system from one single point of view. The difference of viewpoints to the system results in different types of requirements. Using UMLsec [12] one can conclude if a system setting satisfies a set of requirements expressed as stereotypes, while analyzing actors’ dependencies from point of view of trust, permission, ownership, and delegation [20] results in conclusion about dependencies among partners.

11

Depth Oral ReportSection Two: Security Requirements Framework

In addition, the security requirements engineering frameworks do not agree on the concept of security completely. While UMLsec [12] enables modeling and analyzing issues such as fair exchange and secrecy as the security concerns, approaches such as [20, 14] deals with security as an issue that arises from the interaction of social actors, approaches such as misuse cases [16] and abuse cases [3] deal with security as an issue where the system users misuse the functionality, and framework in [15] considers security as a constraints on the functionality.

In short, existing security requirements frameworks do not agree on what is a security requirement. It is expected that the final outcome of the frameworks should be a list of feasible requirements that guarantee system’s security against potential attacks. The list of the security requirements need to be feasible to implement, and for this aim, requirements analysts need to consider alternative solutions that satisfy the requirements and decide on them. The outputs of existing security frameworks include a variety of concerns such as what trust assumptions are not valid, what constraints need to be enforced on functionalities, what attacks should be prevented and by using what security countermeasures, what vulnerabilities need to be patched and how. Although all these conclusions are of importance and interest, security requirements need to be re-defined with a robust agreement among the secure software engineering community.

Reference:14. Liu, L., Yu, E., Mylopoulos, J., Security and Privacy Requirements Analysis

within a Social Setting. In IEEE Joint Int. Conf. on Requirements Engineering (2003) 151-161

15. Charles B. Haley, Robin Laney, Jonathan D. Moffett, and Bashar Nuseibeh, Security Requirements Engineering: A Framework for Representation and Analysis, (to appear in) Transactions on Software Engineering (IEEE) (2007)

16. Sindre, G., Opdahl, A. L., Eliciting security requirements with misuse cases, RE Journal, Volume 10 (2005) 34-44

17. G. Sindre and A. L. Opdahl. Templates for misuse case description. In Seventh International Workshop on Requirements Engineering: Foundation of Software Quality (REFSQ’2001), Interlaken, Switzerland, 2001

18. A. Van Lamsweerde, Elaborating Security Requirements by Construction of Intentional Anti-models, In Proc. of ICSE’04 (2004) 148-157

19. Liu, L., Yu, E., Mylopoulos, J., Analyzing Security Requirements As Relationships among Strategic Actors, In 2nd Symposium on RE for Information Security (SREIS) (2002)

20. Giorgini , P., Massacci, F., Mylopoulos, J., Zannone N., Modeling Security Requirements Through Ownership, Permission and Delegation, In proc. of RE (2005) 167-176

21. Haley, C. B., Laney, R. C., Nuseibeh, B., Deriving Security Requirements from Crosscutting Threat Descriptions, In Proc. of the 3rd Int. Conf. on Aspect-Oriented Software Development (AOSD'04) ACM Press (2004) 112-121

22. Dardenne, A., van Lamsweerde, A., Fickas, S., Goal-Directed Requirements Acquisition, in The Science of Computer Programming 20 (1993) 3-50

12

Depth Oral ReportSection Two: Security Requirements Framework

23. Bresciani, P., Giorgini, P., Mouratidis, H., On Security Requirements Analysis for Multi-Agent Systems, In Proc. of 2nd Int. Workshop on Software Engineering for Large-Scale Multi-Agent Systems SELMAS (2003)

24. Mayer, N., Rifaut, A., Dubois, E., Towards a Risk-Based Security Requirements Engineering Framework, 11th Int. Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ'05) (2005)

25. P. Giorgini, F. Massacci and N. Zannone, Security and trust requirements engineering, In foundations of security analysis and design III, Tutorial lecture LNCS 3655, (2005) 237-272

26. Charles B. Haley, Robin C. Laney, Jonathan D. Moffett, Bashar Nuseibeh, The Effect of Trust Assumptions on the Elaboration of Security Requirements, Proceedings of the Requirements Engineering Conference, 12th IEEE International (RE'04) - Volume 00 (2004) 102-111

27. Charles B. Haley, Robin C. Laney, Jonathan D. Moffett, Bashar Nuseibeh, Using trust assumptions with security requirements, Requirements Engineering archiveVolume 11 ,  Issue 2  (2006) 138-151 

28. P. Giorgini, F. Massacci, J. Mylopoulos and N. Zannone. Requirements Engineering for Trust Management: Model, Methodology, and Reasoning. The International Journal of Information Security, 5(4) (2006) 257-274

29. V. Bryl, F. Massacci, J. Mylopoulos and N. Zannone. Designing Security Requirements Models through Planning. In Proceedings of the 4th International Workshop on AI for Service Composition, pages 28-35, 2006

30. R. De Landtsheer, A. van Lamsweerde, Reasoning about Confidentiality at Requirements Engineering Time, Proceedings of ESEC/FSE’05, The fifth joint meeting of the European Software Engineering Conference and 13th ACM SIGSOFT Symposium on the Foundations of Software Engineering, 2005

31. N. Zannone, The SI* Modeling Framework: Metamodel and Applications, in International Journal of Software Engineering and Knowledge Engineering, 2008

32. Jan Jürjens, Pasha Shabalin: Automated Verification of UMLsec Models for Security Requirements. UML 2004: 365-379

13