Web services security policy assertion trade-offs

Tristan Lavarack1 and Marijke Coetzee2 Academy of Computer Science and Software Engineering

University of Johannesburg Gauteng, South Africa

tlavarack@gmail.com1, marijkec@uj.ac.za2

Abstract— Web services security requirements and capabilities are described in security policies. To enable the seamless interoperation between services, security policy intersection aims to provide a security policy that will satisfy both the service provider and consumer. Not only are there numerous problems with this approach, but is it also difficult for administrators to evaluate the resultant security level supported by such a policy. In contrast to this approach, security policy trade-off analysis can allow parties to make compromises to accommodate each other, while still achieving a satisfactory security level. This paper focuses on modeling the decisions and compromises to be made by web services providers or consumers to be able to interact with each other securely. The security policy support system built to model this problem employs domain vocabularies, fuzzy techniques and domain-specific preferences.

Keywords: Policy Intersection; Policy Compatibility; WS-Policy; WS-SecurityPolicy; FCM

I. INTRODUCTION Web services technology is enabling the integration of IT

systems across organisational barriers where specialised services and resources interact continuously. As such environments have high requirements for security, a first policy usually defined by a web services provider or consumer is the security policy. As more and more policies are attached to service consumers and providers, the compatibility of security policies is vital to address.

Currently, WS-Policy [1] and related WS-SecurityPolicy [2] specifications determine policy compatibility by using policy intersection. The result of policy intersection may produce a policy containing duplicate occurrences of assertions and contradictory assertions. Mechanisms are needed to enable tradeoffs between the security policy assertions to enable interaction where domain knowledge is required to find a mutually acceptable security policy. To assist administrators, automated decision-support mechanisms need to be employed to understand the impact of choosing specific policy assertion above another and at the same time ensuring that the security goal of the environment is not compromised. In the end, security is about balancing trade-offs among competing security policy assertions to achieve “good enough” security [3] [4].

This paper presents a new approach to making web services security policy assertion trade-offs by addressing the interdependence between security mechanisms and other influences. Security policy trade-offs imply that certain

security requirements are relaxed, and at the same time others increased, while still maintaining a satisfactory overall security goal. To enable the evaluation, each security requirement is assigned a value relative to others. The security policy support tool is run several times with varying values to map out alternate choices and trade-offs that can be made.

In the next section, the current weaknesses of WS-Policy for automated policy assertion selection are discussed. A motivating example is introduced, and a security policy support framework, based on Fuzzy Cognitive Maps (FCMs) is proposed. Experimentation with a scenario indicates that the framework is promising to create a web services security contract. Finally, the paper is concluded.

II. BACKGROUND The flexible syntax of the web services policy

framework [1] can lead to potentially complex policies. The basic unit of a policy is assertions that are identified by a Qualified Name (QName) such as TransportBinding. Assertions can be simple strings, or complex objects with many sub elements and attributes. Policy processing only considers the root XML element Qname. Each set of assertions is termed an alternative.

The process of policy intersection requires that security policies are expanded to normal form to be able to examine alternatives against each other one at a time. If the vocabularies indicated by the QNames do not match, alternatives are different and can be discarded. Alternatives with the same Qname could match any number of assertions with the same Qname from the second alternative. The result of policy intersection produces policies that are difficult to evaluate as resultant alternatives may contain duplicate occurrences of assertions, as well as contradictory assertions, mainly differing in terms of detail. For example, <nsSecurityAssertion level="high"/> has the same QName as <nsSecurityAssertion wsp:Optional=”true”> but their meaning is contradictory.

It is clear that WS-Policy intersection is solely focused on syntactic of alternatives and does not address the semantics of assertions, or their influences on each other [6]. The WS-Policy framework specification does not define how these combined alternatives are to be interpreted.

Domain-specific processing or manual inspection is required to determine which alternatives to use. There is currently no existing technique to assist administrators of

2011 Sixth International Conference on Availability, Reliability and Security

978-0-7695-4485-4/11 $26.00 © 2011 IEEE

DOI 10.1109/ARES.2011.80

535

service providers and consumers to come to an agreement on security policy alternatives, satisfying their security requirements.

In the next section a motivating example is given, highlighting some practical considerations that need to be addressed by security policy decisions.

III. MOTIVATING EXAMPLE Figure 1 gives the high-level security policy alternatives

of Provider P and Consumer C.

Figure 1. Security policies of a provider and consumer

