• Nenhum resultado encontrado

Information flow security in web service compositions

N/A
N/A
Protected

Academic year: 2024

Share "Information flow security in web service compositions"

Copied!
67
0
0

Texto

Where part of this thesis has previously been submitted for a degree or other qualification at this university or another institution, this is clearly indicated. The information flow in an executable process refers to the transfer of information between the process variables and how this transfer affects important security properties such as data confidentiality and information integrity. This thesis focuses on the design-time specification and verification of information integrity policies for web service compositions.

We rely on a recently proposed theory and tool for the verification of non-interference in component-based systems, as well as on a tool for translating web service compositions written in the BPEL language into a formal component-based model. We extend and adapt the above-mentioned tools as necessary for the specification and verification of information integrity policies based on the decentralized labeling model first proposed by Liskov in [20]. First of all, I would like to thank Professor Panagiotis Katsaros for the continuous help, support and guidance he provided me during the development of this thesis.

Furthermore, I would like to thank PhD student Emmanouela Stachtiari for providing valuable advice and guidance on all aspects of this work.

Information flow security

A system can be proven to be secure in terms of integrity by conducting a rigorous analysis and demonstrating that it as a whole enforces the integrity policies of its users. Thus, the integrity policy being enforced is an information flow policy, and the mechanisms that enforce it are information flow controls. Integrity policies are considered end-to-end security specifications because they are a natural way to apply the principle of end-to-end design to security requirements specification.

This can be done by verifying various security properties throughout the execution of the system. Privacy policies considered useful involve accurately describing the actual computation of the data. This means that integrity policies should not only specify who changed the data, but also how the data is manipulated.

Informally, non-interference requires that for each trace of the system, removing all high-level events results in a trace that is still valid [30].

Web service composition

During the composition of web services, the security requirements of both web service providers and requesters must be taken into account so that only the web services that are compatible with respect to such requirements may be composed.

Thesis goal and contributions

The approach is illustrated by the secure construction of an 'insurance claims service' case study scenario. In Chapter 2, we present the basics of the BIP component framework, the theory and application of this secBIP tool, and present our 'Insurance Claim' case scenario. Chapter 3 is focused on the definition of information integrity policies using the Decentralized Label Model (DLM) [20] and the specification and analysis of DLM policies using this secBIP tool.

In Chapter 4, we present the model structure for BPEL processes translated into BIP models by the tool in [28] and then propose our BPEL process verification procedure for Information Integrity in web service compositions. Next, the approach is demonstrated using the BIP model created for the “insurance claims service” case study scenario. The thesis concludes in Chapter 5 with a review of its contributions and a discussion of prospects for future work.

Related work

The dissertation concludes in Chapter 5 with an overview of his contributions and a discussion of future work prospects. embedding) from WS-BPEL to BIP and was further extended to encompass all the semantics in a service composition [28]. In this chapter, the BIP component-based framework is presented and its extension, to verify security properties, secBIP is formally described. Furthermore, different parts of the system can be treated independently, which saves time and costs and increases productivity through component reuse.

BIP (Behaviour-Interaction-Priority) [1] is a formal framework for building complex systems by coordinating the behavior of a set of atomic components. Behavior is defined as a transition system extended with data and C/C++ functions. The definition of coordination between components is layered: the first layer contains the component interactions, while the second layer includes dynamic priorities between interactions. The global state of the model at each execution step is given as the current control locations and the values ​​of local variables of all atomic components.

For each interaction, the connector can provide a guard and a data transfer, which are, respectively, an enabling condition and an exchange of data across the ports involved in the interaction.

  • Security Model
  • Noninterference
  • Unwinding relations
  • Configuration synthesis
  • Overview

The security assignment for component C is a mapping σ: X∪P∪γ → S that associates security levels with variables, ports, and interactions such that, moreover, port security levels match interaction security levels, that is, for allα∈γand for all p∈P holds σ(p) =σ(α). In atomic components, security levels assigned to ports and variables allow information flows within components to be traced and intermediate steps of computation to be controlled. On the other hand, communication between components (i.e. data exchange interactions) is monitored by the security levels assigned to the interactions.

This excludes the possibility of obtaining relevant information about occurrences of interactions (events) with a strictly higher (or incomparable) security level than, from the exclusive observation of the occurrences of interactions with a security level lower or equal to. Furthermore, the scope of any non-interference does not include the protection of the actual data transmitted through the interactions of the components. It shows the different security levels that have been assigned to ports and interactions for each of the components.

If there exists a settlement relation R, of all states in an input/output state machine M, for a given policy that divides the events into high security levels (H) and low security levels (L), then non-interference M holds for (H) and ( L) partitions [25]. This tagging keeps track of those variables whose value is directly or indirectly dependent on higher security levels. It starts with intuitively given security annotations for some of the variables in the system model and automatically generates a full security annotation for all variables and ports if the system is proven to be secure.

Otherwise, it locates the security issues and generates an error referring to the inconsistency of the security levels with respect to the initial security annotations. This synthesis approach ensures a formally proven end-to-end information flow security because it is based on the use of the security conditions defined in the previous sections. In secBIP, the information flow analysis of the system's model is based on the construction of a DFG, which considers the set of variables and gates in the model as nodes.

To perform a security synthesis, the algorithm takes as input a partial security configuration of the system and expands it to a complete security annotation. Furthermore, the framework synthesizes the complete security configuration for all system variables taking into account all implicit and explicit data dependencies.

Case study: Insurance Claim Service

In a decentralized environment, no central authority can determine the security policies of the entire system. The owner is the source of the data and the readers are possible destinations of the data. Because this action applies to each of the owners in the set of principals, there is no need for a centralized declassification process.

On the other hand, when it enforces an integrity policy, it specifies who can write to the data and keeps track of the principals who may have modified the data. Removing a policy in the label is considered safe because it limits the number of writers who may have affected the data and limits subsequent use of the value. These types of relabelings appear to be exactly the opposite of the relabelings described in section 3.1.

The DissecBIP model is basically the original BIP model of the system with the addition of initial security annotations for some of the system's data. The tool processes the model together with the acts profile and creates dependency graphs for the components of the system. If no configuration is found, the system is not secure and a diagnostic is generated containing the location of the security flaws.

The represents the allowed alternatives and the shows the occurrence of one or more components of the preceding type. To interpret these actions, thercv_msgport is the input of the data into the process and the write port stores the data in the data component. The BIP model is built together with the monitors and the fault injection component by translating the BPEL program and its WSDL definition.

After inspecting the BIP model verification output, the system designer partially notes the sensitive data (variables) contained in the BIP model data components. The clerk service is then called and creates the claim form containing information about the claim type and value. At the same time, a check is made on the value of the request (ie whether the value of the request is less than or greater than 5000) which is decisive for the following service calls.

If the value of the claim is greater than 5000, the serviceClerkVehicleorClerkHousehold is selectively invoked based on the second check performed on the type of claim. The information flow security requirements in this case study focus on ensuring the integrity of the claim form (d3) created by the clerk. To verify this approach, the system designer introduces his policy by partially annotating some variables contained in the data component of the BIP model.

Atomic components for the BPEL semantics [28]

Clerk service data items – security configuration output

AutoSystem (central process) – security configuration output

Referências

Documentos relacionados