SOA Security Beyond the Perimeter: A Talk With Anne Thomas Manes - Twenty-Four Seven Security

« What's So Funny About SOA Security? | Main | Mr. Freeze Unlocks Encrypted Data »

February 20, 2008
SOA Security Beyond the Perimeter: A Talk With Anne Thomas Manes

Make sure you sign up for what's certain to be an exciting and illuminating ebizQ SOA security roundtable happening next week Wednesday, February 27th. Sign up right here!

Listen to or download the 6:58 minute podcast below:

Download file

What follows is a transcript of my podcast with Anne Thomas Manes, Vice President and Research Director of the Burton Group, where we discuss SOA security -- how traditional security methods are insufficient for protecting SOA, why layered defenses are best, whether or not security will slow down an SOA deployment, and finally, what's coming in the future for SOA security.

What are top security concerns associated with SOA?

I would say that the biggest concern is the fact that with services, you’re exposing business processes within your organization and if you don’t properly secure those interfaces to those business processes, you’re now letting anybody in the world come in and access them.

And, you know, a lot of people think that well as long as I keep it only inside my firewall it’s reasonably well protected. But, you know, if there is a URL that provides access to a service, chances are somebody’s going to be able to connect into it. And the -- the idea that your perimeter is actually going to protect your internal systems is pretty dangerous at this point.

So you mention perimeters, which sounds a lot to me like a traditional security system. How come traditional security like perimeters and intrusion detection systems, how come they’re not sufficient to protect SOA?

They’re really good for protecting a single URL so as long as there is no links, or there’s no hops in the process, as long as you’re having a client talk directly to the service and you’re protected that one URL that’s providing access, then that might work okay. But the thing is that that when you’re -- we’re dealing with service-oriented systems, you typically have many different services involved in a process.

And as you go from one service, to the next service, to the next service, to the next service, you wind up losing all of the authentication information and you lose any opportunity to truly audit the process. And so you need some kind of mechanism to actually carry along the original user’s ID and to capture the path and all the different services that get touched in the process in order to capture the appropriate amount of information to support your requirements for, you know, all the regulations that are going on, or for e-discovery type of requirements and things like that.

So the traditional mechanisms that are out there typically are based on point-to-point security so they will protect a communication between one endpoint and another endpoint. And they will enable authentication between those two endpoints but they won’t provide the kind of security required to protect information when it’s sitting in an intermediary or propagate that authentication information on the next top in the process.

So is what I’m hearing, is it a layered defense would be best for SOA security?

Well, I certainly like layered defenses. So you got the idea. If you got your periphery on the outside, so you’re using traditional firewalls, using traditional virus intrusion detection and those kind of things because there’s an awful lot things that can filter out. But then, you also want to make sure that the individual endpoint does proper authentication, and you may actually want to put in multiple levels in between, which are giving additional levels of authentication, and capturing the audit trail, and other different areas.

So yes, I recommend that you use a combination of security protections when you’re dealing with a service-oriented system. You use the traditional periphery type of security measures, you also use identity-based security measures at the endpoints, and then potentially you use additional intermediaries to perform additional security capabilities like auditing, or cross domain, credential mapping and things like that.

Is it essentially a given that security concerns will slow down a SOA deployment?

Well, that actually depends, on how well managed your security strategy is. If you have too devised a security system for every single service, then obviously, that’s going to delay the deployment of a particular service. But if you’ve got security that’s automated and mechanized within your system, you could actually get it so that you simply deploy the service and then you can figure your security requirements at the service and it’s taken care of automatically.

That’s actually part of your governance program. You want to make sure that it’s part of your governance program, you have a standard security strategy and you just make sure that whenever service gets deployed that it automatically gets instrumented and secured according to your policies.

Right, that’s good to know. Now, what do you see as the future of SOA security?

At this point, I think it’s actually really easy to secure your environment. You just have to use different practices than what you would probably do just for your websites. There are some great technologies that are out there that will enable the kind of security that I’m talking about. Any platform that support Web services has the ability to support WS-Security.

So that gives you the ability to actually capture security information and pass it with the message and that’s one of the things that’s required to do the multiple layer defense approach. And then there’s some really good technologies out there from XML gateway vendors or from Web services management vendors who provide the kind of automated infrastructure that I was just talk about, which will automatically protect your services for you, and automatically configure the kind of management and security protections that you want, such that you don’t have to do a whole bunch of effort every single time you deploy a service.

So the basic security systems are in place right now, and that’s a wonderful thing, and I strongly recommend that people use these technologies to secure their systems. Now there are some additional things that are coming along so, for example, there’s a specification that was finalized last year at OASIS called “WS-Secure Conversation” and that actually gives you an additional layer of security by enabling two communicating service endpoints to establish a secure connection, and that actually is going to be more -- a more efficient way of establishing a secure conversation so that you don’t have to authenticate on each interaction.

You setup the connection once and then you use that connection for a series of exchanges and stuff, and so therefore, you amortize the cost of that initial connection over time. Two additional specifications: WS-Trust was also standardize last year and then WS-Federation just began. These are systems that allow you to establish security token servers, a place where you can go get a security token and it’s actually a component of WS-Secure Conversation to get these tokens to create the sessions.

WS-Federation, now, allows you to actually create a mechanism to cross domains, which is something that’s -- is inherent in business-to-business type communications and also even within a given organization. If you got a large organization with a lot of different business units, you probably have different security domains. And so being able to cross those security domains is a challenge today and right now you have to do a credential mapping, you have to put it an intermediary in between and have them actually map credentials one to the other. But if you can have that more automated that is probably going to be a nice feature. It’ll probably be two or three years I think before that’s really implemented in products but that’ll definitely make life a little bit easier.