What Software Security Is

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

CLASP Resources (including CLASP Keywords)

An integral part of the CLASP Process are resources that aid the planning, implementing, and performing CLASP Activities. Completing the sample coding guideline worksheets resource, for example, can help project managers understand which of the 104 CLASP Problem Types (see Vulnerability View above) could pose security risks for building a particular software system. This knowledge, in turn, can be used to help determine how CLASP Activities should be performed. Several of the CLASP Resources are especially useful for projects that use tools to help automate CLASP process components. These are the CLASP Resources, shown with examples.

"Basic principles of application security"

"insider threats as the weak link"

"assume the network is compromised"

"minimize attack surface"

"secure-by-default"

"defense-in-depth"

"principles for reducing exposure"

"insecure-bootstrapping principle"

"example of basic-principle violation: penetrate-and-patch model"

" Descriptions of core security services and concepts"

"authorization (access control)"

"authentication"

"confidentiality"

"data integrity"

"availability"

"accountability"

"non-repudiation"

"Sample coding guidelines (worksheets)"

"build and test"

"network usage"

"authentication"

"input validation"

"file system"

"documentation"

"object-oriented programming"

"cryptography"

"UNIX-specific"

"Windows-specific"

"C, C++, Perl, Python, PHP"

"Java mobile code"

"Web applications"

"Generic mobile / untrusted code environments"

"System assessment worksheets"

"development process and organization"

"system resources"

"network resource detail"

"file system usage detail"

"registry usage (Microsoft Windows environment)"

"Sample road maps"

"legacy projects"

"new-start projects"

"Aids for creating the process engineering plan"

"Aids for forming the process engineering team"

"Glossary of security terms"

- Scope: CLASP is based on extensive field work by Secure Software employees in which the system resources of many development life cycles were decomposed to create a comprehensive set of security requirements. These resulting requirements form the basis of CLASP’s Best Practices, which can enable organizations to systematically address vulnerabilities that, if exploited, can result in the failure of basic security services (e.g., confidentiality, authentication, and authorization).

- Validation and quality assurance (QA): CLASP possible to apply traditional verification techniques. For this purpose, a tool suite is provided. CLASP consider elicitation of security requirements. An integral part of the CLASP Process are resources that aid the planning, implementing, and performing CLASP Activities.

UML-based approaches

In this section, we discuss approaches to security requirements engineering that make use of Unified Modeling Language (UML) (UML Revision Task Force, 2012) and (Santen & Schmidt, 2010) notation.

Misuse cases

- Description: Sindre and Opdahl (Sindre and Opdahl, 2001) extend the traditional use case approach to also consider misuse cases, which represent behavior not wanted in the system to be developed. Misuse cases are initiated by misusers. A use case diagram (see Fig. 1) contains both, use cases and actors (notated as named ellipses and named stick figures, respectively), as well as misuse cases and misusers (notated as graphically inverted use cases and actors).

Figure : Use case diagram containing misusers and misuse cases (taken from (Sindre and Opdahl, 2001))

A use case is related to a misuse case using a directed association. An association pointing from a misuse case to a use case has the stereotype "threaten". A use case diagram can contain security use cases, which are special use cases. An association pointing from a security use case to a misuse case has the stereotype "mitigate". It is stated that ordinary use cases represent requirements, security cases represent security requirements, and misuse cases represent security threats. Since use case diagrams only give an overview of the system functionality, the essence of the contained uses cases is captured in an associated textual description. This textual description is based on a template to be filled out by an analyst. Sindre and Opdahl extend the template, making it suitable for describing misuse cases, supporting detailed elicitation and analysis of security threats. Furthermore, they present an iterative method based on common risk and threat analysis:

1. Identify critical assets in the system.

2. Define security goals for each asset.

3. Identify threats for each security goal by identifying stakeholders that may intentionally harm the system or its environment. Identify sequences of actions that may result in intentional harm.

4. Identify and analyze risks for the threats (using standard techniques).

5. Define security requirements for the threats to match risks and protection costs. Applying misuse cases results in a use case diagram including use cases, security uses cases, and misuse cases. The approach neither considers a formal foundation nor an attacker model.

