The History Of The Security Requirements

Published Date: 02 Nov 2017

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 software or 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 engineering. Security is a nonfunctional requirement (NFR) that is increasingly critical in its importance (Romero & Mariona, 2010), 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 (Romero & Mariona, 2010), therefore security requirements engineering is needed. Below we explain each of these two concepts, (i.e. software security, and security requirements engineering).

What software security is?

• According to Gary McGraw (McGraw, 2003), "Software security is about understanding software induced security risks and how to manage them."

• Stoneburner et al. (Stoneburner et al, 2001), consider security to be a system property. According to them, "security is much more than a set of functions and mechanisms; IT security is a system characteristic as well as a set of mechanisms that span the system both logically and physically."

Security is uniquely complex and challenging among non-functional requirements (NFRs); as Ian Alexander indicates, "security is unlike all other areas in a specification, as someone is consciously and deliberately trying to break the system" ( Alexander, 2002). Security is a NFR that is increasingly critical in its importance, unique in its requirements, yet still must be integrated with all other functional and non-functional requirements and mapped into successful architectures, designs, and implementation (Romero & Mariona, 2007, 2010).

Software security has as its primary goals three aspects (CIA), the preservation of the Confidentiality, Integrity, and Availability of the information assets and resources that the software creates, stores, processes, or transmits including the executing programs themselves. In this sense, confidentiality preservation refers to the prevention of unauthorized disclosure; integrity preservation is about preventing unauthorized alteration; and availability preservation is about preventing unauthorized destruction or denial of access or service (Redwine, S. et al.2004) and (Romero & Mariona, 2010).

Most of the time, security is not addressed from the very beginning of a software development, and it is only incorporated after the software has been developed, This eventually leads to vulnerabilities in the software product (Futcher, 2011), (Hans, 2010) and (M. Khan, 2008). Software often is developed with minimal concern for security according to (Viega & Mcgraw, 2001). Addressing security in software development is extremely important; particularly because of the effects software security has on society (Romero & Mariona, 2010). Today, software security problems are frequent, widespread, and serious. According to Redwine et al. "the number and variety of attacks by persons and malicious software from outside organizations, particularly via the Internet, are increasing rapidly, and the amount and consequences of insider attacks remains serious" (Redwine, S. et al.2004).

Software security is something that must be taken seriously, but according to McDermott (McGraw, 2003) software security is intrinsically a difficult task. This difficulty arises due to three main reasons:

• Networks are everywhere: Due to the growing connectivity of computers through the Internet, both the number of attack vectors, and the ease with which an attack can be made have also increased. This growth in networked systems just means that there are more software systems to attack and as a consequence greater risks from poor software security practice than in the past.

• Software is Easily Extensible: An extensible host accepts updates or extensions, referred to sometimes as mobile code, so that the system’s functionality can be evolved. Unfortunately, the very nature of extensible systems becomes a two-edged sword, as it makes it hard to prevent software vulnerabilities from slipping in as an unwanted extension.

• System complexity is rising: This increase in complexity, like in many other software fields, makes it difficult to plan for security, as it is an environment that is constantly changing.

Security Requirements Engineering

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

1

1

5

6

9

13

14

28

11

6

Table : Distribution of SRE papers to years according to (Santen & Schmidt, 2010)

Traditionally, one of the most ignored aspects of a software development life cycle is the security requirements engineering (SRE) process. One of the main reasons for this oversight is that traditional requirements engineering processes do not satisfy security requirements (Whitman & Mattord, 2003). There are at least two reasons that RE does not support, or weakly supports, security requirements; first, security requirements are usually not meant for simple analysis and modeling. Second, the lack of expertise from developers to produce secure software (Romero & Mariona, 2010).

When it comes to security, the requirements engineering notion behind it is fairly recent; as codesecurely.org suggests, "one of the most ignored parts of a security enhanced software development life cycle is the security requirements engineering process" (Codesecurely, 2006). It is only recently, that the idea of considering security early in the development of a software has become popular, as traditional requirements engineering is not enough (Firesmith, 2007) and we believe that requirements engineering can provide great support for ensuring that security is built into a system as opposed to "bootstrapped" to it later on (Lewis, 2002).

One of the most ignored aspects of a software development life cycle is the security requirements process (Araujo, 2007). We believe that security at the requirements stage should be an essential notion for understanding not only how to secure a software, but what needs to be done in order to ensure that the customer is satisfied with the end-result (Richardson, 2010). Most of the literature investigated pointed out to a variety of activities involved in requirements engineering; these activities ranged from elicitation to verification and maintenance of software requirements and we believe that these same activities can be used to look at security requirements engineering specifically.

