SRRS

As software systems and networks continue to evolve, so do threats to their security. Unfortunately, most security issues come to light only after completion of the system because security is often managed in an ad hoc fashion late in the software lifecycle. There are many advantages to incorporating security specification into the requirements phase and a number of approaches have been proposed. In this paper, we present a comparative evaluation of three such approaches: The Common Criteria, Misuse Cases, and Attack Trees. We applied each of these approaches to a common problem, a wireless hotspot, and evaluated them for learnability, usability, solution inclusiveness, clarity of output, and analyzability. We found that each approach has strengths and weaknesses, and that they can be complimentary when combined. The Common Criteria are difficult to learn and use, but are easy to analyze. Misuse Cases are easy to learn and use, but produces output that is hard to read. In contrast, ...

2008

Security has become a primary and prevalent concern for software systems. The past decade has witnessed a tremendous increase in not only the sheer number of attacks but also the ease with which attacks can be performed on systems. We believe that in order to protect a system against harm (intended or not), attention must be given to its requirements. Similar to other system properties and quality attributes, security must be considered from inception, in other words starting with requirements. Security is a nonfunctional requirement (NFR) that is increasingly critical in its importance, unique in its requirements, yet must still be integrated with all other functional and non-functional requirements and mapped into successful architectures, designs, and implementation. Similar to other nonfunctional requirements, the unique nature and demands of security make it difficult and often ineffective to specify security concerns using "general purpose " requirements methods. As ...

Safety-critical embedded systems have assisted people in the execution of daily tasks, causing a search for security approaches in the initial phases of the development. The elicitation of security requirements in such systems is a key element for the definition of secure software. Nonetheless, security requirements are mostly ambiguous, incomplete or even not considered, which may be the reason of accidents. In this sense, it is essential to provide a good comprehension of peoples' roles within the development process, and the interactions with the safety-critical embedded systems. This paper presents the Persona Security technique which aims at aiding software engineers in the elicitation of security requirements. We have performed a pilot study to verify the perception and relationship between the easiness of eliciting security requirements, and find out improvement points. The initial results indicate that dividing the requirements into both system and users allows the software engineer to have a clearer and more general view of the system. However, we also identified improvement opportunities such as: (a) the need for identifying requirements related to users and generating their traceability with the software requirements; and (b) the need for the identification of the security requirements that are most relevant for the problem domain, showing their dependencies and their selection impact.

Computer Standards & Interfaces, 2007

In order to develop security critical Information Systems, specifying security quality requirements is vitally important, although it is a very difficult task. Fortunately, there are several security standards, like the Common Criteria (ISO/IEC 15408), which help us handle security requirements. This article will present a Common Criteria centred and reuse-based process that deals with security requirements at the early stages of software development in a systematic and intuitive way, by providing a security resources repository as well as integrating the Common Criteria into the software lifecycle, so that it unifies the concepts of requirements engineering and security engineering.

isara solutions, 2019

There are myriads of security elicitation techniques available in the literature but their industrial implementation is inadequate. It is an important aspect of requirement engineering which assists system analyst toin making sure that the security requirements are unambiguous, complete and consistent. Security is an instinctive property of the program that is missing today in most applications. Organizations need to improve their existing application development lifecycle to incorporate software security measures. Security requirement elicitation techniques can help in the completion of project within the given schedule, cost, budget and according to the desired security functionality. Further, this paper explores the various security requirement elicitation needs, challenges and techniques that may be helpful for security practitioners.

2011 IEEE 35th Annual Computer Software and Applications Conference, 2011

Various governmental or academic institutes survey current security trends, and report vulnerabilities, security breaches, and their costs. However, it is unclear whether (and how) practitioners analyze these vulnerabilities and attacks to arrive at security requirements and decide on security solutions. What modeling methods are used for eliciting, analyzing, and documenting security requirements in real-world practice? This paper intends to answer such questions through a survey of security requirements engineering practices. 374 software professionals from 237 International and Chinese rms participated in the survey. The results show businesses often try to consider security from early stages of the development life cycle; however, ultimately, security is left to be built into the system at the implementation phase. We observed that practitioners favour qualitative risk assessment rather than quantitative approaches, and this helps them consider more varieties of factors when comparing alternative security design solutions.

… Foundation for Software …, 2011

Context & motivation: More and more software projects today are security-related in one way or the other. Many environments are initially not considered security-related and no security experts are assigned. Requirements engineers often fail to recognise indicators for security problems. Question/problem: Ignoring security issues early in a project is a major source of recurring security problems in practice. Identifying security-relevant requirements is labour-intensive and error-prone. Security may be neglected in order to finish on time and in budget. Principal ideas/results: In this paper, we address this problem by presenting a tool-supported method that provides assistance for requirements engineering, with an emphasis on security requirements. We investigate whether security-relevant requirements can be automatically identified with help of a Bayesian classifier. Our results indicate that this is feasible, in particular if the classifier is trained with domain specific data and documents from previous projects. Contribution: We show how the ability to identify security-relevant requirements can be integrated in a workflow of requirements analysis and reuse of experience. In practice, this can increase security awareness within the software development process. We discuss limitations and potential of this approach.

