Managing End-to-End Security Risks with Fuzzy Logic in Service-Oriented Architectures

Youakim Badr LIRIS-CNRS, INSA-Lyon

Lyon, France youakim.badr@insa-lyon.fr

Soumya Banerjee Birla Institute of Technology

Mesra, India soumyabanerjee@bitmesra.ac.in

Service-oriented architectures are increasingly deployed in open, distributed and dynamic environments, which require an end-to-end security awareness security at each phase of the service’s lifecycle. Moreover, the security should not only focus on services without considering the risks and threats that might be caused by elements from business activities or underlying hardware and software infrastructure. In this paper, we adopt a holistic approach to define a security conceptual model that covers all elements at the business, service and infrastructure levels and guides each phase in a typical design method for service-oriented architectures. Since the information security is subject to uncertain and unforeseen threats, we propose a fuzzy logic decision system that helps identify security risks based on the security conceptual model and select appropriate security measures based on security objectives.

Keywords- Security Management, Risk Management, SOA, Reference Models and Design Method, Fuzzy Logic.

I. INTRODUCTION The exponential growth of services available via Web

has enabled the service-oriented architecture (SOA) to become the de facto architectural style to build agile information systems and support interconnections of collaborative business processes by virtue of service compositions. Although SOA ensures business and information systems alignment, it requires the enforcement of security constraints to entirely cover SOA-based information systems. Many SOA security solutions remain limited to services, their composition mechanisms and their technical implementation [1], and they are often underestimated the open environment by which SOA-based information systems collaborate and exchange information with each other [2]. Existing SOA design methods also provide little attention to integrate security concerns in common reference models, guiding each stage of the service lifecycle (i.e., design and runtime) [3].

The SOA lifecycle comprises a series of phases, including project planning, domain analysis, service design, service development, service testing, service deployment and governance [4]. As a result, security policies become briefly inconsistent, increasing SOA systems vulnerability. Hence, information security should not be limited to technological solutions and should simultaneously consider business,

organizational and technological aspects at each stage of the service lifecycle. On one hand, services (i.e., Web services) are not isolated from their environment and they belong to an evolving ecosystem, depending on business and organizational elements such as partners, actors and organizational processes just to mention a few. On the other hand, services hang over hosting software and hardware elements, including Web containers, application servers, operating systems, and networking devices. Dependencies between different elements should be explicitly identified and security objectives must be defined and attached to these elements. SOA design methods and models only focus on services without integrating security as a source of risks[5]. Considering security concerns while designing SOA requires the identification of all business, organizational and infrastructure elements and assessing how they impact each other in a domain containing uncertainty due to the incomplete knowledge of the state of the environment at the time where a given risk is occurred. Service security thus implies causal relationships and dependencies between these elements within and beyond enterprises’ boundary and requires managing the security from a risk perspective in evolving environment and not only from technological and constraints to protect the access to information access.

Managing security as potential risks entails new class of SOA design methods that establish the context of all assets subject to potential risks, identify risks, assess their potential severity of impact and rate of occurrence, prioritize them and finally manage risk treatments (i.e., avoidance, reduction, sharing, and retention). Integrating risk management in SOA design methods also requires a common model or a reference model to: 1) identify all relevant security concepts (i.e., security objectives, security requirements, security measures, etc.), 2) tie all elements at business, service and infrastructure levels to ensure a coherent guideline to design end-to-end SOA security in open environments (security by design), 3) provide a support for a decision process based on partial and uncertain data to assess risks and choose the appropriate security treatment (or security policy) at SOA design and/or runtime.

In this paper, we overcome these limitations by introducing a security reference model to be early used in SOA design methods (i.e., planning phase) and to be followed by all phases in the service lifecycle to ensure an end-to-end security in open and distributed environments. In

2013 IEEE Ninth World Congress on Services

978-0-7695-5024-4/13 $26.00 © 2013 IEEE