- Scope: Misuse cases are applicable to design a system that covers different security needs. It is possible to consider all three CIA goals. It incorporates common risk and threat analysis techniques.

- Validation and quality assurance (QA): The interaction between functional and security needs is considered in terms of linked use cases and security use cases in a use case diagram. The approach does not consider elicitation of requirements, completeness of the set of requirements, validation, verification, conflicting requirements, nor the interaction of security and other non-functional requirements.

Secure-UML

- Description: Lodderstedt et al. (2002) present a UML-based modeling language for the development of secure, distributed systems called Secure-UML. In particular, their approach focuses on embedding role-based access control policies in UML class diagrams using a UML profile. The UML profile defines a vocabulary for annotating class diagrams with relevant access control information. Secure-UML does not consider an attacker model.

- Scope: Lodderstedt et al. focus on the design of role-based access control policies, a rather partial mechanism to fulfill confidentiality and integrity goals. Availability is not covered by this method.

- Validation and quality assurance (QA): Secure-UML does not consider requirements (in the sense of security requirements in the conceptual framework) elicitation, completeness of the set of requirements, validation or verification, nor interaction and conflicts of requirements.

UMLsec

- Description: Ju¨rjens (2003) introduces a UML-based modeling language for the development of security-critical systems named UMLsec. His approach considers several security requirements according to the CIA triad. These requirements are depicted in different UML diagrams using stereotypes, constraints, and tagged values, which are defined in a UML profile. The UMLsec extensions are precisely defined and have a formal semantics. Ju¨rjens’ work considers an attacker model based on the adversary tag. The approach also considers domain knowledge in terms of assumptions.

- Scope: Ju¨rjens’ approach focuses on the design of a machine, and it covers all three CIA goals.

- Validation and quality assurance (QA): Ju¨rjens states that the formal foundation makes it possible to apply traditional verification techniques. For this purpose, a tool suite is provided. UMLsec does not consider elicitation of requirements, completeness of the set of requirements, verification, conflicting requirements, nor possible interaction of security, functional, and other non-functional requirements.

Comparison between Methods/approaches and best practices in security requirements engineering

This comparison give us some differences between the approaches and best practices, each one of these approaches has some attributes make it has a unique features. Table 9 summarizes some major approaches to security requirements engineering, in relation to tasks recommended as part of the requirements phase.

Approaches & Best Practices

Year

Focusing on security requirement level

Level of focusing

consider elicitation of requirements

CIA

Stakeholder participation

Oriented toward system

SQUARE

2005

Yes

Requirements Elicitation

Yes

CIA

Client

System

MSRA

2006

Yes

Analysis

Yes

CIA

Actor

System

CLASP

2005

Yes

Requirements Elicitation

No

C

Client

System

Misuse cases

2001

Yes

Requirements Elicitation & Analysis

No

CIA

Actor

Machine

Secure-UML

2002

No

Design

No

CI

User

Machine

UMLsec

2003

No

Design

No

CIA

Actor

Machine

Table : Comparison between Methods/approaches and best practices in security requirements engineering.

Quantifying Security in Software

During secure software developments, it is essential for the developer to know, for each phase that, how many vulnerabilities are present, what is the potential damage vulnerabilities can cause to various assets of the system the software is going to be a part of, what security requirements have to be incorporated to remove these vulnerabilities, and what is the cost effectiveness of each security requirement. Very little work has been done to help the developer in this direction (Khan, 2008). The quantified information about vulnerabilities is important because if an error leading to vulnerability is not corrected in an early phase, the cost of correcting it might increase tenfold with every additional development phase (Khan, 2008). The table below shows some of the studies focused on quantifying security in software industry through SDLC.

Article Name

Author/year

Problem

Objectives

method

Result

Quantifying Security in Secure Software Development Phases

(Khan, 2008)

There is no concrete technique to quantify security of an SDLC artifact (requirements specification, design document, and source code).

-Propose a methodology, which will enable developers to evaluate the security state of a particular SDLC artifact.

-To perform this

evaluation in an additional SDLC phase "security assessment" after requirements, design, and implementation phases.

-Prioritizing vulnerabilities based on the potential damage they can cause.