If these security policies are intersected, a new security policy is created containing duplicates and inconsistencies. As the vocabulary of both policies match, the resultant policy contains encryption and hashing algorithms of different strengths, both types of authentication tokens and security bindings.

Administrator with little experience may have difficulty in creating a security contract that meets their security requirements. As security critical systems must perform at the required security level, administrators need to evaluate all possible alternatives to determine the best choices.

The interdependence between security mechanisms and how this will affect the strength of security supported by a new policy also needs to be considered. The operational security level provided by a security policy after a security policy is applied need to be evaluated to determine its effectiveness.

The next section defines a security policy support system that can be used to address some of these problems.

IV. SECURITY POLICY SUPPORT SYSTEM In order to address domain-specific security policy

processing to support trade-off decisions, a Security Policy Support System is defined, shown in Figure 2. Here, the case of a provider is highlighted. Policy communication [7] and some decision making is automated, but all policy trade-offs decisions are finalized by administrators. To be able to make trade-offs, a set of choices are provided by the UI (User interface) using the Policy Analyser with assistance of a Help Module. A number of screens

are presented to the administrator to follow and direct the process.

The security policy of a consumer is received, intercepted and evaluated by the Policy Interpreter and Policy Controller. To be able to make decisions that take into account all important issues and their influences, of which many only vague details are known, fuzzy techniques are used. When trade-off decisions are made, they are not made in isolation, therefore environmental influences are considered. The Policy Analyser intelligently processes the content of a security policy and updates nodes of the FCM (Fuzzy Cognitive Map) with fuzzified information using the Fuzzifier component. The FCM incorporates fuzzified inputs from the consumer security policy and the Trust Manager, Firewall, IDS (Intrusion Detection System) and Security metric Manager with a fuzzy rules database.

The main features of the security policy support system to be discussed next are security policy trade-off considerations.

A. Security policy trade-off considerations A large range of aspects need to be considered to be able

to make trade-offs between the security policy alternatives of consumers and providers. This research adopts the taxonomy of information security for service centric systems by Savolainen et al. [15] and other work [1, 2, 3, 5, 8, 12, 13] as a foundation for identifying the aspects to be considered by security policy trade-off analysis.

There are six aspects that are identified. The first 3 aspects consider the environment in which the security policy is used, and the last 3 consider the mechanisms specified in the security policy.

To understand the security provided by a security policy dictates a profound understanding of the complexities of the environment and their influences on each other. Trust, Security Solutions and Threat mechanisms are hidden from other parties and are specific to each environment. They influence the trade-offs that can be made directly. These mechanisms differ according to circumstances and preferences of each provider or consumer.

1)Trust is used to identify the extent to which the lack in security measures of the other party can be tolerated. The importance of trust has been recognized in several security requirements engineering methods [16]. The more participants trust each other, the less strict security requirements are likely to be [17]. A Trust Manager can provide a trust level for each consumer.

2)Security Solutions address means for preventing unwanted behaviour and development of a system and include features such as firewalls, proxy servers and intrusion prevention systems.

3)Security Threats define faults, errors and failures where failures are events that occurs when the delivered service differ from the correct service, errors are deviations in the external state of the system, internal faults are vulnerabilities and external faults are attacks [15]. They are

536

Figure 2. Security policy support system of a provider P

identified by mechanisms such as Intrusion Detection systems, vulnerability scanners, and error and fault reports.

When considering the mechanisms and services specified in the security policy of a domain, an analysis of WS-SecurityPolicy [2] reveals that there are 3 main security concepts supported namely Authentication, Confidentiality and Integrity, defined by a large variety of security mechanisms. In conjunction with each of these concepts, Security Metrics can be used to measure the strengths and weaknesses of related security mechanisms.

4) Integrity and 5)Confidentiality: WS-SecurityPolicy lists algorithm suites [2], which is a collection of cryptographic algorithms for performing operations such as signing, encryption, and generating message digests. The choice of algorithm has an influence on the strength of message security [8]. For example, the choice of digest influences the strength of integrity, and the choice of encryption algorithm has an influence on the strength of confidentiality. The strengths of encryption algorithms can be ordered from strongest to weakest.

6) Authentication: Authentication tokens range from a strong X509Token to weaker UsernameToken [2]. Stronger authentication supports better identification and trust in the other party.

In addition, the Security Binding supported by WS-SecurityPolicy affects the general level of message security and security context namely TransportBinding, AsymmetricBinding and SymmetricBinding. TransportBinding relies on security provided by

