Publications & Resources

This blog also tries to provide a forum for publications about SOA security. Please put any abstracts into the comments of this message and we will merge them into the main message.

Here is our publication at ISSE 2007:

Model driven security for agile SOA-style environments
Dr. Ulrich Lang & Rudolf Schreiner
There is evidence that many IT security vulnerabilities are caused by incorrect security policies and configurations (i.e. human errors) rather than by inherent weaknesses in the attacked IT systems. Security administrators need to have an in-depth understanding of the security features and vulnerabilities of a multitude of ever-changing and different IT "silos". Moreover, in complex, large, networked IT environments such policies quickly become confusing and error-prone because administrators cannot specify and maintain the correct policy anymore. Agile service oriented architecture (SOA) style environments further complicate this scenario for a number of reasons, including: security policies may need to be reconfigured whenever the IT infrastructure gets re-orchestrated; security at the business process management layer is at a different semantic level than in the infrastructure; semantic mappings between the layers and well-adopted standardised notations are not available. This paper explores how the concepts of security policy management at a high, more intuitive (graphical) level of abstraction and model-driven security (tied in with model driven software engineering) can be used for more effective and simplified security management/enforcement for the agile IT environments that organisations are faced with today. In this paper, we illustrate in SecureMDA™ how model driven security can be applied to automatically generate security policies from abstract models. Using this approach, human errors are minimised and policy updates can be automatically generated whenever the underlying infrastructure gets re-orchestrated, updated etc. The generated security policies are consistent across the entire distributed environment using the OpenPMF policy management framework. This approach is better than having administrators go from IT system to IT system and change policies for many reasons (including security, cost, effort, error-proneness, and consistency). The paper also outlines why meta-modelling and a flexible enforcement plug-in model are useful concepts for security model flexibility.

Gartner Hype Cycle for Information Security 2007

Gartner has just released their new Hype Cycle for Information Security 2007, and model driven security is on it. ObjectSecurity's OpenPMF 2.0 (www.openpmf.com) has been identified as aleading product in this emerging area.

This shows that Gartner believes that model driven security is a critical technology approach to simplify enterprise security.

We believe that model driven security plays an important role for securing agile SOA, as illustrated at www.trustedsoa.com.

This blog is a public forum and we are welcoming any views on this.

Related blogs

There is a related blog at www.modeldrivensecurity.org and one with more of a middleware security focus at www.securemiddleware.org.

Looking for TrustedSOA, the SOA security solution?

If you got to this webpage because you are looking for TrustedSOA, ObjectSecurity's innovative SOA security solution, then please go to:

www.trustedsoa.com

or

http://www.objectsecurity.com/en-products-trustedsoa.html

“Brittleness” is a feature, not a bug!

I often hear that standard middleware, be it Web Services based on SOAP or CORBA is too "brittle" for the real world. The provider and the user of a service of such tightly coupled systems have to exactly agree on the interfaces on both sides. This raises problems, because these interfaces always have to be kept in sync, which is hard to manage in real life. If one side changes the interface description, expressed in WSDL or IDL, then the other side does not understand the data transferred anymore.
A often proposed "solution" now is a document centric, loosely coupled message system. Instead of well defined information, now documents, mainly in XML, are sent around and the receiver has to understand only the "relevant" parts. Other parts of the message are processed, modified or reordered somehow.
Great idea! Did the people suggesting this ever hear about type safety and its benefits? What about safety in general? Why do safety critical domains like military or Air Traffic Control use a strict code even for vocal communication? Because in this case both sides exactly know what's going on the other side!
In the loosely coupled approach you never exactly know how a message is handled, whether the ignored parts are relevant or critical.
So strict typing is a feature, not a bug! At at least it gives a clear error message, instead of making a system completely indeterministic.
OK, but the problem is still there! It is a fact that big enterprises have problems to handle all the interfaces, to keep them all in sync. Just by saying that strict typing is a good thing, the problem does not go away.
The real solution is not on the middleware side, a too loosely coupled middleware can be avoided. The solution is on the development and management side. In order to avoid interface clashes, good enterprise wide development tools, e.g. versioning systems with detection of conflicts, and a strict observing of best practices are needed.

Reusable Services and Granularity

The main point of SOA is reusability of components and services. Implement a service once, and then use it by other services or components. One of the standard examples is a service for checking a credit card. Such a service is indeed simple to define, the interface is straightforward and always uses the same set of arguments, e.g. the holder's name, the number, date of expiry and the amount. A good example to sell SOA.