Quantification Methodology using math.

This would allow developing more secure software and particularly, prioritizing

vulnerabilities based on the potential damage they can cause.

Towards Evaluation of Security Assurance during the Software Development

Lifecycle

(Uusitalo, Karppinen, & Ahonen, 2009)

It is difficult to state whether a certain software product is developed securely enough.

Discuss heuristics for evaluating security assurance methods used during the SDLC, and how these evaluations could be transferred to evaluating the whole system.

Used the math.

This paper presents security assurance evaluations heuristics that are the first step towards our security assurance evaluation tool. The heuristics take the security assurance

methods used in each phase of SDLC into account. They are meant to give guidelines on the trustworthiness of the SDLC.

A Scenario-Based Framework for the

Security Evaluation of Software Architecture

(Alkussayer, 2010)

Able to assess the security of software under development at an early stage (e.g., the design stage).

-Reducing the probability that flaws will be introduced and ensuring that stakeholder requirements have been met.

-Focusing on a stage where changes will cost just a fraction of what they would cost in later stages (e.g. implementation).

-Development of a systematic security evaluation framework that aids in assessing the level of security supported by a given

architecture and provides the ability to qualitatively compare

multiple architectures with respect to their security support.

-Use math

Present a systematic process for

generating a security scenario template that simplifies the assessment process.

Software Project Risk Assessment Model Based on Fuzzy Theory

(Tang, 2010)

Risk assessment is the core and foundation of software project risk management, directly affecting other processes and even the success or failure of the software projects.

Provide a new way to effectively reduce the risk probability and increase the rate of the success of the software development.

Using Fuzzy theory

Comes up with a new model of software project risk assessment,

How Can Secure Software be Trusted?

(Futcher, 2011)

These interconnected computers and networks can be attacked at various points, putting the associated information at risk. A substantial portion of these attacks on systems occur through exploiting vulnerabilities in the software that forms an integral part of the system. This raises the question of ‘Why do these vulnerabilities exist in software?’.

Address some key aspects related to the security and trustworthiness of a software application functioning within a specific environment.

Give key aspects of secure trusted software.

By considering these key aspects, a higher level of security and trust could be provided for all stakeholders including the information owners, software developers and users of the software.

Table : some studies about quantifying security in software

As illustrated in the table above there is little works discussed quantifying the security in software industry. However, these researches discussed the situation of security in the SDLC and focus was on the quantifying information about security. The problem is how to assess the security of software (the product is developed securely enough) and how to quantify security of SDLC artifacts. The solution was propose a framework, methodology or a model. No one of these researches focus on the most important phase which is requirement elicitation phase, which is the first phase of SDLC that must be define all business requirements and security requirements that related to the business requirements. No one of these researches used the best practices in security requirements engineering, which is the core of security requirements engineering process.

Requirements elicitation technique for security requirement

Donald Firesmith claims that most requirements engineers are poorly trained to elicit, analyze, and specify security requirements (D.G. Firesmith, 2003). Consequently, they often confuse security requirements with architectural security mechanisms that are traditionally used to fulfill requirements, and end up making architecture and design decisions. Charles Haley and his colleagues recognize the same problem. They show that several standards (such as the Common Criteria and the US National Institute of Standards and Technology computer security handbook) suggest describing security requirements in terms of security mechanisms (Haley et al., 2007). However, as they point out, "Defining requirements in terms of function leaves out key information: what objects need protecting and, more importantly, why the objects need protecting."

Haley and his colleagues define security requirements as "constraints on the functions [that] ... operationalize one or more security goals." They take issue with those who specify security requirements as high-level security goals, arguing that this makes it difficult to make the requirements specific enough to guide designers and to verify that the requirements are met. For the same reason, they recommend security requirements that "express what is to happen in a given situation, as opposed to what is not ever to happen in any situation." (Haley et al., 2007).