transport services such as HTTPS. By applying message protection at the SOAP encoding layer instead of at the transport layer, more flexible policies at finer level of granularity can be defined with AsymmetricBinding and SymmetricBinding for multi-tier architectures. Finally, additional features such as TimeStamps and MessageIDs can be used to further assist with non-repudiation and protect against replay attacks.

Administrators need to carefully evaluate chosen mechanisms and their combinations in order to determine the strength of security that is supported by a security policy.

These six aspects contribute to the Security Level, which defines the security goal the security policy and environment needs to maintain. The Security Level depicts the measure of security provided by a provider or consumer according to its security policy and its environment. The trade-off analysis focuses on the maintenance of a satisfactory Security Level when trade-offs are made between policy alternatives.

The Security Level is an aggregated value that is composed from a large variety of security concepts and their child nodes of both public and private nature. The Security Level is initially derived in a static manner during design time, and during run-time an operational Security Level is determined to continuously monitor the performance of security.

Next, the security policy evaluation process used by the security policy support system is discussed.

537

Figure 3. FCM with security policy concepts and their relationships

V. SECURITY POLICY EVALUATION AND TRADE-OFFS The six concepts defined are interrelated, with feedback

links that propagate influences to the Security Level or to each other. To be able to make trade-off decisions that take into account all concepts and their influences, a fuzzy cognitive map is now defined.

Fuzzy Cognitive Maps (FCM), introduced by Kosko [9], draws conclusions from ambiguous, imprecise or vague information. An FCM has a number of nodes representing concepts and weighted relationships between the concepts. A Fuzzy Cognitive Map consisting of n concepts is represented by a 1 × n state vector C, which gathers the values of the n concepts; and by an n × n edge matrix E, with elements eij.

To exploit knowledge and past experience of decision-making, this research uses an adaptation as suggested by Groumpos and Stylios [11] as follows.

Ci = f ( ∑=

n

j 1

Cj eij + γ Ci) where γ = 1 if C0 >0 (1)

In rule 1, the value of eij indicates how strongly concept Ci influences Cj. The coefficient γ represents the participation of the past decisions that are embodied by a concept in the calculation of the new value of a concept. Here, it is set to 1, if the initial state of a concept exists.

f is a threshold function that transforms the summation into the interval [0,1] in order to express concept values on a

normalised range denoting a degree of activation. The sigmeod logistic function [11] is used as it produces a range of security levels.

Figure 3 represents a FCM for Provider P. There are 25 nodes, whose labels can be found Table I. There are both public and private concept nodes, where private nodes, only visible to the provider, are distinguished by a dashed line. For this research, the security level or goal of a provider (C25), in the centre of Figure 3, is directly affected by six main concepts in light gray namely the

• Trust in the other party (C1), • Security Solutions (C2), • Security Threats (C3), • Integrity (C4), • Confidentiality (C5) and • Authentication (C6). The following inference rule is applied: for the value of

the security level (C25) to be GOOD, Trust in the other party must be MODERATE, reports from Security Solutions must be STABLE, an ACCEPTABLE level of Security Threats must be reported and the strength of Integrity, Confidentiality and Authentication should be GOOD. FCM relationships and edge nodes are defined as follows:

Relationships: The values of the weighted relationships used in the FCM are assigned by the administrator of the FCM through experimentation and range between [-1,+1]. They represent the influence a concept has on another.

Edge nodes: Edge nodes are automatically populated by the Fuzzifier component shown in Figure 2. Table I lists

538

15 edge nodes that are populated with fuzzy values in the interval [0,1].

Some parts of the FCM are now discussed in more detail.

Authentication (C6) found on the left of Figure 3, is described as an example of how the FCM infers a security level. Node C6 is inferred from a number of edge nodes C22, C23 and C1 as follows: The authentication token used (C23) has a strong influence on authentication (C6). If a STRONG authentication token is used e.g. X.509 certificate, authentication (C6) increases by 80%. Authentication metrics (C22) that provide an indication of conformance to the agreed upon authentication rules, moderately influences authentication (C6) by 40%. If the strength of authentication (C6) decreases it lessens the influence of Authentication metrics (C22). The influence of authentication on trust is well-documented in literature [14]. Trust (C1) in another party such as Consumer C influences Authentication (C6) moderately. This indicates that as Trust in Consumer C (C1) increases, weaker authentication mechanisms can be used while still achieving the required security level (C25). On the other hand, if Trust in Consumer C (C1) should decrease, it will lower the level of Authentication (C6), thereby requiring a better Authentication token (C23). A decrease in Authentication (C6) lowers the Trust in Consumer C (C1).

