A New Quantitative Model for Web Service Security

Omid Banaei and Siavash Khorsandi Computer Engineering and Information Technology department

Amirkabir University of Technology (Tehran Polytechnic){omid.banaei, khorsandi}@aut.ac.ir

Abstract—Security is one of important QoS properties of web services that need to be quantified. Quantifying Security can help both in selecting among published web services and also in assessing security weaknesses of services by service providers. In this paper we propose a three level hierarchical architecture for web service security. In this architecture we consider all of important aspects of security that they are: authentication, integrity, authorization, confidentiality, availability and non-repudiation. For each aspect is considered the most important web service threats. Furthermore we consider likelihood and impact factor for each threat. Then we compute weight of each impact with using AHP and finally total security index is computed with weighted averaging.

Keywords-component; Security; Web Service;SOA; Risk Analysis

I. INTRODUCTION

According to World Wide Web Consortium (W3C) definition, a web service is “a software application identified by a URI, whose interface and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols” [1].

Web Services are self-description, platform independent and use open standards so different parties can communicate and work with each other easily. These features cause industry increasingly pay attention to this technology. With increasing web services usage, more and more threats and vulnerabilities are discovered. Attackers identify web service vulnerabilities and use them to penetrate system. Attackers steal sensitive consumer’s information and reduce his privacy [2]. In addition attacks can impact provider’s reputation and reduce consumer trust to provider.

Security assessment identifies service vulnerabilities and security state of system. Accurate security assessment leads provider to a set of vulnerable points of system that need improve. Hence providers can use proper technologies, standards and procedures to improve their security state, fit consumer requirements and build consumer trust for using their services [3].

With increases in web service publishing, there are many web services with same functionality in the web and consumer should select between them so needs non-functional requirements to select best web service that match his requirements. Consumer should compare web service based on

non-functional requirements and most of comparing algorithms use quantitative values, so quantitative values are needed. Also Quantitative values are more understandable for human and consumer can sense better.

One of the important non-functional requirements is security, so assessing and quantifying web service security can help consumers compare and select best service that match their security requirement among web services with same functional requirement.

Problem of assessing and quantifying web service security is largely open and few researches are done about this issue [4]. One of the reasons is that systems and services become complex every day and they are composite of many components that each of them may be provided by different providers or are built by different developers [4]. Also service developers use different technologies that have different structure, therefore security assessment of them needs specific procedure and tool. The other reason is security is very application dependent. For example security requirements for a web service that is used in E-Banking are different from requirements for a web service that is used in IPTV.

S. V. Houmb et. al. [12] propose a qualitative analysis approach. They use a Bayesian Belief Network for determining components that contribute to return on security investment. For evaluating products, Common Criteria (CC) is a good method [13]. CC is a qualitative method that considers multiple security requirements and evaluates products according to these requirements. CC gives an Evaluation Assurance Level (EAL1-EAL7) to each product if product satisfies that level requirements.

Youxiang and Yang propose a quantitatively model [2]. They consider only confidentiality in their model but we consider all of security aspects in our model. They consider two types of vulnerabilities, application vulnerabilities that refer to vulnerabilities are related to application and exclusive vulnerabilities that are related to security mechanisms. They consider three web service threats but we consider top ten threats in our model and generalize our model to work with new discovered vulnerabilities. Ji and Pattinson [3] propose a structure for network and then quantify security of network based on this structure. They propose four parameters for threat likelihood.

In this paper we consider the most important security services: Authentication, Integrity, Authorization, Confidentiality, Availability and Non-Repudiation. We

___________________________________ 978-1-4673-2101-3/12/$31.00 ©2012 IEEE

propose a framework for assessing web service security. This framework considers top 10 web service security threats and their impacts on above security services. Also popular web service security scanners are introduced for discovering vulnerabilities.

The rest of paper structure is as follow: in section 2 the proposed structure for web service security structure is described. Likelihood parameters of threats are presented in section 3. Section 4 describes threat impacts on security aspects and section 5 introduces our model for computing total security of a service. Section 6 gives an example for better understanding our model followed by conclusion in section 7.

II. AN ARCHITECTURE FOR QUANTIFYING Computer security has three main aspects: confidentiality,

integrity and availability. Definitions of these aspects are different in any context that they are used. Their definitions depend on procedures, processes, individuals and laws of organization or context that they are used [5]. Web service security includes important concepts that should be considered when we want to assess it. Web service security concepts include [6]:

� Identification and Authentication: Authentication is the binding of an identity to a principal [5]. In other words authentication is the process of identifying some person or some things is that who claim. When an entity wants to access system resource, its identity should be verified.

� Authorization: Authorization is a process determines an entity have access to resources or not.

� Integrity: Integrity refers to trustworthiness of data and means data don’t alter and change in unauthorized way. Data change can be happen while processing, storing or transferring data in network.

� Non-repudiation: Means that sender cannot deny sending after process ends. For example a consumer sends an order to one store and then seller sends him desired product but sender denies and claims he doesn’t send any invoice.

� Confidentiality: Means concealment and hiding information and other part of system. [5] In other words considering access restrictions for preventing unauthorized access to information and supplying privacy.

� Availability: Availability means system is useable and accessible when an authorized entity requests, according to the performance specification is defined for system. In other words an available system provides service according to system design when

client requests desired service. [7] Availability is very important because impacts on person trust to system, in other words an unavailable service is similar no service exist.

If an assessment model wants to be comprehensive and presents accurate security state of system, should consider all of security aspects. All of security aspects are considered in this paper to cover all of security requirements that should be considered in web services and fit client security requirements.

In this paper we consider top 10 threats that are more specific for web application and web services, based on OWASP Top 10 project. Open Web Application Security Project (OWASP) is an open community that works on web application and web service security. It gives open and free application security tools, standards, standard security controls, libraries and other materials related to web application security. OWASP has an OWASP Top 10 Project that identifies the most critical web application threats facing organizations.

As is discussed before, we consider a structure that covers all of web service security related concepts and risks. This structure illustrated in Fig. 1.

As presented in Fig. 1, we consider a three levels structure. In top level there is total security of web service. Six aspects of web service security are placed in level two. Every threat harms security aspects in a different way, for example Cross-site Scripting (XSS) maybe has more effect on availability than integrity. So we consider web service threats in level three for every security aspect distinctly. Web service threats can be identified by reviewing application by technical experts, also threats and vulnerabilities can be discovered by scanning tools such as Acunetix, Nessus and other popular scanning tools. We consider 10 threats [8]: Injection, Cross-Site Scripting (XSS), Broken Authentication and Session Management, Insecure Direct Object References, Cross-Site Request Forgery (CSRF), Security Misconfiguration, Insecure Cryptographic Storage, Failure to Restrict URL Access, Insufficient Transport Layer Protection and Unvalidated Redirects and Forwards.

Above threats are considered because they are popular web service threats based on OWASP studies but our model is general and not limited to these threats. If a new threat is discovered in service, simply can add it to above structure and give value to its parameters according to methods that are described in later sections and then compute its impacts on service security.

III. WEB SERVICE THREAT LIKELIHOOD For assessing security should consider threat likelihood and

its impacts. In this section we define threat likelihood parameters and in the next section present impact factors. Threat likelihood means how much possible an attack occur successfully.

Security

Authentication Integrity Confidentiality Availability Non-

repudiation Authorization

OWASP Top 10 Threats

OWASP Top 10 Threats

OWASP Top 10 Threats

OWASP Top 10 Threats

OWASP Top 10 Threats

OWASP Top 10 Threats

Security Aspects

Web Service Threats

Possibility of attack occurrence depends on multiple factors. In [2], [3], [4] and [9] multiple likelihood’s parameters are proposed. Some of the proposed parameters are general and related to network security, some of them have similar definition or have overlap. We customize and redefine them for web service. These parameters are:

� Known degree: This parameter defines how a threat is prevalent and is used by other attackers.

� Attack Convenience: How easy it is to use a vulnerability or threat for attacking a web service. Is there an automated tool for attacking?

� Discovery Convenience: How easy it is to discover a threat. For discovering some threats only need to review web service architecture design, some threats need to review code and for some others should review service components and technologies deeply. Also some threat can be discovered by automated scanning and penetration tools. So if discovering threat is easy, attack possibility increases.

� Detection Difficulty: This parameter defines how difficult it is to detect an attack. Some attacks can be detected by using a simple intrusion detection system but detection of some attacks needs review logs and data traffic deeply.

� Attackers Size: How many people can use the threat for attacking to service, only administrator, service developers, internal users, external authorized users or every general person on internet.

� Damage Volume: This parameter is common between most of risk assessment methods. It describes how harmfulness does a threat have or what is scope of threat effect. Some threats can impact on specific web service component and some others can harm whole service and completely destroy it.

