5.2.2.4 Threat Risk Quantification
A threat list can be obtained by using the proposed threat elicitation method. Threats should be quantified in order to perform a comprehensive risk assessment for the target
system. In this case, DREAD [139] is used to rate the security risk for each threat. DREAD is part of a system for classifying computer security threats used at Microsoft. DREAD is a scheme used at Microsoft for classifying security threats. DREAD is an acronym for a set of principles that can used to estimate the overall risk for a given application. DREAD stands for:
• Damage Potential: what are the amount of potential damage caused by a successful attack
• Reproducibility: how easily the attack can be performed and repeated
• Exploitability: what are the skill level and resources required to perform the attack successfully
• Affected Users: how many users are affected if the attack is successfully executed
• Discoverability: how quickly and easily an occurrence of an attack can be identified
DREAD use numeric scheme to represent the serious level of each category. The calculation always generates a number between 0 and 10, the greater the number, the more serious the risk. Here is a use case [139] of how to quantify the DREAD categories in this study.
Table 5-8 DREAD Use Cases [139]
Category Use Cases Value
Damage potential Leaking trivial information 0
Individual user data is compromised or affected 5
Complete system or data destruction 10
Reproducibility Very difficult to reproduce 0
One or two steps required 5
Just a web browser, without authentication 10
Malware or attack tool available 5
Novice programmer 10
Affected users None 0
Some users 5
All users 10
Discoverability Unlikely 0
Accessible only to few users 5
Published 10
5.2.3 Vulnerability Analysis
Once the potential threats are identified, a vulnerability analysis is performed to show what weaknesses exist in the system that may be exploited by the threat. The vulnerability analysis considers how to identify vulnerabilities and their potential impact of loss from a successful attack.
Existing vulnerability identification tools for application can be used to perform vulnerability identification and calculation of the severity scale produced. Vulnerability analysis aims at discovering the vulnerabilities within the application assets rather than data asset.
In this thesis, a vulnerability scanner for web application named N-Stalker [132] is chosen as the sample toolkit. N-Stalker provides a free edition to enhance the overall security level of web applications, using the most complete web attack signature database “N-Strealth Web Attack Signature Database”.
Common Vulnerability Scoring System (CVSS) [116] is one of the frequently used vulnerability scoring systems providing free and open standard quantification approach for scoring the severity of vulnerability and facilitates to determine the priority and urgency of response. The vulnerabilities identified by the N-Stalker will then be evaluated using CVSS. A total score of the vulnerabilities in the application can be produced. The scores are generated from a serious of metrics based on expert measurement involving base metric, temporal metric and environmental metric. For
each of metric, the score ranges from 0 to 10 which means that vulnerabilities with a base score in the range 7.0-10.0 are critical, those in the range 4.0-6.9 as major, and 0-3.9 as minor [116].
5.2.4 An Example
In order to illustrate the usefulness of web application classification, this section will examine a case study used in [152]. The case study is described as: “Widgets Incorporated is a medium-sized consumer goods company. They have determined the need to create I-Tracker: a custom-built inventory tracking application to facilitate growing customer demand. The most common use case will be for sales staff to enter data from a sales order which will automatically update the inventory levels and alert the logistics staff to prepare the order for shipment. When the inventory level for a particular widget drops below a certain threshold the manufacturing division will be notified. The main types of data used in the application include inventory levels, customer IDs, sales orders numbers, descriptions of orders, and product IDs. I-Tracker will be used by 30 internal users spread across the manufacturing, sales, and logistics departments, and that number is anticipated to grow to as much as 100 in the next few years. The business has indicated that the application may need to interface with a partner Widget Accessory supplier in the future. Widgets Incorporated currently receive 50-60 orders per day and anticipates that number grow to around 150.[152]”
According to the description of I-Tracker, data flow diagram can be drawn and shown in Figure 5-7.
Sales Order Order Processing
Sales Staff Update Inventory Data Alert
Logistical Staff Prepare Order Logistical Staff Notify Manufacturing Division Product Data Customer Data
Figure 5-7 Data Flow Diagram of the I-Tracker Phase1. Architecture and Environment Analysis
From the case description, the example web application is used within internal environment facing a number of known users. Thus, it belongs to the first type of web application categories.
Phase2. Asset analysis
Based on the description of section 5.2.1, assets can be identified as data store, data flow and processes. Process is the dynamic execution of application, while data flow is the dynamic representation of a “flow” of data in the system.
Table 5-9 Asset Criticality Analysis
ID Asset Name Type Sensitive Environment Criticality Rating
1 Customer data Internal Data Yes Internal use Medium 5
2 Sales order Sensitive Data Yes Internal use Medium 5
3 Inventory data Public Data No Internal use Very Low 1
4 Product data Public Data No Internal use Very Low 1
5 Order
processing
Sensitive process Yes Internal use Medium 5
6 Order updating Sensitive process Yes Internal use Medium 5
7 Logistics staff alerting
Non-sensitive process
No Internal use Very Low 1
8 Inventory level notifying
Non-sensitive process
No Internal use Very Low 1
9 Preparing order Non-sensitive process
No Internal use Very Low 1
Phase3. Threat analysis Step1: Threat identification
1. Security requirement rating. It is necessary to rate the security requirements CIAA
of target application when using the proposed EDTEM. Using internal guidelines based on documents such as [30], the following application classification may be produced:
• Confidentiality: Low
All data in the application is readily available to anyone in the company. Sensitive financial data and client private information are not handled by this application.
• Integrity: High
Poor inventory and shipping tracking may result in significant financial loss to the company and may result in customer dissatisfaction / loss of customers.
• Availability: Medium
A major disruption of the application will cause a backlog in shipping and have some financial consequences to the organisation. Minor disruptions, however, can be tolerated as customers expect a 4-6 week delay in receiving their goods.
• Accountability: Low
Data processed in the system are not sensitive or personal. For the consideration of budget and time, system accountability is not included in the system design.
2. Filtering. According to the EDTED described in the previous section, the most likely
threats are filtered and listed in Table 5-10.
Table 5-10 Threat List after Filtering
ID Threat Name CIA
6 Viruses, Trojan horses, and Worms CIA
9 Denial of Service A
11 Unauthorised Access CI
20 Credential Theft CI
21 Elevation of Privilege CI
23 Data Tampering I
35 Man in the Middle CI
perform the attacks.
3. Further Filtering. The threat list can be further screened out according to the security
requirements of CIAA aspects. In terms of the EDTEM algorithm, threats with Confidentiality (C) and Accountability (Ac) requirements can be rule out in that the given application has low level requirements, while threats with Integrity (I) and Availability (A) are remained.
Step2: Threat quantification
DREAD is used to quantify the security level for each threat identified from our EDTEM according to the rating value in Table 5-9.
Table 5-11 Threat Risk Quantification
ID Threat Name D R E A D Total
6 Viruses, Trojan horses, and Worms 10 10 10 10 10 10
9 Denial of Service 10 5 5 10 0 6
11 Unauthorised Access 5 5 5 5 0 4
20 Credential Theft 10 0 5 5 5 5
21 Elevation of Privilege 5 5 0 5 0 3
23 Data Tampering 10 5 5 5 5 6
35 Man in the Middle 5 5 5 5 5 5
Phase4: Vulnerability analysis
Using the vulnerability scanning tools, vulnerabilities can be identified and quantified with an overall evaluation number between 1 and 10 by using CVSS.
Phase5: Potential risk
From previous steps, the average score for asset and threat is 2.78 and 5.5 respectively. Suppose the vulnerability score of target application is 3 for simplicity.
According to Formula 5, security vector of the target application SV=
(
)
3 V T A2 + 2 + 2 =(
)
3 3 5.5 78 .shown in Table 5-12, it can be concluded that the security risk of target web application is low.
Table 5-12 Risk Rating Scale
Value Treat Severity Rank
0.0-1.99 Very low 1 2.0-3.99 Low 2 4.0-5.99 Medium 3 6.0-7.99 High 4 8.0-10.0 Very high 5
5.3 Security Evaluation
Each security attribute requires one or more trusted mechanisms that are implemented in software components [170]. Security mechanisms mitigate the threats posed by exploiting vulnerabilities. As shown in Figure 5-8, a security evaluation method is proposed to assess whether the built-in security mechanisms in the legacy system satisfy the security requirements when facing elicited threats, which results in a decision whether the legacy system needs to be evolved to satisfy the user’s security needs.
Let’s consider the security mechanisms provided in I-Tracker case study in Section 5.2.4. Suppose the security mechanisms provided in I-Tracker are similar to those of the case study described in Section 4.6.4, Table 5-13 lists the result of security evaluation.
Table 5-13 Security Evaluation for I-Tracker
Security Objectives Security Threats Security Mechanisms
CIAA Requirements
Threat ID
Threat Name CIAA Risk level
(0--10) Detected Security Mechanisms Security level Confidentiality(C): Low Integrity(I): High Availability(A): Medium Accountability(Ac): Low T6 Viruses, Trojan horses, and Worms
CIA Very High
(10) T9 Denial of Service A High (6) T11 Unauthorised Access CI Medium (4) Username and password Low T20 Credential Theft CI Medium (5) Well-proven encryption algorithms with enough encryption key High T21 Elevation of Privilege CI Low (3)
Group grants Low
T23 Data Tampering I Medium (6) Well-proven encryption algorithms High T35 Man in the Middle CI Medium (5) Well-proven encryption algorithms High
5.4 Security Requirements Elicitation
Security requirements represent the types and levels when attempts to protect the assets to meet security policy [98]. A complete and consistent group of security requirements can be produced by using an elicitation method. Specially, security requirements are identified by risk analysis—“the systematic use of information to identify sources and to estimate the risk” [80]. As discussed in the previous section of this chapter, threat identification is one of the key parts during performing the risk analysis. Shown as Figure 5-9, threat modelling is one of the effective methods to elicit security requirements which can figure out the threats to the application security at the early stage. Security requirement elicitation for web application is proposed in the previous section due to its representativeness and complexity.
Figure 5-9 System Security Engineering [129]
Usually most functional requirements are specified as what must happen, while security requirements are stated in terms of what must not be allowed to happen. After the risk analysis in the previous section, assets can be enumerated with criticality level, threats threatening the assets can be elicited with severity risk level, security features that would be violated by potential threats on assets can be analysed, and priority level representing the developing order of the security requirements can be computed.
In this thesis, security requirements are elicited by risk analysis and represented as a list with columns of asset, threat, security features and priority, which means, for a given asset, the threats threatening to it and the severity level the threats may cause to the asset. It can be used as the priority order of security requirements when system
designers develop security aspects to satisfy them. Table 5-14 shows an example of security requirement format in this thesis.
Table 5-14 Example of Security Requirements
SR No. Asset Threat CIAA Priority
SR1 User bank
account
Sniffing Confidential High
SR2 User account Cross-site Scripting Confidential High
SR3 Place order User Denies Performing an
Operation
Accountability Low
SR4 Display
product
Denial of Service Availability Medium
SR5 Product
Catalogue
Data tampering Integrity Medium
5.5 Summary
Identification and evaluation of threat and assets are of great significance during security evolution. Identifying threats tells the security engineers how many and what kind of threats threatening the system, while evaluation shows to what extent the threats may do harm to the assets. By identifying and evaluating key threats and assets of the target system, it provides the detailed security requirements specifying which asset facing what kind of threats and resulting in what degree of the security risk to the system.
In order to identify and assess the risks the legacy system faced and the security mechanisms built in in a legacy system, this chapter proposed an assessment approach to evaluate the security risks level of the legacy system. The contents covered in this chapter are concluded as follows:
• For security requirements elicitation, a risk assessment framework based on security vector <threat, asset, vulnerability> is proposed as the means to evaluate the risk level a legacy system faced.
• A method to web application classification is proposed as the foundation to modelling threat for web applications. The environment where the web applications host is taken into account.
• Threat modelling is the most important part during the security requirement elicitation. A threat elicitation method is presented based on the proposed environment web application classification, which is a light weight and easy to use especially for security novice users.
• Security evaluation for legacy system is the prerequisite for security-driven software evolution. With the detection of security implementation in the legacy system and the security objective from the users, the system designers can make the decision whether or not the current security implementation satisfies the security requirement and whether or not the security evolution is required.
Chapter 6
Security Enhancement in Evolution
Objectives
__________________________________________________________________
To illustrate the framework for security enhancement in evolution To illustrate the method to organise the security patterns
To define mechanisms to automate search security patterns to fulfil the security requirements
To illustrate the integration of security patterns with the system models
__________________________________________________________________
6.1 Overview
Experience shows that it is difficult to design a system that can fulfil the specific security requirements by simply integrating security mechanism and be error free at the same time, even for a small system. Security expertise tends to be valuable in such circumstances. However, such security expert knowledge is not always available for ordinary software developers. What’s more, with the systems are getting larger and complicated, which makes the situation getting worse.
Inspired by design patterns, security patterns incorporate security expertise to solve the security problems occurred in the specific contexts. For security novice, security patterns represent security best practices which are a convenient way to design secure and reusable software systems [150]. They document basic mechanisms, process or approaches which provide ways to safeguard CIA features of data [151].
In this thesis, the security problems of legacy system are addressed through the use of security patterns. Patterns are well-known solutions to common problems in the given
contexts. Pattern writers have introduced many collections of security patterns recently (see the Chapter 2 “related work on Security Pattern”). However, there are some features missing which impedes the benefit of taking advantage of security patterns. One of the most fundamental features is how to find the appropriate from the existing security pattern to solve the given security problems.
It is not possible to get right and meaningful answers automatically because of no syntax defined in security patterns [150]. Therefore, a framework for semantic description and management of security patterns by the light of defining proper security ontology is developed in this chapter. The fundamental idea is to ease the searching of “right” security patterns with the help of ontology technique. Security patterns can be descibed based on the proposed security core ontology which describes security patterns semantically and precisely. Therefore, sophisticated retrieval and search of security patterns are enabled.
6.2 Framework of the Security Enhanced Approach
In this section, an overview of the proposed security enhancement framework is shown in Figure 6-1. All activities in the framework form the following sections of this chapter. The input of the security enhanced approach includes system design model extracted from Chapter 4, security requirments conceptual model derived from Chapter 5 and existing security patterns. The outputs of the proposed approach are security enhanced design models which can be further transformed into code by using MDA automation tools.
Figure 6-1 Operational Framework for Chapter 6
solutions for various environments. The descriptions of security pattern include abstraction level, type of solution, applicability, context conditions and security properties provided by the pattern. A series semantic properties is defined to each pattern, such as “security attribute: Confidentiality”, “Deployed in design phase” …and so on. The incorporation of precise and rich semantic descriptions of the security patterns enables the use of automated reasoning mechanisms capable of searching proper patterns to fulfil the given security requirement.
In order to achieve this goal, a security ontology is developed and stored as one part of security knowledge base together with security pattern organised as the other one. Figure 6-2 shows the structure of the proposed security knowledge base. A pattern search engine is designed to find the right security pattern with the proposed security ontology inference to satisfy the corresponding security requirements.
Security Knowledge Base
Security Ontology
Security Solution
Context Security Problem
Asset Threat Security Attribute Priority
Security Requirement Ontology Security Pattern Ontology
Pattern Level Pattern Element Level
Security Pattern Pattern Relationship
Security Pattern Base
Security Pattern 1 *
* *
Figure 6-2 Class Diagram for the Security Knowledge Base Meta-model
Basically, Figure 6-2 shows that the structure of the security knowledge base is similar to a tree structure for storing security related information that helps to reveal and organise the security relevant features, and for relating these properties to fundamental security requirements. It consists of two sub repositories, security ontology base and security pattern base. Security ontology base is used to store the established ontology including concepts and relationships while security pattern base is the repository to store
and organise the common security patterns for further processing. Considering the reusability of the stored security relevant information, the information is expressed in a generalised way and focuses on abstract level.
It is impossible to develop a completely secure system because of the cost, time, and resources needed for the development and the emerging new kinds of attacks, even if it could be done, the usability and efficiency of the developed system may be decreased. Thus, developing secure systems is about trade-offs and it is quite a challenge to find a balance point. Prioritising of each elicited security requirement and incorporating user’s security objectives play a key role when facing such a dilemma.
The criticality of each asset has to be decided, which implies a criterion for the security threshold of an asset is decided according to not only the value impact but also the risk for the asset, including likelihood and impact. Therefore, analysing the threat and