Results 1 - 10
of
139
Non-functional requirements in software engineering
, 1999
"... www.utdallas.edu/~chung/, www.inf.puc-rio.br/~julio Abstract. Essentially a software system’s utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided em ..."
Abstract
-
Cited by 114 (7 self)
- Add to MetaCart
(Show Context)
www.utdallas.edu/~chung/, www.inf.puc-rio.br/~julio Abstract. Essentially a software system’s utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.
Elaborating Security Requirements by Construction of Intentional Anti-Models
, 2004
"... Caring for security at requirements engineering time is a message that has finally received some attention recently. However, it is not yet very clear how to achieve this systematically through the various stages of the requirements engineering process. The paper presents a constructive approach to ..."
Abstract
-
Cited by 99 (3 self)
- Add to MetaCart
Caring for security at requirements engineering time is a message that has finally received some attention recently. However, it is not yet very clear how to achieve this systematically through the various stages of the requirements engineering process. The paper presents a constructive approach to the modeling, specification and analysis of applicationspecific security requirements. The method is based on a goal-oriented framework for generating and resolving obstacles to goal satisfaction. The extended framework addresses malicious obstacles (called anti-goals) set up by attackers to threaten security goals. Threat trees are built systematically through anti-goal refinement until leaf nodes are derived that are either software vulnerabilities observable by the attacker or anti-requirements implementable by this attacker. New security requirements are then obtained as countermeasures by application of threat resolution operators to the specification of the antirequirements and vulnerabilities revealed by the analysis. The paper also introduces formal epistemic specification constructs and patterns that may be used to support a formal derivation and analysis process. The method is illustrated on a web-based banking system for which subtle attacks have been reported recently.
Modeling Security Requirements Through Ownership, Permission and Delegation
- In Proc. of RE’05
, 2005
"... 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 the ..."
Abstract
-
Cited by 97 (32 self)
- Add to MetaCart
(Show Context)
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
Security requirements engineering: A framework for representation and analysis
- IEEE TRANSACTIONS ON SOFTWARE ENGINEERING
, 2008
"... This paper presents a framework for security requirements elicitation and analysis. The framework is based on constructing a context for the system, representing security requirements as constraints, and developing satisfaction arguments for the security requirements. The system context is describe ..."
Abstract
-
Cited by 76 (15 self)
- Add to MetaCart
(Show Context)
This paper presents a framework for security requirements elicitation and analysis. The framework is based on constructing a context for the system, representing security requirements as constraints, and developing satisfaction arguments for the security requirements. The system context is described using a problem-oriented notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument consists of two parts: a formal argument that the system can meet its security requirements and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project.
B.: A framework for security requirements engineering
- In: Proceedings of the International Workshop on Software Engineering for Secure Systems (SESS
, 2006
"... ABSTRACT This paper presents a framework for security requirements elicitation and analysis, based upon the construction of a context for the system and satisfaction arguments for the security of the system. One starts with enumeration of security goals based on assets in the system. These goals ar ..."
Abstract
-
Cited by 54 (13 self)
- Add to MetaCart
(Show Context)
ABSTRACT This paper presents a framework for security requirements elicitation and analysis, based upon the construction of a context for the system and satisfaction arguments for the security of the system. One starts with enumeration of security goals based on assets in the system. These goals are used to derive security requirements in the form of constraints. The system context is described using a problem-centered notation, then this context is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument is in two parts: a formal argument that the system can meet its security requirements, and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context, or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems.
Requirements Engineering Meets Trust Management - Model, Methodology, and Reasoning
- In Proc. of iTrust’04, LNCS 2995
, 2004
"... The last years have seen a number of proposals to incorporate Security Engineering into mainstream Software Requirements Engineering. ..."
Abstract
-
Cited by 44 (15 self)
- Add to MetaCart
(Show Context)
The last years have seen a number of proposals to incorporate Security Engineering into mainstream Software Requirements Engineering.
Deriving Security Requirements from Crosscutting Threat Descriptions
- Proc. Third Int’l Conf. Aspect-Oriented Software Development
, 2004
"... 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 ..."
Abstract
-
Cited by 42 (15 self)
- Add to MetaCart
(Show Context)
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.
Social modeling and i*
- CONCEPTUAL MODELING: FOUNDATIONS AND APPLICATIONS: ESSAYS IN HONOR OF JOHN MYLOPOULOS
, 2009
"... Many different types of models are used in various scientific and engineering fields, reflecting the subject matter and the kinds of understanding that is sought in each field. Conceptual modeling techniques in software and information systems engineering have in the past focused mainly on describin ..."
Abstract
-
Cited by 31 (7 self)
- Add to MetaCart
Many different types of models are used in various scientific and engineering fields, reflecting the subject matter and the kinds of understanding that is sought in each field. Conceptual modeling techniques in software and information systems engineering have in the past focused mainly on describing and analyzing behaviours and structures that are implementable in software. As software systems become ever more complex and densely intertwined with the human social environment, we need models that reflect the social characteristics of complex systems. This chapter reviews the approach taken by the i* framework, highlights its application in several areas, and outlines some open research issues.
A Goal Oriented Approach for Modeling and Analyzing Security Trade-Offs, To be appeared
- in Proceeding of 26th International Conference on Conceptual Modeling (ER2007
, 2007
"... In designing software systems, security is typically only one design objective among many. It may compete with other objectives such as functionality, usability, and performance. Too often, security mechanisms such as firewalls, access control, or encryption are adopted without explicit recognition ..."
Abstract
-
Cited by 30 (9 self)
- Add to MetaCart
(Show Context)
In designing software systems, security is typically only one design objective among many. It may compete with other objectives such as functionality, usability, and performance. Too often, security mechanisms such as firewalls, access control, or encryption are adopted without explicit recognition of competing design objectives and their origins in stakeholder interests. Recently, there is increasing acknowledgement that security is ultimately about trade-offs. One can only aim for “good enough ” security, given the competing demands from many parties. Furthermore, one of the main challenges that software designers face is the lack of a common accessible body of security trade-offs knowledge. This work proposes a goal oriented conceptual modeling technique for explicit and systematic modeling and analyzing security trade-offs, taking advantage of i * framework as the basis of the modeling notation. The technique is accompanied by a proposal for a software security trade-off knowledge base which catalogues common vulnerabilities and attacks, alternative security solutions for each one, impact of mechanisms on other goals and threats. The proposal is illustrated by several examples and case studies. ii Acknowledgements I am in debt to my supervisor, Prof. Eric Yu, for introducing me to the research area of goal-oriented modeling, and for helping me to define and refine my ideas on topic of security trade-offs modeling and analyzing. I am grateful for knowledge and experience gained through the collaborations I had with him in the course of my Master’s thesis and a joint publication which was the result of this work. My special thanks go to John Mylopoulos for providing constructive feedbacks on preliminary ideas of this work during the “Conceptual Modeling ” course project. I am
Security and trust requirements engineering
- in Proc. of FOSAD, 2005
"... Abstract. 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 is that providing security does not only require to sol ..."
Abstract
-
Cited by 26 (10 self)
- Add to MetaCart
(Show Context)
Abstract. 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 is that providing security does not only require to solve technical problems but also to reason on the organization as a whole. This makes the usage of traditional software engineering methologies difficult or unsatisfactory: most proposals focus on protection aspects of security and explicitly deal with low level protection mechanisms and only an handful of them show the ability of capturing the high-level organizational security requirements, without getting suddenly bogged down into security protocols or cryptography algorithms. In this paper we critically review the state of the art in security requirements engineering and discuss the motivations that led us to propose the Secure Tropos methodology, a formal framework for modelling and analyzing security, that enhances the agent-oriented software development methodology i*/Tropos. We illustrate the Secure Tropos approach, a comprehensive case study, and discuss some later refinements of the Secure Tropos methodology to address some of its shortcomings. Finally, we introduce the ST-Tool, a CASE tool that supports our methodology. 1