Methods/approaches and best practices in security requirements engineering

As usable approaches to security requirements engineering continue to be developed and mechanisms are identified to promote organizational use, project managers can do a better job of ensuring that the resulting product effectively meets security requirements. The choice of these methods is based not only on their popularities, but also on their efficiency in eliciting security requirements, include:

Security quality requirements engineering methodology (SQUARE)

- Description: SQUARE (Mead et al., 2005) is a comprehensive methodology for security requirements engineering. Its aim is to integrate security requirements engineering into software development processes (Mead et al., 2008). SQUARE stresses applicability in real software development projects and thus provides an organizational framework for carrying out security requirements engineering activities. It is assumed that SQUARE is carried out jointly by requirements engineers and stakeholders.

SQUARE Overview

After its initial development, SQUARE was applied in a series of client case studies. Carnegie Mellon graduate students worked on this project during the summer and fall of 2004 and the summer of 2005. The case study results were published (Chen et al., 2004), (Gordon et al., 2005) and (Xie et al., 2004). Prototype tools were also developed to support the process. It consists of 9 steps (buildsecurityin.us-cert.gov, 2012)

1. Agree on definitions: This step serves to enable a clear communication between requirements engineers and stakeholders.

2. Identify security goals: Initially, the stakeholders will state different security goals. In this step, the goals are aligned, and conflicts are resolved.

3. Develop artifacts: The authors name the following artifacts that should be collected: system architecture diagram, use case scenarios/diagrams, misuse case scenarios/diagrams, attack trees, and standardized templates and forms. These artifacts form the basis for the subsequent steps of the method.

4. Perform risk assessment: In this step, the vulnerabilities and threats related to the system are identified, as well as the likelihood that the threats will lead to attacks. The authors propose to apply existing risk assessment methods.

5. Select elicitation technique: The method selected in this step will be applied in the next step to perform the actual security requirements elicitation. Again, SQUARE recommends to apply an existing technique to be chosen for the project at hand.

6. Elicit security requirements: A crucial point in this step is to ensure that the requirements are verifiable and that they are not implementations or architectural constraints instead of requirements.

7. Categorize requirements: The elicited requirements are categorized (at least) according to the following criteria: essential, non-essential, system-level, software- level architectural constraint. Since the latter are not considered as requirements, their existence indicates that the previous steps should be executed again.

8. Prioritize requirements: It is assumed that not all requirements can be implemented; hence, the most important requirements must be identified.

9. Requirements inspection: In this last step, the requirements are checked for ambiguities, inconsistencies, mistaken assumptions, and the like. Its result is the final security requirements documents for the stakeholders.

The draft process was revised and base lined after the case studies were completed; the base lined process is shown in Table 7. In principle, Steps 1-4 are actually activities that precede security requirements engineering but are necessary to ensure that it is successful. Brief descriptions of each step follow (Mead et al., 2005).

Number

Step

Input

Techniques

Participants

Output

1

Agree on definitions

Candidate definitions from IEEE and other standards

Structured interviews, focus group

Stakeholders, requirements engineer

Agreed-to definitions

2

Identify assets and security goals

Definitions, candidate goals, business drivers, policies and procedures, examples

Facilitated work session, surveys, interviews

Stakeholders, requirements engineer

Assets and goals

3

Develop artifacts to support security requirements definition

Potential artifacts (e.g., scenarios, misuse cases, templates, forms)

Work session

Requirements engineer

Needed artifacts: scenarios, misuse cases, models, templates, forms

4

Perform risk assessment

Misuse cases, scenarios, security goals

Risk assessment method, analysis of anticipated risk against organizational risk tolerance, including threat analysis

Requirements engineer, risk expert, stakeholders

Risk assessment results

5

Select elicitation techniques

Goals, definitions, candidate techniques, expertise of stakeholders, organizational style, culture, level of security needed, cost/benefit analysis, etc.

Work session

Requirements engineer

Selected elicitation techniques

6

Elicit security requirements

Artifacts, risk assessment results, selected techniques

Joint Application Development (JAD), interviews, surveys, model-based analysis, checklists, lists of reusable requirements types, document reviews

Stakeholders facilitated by requirements engineer

Initial cut at security requirements

7

Categorize requirements as to level (system, software, etc.) and whether they are requirements or other kinds of constraints

Initial requirements, architecture

Work session using a standard set of categories

Requirements engineer, other specialists as needed

Categorized requirements

8

Prioritize requirements

Categorized requirements and risk assessment results