� Re-distributability: How easy it is to repeat attack or redistribute it. Usually attackers are interested in using attacks that can be redistributed easily, for harming system more and gaining more resources. We can

conclude if an attack is more repeatable and redistributable, likelihood of it is more.

� Technical Easy: How technically it is easy to do an attack. This means which technical skill level is needed to perform attack. Attacks are technically easy having more possibility and their threat likelihood is more.

� Attack benefits: This means how much more valuable resources or information gain from attack. If information and resources gain from attack are more valuable, attackers are more interested in using that attack.

� Required Resources: How much resource or access does attacker need for discovering and exploiting threat?

We give values between 1 and 9 to likelihood parameters. For combining these parameters values and calculating likelihood of a threat, in [4] authors use normalized average. They sum parameters’ value and then divide it to sum of likelihood parameters of all threats. In OWASP risk rating methodology [9] authors use simple average. They use three levels (High, Medium and low) for describing threat risk. Using simple average means all of parameters have the same weight and no one has priority to others. This method is not suitable for Service Oriented Architecture (SOA) because in SOA there are very different web services that have different technologies. We use weighted average method for calculating threat likelihood. Weight values are between 0 and 1. Likelihood of a threat can be computed as below:

Threat likelihood (Li) = ∑ (Likelihood parameter * Parameter Weight) (1)

In section 7 is presented an example for better understanding this equation. In next section we describe threat impacts on security parameters and then use it for calculating total security value.

IV. THREAT IMPACTS Treats impact on six aspects of security and totally reduce

service security. Effects of threats on these security aspects are

Figure 1. Web Service Security Quantifying Structure

different in every service and depend on service usage. Also based on technologies and standards are used in services, threat impacts on security aspects are different. For example if a web service uses strong access control mechanisms but uses weak cryptographic algorithm, XSS can affect more on integrity than authorization. Therefore computing threat impacts needs to know service usage, architecture, technologies and standards are used to develop service.

We survey multiple methodologies for classifying threats such as Microsoft methodologies for web service and web application threats (DREAD and STRIDE) [10], OWASP risk rating methodology and Common Vulnerability Scoring System (CVSS). According to guides and methods they recommend, we derive threat impacts on each security aspect and give them a number between 1 and 9. Table I show threats and their impact value on each security aspect.

This table is derived based on our studies and experience; it can be different for different web service environments. Organization’s security analysts can give value to threat impacts distinctly based on their knowledge about service usage and its developing technologies. After giving value, they can calculate their service security index based on general model that is proposed in next section.

V. CALCULATING TOTAL SECURITY INDEX After calculating threat likelihood and impact, we should

aggregate these values and calculate total security index of web service. We use Analytic Hierarchy Process (AHP) [13] for calculating total security index.

AHP is a popular algorithm that is useful for making multi-criteria decisions involving benefits, opportunities, costs, and risks [13]. AHP is applicable for complex problems. It has 3 steps. First it breaks down problem into multiple sub-problems and constructs a hierarchy of sub-problems. Second it

determines priority of elements. It constructs a matrix and puts all of elements in it and then gives values between 1 and 9 to them. If element A is completely important than element B it gives 9. Subsequently element B is low important than A and gives 1/9. This pairwise comparison should be done for all of elements in current level until matrix is completed. Third, computes element weight with (2) based on values of priority matrix that is constructed in before step [3]:

(2)

As is discussed in section 3, we break down our problem into three levels. In level 3 in the below of every aspect we have threats. According to AHP method, first we should determine priority of threats, for example priority of injection threat relative to XSS in authentication aspect or priority of CSRF relative to injection in integrity aspect. Therefore we construct a matrix for every security aspect (totally 6 matrixes), put threats in columns and rows and determine priority of them in that aspect. One of the problems in related works [2][3] is they don’t propose priority criteria, in other words they don’t say how to determine priorities or weights. For determining threat priorities, we consider their impact on security aspects. Priority is computed as below:

(3)

Where is impact difference of threat i and threat j on security aspect n, Iin is impact of threat i on security aspect n and

y is priority of threat i relative to threat j below the

security aspect n.

Threats Name Web Service Security Aspects

Authentication Integrity Authorization Confidentiality Availability Non-repudiation

Injection 9 7 7 9 7 9 Cross-Site Scripting

(XSS) 9 5 9 9 4 7

Broken Authentication and Session Management 9 9 9 9 7 7

Insecure Direct Object References 1 7 9 7 5 1

Cross-Site Request Forgery (CSRF) 5 3 9 3 3 9