Security binding (C13) to the right of Figure 3 is a set of properties that together provide coherent information on how to secure a given message exchange. It is inferred from three public nodes, the Algorithm suite (C14), the Binding type (C15) and Timestamps (C16). Making use of a STRONG Algorithm suite (C14) has a positive influence on the level of the Security binding (C13), as it ensure a sound combination of security mechanisms for integrity and confidentiality. AsymmetricBinding can ensure more fine-grained message security, as parts of a message can be protected as it moves across domains. If TransportBinding is used, HTTPS and not SOAP security is applied, providing point-to-point protection, of LOW strength. Including Timestamps (C16) strengthens integrity, confidentiality and provides non-repudiation evidence.

Next, an example illustrating the use the security policy evaluation process discussed in this section is examined.

VI. EXAMPLE Table I shows edge nodes of various FCM instantiations

for Provider P, given by each column. Before any interaction, Provider P sets its expected security level and preferred security requirements and mechanism values, listed in the first column as P1. The security level (C25), shown at the bottom of the first column, is inferred by the FCM to be 0.866. All values are determined by an administrator through experimentation. For example, Provider P expects that there should be MODERATE Trust in a prospective consumer (0.5), and Security Solutions and Security Threats should be reporting GOOD levels of activity. The digital signature algorithm and key length used with prospective consumers should be STRONG (0.8) and MODERATE integrity metrics need to be reported (0.5).

TABLE I. SECURITY POLICY STATES

Edge Nodes P1 C1 C01

C1 Trust 0.5 0.5 0.5

C2 Security Solutions 0.3 0.3 0.3

C3 Security Threats 0.3 0.3 0.3

Integrity

C12 Dig Sig Alg 0.8 0.4 0.4

C11 Dig Sig KeyLen 0.8 0.3 0.3

C10 Dig Sig Metrics 0.5 0.5 0.5

C7 MessageID 0 0 0

Confidentiality C21 Encr Algorithm 0.8 0.3 0.8 C20 Encr Key Length 0.8 0.3 0.8

C19 Encr Metrics 0.5 0.5 0.5

Authentication

C23 Auth Token 0.8 0.3 0.3 C22 Auth Metrics 0.5 0.5 0.5

Security Binding

C14 Algorithm Suites 0 0 0

C15 Binding Type 0.3 0.8 0.3

C16 Timestamp 0 0 0

C25 Security Level 0.866 0.636 0.731

The security level (C25) of 0.866 thus represents a

STRONG level of security, which may be difficult for new consumers to achieve as they may not initially have good trust and metric levels, and support strong security mechanisms. Experimentation indicates an acceptable range between 1 and 0.7, representing a strong to moderately good security level.

Scenario: Consumer C requests to interact with Provider P and presents its security policy, given in Figure 1. The consumer security policy supports weaker mechanisms such as Sha1 for integrity with 128 key length, TripleDES with 128 Key Length, Username/password authentication and TransportBinding with HTTPS, shown in Figure 1.

The security policy is evaluated by the Policy Interpreter. The Policy Analyser and Fuzzifier populate edges of nodes of the FCM, as shown in column C1. As no trust value or security metrics are available for this consumer at this time, they are set to 0.5 in order to bootstrap the inference calculation (C1, C10, C19, C22). Consumer C’s security policy supports weaker authentication, confidentiality and integrity mechanisms, as reflected by the low values. A security level (C25) of 0.636 is inferred and presented to the administrator of Provider P. This value does not meet the required security level of at least 0.7. Trade-offs needs to be determined. The Policy Analyser inspects the fuzzy rule base and presents sets of trade-offs in turns to the administrator. In order to try to

539

accommodate the security policy requirements of Consumer C, minimal changes are proposed as follows:

• The encryption key length (C20) can be improved to be (0.6) or GOOD. The security level is 0.685 which is too low.

• The Consumer C can use a very strong authentication token (C23) – certificates (0.8) HIGH. The security level evaluates to 0.686 which is too low.

• If Consumer C makes use of a STRONG encryption algorithm (C21), the security level is 0.687, but in combination with a STRONG key length (C20) the security level becomes 0.731. The administrator can make further adjustments as

required and can run the FCM a number of times. He/she finally decides to request an improvement in the low Encryption algorithm (C21) and Encryption key length (C20) from Consumer C. These updated security policy mechanisms are shown in column CO1. The Security level (C25) inferred is 0.731, which is in the acceptable range. The resultant security contract is shown in Figure 4.

Figure 4. Resultant security contract