Prioritization methods such as Analytical Hierarchy Process (AHP), Triage, Win-Win

Stakeholders facilitated by requirements engineer

Prioritized requirements

9

Inspect requirements

Prioritized requirements, candidate formal inspection technique

Inspection method such as Fagan, peer reviews

Inspection team

Initial selected requirements, documentation of decision-making process and rationale

Table : SQUARE Process

- Scope: SQUARE is a comprehensive security requirements engineering methodology that recommends to make use of other techniques developed in the field, and that covers all CIA goals.

- Validation and quality assurance (QA): Each step of SQUARE closes with some exit criteria, which have to be fulfilled before the next step is begun. Moreover, the last step is exclusively dedicated to validating the requirements. However, no formal validation is performed.

Multilateral security requirements analysis (MSRA)

- Description: The objective of the Multilateral Security Requirements Analysis (MSRA) method (Gu¨rses and Santen, 2006) and (Gu¨rses et al., 2006) is to apply the principles of multilateral security (Rannenberg et al., 1999) during the requirements engineering phase of systems development. This is done by analyzing security and privacy needs of all the stakeholders of a system-to-be, identifying conflicts, and consolidating the different stakeholder views. The method borrows both from theories on multilateral security and viewpoint-oriented requirements engineering. In order to articulate the different security needs of the stakeholders, MSRA users elaborate security requirements from the perspectives of the different stakeholders with respect to bundled functionalities of a system.

Security requirements result from the reconciliation of multilateral security goals. Security goals are selected from a rich taxonomy derived from the CIA triad, which also includes properties such as accountability and pseudonymity etc. Security goals, and later requirements, contain the attributes stakeholders who have an interest in the requirement, counter-stakeholders towards whom a requirement is stated, and a number of other attributes that are defined in the following paragraphs.

A stakeholder is defined as any person or organization that has an interest in the system-to-be. Therewith, the elaboration of the security requirements is not limited to the functional users of the system-to-be, the latter being referred to as actors. Rather, a distinction is made that allows the elaboration of both, those who have a stake in the system security, and those who will be using the system.

The variant Confidentiality Requirements Elicitation and Engineering (CREE) of MSRA (Gu¨rses et al., 2005) considers only confidentiality requirements. Later work has focused on the formalization of the confidentiality requirements in CREE and the use of defeasible logic to analyze ambiguities and conflicts (Onabajo and Weber, 2008). Counter-stakeholders refer to those stakeholders whom the security goals are directed at. These may or may not be malicious attackers or actors of the system. Further, MSRA works with an information model, the elements of which are the objects of the different security requirements. The information model is of a higher level of abstraction than a data model, as would be necessary for a functional specification of the system-to-be.

Additional attributes of a security requirement are: the owner of the security requirement; the degree of agreement among stakeholders towards the security requirement; the goal of the requirement (in CREE this is only confidentiality or consent); the information the requirement addresses; the strictness, stating if the security requirement makes a statement about the security of information that it is not explicitly addressing; and the rationale, articulating why the information needs to be secured. Further, temporal validity, defining how long the security concern must be preserved, is seen as an attribute.

An episode comprises system functionality that relates to similar security interests of a single or a group of stakeholders. They are useful for identifying conflicts between the security goals. Several kinds of conflicts between security goals can exist: for a single stakeholder, between the different requirements she has towards multiple episodes; between the different stakeholders of an episode; and between the requirements of episodes regardless of stakeholders. Once the conflicts and inconsistencies are addressed, the security goals are said to be refined into security requirements. Further, additional conflicts may exist between security requirements, functional requirements, and other non-functional requirements. The method proposes analyzing conflicts carefully and solving them either during requirements analysis, through design, or using negotiation mechanisms at runtime.

The following are the main steps of the multilateral security requirements analysis method, once an initial functional requirements analysis for the main functionalities of the system is concluded:

1. Identify stakeholders: Stakeholders are all parties that have functional, security, privacy, or information interests in the system-to-be.

2. Identify episodes: Episodes are similar to scenarios, but are of a lower granularity, identifying sets of functionalities as would be meaningful to users. Episodes are used to partition the security goals and are later useful in identifying conflicts between multiple security goals.

3. Elaborate security goals: Identify and describe the security goals of the different security stakeholders for each of the episodes.

4. Identify facts and assumptions: These are the properties of the environment that are relevant for stating security goals.

5. Refine stakeholder views on episodes: Elaborate the stakeholder views taking facts, assumptions, and the relationships between episodes into account.

6. Reconcile security goals: Identify conflicts between security goals, find compromises between conflicting goals, and establish a consistent set of security system requirements.