Security Misconfiguration 1 5 9 7 7 7

Insecure Cryptographic Storage 1 9 9 9 5 1

Failure to Restrict URL Access 1 3 9 7 3 1

Insufficient Transport Layer Protection 1 5 1 9 5 3

Unvalidated Redirects and Forwards 7 1 5 7 3 3

TABLE I. A SAMPLE QUANTIFICATION OF THREATS IMPACTS

Second we should compute threat weight wi based on (2). Third security risk for every security aspects computed with (4):

(4)

Where Lii is likelihood of threat i (Section 4), is impact of threat i on security aspect n (Table I) and is weight of threat i below the security aspect n (is computed with formula 3 and 2).

Until now, we compute security risk for every security aspects. Based on AHP method, for computing total security risk in our hierarchical structure (Fig. 1), we should compute weight of every security aspect (Level 2) and then calculate total security risk (Level 1) based on these weights.

Parameter Name Value Description Weight

Known degree 9 Well known threat 0.05

Attack Convenience 6 Nearly convenient attack 0.2

Discovery Convenience 7 Discovery of threat is nearly easy 0.15

Detection Difficulty 3 Attack detection is nearly hard 0.05

Attackers Size 9 Whole persons can use this attack 0.05

Damage Volume 4 Damage size of attack is nearly medium 0.15

Re-distributability 2 Attack cannot be redistribute easily 0.05

Technical Easy 7 Attack don’t need technical skill 0.1

Attack benefits 5 Benefits of attack is medium 0.15

Required Resources 3 Resources are needed for attacking is nearly low. 0.05

Determining weights of security aspects is dependable to web service usage, provider or consumer security requirements. For example for a general web service that computes and shows weather, availability is very important but confidentiality has low importance but for a web service that is encrypting data, integrity and confidentiality is more important than availability. In addition to service usage, consumer security requirements are different for example one consumer prefers his desired service has more confidentiality than availability and other consumer prefers non-repudiation than availability. So when a service provider want evaluate security of his service, should consider his service usage and his security requirements also when a consumer wants to assess security of service and select between many available web services in the world, should consider his security preferences and his usage and then determine security aspects weight. After determining security aspect weight, total security risk is calculated by (5).

(5)

Where SRAi is security risk of aspect i, for example security risk of authentication and Wi is weight of security aspect i. We give an example in next section for illustrating our model.

VI. EXAMPLE Consider a web service that values and weights of its

likelihood parameters are presented in table II. For simplicity we suppose that values and weights of parameters for all 10 threats are the same. If this values is not the same so we should consider 10 tables similar to table II.

A. Compute Treat’s Likelihood Based on (1) and using parameter’s values cited in table II,

threat’s likelihood is calculated as below:

Lii = 9*0.05+6*0.2+7*0.15+3*0.05+9*0.05+4*0.15+ 2*0.05+7*0.1+5*0.15+3*0.05=5.6

Because we suppose that values and weight of likelihood parameters are the same for all ten threats, we have:

Lii = 5.6 , i = 1,…,10 (6)

B. Compute Threat Priority and Weight As is discussed before, for computing threat weight we

should construct priority matrixes and determine threat priority. Suppose that we want to determine threats priorities below the availability aspect. Availability is fifth aspect in table I, so n is equal to 5 (n=5). For example for injection and CSRF threats, injection is first threat in table I so i=1 and CSRF is fifth threat so j=5. According to (3) we have:

(7)

(8)

This means that priority of injection relative to CSRF below the availability is 5 and priority of CSRF relative to injection is 1/5. We compute priorities similarly for all of ten threats. Table III shows all of threats priorities for availability aspect.

Similarly, should construct 5 other matrixes for other security aspects and determine threats priorities. After determining priorities, should compute threat weight. For computing threat weight below availability, put values of table III in (2) and compute ten weights for ten corresponding threats. Computed weights are presented in last column of table III.

C. Compute Security Risk of Aspects (SRAi) Now we have all of parameters are needed to compute

security risk of six web service security aspects. For computing security risk of availability (n=5) we have:

(9)

TABLE II. A SAMPLE SCENARIO OF LIKELIHOOD PARAMETERS AND WEIGHTS

Where Lii = 5.6 for i = 1,…,10 , values of are cited in column 5 of table I and values of are cited in last column of table III. Similarly compute SRA for other security aspects.

D. Compute Total Security Risk Finally we should compute total security risk (top level in

Fig. 1) based on values of SRA and security aspect weight. Suppose that weights of security aspects based on user security requirements are similar to table IV.