DOI 10.1109/SERVICES.2013.28

111

2013 IEEE Ninth World Congress on Services

978-0-7695-5024-4/13 $26.00 © 2013 IEEE

DOI 10.1109/SERVICES.2013.28

111

addition, we introduce a dependency model to establish causal relationships between services and all vulnerable elements at business, service and infrastructure levels that may impact the service security. We also introduce a decision process based on fuzzy logic to find best security policy based on uncertain data and randomness of threats that might occur during SOA design and execution.

The rest of the paper is organized as follows: In section

2, we discuss works related to reference models in service-oriented architectures. We examine how current reference models underestimate security requirements (i.e., end-to-end security) and we inspect the inadequacy of traditional risk management methods to identify risks and vulnerable assets in an open environment by which SOA-based systems operate. In section 3, we also propose the dependency model to tie all essential assets business, service and infrastructure levels. In section 4, we introduce the conceptual model, which comprises three distinct models; the service’s conceptual model, the risk’s conceptual model and the security policy’s conceptual model. In section 5, we introduce the fuzzy inference system. We finally conclude our work and provide directions to extend our contribution in section 6.

II. RELATED WORK Given a domain of interest, a conceptual model is defined

as an abstract representation of basic concepts, their characteristics, and relationships among concepts. In service-oriented architectures, a conceptual model is used to present different service elements (i.e., input, output, operations, security policies, etc.), their structures and relationships between them. In the SeCSE’s project [6] a conceptual model has been proposed to define service’s concepts (i.e., publication, discovery, composition, execution and supervision) and to describe business activities between partners with respect to a common reference. The model presented in [7] aims at describing business processes and services in order to support a model-driven approach and transform business processes into deployable services.

Standards organizations, such as the OASIS, the Open Group and the OMG just to mention a few, have also played an important role to establish broad consensus on SOA concepts and disseminate reference models to foster the design of SAO–based applications. Nevertheless, most of these reference models focus on some viewpoints and pay less attention to security concerns, which are fundamental constructs in any service design methods. In fact, the reference model proposed by OASIS [8] focuses only on fundamental SOA concepts (i.e., service description, visibility, interaction, execution context, …) and discards service security and its deployment. The reference document “SOA Ontology" [9] published by the Open Group is limited to an ontological based language, describing SOA concepts. As for the OASIS reference architecture [8], its main purpose emphasizes on service implementation in secure collaborative environments based on trust relationships among partners. The OASIS reference architecture is particularly used by the SoaML Modeling Language [10] to

design services following the Integration Maturity Model, assessing the services’ maturity before starting a SOA project. An interesting comparison in [11] discusses how the before mentioned models have gained a high maturity’s level in designing, deploying and governing service-oriented architectures. To this end, we argue that none of these representative models have been developed with the intention of designing secure service-oriented architectures. Despite recent efforts to include security aspects and trust networks in the SOA design (i.e., the OASIS’s reference architecture), most of existing models remain preliminaries. They only focus on services without integrating security as a source of risks in the SOA design methods or in the service lifecycle. Traditional risk management methods such as EBIOS [12], OCTAVE [13] and CORAS [14] emphasize on dependencies between assets in information systems to assess risks in relatively closed and stable information systems. They cannot be easily applied to SOA since services are distributed in open environments. Some efforts in the SOA community attempt to enlarge the scope of security by including dependencies between services and elements from business and hosting infrastructure [15] to identify casual relationships that impact security. Nevertheless, most of initiatives remain fragmented without a holistic vision of security including organizational, business, services, hardware and software assets. As result, a security policy that does not take into accounts all of these assets and levels would be unstable and incomplete and produce a dangerous solution based on a false sense of security even more damaging than doing nothing [12].

III. DEPENDENCY MODEL In order to highlight dependencies between all assets

related to business, service and infrastructure levels, we define the SOA design context as a set of “essential assets” that are subject to potential security risks and we divide them onto three categories as follows:

• Business elements: describe business, organizational and legal assets, including business processes, business documents, partners, actors and their roles, protection level agreements, security preferences and objectives, legal and regulatory compliance.

• Service elements: include atomic and composite services, which implement business activities (i.e., operations) and refer to information required by these operations. Data, documents and messages are types of information of different granularities, which allows a better management of information security.

• Infrastructure elements: describe services’ hosting context and consist of software (operating systems, server applications, web containers, database management systems, firewall, and network protocols, ...) hardware (i.e., networking devices, servers,…).

We illustrate the dependency model in Figure 1 as a directed graph, identifying casual relationships between types of essential assets. In practice, the dependency model is a complex graph because it is built from instances of each

112112

type of essential assets, and, hence, it can be learned from lists of essential assets using Bayesian networks [16] for example. The casual relationships are thus not static and depend on the essential assets and the domain of interest. The dependency graph shows that a threat to any essential element can be easily propagate through dependency relationships among essential assets and, consequently, it identifies the infected elements and assesses SOA-based system vulnerability.

Actor

PartnerRole

Business Process

Manual Activity

Business Service

Business Object

Service

Operation

Software

OS

Device

Figure 1. The Dependency Model

IV. SECURITY SERVICE REFERENCE MODEL We introduce the Security Service Reference Model as

an interlaced set of clearly defined concepts to gain understanding of security concerns within the SOA environment and provides common semantics that can be used unambiguously across and between different implementations. As a reference model, the conceptual secure service model communicates ideas among actors involved in service design, development and execution at business and technological levels. However, it is technology agnostic and not directly tied to any concrete implementation details. As depicted in Figure 2, the Security Service Model is built from three distinct sub-models:

• The Service Conceptual Model, which is based on a small number of unifying concepts and used as a basis for describing essential assets related to services.

• The Risk Conceptual Model, which refers to different types of threats and risk treatment.

• The Security Policy Model, which associates security objectives with security requirements and measures.

In the following sub-sections, we describe these models in details and create interlinks between them based on the “essential element” as a unifying concept that leverages SOA security risks and policies.

A. The Service Conceptual Model The Service Conceptual Model describes the minimal set

of essential assets, relationships and properties necessary to describe the service layer located in the middle between the business layer and the infrastructure layer.

The Service Conceptual Model presented in Figure 2 associates the essential assets identified in the dependency model with additional details. For example, the business process is composed of business services (automatic and semi-automatic activities) and manual activities. Each business service provides operations that are realized by one or more services. At the heart of the model is the essential element ‘business service’ itself, which exchanges messages, encapsulating business documents, consisting of operations each of which is implemented by low level services (i.e., integration services, utility services, data services, …). One low level service may require the use of another.

The basic roles, client and provider, specify the provision and use of a service. Their relationships are governed by a contract denoting interfaces (i.e., set of operations) and describing non-functional properties. A contract is regulated by a set of rules. These are typically derived from some combination of security assertions and quality of protection policy that is decided at the business level. All services are hosted by the infrastructure layer elements. An individual service may also be part of ‘business processes’, which are logically part of the business layer.

The key relationships to notice in this model are the connections between the service layer and respectively the infrastructure layer and the business layer. Due to page limit we do not detail these two layers but they contain essential assets that are subject to security vulnerability and have impact on service security at business level (i.e., business events, business rules, roles, processes, …).

B. Security Policy Conceptual Model Security in dynamic and open SOA-based environment,

by which reusable services from various providers are composed together, is a very complex task that ranges from the level of encryption over secure transmission protocols and authentication to the level of organizational matters (i.e., roles) and legislation. The main reason is the lack of appropriate design method that early considers security awareness in each stage at the design time, including stages such as preparatory, requirement, design stage, implementation, testing, integration and delivery, as well as during the runtime by considering execution, monitoring, security assessment and treatment activities [17]. Roughly speaking, a security policy identifies information security of any consistent essential assets in business processes, services, and infrastructure assets, as long as they are subject to random threats and unpredictable vulnerability. Instead of being limited to technical solutions to secure transmission and information access, it also contains security information confronted to business regulation and legislation.