The Comprehensive Lightweight Application Security Process (Clasp) states that all requirements should be Smart requirements: specific, measurable, appropriate, reasonable, and traceable. Clasp gives no examples, however, as to what a typical security requirement should look like. Firesmith gives such examples. He defines a security requirement as "a detailed requirement that implements an overriding security policy." He suggests dividing security requirements into categories, such as identification, integrity, and privacy requirements(D.G. Firesmith, 2003). For example, the requirement "The application shall identify all of its client applications before allowing them to use its capabilities" is an identification requirement, whereas "The application shall not allow unauthorized individuals or programs access to any communications" is a privacy requirement.

Haley and his colleagues also give examples of security requirements, such as "The system shall

provide Personnel Information only to members of Human Resources Dept." (Haley et al., 2007). By expressing security requirements in relation to specific functional requirements, they claim that they can achieve enough specificity to guide designers and let them verify that the requirements are actually fulfilled. These examples notwithstanding, we haven’t found a universally accepted definition of "security requirement" in the literature.

The Software Engineering Institute’s SQUARE (Secure Quality Requirements Engineering) has nine main steps as mentioned in earlier section (Mead et al., 2005):

1. Agree on definitions.

2. Identify security goals.

3. Develop artifacts.

4. Perform risk assessment.

5. Select an elicitation technique.

6. Elicit security requirements.

7. Categorize requirements.

8. Prioritize requirements.

9. Inspect requirements.

Square is based on interaction between requirements engineers and an IT project’s stakeholders,

where facilitation by a requirements engineering team is of major importance. Although Square is intended for the early phases of software development, step 3 in particular requires some previous design activity. This is because the artifacts that are to be developed or identified include system architecture diagrams.

Stating what Square includes and doesn’t include isn’t straightforward, because developers can choose several techniques for the different steps. For example, the main Square methodology doesn’t include asset identification, but one case study uses survivable system analysis(Mead et al., 2005). which includes identification of essential assets and services.

Haley and his colleagues’ framework gives four main steps (Haley et al., 2007):

1. Identify functional requirements.

2. Identify security goals including assets, threats, management principles, and business goals.

3. Identify security requirements.

4. Verify the system.

The authors suggest using Jon Hall and his colleagues’ problem diagrams (Hall et al., 2005), a notation most developers are unfamiliar with. Although they also suggest that verification include formal argumentation, the main methodology would likely work with more informal techniques. Iteration between requirement and design activities is an important part of the framework. Fulfilling a security requirement might lead to new assets, resulting in new security requirements.

Gustav Boström and his colleagues consider security requirements engineering in a different context agile development with a focus on extreme programming (XP) practices (Boström et al., 2006). They suggest seven steps for identifying and handling security requirements:

1. Identify critical assets.

2. Formulate abuser stories (that is, brief, informal descriptions of how an attacker might abuse the system).

3. Assess abuser story risk.

4. Negotiate abuser and user stories.

5. Define security-related user stories.

6. Define security-related coding standards.

7. Cross-check abuser stories and countermeasures.

This process extends XP user stories to include security requirements. The main ideas should

also be relevant for other types of development processes.

Clasp again is a major initiative for securing software development life cycles. It specifies a set of process pieces that you can integrate into any software development process. Maybe because of Clasp’s general nature, the steps outlined aren’t as concrete as, for example, Boström and his colleagues’(2006). The requirements phase of the Clasp green-field roadmap has two steps (that is, steps recommended for new software development):

1. Document security-relevant requirements (for example, identify business requirements and functional security requirements and dependencies) for determining risk mitigations and resolving deficiencies and conflicts.

2. Identify resources and trust boundaries, such as network-level design and data resources.

Several authors suggest use cases as a starting point for identifying security requirements. Although the green-field roadmap doesn’t include the task "detail misuse cases," Clasp describes this task as a possible requirements activity. Eduardo Fernandez points out that use cases are helpful for determining the rights each actor needs and for considering possible attacks (Fernandez, 2004). Gunnar Peterson suggests use and misuse cases as a basis for security requirements, but notes that you might need additional nonfunctional requirements (Peterson, 2004). Kenneth van Wyk and Gary McGraw suggest using abuse cases (Van Wyk and McGraw, 2005). Abuse cases are also one of McGraw’s "touchpoints" for the requirements and use cases phase, together with security requirements (McGraw, 2006). However, McGraw gives little detail on this security requirements touchpoint.