According to (5) we have:

(10)

Where values of SRAi are computed in before section and values of Wi are cited in table IV.

VII. CONCLUSION In this paper we propose a hierarchical structure for web

service security and present a model that compute step by step security state of web service. We consider all of security aspects and using weighted averaging and AHP Theory for prioritizing security requirements. We use weighted averaging

in all levels of our model to adapt with provider/consumer requirements.

REFERENCES [1] C. Ferris, A. Barbir, S. Garg, and D. Austin. Web services architecture

requirements.W3C note, W3C, Feb 2004. http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211 -last accessed April, 2011.

[2] D. Youxiang and G. Yang, “Evaluating vulnerabilities quantitatively based on the rank of web services confidentiality,” Journal of Next Generation Information Technology, vol. 2, no. 1, 2011.

[3] X. Ji and C. Pattinson, “AHP Implemented security assessment and security weight verification,” 2010 IEEE Second International Conference on Social Computing (SocialCom), pp. 1026–1031, 2010.

[4] A. Yautsiukhin, R. Scandariato, T. Heyman, F. Massacci, and W. Joosen, “Towards a quantitative assessment of security in software architectures,” in 13th Nordic Workshop on Secure IT Systems, Copenhagen, Denmark, vol. 26, 2008.

[5] M. S. Ahmed, E. Al-Shaer, and L. Khan, “A novel quantitative approach for measuring network security,” the 27th Conference on Computer Communications. IEEE, pp. 1957–1965, 2008.

[6] Improving Web Application Security: Threats and Countermeasures. Available via http://msdn.microsoft.com/en-us/library/ms994921.aspx, June 2003.

Injection Cross-Site Scripting

(XSS)

Broken Authentication

and Session Management

Insecure Direct Object

References

Cross-Site Request Forgery (CSRF)

Security Misconfigur

ation

Insecure Cryptographic Storage

Failure to Restrict

URL Access

Insufficient Transport

Layer Protection

Unvalidated Redirects

and Forwards

Weight

Injection 1 4 1 3 5 1 3 5 3 5 0.19

Cross-Site Scripting

(XSS) 1/4 1 1/4 1/2 2 1/4 1/2 2 1/2 2 0.06

Broken Authenticati

on and Session

Management

1 4 1 3 5 1 3 5 3 5 0.19

Insecure Direct Object

References

1/3 2 1/3 1 3 1/3 1 3 1 3 0.09

Cross-Site Request Forgery (CSRF)

1/5 1/2 1/5 1/3 1 1/5 1/3 1 1/3 1 0.03

Security Misconfigur

ation 1 4 1 3 5 1 3 5 3 5 0.19

Insecure Cryptograph

ic Storage 1/3 2 1/3 1 3 1/3 1 3 1 3 0.10

Failure to Restrict

URL Access 1/5 1/2 1/5 1/3 1 1/5 1/3 1 1/3 1 0.03

Insufficient Transport

Layer Protection

1/3 2 1/3 1 3 1/3 1 3 1 3 0.09

Unvalidated Redirects

and Forwards

1/5 1/2 1/5 1/3 1 1/5 1/3 1 1/3 1 0.03

TABLE III. THREATS’ PRIORITIES AND WEIGHTS FOR AVAILABILITY

[7] M. A. Bishop, The art and science of computer security. Boston, MA, USA: Addison-Wesley Longman Publishing Co., 2002.

[8] A. Singhal, T. Winograd, and K. Scarfone, “Guide to secure web services,” NIST Special Publication, vol. 800, no. 95, p. 4, 2007.

[9] OWASP Top 10 project. available via https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.

[10] OWASP risk rating methodology. available via https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology.

[11] T. L. Saaty, “Analytic hierarchy process,” in Encyclopedia of Biostatistics, John Wiley & Sons, Ltd, 2005.

[12] S. H. Houmb et. al. “Cost-benefit trade-off analysis using bbn for aspect-oriented risk-driven development”. In Proc. of ICEECS, IEEE, 2005.

[13] International Organization for Standardization (ISO/IEC). Common Criteria for Information Technology Security Evaluation. Common Criteria Project Sponsoring Organisations, 2.2 edition, January 2004.

Web Service Security Aspects

Authentication Integrity Authorization Confidentiality Availability Non-repudiation

Weight 0.2 0.15 0.15 0.3 0.1 0.1

TABLE IV. THREATS’ PRIORITIES AND WEIGHTS FOR AVAILABILITY