113113

Service Model Security Policy Model Risk Model

Security Objective

Contract

depends

Risk

Essential Asset

Threat

Treatment

Vulnerabilityexploits

Attack

creates

Contextdepends

createsmitigates

impacts

Attacker

conducts

Person

Misuse creates

Security Policy

Constraintsapply to

Scenarioresults

Incident results

Organizational Risk

Technological Risk

accomplishes

Service

Business Object

Business Process

Manual ActivityBusiness Service

exchanges

realized by

Message

Business Asset

encapsulates

Operation

Infrastructure Asset

offers

hosted on

Provider

ClientInterface

depends

Acceptance

Avoidance

Transfer

Mitigation

Security Measure

Security Service

Security Mecanism

Security Protocol

Security Pattern

ensures

corresponds to

Security Assertions

specifies

defines

Threat Patterns

specifies

leads todefine

identifies

expose

providesconsumes

weaken

Software Hardware

Role Actor Business Policy

ensures

provides

Service Model

s

def

Risk Model

A

g

ded

EsA

i t

nal

expose

Security Policy Model

m

tsw

t

Figure 2. Secure Service Conceptual Model

For these reasons, we introduce the Security Policy

Conceptual Model, which describes general concepts that are the same across all knowledge domains. It particularly defines security objectives and applies them to business, organizational and technological essential assets. As illustrated in Figure 2, the model defines policies and applies them to essential assets by setting appropriate constraints and specifying contracts that regulate their access by actors (people, organization and third party software, ...). The context refers to a set of essential element that requires a common security policy.

The Security Policy Conceptual Model entails three generic security objectives to cover business, technology and support security objectives and comprises the following concepts:

• The ‘Management’ of essential business elements, which refers to creation and administration of contracts, rights and obligations (i.e., managing access rights to business documents and managing agreements on the quality of protection (QoP) offered during the service delivery, …)

• The ‘Classification’ of business processes and business documents by assigning sensitivity levels. For example, assigning black for private data, gray for data requiring a standard level of protection and white for public data [18].

• The ‘Trust’ provides security across multiple domains through inter-domain trust relationships. It classifies actors and establishes sharing trusted domains based on specific security policies. For example, based on trust relationships between inter-domains, the authentication mechanism in each domain trusts the authentication mechanism for all other trusted domains. If a user or a service is authenticated within its own domain, its effect is then accepted by all other trusted domains.

C. The Risk Conceptual Model The security risk is often represented as any event that

can affect confidentiality, integrity and availability of information. Different types of risks exist (i.e., business, organizational and technological risks). In Figure 2, the Risk Conceptual Model includes basic elements found in risk management [13]; the threat is a potential violation of security that causes damages. Vulnerability is a weakness in a system that is left unprotected and thus it can be exploited by threats. A security attack is the action that causes a threat to occur. Security measures are actions taken to counter security threats and attacks. As a general concept, security measures can refer to security policies, security protocols and security mechanisms (i.e., encryption), and imply security treatments such as acceptance, avoidance, transfer or reduction.

114114

To this end, the Security Service Reference Model identifies essential assets (policies, risks and security measures) to create a context by which service security is defined and managed at the business and infrastructure levels.

The service, as a fundamental concept in the SOA, is not anymore isolated: its security depends on the essential assets at the business, organizational and technological levels. The model also identifies risks that may harm the identified essential assets. The security risk identification is accomplished by identifying the unwanted incidents that may harm the essential assets while referring to threats and vulnerabilities. Finally, it identifies security measures to treat risks and meet security objectives

As we mentioned early the Security Service Reference Model is intended to guide SOA design methods by integrating security concerns early at each design phase and consider the security as holistic approach rather that assembly of solutions and techniques focusing on specific concerns.