7. Reconcile security and functional requirements: Trade functionality for security and vice versa in case of conflicting functional and security requirements.

- Scope: MSRA is integrated into the requirements analysis phase and can be applied as soon as the initial functional requirements of the system are identified. All CIA goals are considered, although the emphasis on privacy has put the focus on confidentiality and integrity goals. MSRA puts an emphasis on multilateral security, focusing on stakeholder views, the circumstances of security requirements, and reconciliation of conflicting requirements. MSRA uses UML models to capture episodes, the information model, as well as the functional and security requirements.

- Validation and quality assurance (QA): MSRA does not provide explicit validation methods. It does not guarantee completeness of security requirements, although multilateral security is an attempt to define security and privacy requirements in a system for all stakeholders, with the intention of discovering requirements that from a monolithic technical perspective could else have been missed. Through the multilateral view to security, conflicts are a central concern of the method. The method explicitly addresses interactions among security requirements, as well as between security and functional requirements. Later formalization work with defeasible logic proposes automated analysis of the requirements for conflicts and ambiguities. Non-functional requirements other than security are not considered. The method is iterative, in the sense that after the reconciliation of security goals into security requirements, interactions are expected to affect the functional requirements of the system, requiring a review of the security requirements.

Comprehensive, Lightweight Application Security Process (CLASP)

- Description: Comprehensive, Lightweight Application Security Process (CLASP): it is a specific approach for security requirements. CLASP is a life cycle process that suggests a number of different activities across the development life cycle in order to improve security. CLASP is an activity driven, role based set of process components guided by formalized best practices وضع المرجع(John Viega, Secure Software, Inc., 2005). CLASP is designed to help software development teams build security into the early stages of existing and new start software development life cycles in a structured, repeatable, and measurable way (buildsecurityin.us-cert.gov, 2012).

The CLASP Process is presented through five high-level perspectives called CLASP Views. These views allow CLASP users to quickly understand the CLASP Process, including how CLASP process components interact and how to apply them to a specific software development life cycle.

Concepts View: This view provides a high-level introduction to CLASP by briefly describing, for example, the interaction of the five CLASP Views, the seven CLASP Best Practices, the CLASP Taxonomy, the relation of CLASP to security policies, and a sample sequence for applying CLASP process components.

Role-Based View: This view contains role-based introductions to the CLASP Process.

Activity-Assessment View: This view helps project managers assess the appropriateness of the 24 CLASP Activities and select a subset of them. CLASP provides two sample road maps (i.e., legacy and new-start) to help select applicable activities.

Activity-Implementation View: This view contains the 24 security-related CLASP Activities that can be integrated into a software development process. The activities phase of the SDLC translates into executable software any subset of the 24 security-related activities assessed and accepted in Activity Assessment.

Vulnerability View: This view contains a catalog of the 104 underlying "problem types" identified by CLASP that form the basis of security vulnerabilities in application source code. CLASP divides the 104 problem types into 5 high-level categories. An individual problem type in itself is often not a security vulnerability; frequently, it is a combination of problems that create a security condition leading to a vulnerability in source code. Associated with the Vulnerability View are the CLASP Vulnerability Use Cases, which depict conditions under which security services are vulnerable to attack at the application layer. The use cases provide CLASP users with easy-to-understand, specific examples of the relationship between security-unaware source coding and possible resulting vulnerabilities in basic security services.

Graphic showing CLASP views and their interactions.

Figure : CLASP views and their interactions taken from (buildsecurityin.us-cert.gov, 2012).

CLASP Best Practices

Within a software development project, the CLASP Best Practices are the basis of all security related software development activities whether planning, designing or implementing including the use of all tools and techniques that support CLASP. These are the seven CLASP Best Practices:

Institute awareness programs

Essential security concepts and techniques may be foreign to an organization’s software developers and others involved in application development and deployment. Thus, it is imperative at the outset to educate everyone involved. It is critical that project managers as the driving force behind most application development or upgrade projects consider security to be an important project goal, both through training and accountability. Awareness programs can be readily implemented, using external expert resources as appropriate, and can deliver a high return by helping to ensure that other activities promoting secure software will be implemented effectively.

Perform application assessments

While it is true that security cannot be tested into an application, application testing and assessments should still be a central component of an overall security strategy. Assessments particularly automated tests can find security problems not detected during code or implementation reviews, find security risks introduced by the operational environment, and act as a defense in depth mechanism by catching failures in design, specification, or implementation. Test and assessment functions are typically owned by a test analyst or by the QA organization but can span the entire life cycle.

Capture security requirements

