In order to avoid the high impacts of software vulnerabilities, it is necessary to specify security requirements early in the development on a detailed level. Current approaches for security requirements engineering give insu cient support for re ning high-level requirements to a concrete and assessable level. Furthermore, reuse mechanisms for these detailed requirements are missing. This paper proposes a web security model based on experiences with other quality models that is used in a security requirements engineering approach. The model provides (1) a means for re nement and (2) a requirements repository for reuse. The approach is illustrated with an example involving the Tomcat servlet container.
Malicious attacks on software systems are a topic with high public visibility as average users can be a ected. The level of vulnerabilities is still high today. The CERT1 reports of 6,058 total vulnerabilities for the rst 9 months of 2008. These attacks have a strong nancial impact. In last year's E-Crime Watch Survey2, it is stated that on average for each company security attacks result in a monetary loss of $456,700 in 12 months.
Therefore, software security is still a large and important problem in practice. It not only a ects nancial aspects but also ethical issues such as privacy. Hence, it is an important goal in software development to produce secure systems. This especially holds for web systems that are usually accessible in public networks. Secure web systems begin with the speci cation of security requirements. In order to become e ective, they need to be clear and precise so that they are a real guidance for their implementation. This way, vulnerabilities can be prevented or at least reduced. Problem Despite the importance of high-quality security requirements for web systems, in practice they are often not well documented or not documented at all. Quality in general and security in particular are concepts with many facets and aspects. Hence, formulating precise requirements is di cult and elaborate.
First, there is no methodological guidance for re ning high-level security requirements such as con dentiality or integrity to a concrete and assessable level. The re nement of security requirements is often complicated by many reasons such as by unavailable end users. This especially is true for systems that are distributed within a huge market, as it is the case for many web systems. Second, it is often unclear how reuse of requirements can be properly integrated in the development process. It is economically questionable to write detailed security requirements for each system from scratch.
Contribution The main contribution of this paper is an approach for security
requirements engineering for web systems that mitigates the above mentioned
problems. It uses an explicit and detailed security model as a knowledge
repository for the reuse of requirements and their re nement. This security model
builds on experiences with other quality models and documents in detail what
security means in a given setting. We use the model in the approach to support
two steps in particular: (1) deriving misuse cases based on the modelled attack
patterns and (2) re nement of the high-level misuse cases to assessable, low-level
requirements
Related Work In recent years much work has been done considering security
requirements and related engineering processes. SQUARE [
Quality models describe in a structured way what quality of software means. We introduce activity-based quality models and propose the web security instance that we use in the requirements approach. 2.1
We use the term quality model here in the sense of a quality de nition model from
[
We have proposed to use activity-based quality models (ABQM) [
For ABQMs, an explicit meta-model was de ned in order to characterise the quality model elements and their relationships. Four elements of the meta-model are most important: Entity, ATTRIBUTE, Impact and Activity. An entity can be any thing, animate or inanimate, that can have an in uence on the software's quality, e.g. the source code of a method or the involved testers. These entities are characterised by attributes such as STRUCTUREDNESS or CONFORMITY. The combination of an entity and an attribute is called a fact. We use the notation [Entity j ATTRIBUTE] for a fact. These facts are assessable either by automatic measurement or by manual review. If possible, we de ne applicable metrics for measuring the facts inside the ABQM. An in uence of a fact is then speci ed by an Impact. The impact on an Activity can be positive or negative. An activity is anything that is done with the system. For example, redundant methods (code clones) in the source code render modi cations more di cult and elaborate. This is expressed in the model as [Method j REDUNDANCY] ! [Modi cation].
The model does not only contain these impacts of facts on activities but also the relationships among these. Facts as well as activities are organised in hierarchies. A top-level activity Activity has sub-activities such as Use, Maintenance or Administration. In realistic quality models, these are then further re ned.
Having de ned all these entries in the ABQM, we can specify which activities we want to support and which in uencing facts need to be considered. In terms of the above example, if we want to support the activity Modi cation, we know that we need to inspect the redundancy of methods. 2.2
For handling web security requirements, we need to create a web security
instance of the ABQM. Most important in this instance is to add attacks to the
activity tree. These are activities that need to be negatively in uenced. First,
we have to di erentiate between anticipated attacks and unanticipated attacks.
A major problem in software security is that it is impossible to know all attacks
that the system will be exposed to. This is the case because new attacks are
developed every day. Hence, to assure quality, we need to employ two strategies:
(1) prepare the system against anticipated attacks and (2) harden the system
in general to avoid other vulnerabilities. For the classi cation of the attacks,
there are several sources possible. We rely on the open community e ort
Common Attack Pattern Enumeration and Classi cation (CAPEC) [
Unanticipated
Attack
Attack Anticipated
Attack Abuse of Functionality
Data Attack
Exploitation
Injection
Physical Attack
Probabilistic Techniques
Resource Attack
Spoofing
Time and State
Attack DataAtLteacakkage DataAStttarcukcture AEuxpthloeintatitcioantioonf PErxivpilloeigtaet/ioTnruosft Resource Depletion
Resource Manipulation
The creation of the facts tree is far more complicated. The facts tree needs
to contain the available knowledge about characteristics of the system, its
environment and the organisation that in uence the described attacks. We employed
various sources for collecting this knowledge including the ISO/IEC 27001 [
We cannot describe the incorporation of the sources in all details in this paper but we give some examples on how knowledge from the sources has been modelled in our security model. For this, we use a sub-tree of the fact tree for the system as depicted in Fig. 2. The system consists of Data and Functionality. Furthermore, it has Dynamics and a Static Structure. These entities have then again children. For example, data can be a Cookie or an HTTP Request. Interesting functionality can be Cryptographic Support or File Handling.
Many of the entries in the quality model that have their origin in the Common Criteria are modelled as a part of Functionality because they mainly describe behavioural aspects that nevertheless are important for security. An example that is shown in Fig. 2 is the cryptographic support of the system. Following the CC, this can be decomposed into Cryptographic Key Management and Cryptographic Operation. A further part of Cryptographic Key Management is the Cryptographic Key Generation. The CC de nes a requirement for that key generation that it shall be
Data
Functionality
Dynamics
Static Structure Cookie
HTTP Request Cryptographic File Handling
Support
Ressource Allocation
Web Page in accordance with a speci ed algorithm and speci ed key sizes. In the model, we express that by using the attribute APPROPRIATENESS for Cryptographic Key Generation. The resulting fact [Cryptographic Key Generation j APPROPRIATENESS] is textually described by \The system generates cryptographic keys in accordance with a speci ed cryptographic key generation algorithm and speci ed cryptographic key sizes that meet a speci ed list of standards." Unfortunately, the CC does not contain any description of impacts. This would make the standard more useful because the motivation to use these requirements would be higher. Hence, we complete the information using other sources. In this case, the CAPEC contains possible solutions and mitigations in the description of the cryptanalysis attack that includes the recommendation to use proven cryptographic algorithms with recommended key sizes. Therefore, we include the corresponding negative impact of [Cryptographic Key Generation j APPROPRIATENESS] on Cryptanalysis.
In contrast to the CC, the Common Weakness Enumeration mainly provides characteristics of the system and especially the kind of code that should be avoided. We include these characteristics into the model in this negative way with a positive in uence on the attacks, i.e. making attacks easier. Another possibility is to reformulate the weaknesses as strength that are needed with negative in uence on attacks. We used both possibilities depending on which option was more straightforward to model.
Several weaknesses in the CWE are not aiming at speci c attacks but describe characteristics that are indicators for possible vulnerabilities. We model these as facts that have an impact on unanticipated attacks. An example from the CWE that is in our security model is dead code. Several parts of the code can be super uous such as variables, methods or complete classes. For a variable, we can model that as a positive impact of [Variable j SUPERFLUOUSNESS] on Unanticipated Attack. 3
A requirements engineering (RE) process in general aims at systematically and
e ectively de ning requirements that are aligned with the needs of all relevant
stakeholders. According to [
Legend: Artefacts Activities
Activities (Attacks) Derive
Activity-based Quality Model
Impact (+/-)
Entities
Attributes ReqCuoirnetmroel nts Update
Validation - Control Requirements - Update ABQM Elicitation - Elicit Goals, Services,
Assets & Policies - Derive Security Goals
Analysis - Identify Use Cases - Identify Threats, Vulnerabilities &
Develop Misuse Cases - Derive quantified Security Requirements Elicitation During the requirements elicitation high level business requirements and/or market needs are collected. These represent high-level, initially stated, requirements. In particular, business requirements encompass (1) goals that have to be achieved by the nal product, (2) services and assets that are o ered and maintained by the product and (3) policies that might restrict its functionality. This information provides a su cient basis for deriving security goals. Analysis The requirements analysis aims at re ning the business requirements to measurable ones. The rst step of this re nement procedure consists of the identi cation of use cases. They represent the system's external behaviour by describing scenarios | speci c sequences of interaction between users and the system. Because for security requirements also undesired use is relevant, misuse cases are derived. A misuse case can be seen as the inverse of a use case that shows an undesirable sequence of interactions, i.e. they describe how a speci c attack can be performed.
The last step within analysis consists in deriving more concrete security requirements. These requirements demand speci c properties (attributes) of the system and its environment that are meant to prevent the attack possibilities described within the misuse cases. For example, if a misuse case describes a speci c attack that embeds malicious code into the system, derived security requirements could demand speci c properties of sensitive data that is transmitted in encrypted connections.
However, as already described, a major challenge consists not only in identifying possible misuse cases but also in deriving security requirements from the scenarios that address the prevention of such attacks. The quality model therefore serves as a knowledge repository that supports the reuse of requirements for the purpose of identifying and re ning them. The activities within the quality model correspond to the scenarios (use cases and misuse cases) that are elicited and re ned. The entities correspond to the system elements that are constrained by the requirements in terms of demanding speci c properties of these elements, while the attributes of the entities correspond to such properties.
In this sense, the ABQM can be used to identify misuse cases by harvesting
relevant attack scenarios from the activity tree. To derive quanti ed security
requirements from these misuse cases, the ABQM is also used. As it also de nes the
relations between the scenarios and corresponding (e.g. technological) entities of
a system, we only need to follow the impact of an activity to the corresponding
entities to derive detailed requirements. These detailed requirements constrain
the system's entities in a measurable way. In this case measurable does not
necessarily mean automatically measurable. Also manual assessments like reviews
and inspections can be used to evaluate quality requirements. This tackles the
problem that requirements engineers do not need to have all technological
possibilities in mind for each scenario. For example, attack scenarios that exclusively
refer to web technologies can be grouped together [
Validation The validation aims at proving and controlling requirements according to chosen (quality) criteria. In particular, the goal is to avoid and resolve con icted, under-speci ed, unfeasible, incomplete and incorrect requirements. To nd and correct such requirements, the ABQM can be used. For example, two requirements are con icted (make contrary assertions), if they constrain the same system entity in a di erent way. Also under-speci ed requirements can be detected. If a requirement is under-speci ed, it is impossible to nd an impact to a certain system entity. Also the correctness of the requirements can be tackled, because all detailed requirements are derived from business requirements and can be traced back to them.
Finally, requirements validation also includes updating the ABQM with requirements that are elaborated in addition to ones that are already stored within the ABQM. This update consists of two steps. First, the activity tree undergoes an update by inserting new scenarios, such as misuse cases that are not yet addressed by the activity tree. Second, the entities are inserted by adding the entities that are constrained with speci c quality attributes. 4
To further illustrate our approach, we use the servlet container Tomcat 6.0 4 and develop security requirements for it. Tomcat is the reference implementation of
the Java servlet and JSP speci cation and provides support to deliver dynamically assembled HTTP responses based on an HTTP request. We follow the RE process introduced in the previous section, while describing only exemplary requirements for reasons of space limitations.
Elicitation We concentrate on the most important high level goal for Tomat: The system allows the user to send any request and get a response. From this goal the elementary services request and response are derived in terms of that a server has to respond to every possible sequences of HTTP requests from a client. Several critical assets are possible but we assume that only sensitive information is important in our example. Security goals are now identi ed to protect each of the identi ed services and assets and to attain the de ned goals. The derived security goals are: (a) The system services shall be available for the subscript user and (b) the system shall ensure privacy, integrity and availability of the sensitive data communicating among the involved legitimate parties. Analysis Based on the elicited business requirements we examine the threats and vulnerabilities from our model. We use the identi ed services as a basis for identifying the relevant use case (request & response). There are several possible anticipated attacks for this use case that violate the con dentiality and integrity of sensitive information. For instance, injection attacks that cause the unauthorised access in an established session so that attackers can view, capture and modify any data that is communicated within this session. Therefore, \attack by injection" is considered as a misuse case. Figure 4 illustrates how from the ABQM misuse cases are derived. The left side of the gure represents the attack activities contained in the model, the right side the identi ed misuse cases that set the attacks in context to the relevant use cases. In the model, this attack is in uenced by the fact [Directive j SANITATION] and [Processing j SANITATION]. Hence, the requirements have to explicitly include that user input of directives and processing of data needs to be validated before it is used. In a similar way, we analyse the other attacks such as resource attacks with their related facts.
Activity Tree of the ABQM (Attacks Activities)
Misuse Cases (Attack Scenarios) Activity Anticipated
At ack
Fig. 4. Using the ABQM for deriving misuse cases
At this stage security requirements are speci ed based on the identi ed attacks and related facts from the model. These security requirements are detailed enough to be able to assess their ful lment directly in the code, e.g. by reviews. The elicited security requirements can be textually speci ed like in the following: { The software shall sanitise user-controllable input for content before it is prepared in output that is used as a web page. Unsanitized special elements that have control implications in web pages, such as HTML tags or mouse events, are interpreted as control characters that execute in violation of the client's trust in the application or system. This weakness usually enables cross-site scripting attacks in web applications. { The system shall verify user inputs that are assumed to be immutable but are actually externally controllable, such as a cookie.
Validation As our short list of the above requirements does not contain any con icts, the validation is rather simple. However, there are further threats which are not currently covered in our activity tree. For example, an attacker can have the opportunity to view or modify the sensitive data by unauthorised physical means. This needs to be re ned without speci c guidance from the ABQM but can then be fed back into it. This way, this new kind of attack is available in the requirements elicitation for the next project. 5
Because of the importance of software security in web systems, we need to consider security aspects from the very beginning in the requirements engineering process. The basis of our security requirements approach consists of an activitybased security model that uses experiences with such models in other areas. The way of modelling allows to break down security to assessable and partly directly measurable characteristics of the system, its environment and the organisation. The activities in the model consist of common attack patterns that need to be prevented and thereby deliver the means for re ning high-level security goals to such concrete and assessable, but necessarily measurable characteristics. Moreover, the model can also serve as a comprehensive repository that fosters the reuse of security requirements.
An example was conducted with the Tomcat servlet container. It showed that
the approach is feasible in principle and that there is a potential for preventing
vulnerabilities by specifying more concrete requirements. We plan to perform
industrial case studies with the security model in order to explore the bene ts
and limitations of the approach. Finally, the UMD by Donzelli and Basili [