In the following, we illustrate the usage of the Security Service Reference Model to asset decision makers to choose the best security treatment strategy taking into account issues arising from the imprecision conveyed by natural language, such as inaccurate measures, ambiguous facts, and subjective analyses that characterize the security decision-making process and the strategy to adopt to treat security threats.

V. FUZZY INFERENCE SYSTEM FOR SECURITY POLICIES Establishing security policies and deciding on strategies

to deal with threats and vulnerabilities often rely on rules of thumb or incorporate personal intuition and judgment on indefinite linguistic concepts, e.g. 'high risk', 'minor impact', and 'possibly vulnerable'. This terminology is a natural way to decision makers to characterize unreliable data and imprecise measures as in the case of information security where the vagueness and decisions are fuzzy.

The fuzzy logic is an approach for simulating analogy and approximation in the human reasoning process [19]. Fuzzy logic can be useful to model and analyze security decisions because it correlates well with the mental concepts, i.e. facts, rules, and inference schemes used by decision makers and practitioners. In practice, fuzzy logic illustrates different solution alternatives, each of which need not be right or wrong but instead be possibly true to a certain degree.

Based on the Service Security Reference model we develop a fuzzy logic framework for end-to-end security analysis and risk assessment, and approximate reasoning to find the security treatment based on security objectives. The decision(s) for any security treatments is based on the enterprise capability to handle (or implement) the security measures that correspond to their security objectives. The reasoning system can be summarize as:

<Threats> cause <Risks> handled by <Security Objectives> resulting in <Security Treatment>

The evaluation process can be modeled with facts and

rules that are written in terms of fuzzy sets [19].

A fuzzy set F in a universe U is a collection of ordered pairs {⟨u, 𝜇F (u)⟩ | u ∈ U} where 𝜇F : U ⟶ [0, 1] is the membership function of F. 𝜇F (u) is the membership grade of u in F and be regarded as the degree of truth that u belongs to F.

The reasoning process in the fuzzy logic is modus ponens, which is similar to rule-based systems, to proximate approximate relationships among linguistic variables and handle uncertainty that generates imprecise conclusions.

A typical fuzzy production rule has the form; IF X is A, THEN Y is B', where the “IF part” is the

premise or antecedent, the “THEN part” is the conclusion or consequent of the rule, A and B are fuzzy sets (e.g., high, medium, or low), and, X and Y are linguistic variables.

We briefly discuss membership functions, linguistic

variables, and production rules for security decision.

A. Membership Functions Manipulations of membership functions require three

basic fuzzy set operations, complementation, intersection, and union, which are typically defined as follows.

Let A and B be fuzzy sets in U. The complement A of A is the fuzzy set with

membership function 𝜇not A (u) = 1-𝜇A (u), The intersection of A and B is the fuzzy set C =A∩B with 𝜇C (u) = 𝜇A (u) � 𝜇B (u), where a�b means min{a, b}. The union of A and B is the fuzzy set D = A∪B 𝜇D (u) = 𝜇A (u) � 𝜇B (u), where a�b means max{a, b}. In order to facilitate the calculation of inferential logic,

we choose trapezoids for representing the relevant fuzzy sets of end-to-end security analysis and risk assessment model. The trapezoid T = (a, b, c, d) with amplitude one is defined by:

0 u ≤ a (u-a)/(b-a) a < u ≤ b T(u) = 1 b < u ≤ c (d-u)/(d-c) c < u ≤ d 0 d < u

where a, b, c, and d are real numbers -∞< a ≤ b ≤ c ≤ d < +∞