IEEE Access, 2021

Forming high quality requirements has a direct impact on project success. Gathering security requirements could be challenging, since it demands a multidisciplinary approach and security expertise. Security requirements repository enables an effective alternative for addressing this challenge. The main objective of this paper is to present the design of a practical repository model for reusable security requirements, which is easy to use and understand for even non-security experts. The paper also portrays an approach and a software tool for using this model to determine subtle security requirements for improved coverage. Proposed repository consists of attributes determined by examining common security problems covered in state-of-the-art publications. A test repository was prepared using specification files and Common Criteria documents. The outcomes of applying the proposed model were compared with the sample requirement sets included in the state-of-the-art publications. The results reveal that in the absence of a security requirements repository, key security points can be missed. Repository improves the completeness of the security terms with reasonable effort.

The requirements are the foundation stones upon which the entire software depends. The quality of software entirely depends upon the software requirements attributes. The software attributes like reliability, availability, dependability etc. are well considered in the beginning phases of the software life cycle. Problems in building and refining a system can be mostly traced back to errors in requirements. The requirement elicitation, specification, and validation are the important criterion to assure the quality of the software. The requirement engineering discipline is getting more and more popular in the last few years due to its dependability of the software quality. There is no 'golden metrics' available for the assessing the relative security of the system. But we have found in practice that the use of a standard set of security analysis guideline is very useful. This paper we present a survey report of the research work done on the requirement engineering discipline..

International Journal of Software Engineering and Computer Systems

The security requirements are one of the non-functional requirements (NFR) which acts as a constraint on the functions of the system to be built. Security requirements are important and may affect the entire quality of the system. Unfortunately, many organizations do not pay much attention to it. The security problems should be focused on the early phases of the development process i.e. in the requirements phase to stop the problems spreading down in the later phases and in turn to avoid the rework. Subsequently, when security requirements are to be focused, proper guidance should be provided which should assist requirements engineers. Many security requirements engineering methods were developed in the past which require different level of expertise such as SQUARE process which requires requirements engineer to have a certain level of security expertise. Moreover, it lacks proper guidance especially for novice developers in applying the existing security requirements engineering (S...

Requirements Engineering, 2010

Proceedings of the IEEE SoutheastCon 2006

The Common Criteria is often too confusing and technical for non-security specialists to understand and therefore properly use. At the same time, it is essential that security critical IT products under development be validated according to such standards not after but rather during the software engineering process. To help address these issues, this paper presents an approach to eliciting security requirements for IT systems with use cases using Common Criteria methodologies. The approach involves using actor profiles to derive threats, mapping derived threats to security objectives, and mapping objectives to security requirements using a CC Toolbox data set. Our aim is to ensure that security issues are considered early during requirements engineering while making the Common Criteria more readily available to end-users in an understandable context. Violet, an open source UML diagram modeling tool, has been extended to implement the approach from a use case textual description perspective.

2006

Nowadays, security solutions are focused mainly on providing security defences, instead of solving one of the main reasons for security problems that refers to an appropriate Information Systems (IS) design. In this paper a comparative analysis of eight different relevant technical proposals, which place great importance on the establishing of security requirements in the development of IS, is carried out. And they provide some significant contributions in aspects related to security. These can serve as a basis for new methodologies or as extensions to existing ones. Nevertheless, they only satisfy partly the necessary criteria for the establishment of security requirements, with guarantees and integration in the development of IS. Thus we conclude that they are not specific enough for dealing with security requirements in the first stages of software development in a systematic and intuitive way, though parts of the proposals, if taken as complementary measures, can be used in that manner.

This paper presents a conceptual framework for security engineering, with a strong focus on security requirements elicitation and analysis. This conceptual framework establishes a clear-cut vocabulary and makes explicit the interrelations between the different concepts and notions used in security engineering. Further, we apply our conceptual framework to compare and evaluate current security requirements engineering approaches, such as the Common Criteria, Secure Tropos, SREP, MSRA, as well as methods based on UML and problem frames. We review these methods and assess them according to different criteria, such as the general approach and scope of the method, its validation, and quality assurance capabilities. Finally, we discuss how these methods are related to the conceptual framework and to one another.

International Journal of Advanced Computer Science and Applications, 2011

Security breaches are largely caused by the vulnerable software. Since individuals and organizations mostly depend on softwares, it is important to produce in secured manner. The first step towards producing secured software is through gathering security requirements. This paper describes Software Security Requirements Gathering Instrument (SSRGI) that helps gather security requirements from the various stakeholders. This will guide the developers to gather security requirements along with the functional requirements and further incorporate security during other phases of software development. We subsequently present case studies that describe the integration of the SSRGI instrument with Software Requirements Specification (SRS) document as specified in standard IEEE 830-1998. Proposed SSRGI will support the software developers in gathering security requirements in detail during requirements gathering phase.