In this blog entry, we continue our presentation of the benefits that the EU MASTER project brings to companies in the area of compliance. In particular, we explain the specific needs from companies, the way these needs can be addressed, and a particular research topic related to the configuration of compliance management tools for Service-Oriented Architectures.
The introduction of regulations such as the Sarbanes-Oxley Act requires organizations to design an implement an effective internal controls system in order to ensure that their processes are regulatory compliant. This implies that business processes are constrained in such a way that incorrect and illegal behavior is avoided when performing business activities.
A popular way for modeling and implementing business processes in today’s world is using the Service-Oriented Architecture (SOA) paradigm. In this paradigm, the functionalities of an IT system is structured in small units called services. Then, business processes are modeled to orchestrate these services in order to implement a business activity. The services providing the implementation may change independently from the process specification, thus enabling and accelerating business & IT alignment and agility.
- Facilitate the monitoring, enforcement, and audit of quantifiable indicators on the (security) constraints of a business process;
- Provide manageable assurance of the security levels, trust levels and regulatory compliance of highly dynamic service- oriented architecture in centralized, distributed (multi-domain), and outsourcing contexts.
Companies need to assess whether and to which extent a business is running according to some constraints and satisfies control objectives. To evaluate these constraints, evidence on the operation of business processes has to be collected and analyzed. Since business processes are nowadays often implemented as an orchestration of services, it is necessary to observe and analyze the behavior of services at runtime. Runtime monitoring allows to check whether some behavior happened in practice and it can check application data which is only available at runtime. As runtime monitoring requires evidence of runtime behavior, a business process and its implementation should not only satisfy the constraints, but must also produce evidence of its behavior.
Figure 1: Architecture of MASTER’s Runtime Infrastructure
Figure 1 depicts the architecture of the MASTER runtime infrastructure. At the bottom-level, we see that every Web Service is instrumented such that it produces events that represent its behavior. This instrumentation is called “Signaling”. Then, a component called “monitoring” aggregates, correlates and filters the events originating from the event streams which are produced by the different WS-specific “Signaling”-components. The “Monitoring”-component is basically an event stream processor which transforms (simple) system-level events to abstract or complex or business-level events which can be consumed by assessment and enforcement components. The assessment is responsible for measuring the degree of being compliant expressed as indicators while enforcement takes action when some non-compliant behavior happened. Assessment puts every event in a data warehouse and it performs some database queries to compute the indicators.
We illustrate the behavior of MASTER’s signaling and monitoring infrastructure with the following example. The IT Control Objectives for SOX (SOX-CobiT 2006) suggest “that procedures exist and are followed to maintain the effectiveness of authentication and access mechanisms” [1, p. 72]. Part of such a procedure could be the implementation of a centralized access control management solution that enforces access control in a Service-Oriented Architecture. A runtime monitoring infrastructure is required to measure the effectiveness of this access control solution. Consider now that the organization in the example implements an SOA , which is composed of Web Services that invoke an XACML  policy engine. This policy engine makes all the access control decisions for the Web Services in the SOA. We instrument each Web Service such that its corresponding signaling component emits an event when the Web Service performs an invocation to the XACML policy engine. Moreover, we instrument the XACML policy engine such that its signaling component emits an event when it receives an access control request. The different signaling components send their event streams to the monitoring component. This component runs queries that combine information from the different event streams. In this context, a query such as “report when we observe an invocation of the XACML policy engine by a Web Service and this event is not followed by an access-control-request event from the XACML policy engine” can be deployed. When this query evaluates to true, we know that a Web Service tried to invoke the XACML policy engine. However, the XACML policy engine did not receive the access control request. We can conclude that some suspicious behavior occurred and we report this to the assessment and enforcement components of the MASTER runtime infrastructure.
In the example above, we have seen that constraints and control objectives are defined at a high-level of abstraction. The runtime components in the MASTER architecture such as the event stream processor and the data warehouse are configured using “low-level” query languages such as SQL  and XQuery 1.1. In order to solve the gap and to achieve an end-to-end solution, language translations are required. Our research team at SAP Research France is doing research on these language translations. In future articles on SDN about the MASTER project we will describe more details about this translation.
For further information please contact:
Theodoor Scholte (firstname.lastname@example.org)
Emmanuel Pigout (email@example.com)
Philip Miseldine (firstname.lastname@example.org)
Hoon Wei Lim (email@example.com)
 The IT Governance Institute (2006): IT Control Objectives for Sarbanes-Oxley. http://www.isaca.org/Template.cfm?Section=Home&CONTENTID=17003&TEMPLATE=/ContentManagement/ContentDisplay.cfm, retrieved 2008-06-30.
 Oasis (2005): eXtensible Access Control Markup Language (XACML) Version 2.0
 E.F. Codd (1990): The relational model for database management: version 2, Addison-Wesley Longman Publishing Co., Inc.