Ensure that security requirements have the same level of "citizenship" as all other "must haves." It’s easy for application architects and project managers to focus on functionality when defining requirements, as they support the greater purpose of the application to deliver value to the organization. Security considerations can easily go by the wayside, so it is crucial that security requirements be an explicit part of any application development effort. Among the factors to be considered are:

an understanding of how applications will be used and how they might be misused or attacked.

the assets (data and services) that the application will access or provide and what level of protection is appropriate given the organization’s appetite for risk, regulations to which it is subject, and the potential impact on its reputation should an application be exploited.

the architecture of the application and probable attack vectors.

potential compensating controls and their cost and effectiveness.

Implement secure development practices

An essential application security goal is to create and maintain reusable source code that strengthens basic security services within an application and across an organization's applications. This goal is best achieved through implementing secure development practices into an organization's overall development process as early as possible in the SDLC.

This CLASP Best Practice makes available an extensive set of process components. It provides well defined, role based activities that, for example, help guide project teams when applying security principles to design, integrating security analysis into the source management process, and implementing resource policies and security technologies. It also provides extensive sample coding guidelines as well as artifacts like the 104 CLASP Problem Types that help a project team systematically avoid security vulnerabilities in source code.

Build vulnerability remediation procedures

It is especially important in the context of application updates and enhancements to define which steps will be taken to identify, assess, prioritize, and remediate vulnerabilities. Building remediation procedures will speed response and minimize risk by defining roles, responsibilities, and processes to follow after identification of vulnerability. Remediation procedures are often fed by software assessments, both in house or third party, and help to control information when disclosure must occur.

Define and monitor metrics

A development project team cannot manage what it cannot measure. Unfortunately, implementing an effective metrics monitoring effort can be a difficult undertaking. Despite this, metrics are an essential element of an overall application security effort. They are crucial in assessing the current security posture of an organization, help focus attention on the most critical vulnerabilities, and reveal how well or poorly the organization’s investments in improved security are performing.

Publish operational security guidelines

Security does not end when an application is completed and deployed in a production environment. Making the most of existing network and operational security investments requires that those tasked with monitoring and managing the security of running systems are informed and educated; they need advice and guidance on the security requirements the application demands and how to best use the capabilities built into the application.

The 24 CLASP Activities

CLASP is designed to allow easy integration of its security related activities into existing application development processes. Each CLASP Activity is divided into discrete process components and linked to one or more specific project roles. In this way, CLASP provides guidance to project participants (e.g., project managers, security auditors, developers, architects, testers, and others) that is easily adaptable to their way of working. This results in incremental improvements to security that are easily achievable, repeatable, and measurable.

Note: The project role of security auditor is CLASP created. This role mainly examines the current state of a project and tries to ensure the security of the current state of the project in these project phases: requirements, design, and implementation. Table 6 lists the 24 CLASP Activities and their related project roles and shows the recommended distribution of these activities across the CLASP Best Practices.

CLASP Best Practices

CLASP Activities

Related Project Roles

1. Institute awareness programs

Institute security awareness program

Project manager

2. Perform application assessments

Perform security analysis of system requirements and design (threat modeling)

Security auditor

Perform source-level security review

Owner: security auditor

Key contributor: implementer, designer

Identify, implement, and perform security tests

Test analyst

Verify security attributes of resources

Tester

Research and assess security posture of technology solutions

Owner: designer

Key contributor: component vendor

3. Capture security requirements

Identify global security policy

Requirements specifier

Identify resources and trust boundaries

Owner: architect

Key contributor: requirements specifier

Identify user roles and resource capabilities

Owner: architect

Key contributor: requirements specifier

Specify operational environment

Owner: requirements specifier

Key contributor: architect

Detail misuse cases

Owner: requirements specifier

Key contributor: stakeholder

Identify attack surface

Designer

Document security-relevant requirements

Owner: requirements specifier

Key contributor: architect

4. Implement secure development practices

Apply security principles to design

Designer

Annotate class designs with security properties

Designer

Implement and elaborate resource policies and security technologies

Implementer

Implement interface contracts

Implementer

Integrate security analysis into source management process

Integrator

Perform code signing

Integrator

5. Build vulnerability remediation procedures

Manage security issue disclosure process

Owner: project manager

Key contributor: designer

Address reported security issues

Owner: designer

Fault reporter

6. Define and monitor metrics

Monitor security metrics

Project manager

7. Publish operational security guidelines

Specify database security configuration

Database designer

Build operational security guide

Owner: integrator

Key contributor: designer, architect, implementer

Table : CLASP activities and related project roles and best practices