VII. CONCLUSION This research introduces the use of fuzzy techniques for

trade-off analysis for web services security policies. The security policy support system supports administrators to consider all security aspects found in the environment and the security policies with their interrelated effect when policy trade-offs are made to accommodate consumers. Administrators specify an initial set of security preferences and security goals using fuzzy linguistic terms to make it easier to express themselves and understand the results of the analysis. The system supports an operational security level, to alert administrators of changes.

Experimentation shows that the FCM performs well. The approach to security policy assertion trade-off is highly intuitive and is based on incomplete information. The FCM enables a provider to identity whether the security supported by the security policies of consumers is sufficient. The causal relationships and fuzzy rules are still the focus of much experimentation.

VIII. ACKNOWLEDGMENT The financial assistance of the National Research

Foundation (NRF) in South Africa under Grant number 66302 is hereby acknowledged. Any opinion, findings and conclusions or recommendations expressed in this material are those of the authors and the NRF does not accept any liability thereto.

IX. REFERENCES [1] Boubez, T., Hirsch, F., Hondo, M., Orchard, D., Vedamuthu, A.,

Yalcinalp, U., Yendluri, P.: Web Services Policy 1.5 – Framework, 2007.

[2] Barbir, A., Goodner, M., Granqvist, H., Gudgin, M., Nadalin, A.: WS-SecurityPolicy 1.2. OASIS Standard, 1 July 2007.

[3] Elahi, G. and Yu, E.: Modeling and analysis of security trade-offs - A goal oriented approach. Data Knowl. Eng. 68, 7 July, 2009, 579-598 (2009).

[4] Georg, G., Anastasakis, K., Bordbar, B., Hilde Houmb, S., Ray, I., Toahchoodee, M.: Verification and Trade-Off Analysis of Security Properties in UML System Models, IEEE Transactions on Software Engineering, vol. 36, no. 3, pp. 338-356, May/June 2010.

[5] Anderson, A.: An Introduction to the Web Services Policy Language (WSPL), IEEE 5th International Workshop on Policies for Distributed Systems and Networks, New York, USA, 7-9 June, 2004.

[6] Hollunder, B.: Domain-Specific Processing of Policies or: WS-Policy Intersection Revisited, IEEE International Conference on Web Services (ICWS 2009), pp. 246-253, 2009.

[7] Ballinger, K., Box, D., Curbera, F., Davanum, S., Ferguson, D., Graham, S., Liu, K.: Web Services Metadata Exchange (WS-MetadataExchange) Version 1.1, August, 2006.

[8] Ono, K., Nakamura, Y., Satoh, F., Tateishi, T.: Verifying the Consistency of Security Policies by Abstracting into Security Types, IEEE International Conference on Web Services (ICWS 2007), pp. 497-504, 2007.

[9] Kosko, B.: Fuzzy Cognitive Maps. International Journal Man-machine Studies, Vol.24, pp. 65-75, 1986.

[10] Groumpos P.P. and Stylios C.D.: Modeling complex systems using Fuzzy Cognitive Maps, IEEE Transactions on systems, man and cybernetics – Part A: Systems and Humans, Vol. 34(1), 2004.

[11] McNeill F. M.: A Rich Collection of Squashing Functions, Technical Report, Fuzzy Systems Engineering, http://www.fuzzysys.com/squash2.pdf, 2003.

[12] International Organization for Standardization, IS07498-2, Information Processing Systems – Open Systems Interconnection – Basic Reference Model – Part 2: Security Architecture.

[13] Kim, A., Luo, J. and Kang, M.: Security ontology for annotating resources, Lecture Notes in Computer Science, Vol. 3761, Springer-Verlag, pp. 1483-1499, 2005.

[14] Abdul-Rahman, A. and Hailes, S.: A distributed trust model. In Proceedings of the 1997 workshop on new security paradigms (NSPW '97). ACM, New York, NY, USA, 48-60, 1998.

[15] Savolainen, P., Niemelä, E., Savola, R.: A Taxonomy of Information Security for Service-Centric Systems, 3rd EUROMICRO Conference on Software Engineering and Advanced Applications, pp. 5-12, 2007.

[16] Elahi, G., Yu, E.: Trust Trade-off Analysis for Security Requirements Engineering, 17th IEEE International Requirements Engineering Conference, pp. 243-248, 2009.

[17] Viega, J., Kohno, T., and Potter, B.: Trust (and mistrust) in secure applications,” Common. ACM, vol. 44, no. 2, pp. 31-36, 2001.

540