B. Fuzzy Linguistic Variables A fuzzy linguistic variable, X, is defined as a tuple (T, U, G, M) where T is an association of U with the terms of X, or labels x ∈ X. U is the universe of discourse of X. G is a syntactic rule that prescribes the terms x. M is a semantic rule which assigns to each x a fuzzy set, M(x) = {⟨u, 𝜇F (u)⟩, u ∈ U }. Some linguistic variables may have different numerical scales. For example, variables can be scaled by numerical scales, ratios, or nominal scales. Analysis of our security and risk assessment case requires several linguistic variables. We present ten linguistic

115115

variables, including Essential Assets, Vulnerability, Incident, Threat, Security Objective, Security Measures, Rate of Occurrence, Severity of Impact, Risk and Risk Treatment. These variables may not concur exactly with the preferred language of all experts but they still describe suitably some elements of our Security Service Reference Model. For each variable, we define terms for an illustration purpose rather than characterizing these variables. In addition, the scales are subjective assignments, as alternatives to the lack of a universally standard formula to measure for numerical values of these variables. T(Essential Assets) = {Service, Operation, Message, Business Process} T(Vulnerability) = {Low, Medium, High} T(Incident) = {Random, Regular, Intentional} T(Threat) = {Malicious, Accidental, Failure, Natural} T(Security Objective) = {Confidentiality, Integrity, Availability, Accountability, Assurance} T(Security Measure)={Encryption, Authentication, SecureTransmission} T(Rate of Occurrence) = {Certain, Possible, Probable, Rare} T(Severity of Impact) = {Insignificant, Major Impact, Loss} T(Risk) = { Low, Medium, High} T(Risk Treatment) = {Reduction, Sharing, Avoidance, Retention}

C. Fuzzy Production Rules We have developed a set of fuzzy production rules based

is a first approximation to a prototypal knowledge base for security and risk assessment. Each rule consists of multiple antecedent linguistic variables, but only one consequent linguistic variable. The meta-fuzzy rules can be described as follows:

1) IF [Essential Assets] AND [Vulnerability] AND [Incident] THEN [Threat] 2) IF [Threat] AND [Rate of Occurrence] AND [Severity of Impact] THEN [Risk] 3) IF [Risk] AND [Security Objective] THEN [Security Measure] 4) IF [Security Measure] THEN [Risk Treatment]

There are four stages of production rules that link four levels of variables. We denote by Rij the j-th set of rules at stage i.

A specific set of rules in the first stage is R11, which approximates “Threat”. Each rule in R11 has as its antecedent Essential Assets, Vulnerability, and Incident with Threat in the consequent. A typical rule is:

IF Essential Assets is Service AND Vulnerability is High AND Incident is Intentional THEN Threat is Malicious

A set of second-stage rules is R21, which evaluates “Risks” and consists of Threat and Rate of Occurrence, Severity of Impact, and Risk as antecedent variables. A typical rule is:

IF Threat is Malicious AND Rate of Occurrence is Possible

AND Severity of Impact is Loss THEN Risk is High

A set of third-stage of rules, R31, requires Risk and Security Objective in the antecedent with Security Measure in the consequent. A typical rule is:

IF Risk is AND Security Objective is Confidentiality THEN Security Measure is Encryption

The final stage of rules, R41 infers the Risk Treatment in in the antecedent with Risk Treatment in the consequent. The inferred conclusion is only partially true.

A typical rule is: IF Security Measure is Encryption THEN Risk Treatment is Reduction

D. Evaluation and Inference The fuzzy evaluation analyzes rules at each stage and

assesses a partial match of fuzzy input to infer from the rule a conclusion that approximate corresponding terms in the antecedents. The assessments are thus combined by means of fuzzy modus ponens to obtain a fuzzy derived outcome that approximates the consequent of the rule. Outcomes of all rules are combined into a cumulative membership function, which is the aggregate of all possible results generated from the partial match of fuzzy input data with the antecedent of every rule.

Inspired by the mathematical basis of the fuzzy evaluation method to propagate multi-stage analysis to risk assessment [20], we propose a formal description for our evaluation and inference method.

