Analyzing and Specifying Reusable Security Requirements (original) (raw)
Related papers
Specifying Reusable Security Requirements
2004
Abstract Unlike typical functional requirements, security requirements can potentially be highly reusable, especially if specified as instances of reusable templates. In this column, I will discuss the concepts underlying security engineering including its quality subfactors. I will then address the issue of security requirements and how they differ from the architectural mechanisms that will fulfill them.
Towards a Catalogue of Reusable Security Requirements, Vulnerabilities and Threats
2018
Organizations are giving more importance to secure their systems due to the increasing number of cyber-attacks and inherent complexity. The aim of our work is help organizations plan and consider these security concerns from the very beginning, since the requirements and design phases, and not just later in the implementation or deployment phases. Consider security-bydesign and security-by-default principles are good approaches to avoid rework costs or to mitigate security flaws. However, there is not yet a suitable approach to specify security requirements in a rigorous and systematic way. In this paper we propose an approach that allows the definition and specification of security-specific concerns like security requirements but also vulnerabilities, risks or threats. We discuss this approach based on two key parts: First, we introduce the RSLingo RSL language, that is a rigorous requirements specification language, and discuss how it is extended to support such security-specific concepts. Second, we claim the relevance for a catalogue of reusable security-specific specifications and then we show concrete examples of defining and using such specifications. The proposed catalogue can be easily used and extended by the community and involves currently 52 goals, 12 vulnerabilities and 31 risks; these concerns are defined into 9 packages each one representing a distinct asset.
A reuse-based approach to determining security requirements
2003
Abstract The paper proposes a reuse-based approach to determining security requirements. Development for reuse involves identifying security threats and associated security requirements during application development and abstracting them into a repository of generic threats and requirements.
Reusable Security Requirements Repository Implementation Based on Application/System Components
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.
1 Security Requirements Engineering: A Survey
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 ...
A Framework for Security Requirements Engineering
Proceedings of the 2006 …, 2006
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 Reuse for Improving Information Systems Security: A Practitioner’s Approach
Requirements Engineering, 2002
Information systems security issues have usually been considered only after the system has been developed completely, and rarely during its design, coding, testing or deployment. However, the advisability of considering security from the very beginning of the system development has recently begun to be appreciated, and in particular in the system requirements specification phase.
An Approach to Security Requirements Engineering for a High Assurance System *
Requirements Engineering, 2002
Requirements specifications for high assurance secure systems are rare in the open literature. This paper examines the development of a requirements document for a multilevel secure system that must meet stringent assurance and evaluation requirements. The system is designed to be secure, yet combines popular commercial components with specialized high assurance ones. Functional and non-functional requirements pertinent to security are discussed. A multi-dimensional threat model is presented. The threat model accounts for the developmental and operational phases of system evolution and for each phase accounts for both physical and non-physical threats. We describe our team-based method for developing a requirements document and relate that process to techniques in requirements engineering. The system requirements document presented provides a calibration point for future security requirements engineering techniques intended to meet both functional and assurance goals.
Computer Standards & Interfaces, 2019
One of the responsibilities of developers is the early definition of non-functional requirements (NFR) at the system level and their related allocation as functional user requirements (FUR) at the software level. To identify some of the widely consensual security elements that could be used in a standards-based security framework, the security-related terminology and views from three sets of international standards (ECSS, IEEE and ISO) are analyzed and integrated. Next, the set of concepts adopted by ISO 19761 for describing software functionality at a lower level are introduced, thereby ensuring that the proposed framework is designed for measurement purposes as well. For the capture of security concepts, the proposed framework is designed using soft-goal interdependency graphs (SIG) and three main system NFR-security types: system availability, confidentiality and integrity. This standards-based system security framework at the function and service level can support software developers to derive such requirements in the early stages of the development process. Finally, an ATM example for the measurement of system security NFR allocated as software FUR within a service-oriented architecture (SOA) is presented.