Security Requirements for the Rest of Us: A Survey
---
paper_title: Engineering Security Requirements

paper_content:

Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job.
---
paper_title: When Security meets Software Engineering: A Case of Modelling Secure Information Systems. Information Systems

paper_content:

Although security is a crucial issue for information systems, traditionally, it is considered after the definition of the system. This approach often leads to problems, which most of the times translate into security vulnerabilities. From the viewpoint of the traditional security paradigm, it should be possible to eliminate such problems through better integration of security and software engineering. This paper firstly argues for the need to develop a methodology that considers security as an integral part of the whole system development process, and secondly it contributes to the current state of the art by proposing an approach that considers security concerns as an integral part of the entire system development process and by relating this approach with existing work. The different stages of the approach are described with the aid of a real-life case study; a health and social care information system.
---
paper_title: Security Requirements Engineering: A Framework for Representation and Analysis

paper_content:

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.
---
paper_title: The affordable application of formal methods to software engineering

paper_content:

The purpose of this research paper is to examine (1) why formal methods are required for software systems today; (2) the Praxis High Integrity Systems' Correctness-by-Construction methodology; and (3) an affordable application of a formal methods methodology to software engineering. The cultivated research for this paper included literature reviews of documents found across the Internet and in publications as well as reviews of conference proceedings including the 2004 High Confidence Software and Systems Conference and the 2004 Special Interest Group on Ada Conference. This research realized that (1) our reliance on software systems for national, business and personal critical processes outweighs the trust we have in our systems; (2) there is a growing demand for the ability to trust our software systems; (3) methodologies such as Praxis' Correctness-by-Construction are readily available and can provide this needed level of trust; (4) tools such as Praxis' SparkAda when appropriately applied can be an affordable approach to applying formal methods to a software system development process; (5) software users have a responsibility to demand correctness; and finally, (6) software engineers have the responsibility to provide this correctness. Further research is necessary to determine what other methodologies and tools are available to provide affordable approaches to applying formal methods to software engineering. In conclusion, formal methods provide an unprecedented ability to build trust in the correctness of a system or component. Through the development of methodologies such as Praxis' Correctness by Construction and tools such as SparkAda, it is becoming ever more cost advantageous to implement formal methods within the software engineering lifecycle. As the criticality of our IT systems continues to steadily increase, so must our trust that these systems will perform as expected. Software system clients, such as government, businesses and all other IT users, must demand that their IT systems be delivered with a proven level of correctness or trust commensurate to the criticality of the function they perform.
---
paper_title: Engineering Security Requirements

paper_content:

Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job.
---
paper_title: Security Requirements Engineering: A Framework for Representation and Analysis

paper_content:

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.
---
paper_title: Extending XP practices to support security requirements engineering

paper_content:

This paper proposes a way of extending eXtreme Programming (XP) practices, in particular the original planning game and the coding guidelines, to aid the developers and the customer to engineer security requirements while maintaining the iterative and rapid feedback-driven nature of XP. More specifically, these steps result in two new security-specific flavours of XP User stories: Abuser stories (threat scenarios) and Security-related User stories (security functionalities). The introduced extensions also aid in formulating security-specific coding and design standards to be used in the project, as well as in understanding the need for supporting specific Security-related User stories by the system. The proposed extensions have been tested in a student project.
---
paper_title: Software Security: Building Security In

paper_content:

Summary form only given. Software security has come a long way in the last few years, but we've really only just begun. I will present a detailed approach to getting past theory and putting software security into practice. The three pillars of software security are applied risk management, software security best practices (which I call touchpoints), and knowledge. By describing a manageably small set of touchpoints based around the software artifacts that you already produce, I avoid religious warfare over process and get on with the business of software security. That means you can adopt the touchpoints without radically changing the way you work. The touchpoints I will describe include: code review using static analysis tools; architectural risk analysis; penetration testing; security testing; abuse case development; and security requirements. Like the yin and the yang, software security requires a careful balance-attack and defense, exploiting and designing, breaking and building-bound into a coherent package. Create your own Security Development Lifecycle by enhancing your existing software development lifecycle with the touchpoints
---
paper_title: Demystifying the threat modeling process