Formally, the set of rules Rij consists of K = K(i, j), rules Rijk, k = 1..... K, each rule as L = L(i,j) antecedent

linguistic variables Xijl, l = 1,..., L, with domain Uijl and a single consequent variable Yij. The value taken by Xijl in rule Rijk, is the fuzzy set Fijkl and has the membership function 𝜇F ijkl(uijl).

The simultaneous match across Rijk forms a vector of fuzzy sets having corresponding membership functions defined as uij=(uijl, ... , uijL) and given by:

𝜇k (uij) = (𝜇F’ij1 (uij1) � 𝜇F’ij1 (uij1) , …, 𝜇F’ijL (uijL) � 𝜇F’ijL (uijL)) By finding the largest value, the supremeum (denoted by sup) of all possible fuzzy matching over all uij .

λijk = sup {�l=1, .., L [ 𝜇F’ij1 (uij1) � 𝜇F’ijkl (uij1)]} λijk can be considered the extent to which the antecedent

statements are simultaneously true when the input is F’ij Using the fuzzy logic inference with some elements from

the Service Security Reference Model shows a complementary perspective to illustrate our holistic approach to handle end-to-end security without making competitive comparisons to risk assessment methods or other techniques [21][22]. Nevertheless, the main purpose of the Service Security Reference Model is to be used in designing of secure SOA by considering security concerns and risk

116116

management at design time [23]. Combining Fuzzy Logic and Probability is useful to relate the fuzzy predicates of our decision system to the probability distribution of the unfavorable events as defined by the dependency graph. Interested readers may refer to [23] for a practical guide showing both fuzzy logic and probability in problem solving techniques or [24] for fuzzy causal probabilistic networks, providing a formalism for inference under fuzziness and randomness.

VI. Conclusion We propose in this paper Service Security Reference

model to handle security concerns at the business, service and infrastructure levels and used in SOA design methods. A preliminary version of the Service Security Reference model is used in our previous work [25] to develop a secure SOA design method that tackles security from a risk management perspective. In our work, we integrate risk management and SOA design steps as well as incorporate both technological and organizational levels. Risk management in order to cover the whole SOA lifecycle, optimize security investments, and sustain security measures. In this paper, we illustrate the Service Security Reference Model with a fuzzy reasoning system to identify SOA security risks and propose risk treatments based on security objectives. We have implemented the fuzzy inference engine with the JFuzzyLogic [26], which is a fuzzy logic package written in java. However, there are still some remaining issues that are not addressed so far. For instance, we plan to enhance our security analysis and risk assessment decision support system by providing fuzzy production rules to cover all essential assets or assets in the Security Service Reference Model. To support an automatic construction of the dependency graph, we will investigate the Bayesian Network to generate the automatically generate the dependency graph and relationships between essential assets from learning from data.

REFERENCES [1] A. Singhal, “Web Services Security: Techniques and Challenges

(Extended Abstract),” in Data and Applications Security XXII, vol. 5094, V. Atluri, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 158–158.

[2] A. Miede, N. Nedyalkov, D. Schuller, N. Repp, and R. Steinmetz, “Cross-organizational security - the service-oriented difference,” in Proceedings of the 2009 international conference on Service-oriented computing, Berlin, Heidelberg, 2009, pp. 72–81.

[3] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann, “Service-Oriented Computing: State of the Art and Research Challenges,” Computer, vol. 40, no. 11, pp. 38 –45, Nov. 2007.

[4] T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2005.

[5] L. Kagal, T. Finin, A. Joshi, and S. Greenspan, “Security and Privacy Challenges in Open and Dynamic Environments,” Computer, vol. 39, no. 6, pp. 89–91, Jun. 2006.

[6] M. Colombo, E. D. Nitto, M. D. Penta, D. Distante, and M. Zuccalà, “Speaking a Common Language: A Conceptual Model for