But in reality, for more complex services, reusabilty is easier said than done, even with state of the art platforms like SecureMiddleware.
I wanted to implement a SecureMiddleware component representing a GPS receiver. This component is to be used by several other services and applications, e.g. a navigation system or prototypes of emergency management systems.
OK, no problem, I thought, a GPS receiver has a quite simple interface, and I just have to map the GPS interface to the component interface, to be used by the other components.
First of all, I needed to develop and test the component business logic, the interface code to obtain information from my good, old Garmin. So I ended up with an interface providing the satellite positions, signal strength, and a lot of error codes. This interface was very complete and provides everything you ever want to know from a GPS receiver in form of a few operations sending around a lot of data. Fine, worked!
Then I wanted to use the GPS receiver for my applications. The existing, coarse grained interface and its operations provided much more data than I needed in my application. So I splitted up the interface into several calls to just get specific information with a single call, e.g. the position. This fine grained interface worked, but was very inefficient, because of the overhead and latency of the multiple calls. Not good either!
So I implemented an additional interface which exactly matches the requirements of my navigation application. Great, now it is efficient, I get exactly what I need in a single call. I do not wast bandwidth with the transfer of unnecessary large chunks of data and avoid the overhead of multiple calls. But if I change the data required by the application, I also have to adapt my GPS service component, which makes the application quite brittle.
If I want to reuse the component by other applications, I have to add additional interfaces. For example when I wanted to transfer the GPS position over a wireless link based on GPRS, I again had to define an interface exactly meeting the requirements of this application. Multiple calls did not work well, due to the high latency of GPRS, sending more data then necessary was forbidden by the cost model of the GPRS services.

So instead of a single component with a single and universal interface I ended up with a single component with multiple interfaces of very different granularity, each exactly tailored for a specific use. I can reuse this single component from all my current applications or other components. But I doubt this approach of multiple interfaces is really in line with the concepts of SOA. At least SecureMiddleware's Policy Management Framework allowed a flexible definition of security policies, so I did not need to implement policy enforcement in the component code. This would completely kill reusability.
So while reusability of services sounds very good in theory, it is hard to achieve for non trivial services, esp. if Quality of Service of efficiency plays a role.

Loosely coupled/decoupled?

We at ObjectSecurity have looked at loosely coupled systems and the idea of decoupling for more than a decade now. Over the years there were various incarnations of middleware, and now there is SOA. Since the advent of component based systems (e.g. CCM, J2EE) and XML webservices, the issue of coupling as been (somewhat) tackled. That is, it has been tackled on a syntactic level: well-specified interfaces and service/component descriptions can be obtained from somewhere (e.g. in a SOA registry, WSDL/UDDI, CORBA trader service) and the consumer can connect to the provider. However, on a semantic level everything is still as tightly coupled as before - the consumer needs to understand what each parameter actually means, and both parties need to have a common understanding of the meaning of parameters descriptions passed around.
So what really needs to be tackled for SOA decoupling is the semantic decoupling. There are numerous ways of doing this, such as information modelling and metamodelling. ObjectSecurity has spent several years researching model driven concepts (esp. for security policies) and we believe that this is doable as long as everyone 100% sticks to the conventions. Contact us if you would like to know more about this. Any comments are also more than welcome.

Our SOA definition and scope

Another 'setting the scene' issue is related to the fact that there are about as many SOA definitions out there as there are SOA experts. These definitions range from as narrow as possible (just XML webservices) to as wide as possible (BPM based orchestration of IT service components dependent on business process usage, e.g. in BPEL).
In this blog, we are explicitly looking at the widest definition of SOA: We are interested in SOA because its orchestration based on business processes using BPM/BPEL etc. can provide great value (especially if combined with MDA). In our definition, the SOA ESB does not have to be implemented using XML webservices, instead any middleware that meets the requirements could be used. ESB is also quite a badly defined term - we will mainly use it for a collection of (several) middleware technologies, registries, repositories etc.
So this definition may explain why we will be talking about business processes etc. quite a bit.

SOA and model driven security

FYI - SOA and model driven security are also discussed at our other blog http://www.modeldrivensecurity.org/

Manage SOA expectations, and SOA assurance

Before we get going with discussing the various pitfalls and issues of trusted SOA (and SOA in general), I would like to 'set the scene' by stressing the positive side:
SOA can be a great step in the right direction if it is properly managed and if it is sold to decision makers in comparison to the current state if IT integration, agility, reuse, and alignment with business processes. Even if the benefits maybe cannot be attributed to the fact that SOA (e.g. using web services) was used, the fact that IT integration is done in a structured way is invaluable. There are SOA 'success stories' all over on the web, but most of them really do not leverage the idea of SOA - they are simply success stories about productivity gains through systems integration. But it is the result that matters.
Our particular focus is on how to use SOA to build and maintain agile IT systems in a secure way. This is why the blog is called "Trusted SOA". We believe that one of the main show-stoppers for SOA is the lack of (information and software) assurance, and we want to raise awareness of the issues and potential solutions.
In this blog, we try to be as vendor independent and hype neutral as possible. So if you have any issues or feel inappropriately represented, then please contact us.
And comments are of course welcome - we will weave them into the main blog if you like.

Welcome & Introduction

On this blog, we will discuss our thoughts about various aspects of service oriented architecture. For example, we will elaborate
- why middleware adoption previously often failed (because of lack of leadership and the cost hurdle with delayed ROI),
- why achieving decoupling is actually difficult,
- why agility and security can conflict unless a good modelling design is used,
- how models for business processes, information, and IT infrastructure can be matched in a traceable way using MDA.
- the importance of traceability for assurance and why traditional methods fail
- when to do SOA and when not to do it.

Any comments on SOA and security are greatly appreciated.