Steve Lipner and Michael Howard describe the Microsoft Trustworthy Computing Security Development Lifecycle, focusing on planning security activities that are to take place later in the software development life cycle (Lipner and Howard, 2005). They also state that you should identify key security objectives together with security feature requirements that are based on customer demand and compliance with standards. You’ll identify other security feature requirements as part of threat modeling, which takes place during design. Threat modeling (Torr, 2005) although part of the design phase, also has some steps that might consider for the requirements phase:

1. Identify use scenarios.

2. Identify assets.

3. Identify threats.

4. Identify dependencies.

Axelle Apvrille and Makan Pourzandi suggest four steps for the security requirements and analysis phase (Apvrille and Pourzandi, 2005):

1.Identify the security environment and objectives.

2.Determine the threat model.

3.Choose a security policy, which includes prioritizing according to the information’s sensitivity.

4. Evaluate risk.

They intend that the developers themselves perform these steps, but they don’t explain the steps in much detail. Because we aim for a lightweight approach, this survey deliberately omits formal methods. Unfortunately, this also means that Howard Chivers’s work on automated risk analysis falls outside this article’s scope, because it relies on formal modeling (Chivers, 2006). The same goes for Axel van Lamsweerde’s work on intentional antimodels (van Lamsweerde, 2004).

A number of studies have focused on the question of addressing security concerns at the requirements phase. In their paper, Ware et al. presented an approach to eliciting security requirements for IT systems with use cases using Common Criteria methodologies (Schmidt and Townsend, 2003). Other work that has investigated the applicability of the Common Criteria is presented by Shi and Sun (Montenegro et al., 2003). However, both of these efforts are limited only to investigation of the use of the Common Criteria in providing security confidence for software systems.

Hope et al. analyzed Misuse Cases and Abuse Cases in the perspective of putting them to work (Pauli and Xu, 2005). They emphasized the need of addressing security throughout the lifecycle starting from the requirements engineering, where Misuse and Abuse Cases can be used to specify security requirements. There have been many studies that have employed Misuse and Abuse Cases for specifying security requirements (Schneier, 2000), (Sindre and Opdahl, 2000, 2001), (Shi and Sun, 2001), (Moore et al., 2001), (Alexander, 2002, 2003) and (Kwan and Berry, 2004).

Comparisons demonstrates the problem of current frameworks and methods related to security requirements.

Our studying to the methods, approaches, frameworks, techniques and best practices reveals that, no common agreement exists on what a security requirement is. More specifically, the various approaches don’t agree on the extent to which the requirements should state concrete security measures. SQUARE requires some design work as background material for security requirements elicitation. MICROSOFT considers some of the other approaches’ requirement activities as part of the design phase. CLASP considers determining risk mitigations to be a requirements activity, while others consider this part of design. One reason for these differences might be different focuses on iteration. Agile development, Boström and his colleagues’ focus, is iterative, unlike what seems to be the case with other approaches, such as SQUARE.

The approaches also provide different levels of detail as to how to perform the tasks. For example, Clasp’s and Apvrille suggestions are more general, and thereby less concrete, than those of Boström and colleagues, who focus on XP development. The approaches also require different levels of expert knowledge. SQUARE relies on a requirements team facilitating the process. Haley and his colleagues suggest artifacts that are probably too complex for regular developers. Other approaches, such as those of Boström and colleagues, Microsoft, and Clasp, are more lightweight.

We’re aware of methodical limitations. The different approaches might weight the activities differently, some approaches are more accepted than others, and the comparison criteria might be inadequate. Table 9 shows that the approaches commonly recommend misuse or threat identification. Many of the typical artifacts used for security requirements engineering also support this task. Many of the approaches also recommend identifying objectives and assets. So, our impression first is, that these three tasks (CIA) are highly important to security requirements engineering, although the approaches’ recommendations as to how to perform them differ, the second impression is, most of the approaches and methods don’t consider in their tasks requirements phase to starting the security process from the roots. Our work differs from these studies in that we are not using a single method; rather we are using a number of them, along, and we will cover the requirements phase with security aspects using the shared and common used tasks between best practices.