Describing Service-Oriented Systems,” in Service-Oriented Computing - ICSOC 2005, B. Benatallah, F. Casati, and P. Traverso, Eds. Springer Berlin Heidelberg, 2005, pp. 48–60.

[7] C. Emig, K. Krutz, S. Link, and C. Momm, Model-Driven Development of SOA Services. Universität Karlsruhe (TH), Karlsruhe, 2007.

[8] C. Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter F Brown, and Rebekah Met, “Reference Model for Service Oriented Architecture v1.0,” 2006. [Online]. Available: http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html. [Accessed: 02-Apr-2013].

[9] The OpenGroup, “Service-Oriented Architecture Ontology,” 2010. [10] Object Management Group (OMG), “Service oriented architecture

Modeling Language (SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS),” 2007.

[11] H. Kreger and J. Estefan, “Navigating the SOA Open Standards Landscape Around Architecture,” Joint Paper, The Open Group, OASIS, and OMG, 2009.

[12] ANSSI, “EBIOS: Expression des Besoins et Identification des Objectifs de Sécurité,” 2010. [Online]. Available: http://www.ssi.gouv.fr/. [Accessed: 17-Mar-2013].

[13] C. Alberts and A. Dorofee, Managing Information Security Risks: The OCTAVE Approach, 1st ed. Addison-Wesley Professional, 2002.

[14] M. S. Lund, B. Solhaug, and K. Stølen, Model-Driven Risk Analysis: The CORAS Approach, 2011th ed. Springer, 2010.

[15] M. Hafner and R. Breu, Security Engineering for Service-Oriented Architectures, 2009th ed. Springer, 2008.

[16] J. Cheng, D. Bell, and W. Liu, “Learning Bayesian Networks from Data: An Efficient Approach Based on Information Theory,” On World Wide Web at http://www.cs.ualberta.ca/∼jcheng/bnpc.htm, 1998.

[17] D. Trček, Managing Information Systems Security and Privacy. Springer-Verlag Berlin and Heidelberg GmbH & Company KG, 2006.

[18] Y. Badr, F. Biennier, and S. Tata, “The Integration of Corporate Security Strategies in Collaborative Business Processes,” IEEE Transactions on Services Computing, 2010.

[19] L. A. Zadeh, The Concept of a Linguistic Variable and Its Application to Approximate Reasoning. National Technical Information Service, 1974.

[20] J. B. Levy and E. Yoon, “Modeling Global Market Entry Decision by Fuzzy Logic with an Application to Country Risk Assessment,” European Journal of Operational Research, vol. 82, no. 1, pp. 53–78, 1995.

[21] J. D. McCalley, V. Vittal, and N. Abi-Samra, “An Overview of Risk Based Security Assessment,” in IEEE Power Engineering Society Summer Meeting, 1999, 1999, vol. 1, pp. 173–178 vol.1.

[22] P. Bou Nassar, Y. Badr, K. Barbar, and F. Biennier, “Risk Management and Security in Service-Based Architectures,” presented at the International Conference on Advances in Computational Tools for Engineering Applications, 2009, pp. 214–218.

[23] T. J. Ross, J. M. Booker, and W. J. Parkinson, Eds., Fuzzy Logic and Probability Applications: A Practical Guide. Society for Industrial and Applied Mathematics, 2002.

[24] H. Pan and D. McMichael, Fuzzy Causal Probabilistic Networks - A New Ideal And Practical Inference Engine. 1998.

[25] P. B. Nassar, Y. Badr, F. Biennier, and K. Barbar, “Securing Collaborative Business Processes: A Methodology for Security Management in Service-based Infrastructure,” in APMS Advances in Production Management Systems, 2011, pp. 480–487.

[26] P. Cingolani and J. Alcala-Fdez, “JFuzzyLogic: A Robust and Flexible Fuzzy-Logic Inference System Language Implementation,” in Fuzzy Systems (FUZZ-IEEE), 2012 IEEE International Conference on, 2012, pp. 1–8.

117117