The History Of Clasp Resources

Published Date: 02 Nov 2017

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

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

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.