Mitigating Security Risks in Web Service Invocations: Contract-Based Approaches

The pervasiveness of Web services increases the necessity for consumers to access and use them in a secure way. Besides secure communications, consumer security also involves providing strong guarantees that a requested security policy is satisfied. Needless to say, remote services are adverse to most techniques of control and analysis that usually require direct access to either execution or implementation. In this chapter, we classify service execution paradigms and provide a characterization of the security threats that may affect a Web service infrastructure depending on the elements composing it. In particular, we provide a discussion of the threat models for several different Web service paradigms involving service consumers, providers, and platforms and illustrate how and when contract-based security approaches and its variants can be applied for mitigating risks in service invocations in the identified paradigms. INTRODUCTION Web services offer various functionalities to its consumers, including data storage, information retrieval, social interaction, and more. A service and its clients interact through specific interfaces defining the syntax and semantics of the exchanged messages (and their parameters). Papazoglou (2007) defines some key roles for Service Oriented Computing; among them, the service consumer and the service provider are the two most important ones. The two entities share knowledge only about the service interface, i.e., the protocols that they use to communicate. Existing protocols can guarantee security properties, e.g., authenticity and secrecy, on these communications. However, messages can carry complex data or even executable instructions, for example, mobile code, which makes the computation distributed over the involved systems. Needless to say, mobile systems exacerbate the problem of providing security guarantees for both service consumer and provider. Recently, some proposals highlighted the advantages of including a third entity in services architectures, that is, the service platform. In general, a service platform offers support to both consumers and providers. For instance, consumers may ask the platform for information about a service, e.g., its cost and its provider identity. Similarly, providers may obtain support for the orchestration with other services. Clearly, each feature of the platform must be implemented by appropriate components. When consumers and providers interact with a service platform, they implicitly accept it as a trusted entity and they expect it to provide protection against possible misbehaviors. According to its designated purpose, the platform may include support for service publication and discovery, service composition, mobile code signature, and even execution. In this chapter, we provide a characterization of the security threats which may affect a Web service infrastructure, according to the elements composing it. In particular, we provide a classification of the threat models for different Web service paradigms involving service consumers, providers, and platforms. We consider the consumer point of view and examine three main resources in each paradigm: the service code, the service contract, and the consumer policy. Furthermore, we survey techniques that have been proposed for assessing security issues. Then, according to the availability and reliability of the resources, we show how contract-based approaches, such as Security-by-Contract and its variants can be applied to guarantee the security of Web services. The result is a precise characterization of the necessary conditions for the application of the security assessment methods for the Web services. The chapter is organized as follows. The next section provides background information on protection techniques for assessing security aspects in a service-driven environment and presents related work in the area. Next, service composition paradigms considered in this work are discussed followed by an illustration of how and when Security-by-Contract and its extensions can be applied for guaranteeing security. Finally, a discussion about future work and some concluding remarks are presented. BACKGROUND Several techniques have been proposed to tackle specific security aspects. These approaches may be combined in security frameworks or used to guarantee the reliability of third-party provided resources. In our context, resources are the service code, the service contract, and the consumer policy. We assume that each consumer specifies its security requirements, herein referred to as policies. A policy is a security requirement that a consumer wants to apply to a service execution. In general, consumers want to be sure that their policies will be respected during service execution. A violation happens when a service S behaves in a way that is not allowed by the policies. Thus, a threat corresponds to the possibility that a service violates a policy. Usually, consumers have more than one policy to be satisfied by a service. Generally, service providers release interface information about the provided service, called the service contract. A service contract is a formal description of the service behavior. Contracts typically describe the service in terms of interaction protocol (e.g., input and output channels, message syntax, parameter types, and encryption algorithms) and service computation (e.g., message semantics, service state transitions, and resource usage). The techniques listed below exploit these resources for obtaining security guarantees. In general, these guarantees consist in proving that precise relations exist among (two or more) resources. Evidence checking: In order to verify a piece of code statically, some methods use an entity provided proof (evidence) and validate it. This entity can be a trusted third party or the developer itself. The proof is linked to the code, e.g., through instrumentation, and the provider originally computes it. Verifying the validity of the proof is more efficient than generating it. The verification procedure follows the steps of the proof and if all of them are correct, validates its conclusion. In our context, the proof conclusion can be the compliance either with a contract (code-contract verification) or with a policy (code-policy verification). Notice that, as the proof is computed by the provider, allowing customers to specify their own policies requires new proofs to be generated. By the way, that makes this solution extremely cumbersome for service providers. An instance of this approach is the model-carrying code method (Sekar et al., 2003). Compliance verification (Matching): Static analysis techniques can be applied in order to certify that a specification, e.g., a contract, is compliant with a required policy (contract-policy matching). However, tools for verification suffer from the high complexity that rapidly grows with both the expressiveness of the formalisms and the size of the specifications. Moreover, since the steps of the verification chains can take place at different locations, we need some guarantee on the reliability of these results. Enforcement: The run-time enforcement approach consists of running a service code inside the scope of a controller, which checks its execution step by step. At each operation, the behavior of the service is compared with the consumer policy (policy enforcement). As violations are prevented, the controller guarantees that the service running in the controller context satisfies the policy. Many implementations of the policy enforcement approach have been proposed (Bauer, Ligatti, & Walker, 2005). Nevertheless, they poorly fit with the distributed computation, typical of Web services, where often there is no single location where the code is executed. In addition, the reaction of the enforcement mechanism to violation detection can modify the standard service behavior, e.g., by closing a session beforehand, thus introducing session failures. However, in some cases, an enforcement facility can be included in the service execution environment, provided by a service platform. Monitoring: In contrast to enforcement, the monitoring approach only observes the behavior of the service. The monitor does not intervene in the execution and only notifies the interested party (e.g., consumer) about the events that occur. This information (e.g., audit logs) is analyzed and decisions are made about possible violations of the contract (contract monitoring) or the policy (policy monitoring). Such a monitor, which does not alter the behavior of the code, is called a passive monitor. Quantitative assessment: Security metrics aim at assessing security threats by releasing the assumption that a system is either secure or not. These techniques use non-binary quantities, e.g., real or natural numbers, in security domains for representing the available knowledge about a system. For instance, metrics can describe a system in terms of its reputation in a community, number of past successful interactions, or average number of failures per year. Then, these values are exploited in order to make security aware decisions. Among the others, trust and risk aspects are receiving major interest. Henceforth, we will discuss contract-based approaches that are able to guarantee security at runtime in Web services. These approaches cover almost all functionalities described above combining several aspects of these assessment techniques in an integrated way. In (Dragoni & Massacci, 2007), the Security-by-Contract framework has been applied to Web services for client-server interactions. In particular, the authors only consider cases in which the client retrieves and executes the full service implementation. In this chapter, we cover this case and extend the application of the Security-by-Contract framework by presenting new variants, which fit better with more realistic and common scenarios. Jones & Hamlen (2011) present a mechan