paper_content:

In today's hostile online environment, software must be designed to withstand malicious attacks of all kinds. Unfortunately, even security-conscious products can fall prey when designers fail to understand the threats their software faces or the ways in which adversaries might try to attack it. To better understand a product's threat environment and defend against potential attacks, Microsoft uses threat modeling, which should be treated like any other part of the design and specification process. In fact, singling it out as a special activity performed outside the normal design process actually detracts from its importance to the overall development life cycle. We must consider security needs throughout the design process, just as we do with performance, usability, localizability, serviceability, or any other facet.
---
paper_title: Elaborating security requirements by construction of intentional anti-models

paper_content:

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 application-specific 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 anti-requirements 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.
---
paper_title: The Trustworthy Computing Security Development Lifecycle

paper_content:

This paper discusses the trustworthy computing security development lifecycle (or simply the SDL), a process that Microsoft has adopted for the development of software that needs to withstand malicious attack. The process encompasses the addition of a series of security-focused activities and deliverables to each of the phases of Microsoft's software development process. These activities and deliverables include the development of threat models during software design, the use of static analysis code-scanning tools during implementation, and the conduct of code reviews and security testing during a focused "security push". Before software subject to the SDL can be released, it must undergo a final security review by a team independent from its development group. When compared to software that has not been subject to the SDL, software that has undergone the SDL has experienced a significantly reduced rate of external discovery of security vulnerabilities. This paper describes the SDL and discusses experience with its implementation across a range of Microsoft software.
---
paper_title: Information modeling for automated risk analysis

paper_content:

Systematic security risk analysis requires an information model which integrates the system design, the security environment (the attackers, security goals etc) and proposed security requirements. Such a model must be scalable to accommodate large systems, and support the efficient discovery of threat paths and the production of risk-based metrics; the modeling approach must balance complexity, scalability and expressiveness. This paper describes such a model; novel features include combining formal information modeling with informal requirements traceability to support the specification of security requirements on incompletely specified services, and the typing of information flow to quantify path exploitability and model communications security.
---
paper_title: Using abuse case models for security requirements analysis

paper_content:

The relationships between the work products of a security engineering process can be hard to understand, even for persons with a strong technical background but little knowledge of security engineering. Market forces are driving software practitioners who are not security specialists to develop software that requires security features. When these practitioners develop software solutions without appropriate security-specific processes and models, they sometimes fail to produce effective solutions. We have adapted a proven object oriented modeling technique, use cases, to capture and analyze security requirements in a simple way. We call the adaptation an abuse case model. Its relationship to other security engineering work products is relatively simple, from a user perspective.
---
paper_title: Extending XP practices to support security requirements engineering

paper_content:

This paper proposes a way of extending eXtreme Programming (XP) practices, in particular the original planning game and the coding guidelines, to aid the developers and the customer to engineer security requirements while maintaining the iterative and rapid feedback-driven nature of XP. More specifically, these steps result in two new security-specific flavours of XP User stories: Abuser stories (threat scenarios) and Security-related User stories (security functionalities). The introduced extensions also aid in formulating security-specific coding and design standards to be used in the project, as well as in understanding the need for supporting specific Security-related User stories by the system. The proposed extensions have been tested in a student project.
---
paper_title: An extended misuse case notation: Including vulnerabilities and the insider threat

paper_content:

Access control is a key feature of healthcare information systems. Access control is about enforcing rules to ensure that only authorized users get access to resources in a system. In healthcare systems this means protecting patient privacy. However, the top priority is always to provide the best possible care for a patient. This depends on the clinicians having access to the information they need to make the best, most informed, care decisions. Care processes are often unpredictable and hard to map to strict access control rules. As a result, in emergency or otherwise unexpected situations, clinicians need to be able to bypass access control. In a crisis, availability of information takes precedence over privacy concerns. This duality of concerns is what makes access control in healthcare systems so challenging and interesting as a research subject. To create access control models for healthcare we need to understand how healthcare works. Before creating a model we need to understand the requirements the model should fulfill. Though many access control models have been proposed and argued to be suitable for healthcare, little work has been published on access control requirements for healthcare. This PhD project has focused on bridging the gap between formalized models and real world requirements for access control in healthcare by targeting the following research goals:RG1 To collect knowledge that forms a foundation for access control requirements in healthcare systems.RG2 To create improved access control models for healthcare systems based on real requirements.This PhD project has consisted of a number of smaller, distinct, but relatedprojects to reach the research goals. The main contributions can be summarized as:C1 Requirements for access control in healthcare: Studies performed onaudit data, in workshops, by observation and interviews have helped discoverrequirements. Results from this work include methods for access controlrequirements elicitation in addition to the actual requirements discovered.C2 Process-based access control: The main conclusion from the requirementswork is that access control should be tailored to care processes. Care processesare highly dynamic and often unpredictable, and access control needs to adaptto this. This thesis suggests how existing sources of process information, bothexplicit and implicit, may be used for this purpose.C3 Personally controlled health records (PCHR): This thesis explores theconsequences of making the patient the administrator of access control andproposes a model based on these initial requirements. From a performedusability study it is clear that the main challenge is how to keep the patientinformed about the consequences of sharing.
---
paper_title: Dealing with Security Requirements During the Development of Information Systems

paper_content:

A growing concern for information systems (ISs) is their quality, such as security, accuracy, user-friendliness and performance. Although the quality of an IS is determined largely by the development process, relatively little attention has been paid to the methodology for achieving high quality. A recent proposal [32] takes a process-oriented approach to representing non-functional, or quality, requirements (NFRs) as potentially conflicting or harmonious goals and using them during the development of software systems. By treating security requirements as a class of NFRs, this paper applies this process-oriented approach to designing secure ISs. This involves identification and representation of various types of security requirements (as goals), generic design knowledge and goal interactions. This treatment allows reusing generic design knowledge, detecting goal interactions, capturing and reasoning about design rationale, and assessing the degree of goal achievement. Security requirements serve as a class of criteria for selecting among design decisions, and justify the overall design. This paper also describes a prototype design tool, and illustrates it using a credit card system example.
---
paper_title: Eliciting security requirements with misuse cases

paper_content:

Use case diagrams (L. Jacobson et al., 1992) have proven quite helpful in requirements engineering, both for eliciting requirements and getting a better overview of requirements already stated. However, not all kinds of requirements are equally well supported by use case diagrams. They are good for functional requirements, but poorer at e.g., security requirements, which often concentrate on what should not happen in the system. With the advent of e- and m-commerce applications, security requirements are growing in importance, also for quite simple applications where a short lead time is important. Thus, it would be interesting to look into the possibility for applying use cases on this arena. The paper suggests how this can be done, extending the diagrams with misuse cases. This new construct makes it possible to represent actions that the system should prevent, together with those actions which it should support.
---
paper_title: Security Use Cases

paper_content:

Although use cases are a popular modeling approach for engineering functional requirements, they are often misused when it comes to engineering security requirements because requirements engineers unnecessarily specify security architectural mechanisms instead of security requirements. After discussing the relationships between misuse cases, security use cases, and security mechanisms, this column provides examples and guidelines for properly specifying essential (i.e., requirements-level) security use cases.
---
paper_title: Dealing with non-functional requirements: three experimental studies of a process-oriented approach

paper_content:

Quality characteristics are vital for the success of software systems. To remedy the problems inherent in ad hoc development, a framework has been developed to deal with non-functional requirements (quality requirements or NFRs). Taking the premise that the quality of a product depends on the quality of the process that leads from high-Ievel NFRs to the product, the framework's objectives are to represent NFR-specific requirements, consider design tradeoffs, relate design decisions to IYFRs, justify the decisions, and assist defect detection. The purpose of this paper is to give an initial evaluation of the extent to which the framework's objectives are met. Three small portions of information systems were studied by the authors using the framework. The framework and empirical studies are evaluated herein, both from the viewpoint of domain experts who have reviewed the framework and studies, and ourselves as framework developers and users. The systems studied have a variety of characteristics, reflecting a variety of real application domains, and the studies deal with three important classes of NFRs for systems, namely, accuracy, security, and performance. The studies provide preliminary support for the usefulness of certain aspects of the framework, while raising some open issues.
---
paper_title: Towards agile security in web applications

paper_content:

In this paper, we present an approach that we have used to address security when running projects according to agile principles. Misuse stories have been added to user stories to capture malicious use of the application. Furthermore, misuse stories have been implemented as automated tests (unit tests, acceptance tests) in order to perform security regression testing. Penetration testing, system hardening and securing deployment have been started in early iterations of the project.
---
paper_title: Security Requirements Engineering: A Framework for Representation and Analysis

paper_content:

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.
---
paper_title: Security Requirements Engineering: A Framework for Representation and Analysis

paper_content:

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.
---
paper_title: Demystifying the threat modeling process

paper_content:

In today's hostile online environment, software must be designed to withstand malicious attacks of all kinds. Unfortunately, even security-conscious products can fall prey when designers fail to understand the threats their software faces or the ways in which adversaries might try to attack it. To better understand a product's threat environment and defend against potential attacks, Microsoft uses threat modeling, which should be treated like any other part of the design and specification process. In fact, singling it out as a special activity performed outside the normal design process actually detracts from its importance to the overall development life cycle. We must consider security needs throughout the design process, just as we do with performance, usability, localizability, serviceability, or any other facet.
---
paper_title: Engineering Security Requirements

paper_content:

Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job.
---
paper_title: Security Requirements Engineering: A Framework for Representation and Analysis

paper_content:

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.
---

Title: Security Requirements for the Rest of Us: A Survey
Section 1: Introduction
Description 1: Introduce the importance of security requirements in software development and provide a brief overview of the survey's purpose.

Section 2: Security Requirements in the Literature
Description 2: Summarize the findings and claims from existing literature regarding security requirements and their elicitation.

Section 3: How to Proceed
Description 3: Discuss methods and steps proposed by various authors and approaches for eliciting security requirements, focusing on practical techniques for developers.

Section 4: Security Requirements Artifacts
Description 4: Describe the different artifacts produced during the process of eliciting security requirements, such as misuse cases, attack trees, and softgoal interdependency graphs.

Section 5: Comparisons
Description 5: Compare different approaches to security requirements elicitation and discuss the reasons for the differences in these approaches.

Section 6: Proposed Approach
Description 6: Outline a new, lightweight method for eliciting security requirements that is suitable for average software developers.

Section 7: Security Objectives
Description 7: Discuss the identification of high-level security objectives and the steps developers need to take to understand and identify these objectives.

Section 8: Asset Identification
Description 8: Explain how to identify and prioritize assets that need protection in the system.

Section 9: Threat Analysis
Description 9: Recommend methods for analyzing threats to the identified assets, using categories like Stride and techniques like attack trees.

Section 10: Documentation of Security Requirements
Description 10: Provide guidance on how to document security requirements effectively, ensuring visibility and traceability.

Section 11: Does Lightweight Equal Worthless?
Description 11: Address the potential limitations of a lightweight approach and advocate for its practicality in improving security in software development projects.

Section 12: About the Authors
Description 12: Provide brief biographies of the authors, highlighting their research interests and contact information.