Complete Transcript: SOA Security -- The Real Deal or Much Ado About Nothing?

Participants in this Webinar include Mike Rothman, President and Principal Analyst, Security Incite; Fred Etemadieh, Chair of The Open Group SOA-Security project; Gunnar Peterson, Managing Principal, Arctec Group and Andrew Brown, AmberPoint's Director of Security Product Marketing, AmberPoint

To listen to a full replay, click here.

Mike Rotham: Welcome to the SOA Security Roundtable. My name is Mike Rothman and I will be the moderator and one of the presenters for today's program. Before introducing our Webinar today, I would like to take a moment to acquaint you with the features of our highly interactive online environment trade show. Say that ten times fast, I dare you. You can use the chat function to communicate with any of the folks attending today's session.

And you can send a business card or leave a message or do all sorts of stuff. And we'll also be taking questions throughout the session. Part of my role as the moderator is to monitor the question line and make sure that we are answering pretty much all the attendee's questions. So you can do the -- click on the “Ask A Question” button on the gray bar console. And if you want to enlarge any of the slides, click on the magnifying glass icon to the right of the slide.

So enough with this housekeeping stuff, let's -- let's get into the meat because I know everybody dialed in and are spending a lot of their time today with us to really focus on SOA security. So the title of today's broadcast is SOA Security: The Real Deal or Much Ado About Nothing. And I do want to send a little shout-out to the Webcast sponsor AmberPoint and -- and we'll have a representative from AmberPoint on the panel so it'll be a lot of fun.

So with that, let me take a minute and allow our panelists to introduce ourselves. First we'll start with Gunnar Peterson. Gunnar, Managing Principal from Arctec Group. Gunnar, if you could, say hello and may be explain a little bit about who you are and what you do.

Gunnar Peterson: Thanks Mike. My name is Gunnar Peterson and I'm a Managing Principal at Arctec Group Consulting, which is a boutique architecture and security architecture consulting firm. And we provide architectural services and training services in SOA and security.

MR: Great. Thank you, Gunnar. Next up we have Andrew Brown who is Director of Security Product Marketing for AmberPoint.

MR: Andrew, why don't you say hello and tell us a little bit about yourself.

Andrew Brown: Good morning, I'm Director of Security Product Strategy here at AmberPoint. I -- in the past have worked as an XML security evangelist at VeriSign. I've participated in WSI in the early days helping to define some of the early security profiles and been involved in SOA security essentially from the beginning.

MR: Great. And last we have Fred and I'm not even going to try to butcher your -- your last name, my friend. That would not be the -- the right way to start off the panel. So Fred, why don't you give us the proper pronunciation of -- of your last name and explain a little -- a little bit about what -- what involvement with SOA security is.

Fred Etemadieh: Yes, this is Fred Etemadieh. Thank you for inviting me to this panel. It's a pleasure and I am the co-chair of SOA Security which is a hybrid of a group of people. One side from the SOA Forum and the other from Security Forum trying to merge the concepts and ideas that are sending out of these two teams and putting them in some form of a guidelines for community to use. I'm very pleased to be here.

MR: That's great, Fred. Thanks. And again, thanks to -- to all of our panelists for -- for spending some time with us today. And obviously, ebizQ who is the -- the organization that's -- that's running the Webcast today. And obviously, once again to send a shout-out to our sponsor AmberPoint. So with that, let's get going. Oh, I should probably introduce myself a little bit. I just in my own inflated opinion, believe probably everybody knows who I am but that may not be the case.

I'm Mike Rothman; I run a boutique research shop called Security Incite. I'm a featured analyst within the ebizQ Network Security function so I -- I write a monthly feature as well as do a do a monthly podcast for my friends at -- at ebizQ about application security topics. And I've been in this space for a long time I know where the bodies are buried.

So let's move on and you know really kind of go into a little bit about SOA and why it's important and everybody's talking about SOA. A lot of people are really kind of enamored with the technology and the openness and some of the architectural aspects of that.

So Gunnar if you would, could -- could you kind bring us through a little bit of an explanation as to why SOA is important and then maybe elude to some of the potential security risks that we add by moving towards this kind of Web services mentality.

GP: Sure. So I -- I think that businesses and technology vendors are moving towards SOA because there is a missing interoperability layer in the -- the tools and technologies we use to build systems today. So if you go into an enterprise you will find lots of applications written in Java, different J2E platforms, .NET platforms, various UNIX type environments, mainframe and so on.

But at the end of the day, the customers and the business people really don't care about IT complexity. What they really care about is accomplishing some task, running transactions, updating customer information and so on. So the goal of SOA or SOA is to get these systems to work together more seamlessly through open standards.

And so if you think of Web services as a working implementation of what SOA is trying to do that's -- that's one example, but you can certainly do SOA without -- without Web services. Just so happens that Web services are probably the highly adopted a way of the doing it and probably the most advanced environment to do this in today.

MR: Sure.

GP: But the kind of thinking that goes into building interoperability, things like reusability and abstracting the interface from the implementation has been around since object oriented programming and component programming and other competing paradigms.

So it's not so much that if the new -- totally new paradigm as much as we now have standards that can help implement some of the good ideas from the past and bring these systems together to work together. Now to the security point, I think it's fair to say that security always lags technology.

So whatever is coming out of research and development or new technologies, new programming paradigms, security is really pretty much always going to be behind the curve. Now, there are some interesting standards and tools that will I'm sure talk about here today to help deal with security issues in SOA but they really came along after the fact in many cases.

Certainly, SOA and XML were invented before WS-Security. And if you look in Web 2.0 space, sort of the next wave that's coming, you see that security hasn't even really begun to be factored into those discussions. So I bring that up because technology outpaces security. Security is always playing catch-up and it's wonderful that SOA and Web services are going to help us get our.NET systems talking to our Java systems, and our Java systems talking to our PERL systems and so on.

But the problem is that you have many security models than need to fit together as well. So there's a security model for authentication, authorization, auditing inside of .NET systems. And there's a different authentication, authorization, and auditing system in your Java system. And when you create an interoperability layer to a service, you have introduced now a third security model and they all need to be meshed together and work, ideally, seamlessly.

And -- and that's sort of the grand challenge, I think, in security in service-oriented architecture is to mesh together these different security models, which in some cases have different ways of representing that you use for authentication, authorization, and auditing and get them all to work together the same way the applications do.

MR: Yep. Okay. So that's actually good -- a good overview. So if we go back to the first kind of set of statements you made, Gunnar, in terms of kind of what SOA does and you know, how attractive it is and why it's attractive? You know do you see applications or SOA applications being deployed in production environments today or do you think people are still kicking the tires or a lot of experimentation along those lines, or any, I mean you spent a lot of time training folks about many of these issues so given are they early in the process of trying to figure out which end is up or are these folks actually kind of doing this stuff in the real world now?

GP: Well, I definitely think there's a lot of real world SOA work out there. And I think that you're not seeing as much -- it's not something that is takes over your entire system so in some respects it's not the same kind of wave that hit like when BEA came out with WebLogic and became the first and fastest company ever to $1 billion because everybody was suddenly rebuilding their applications top to bottom on J2EE.

MR: Right.

GP: So in SOA what you have is people are sort of tinkering at the edges and building core business assets but they're not necessarily, in most cases, rewriting entire applications stacks. So they're writing new interfaces and improved ways to reuse some of the business logic and data assets that they have but they're not necessarily doing top-to-bottom rewrites.

But having said that, I think it is a very widespread paradigm these days, definitely, in the enterprise. And to some extent I think if you talk to the people in the .COM type spaces and Amazon and companies like that, they would say that they have very advanced SOA environments so your result of calling your Amazon.com homepage is actually probably 65 or more service calls.

So your gold box, your recommendations, what comes up on the homepage, plus they're all little independent units or services that go that one screen and they can be plugged and played in lots of different ways and so I think there's a lot of good examples. Again, I have customers who are all over the map in terms of adoption. Some are very far along and have been doing this for five years or more, and some are just getting started.

And again, when I see the companies that are just getting started, many of them are just trying to get a real basic bootstrap environment up and running and they're not asking the questions around security and around policy that people who've been doing it for a couple of years inevitably need to when they start to “run their business” on this stuff.

MR: Yep. Fred, I know we're talking about standards a little bit later on in the session, but are are you seeing it's a similar set of anecdotes as Gunnar did relative to adoption in the folks that you're dealing with at least from The Open Group standpoint?

FE: We do. And I just want to underline a couple of points that Gunnar brought up. Interoperability is a point that directs itself towards the standards. So when you have a multitude of different entities that are trying to communicate with one another through services as I think that SOA is promoting at this point.

You will realize that consummates are abandoned and one begins to focus in organizations such as ours, The Open Group on promoting, common and efficient means of intercommunication. And that is, I think, where the standards play a significant role. So you have major players both on the side of vendors and on the side of users -- consumers who are very eager to make sure that not only we can communicate with one another through the VaporWare of Internet, but also that it is secure.

And in addition to authenticity, authorization, and audition, the terms that we regularly hear, we also have from time-to-time you might hear a term called “CIA”, which stands for confidentiality, integrity, and availability. These terms are very commonly used and they in each category you can write whitepapers and, of course, guidelines to try to bring the focus of the industry both on the consumer side and on the vendor side toward a focal point where we can see more and more transparency on the part of communication.

And I would like to very briefly also introduce a -- a forum called “Jericho”. And the point of Jericho in the Open Group is if you guys have not heard it; do go to Open Group and type in Jericho, J-E-R-I-C-H-O. And their focus is de-perimeterisation, which is which is removing the barriers and -- and the perimeters of -- of -- of the security boundaries surrounding each entity to the best that it can -- conducive to -- towards a free flow of information.

MR: Yep. I think that's a good point. Obviously, I've been following what The Open Group and Jericho has been doing for a long time relative to that. You know, I mean, to me a lot of the advantage of SOA is really as Gunnar said flexibility. It really is interoperability. It's a lot of these activities that, obviously, make it easier to change, and adapt, and become more kind of nimble as an organization.

And you know, he mentioned a little bit about kind of a lot of the Internet startups and many companies that are being built today that are using SOA-based models as the way they build their business by definition because it just gives them a lot more flexibility to be more nimble in a business environment. And this is really a macro statement business environment that is really changing dramatically and requires organizations that are going to survive for the long term to be able to really react quickly to what's happening out there.

We do have a poll here because I know it's great to get the attention opinions of folks on the panel, but it would also be great to hear from our attendees in terms of where they are relative to the deployment of SOA-based applications. So if your question should have popped up in your little interface. Just click on which one you feel it is and we'll kind of talk about that in a minute or two. I'll give you folks a minute or two to do that.

You know while we're at that, I want to talk a little bit about kind of the security aspects again. Gunnar gave a great overview in terms of some of the architectures and some of the differences that are required relative to how we need to think about security differently in SOA but I certainly have an opinion and I'm going to want Andrew's perspective on this.

But you know I'm not sure we know exactly what a lot of the ramifications of SOA from a security standpoint are because what we're doing is really decomposing applications. What we're doing is really kind of say data, and application logic, and presentation are totally different now. They're totally separate. They're not really dependent and through these set of common interfaces and, common architectures whether it's .NET or J2E those are obviously the two big ones.

You know I'm not sure we've kind of given enough thought to the idea of how we need to provision security, how we need to protect data in this kind of SOA-based model. I mean, Andrew, have you guys kind of thought a little bit about that and as part of your kind of SOA management and infrastructure offerings really factor in security from that standpoint?

AB: We start up at far more than a little bit, I would say. In fact the basic story with security is it's really critical that security is not bolted onto a solution as an afterthought. That's typically how solution for security emerge and how are implemented. So I would say that with SOA going back even to the early days of the definition of XML encryption, XML signature and the follow on definitions of WS-Security the codification and the WSI profiles.

I would say that quite a bit of thought and care has been put into defining how we do we secure, specifically, the Web services infrastructure that's being deployed. Of course, SOA is a much bigger now than only Web services, but Web services piece, I think, is indicative of the amount of forethought that's been put into the issue of security because, of course, within Web services the message is in fact in some senses the application itself and so what we've had to focus on initially is really providing the integrity, and the confidentiality, and the other security primitives around that level of messaging, which really comes out of the whole model which is really more fundamental to SOA, which are the concepts of really loose coupled, right.

And in fact, if you go through and then you and look at an old core concept of SOA such as loose coupling and reuse, you find that they have the kind of a flip side right. The benefits of opening up your applications and your data have kind of unintended consequences reuse leads to unintended reuse. And loose coupling, you can't have big locks if you're going to encourage a loosely coupled architecture with your services.

So that's why AmberPoint provides above runtime governance and we really see security as being fully intertwined with the concept of governance. And by that I mean, really that on the hand, you have to govern your security mechanisms but you also have to secure your governance procedures. So we're really not talking about point solutions for security.

It's not a question of how do I build and implement WS-Security, or how do I apply PKI to my SOA; it's really a matter of thinking holistically. How do I build a trustworthy a SOA and so it raises all of these other issues of visibility and discovery. So, for example, how am I going to secure services that are deployed to my SOA if I don't know that they exist and if I don't know how they're wired together?

Because as we know and, particularly, in distributed SOAs given their heterogeneous nature, the fact that they're created by distributed development teams, it can be really difficult to align all the architectural designs with what's really going on in the runtime reality of that environment, what's deployed, how are things wired together, what are the performance characteristics, who's consuming the services, who am I likely to impact, if I do change security policy on the server side?

By the same token, there are issues of integrity and -- and configuration. Really, and the idea of that if applications are not functioning as you expect them to, or if in some way the configurations are out of synchronization, those can create larger security issues. In fact, -- and you know, just that the application of a -- of a point solution.

So it's really critical to combine all of these various aspects into a solutions that's going to provide SOA Security on a holistically and in line with governance as you kind of expedientially increase the complexity of your environment as you're deploying heterogeneous services in multi-vendor environments with numerous intermediaries as participants in transactions in terms of gateways and enterprise service buses providing all kinds of intermediary security as well as locking down the endpoints and enabling security for the client applications that are trying to consume your service provider applications. So just to summarize that we really see security not as an isolated problem; it's really -- it's really one aspect of probably governance.

MR: Okay. And -- and that's that's a great point. But, Andrew kind of following up on that are you seeing any variation in terms of one, whether it's their adoption of SOA or their understanding of the security issues inherent to SOA across vertical markets. So you know, financials doing something different because, obviously, there's a huge kind of regulatory oversight in healthcare, versus manufacturing, versus maybe some of them of the government environments out there that may or may not be embracing these kind of these application architectures. So, what are you seeing along those lines?

AB: Sure. Absolutely. Every vertical that you go into is going to have something form of regulatory compliance required. You know when we deal with financial services; the question is all about access control, auditing, integrity of financial information. We have customers in the health vertical who are managing what's defined by the HIPAA regulation as electronically protected health information.

And so, that doesn't really boil down just to implementing encryption on the various services. There's also the aspect of integrity, there's issues of intelligently kind of defining the data that's covered under these regulations and then having the infrastructure introspect on the messages that are being transmitted in and intelligently removing the information that shouldn't be provided.

And especially in a lot of cases when you have participating intermediary applications, there's really a need to keep an SOA which is distributed, and loosely coupled, and it has various collaborating applications that are going to create these composite applications that deliver services. There's really the issue of keeping all of your internal services on a need-to-know basis and that's one area where we're seeing probably most of the pain points on the security side.

How do I really lock down this data and overcome some of the challenges of encryption associated with key management and all those other complexities and really find lighter weight solutions that provide content filtering that sort of changes the need-to-know, and makes it basically easy to actually share the data that shared in a way that is in line with regulatory compliance.

Because as we know, these regulations have been in a sense been given a real teeth and they carry with them significant risk to the enterprise in terms of damage to the brand in terms of jail time for executives. So yeah, that regulation -- each vertical's impacted by that and are a number of different ways of approaching it and regulations really need to be addressed by governance with security mechanisms in a policy-based approach that really lets you centralize the security behavior of all you applications while letting the applications themselves secure that data in whatever way is appropriate for them to do so.

MR: Yeah. Hey Gunnar, I have found kind of have you expand a little bit on that because right when you -- you were talking before, you had said you have some clients that there are, obviously, very advanced, you have been doing SOA for five years they really think about security policy and others that are basically just trying to you know, kind of crawl and -- and get forward motion a little bit.

So we kind of restrict our thinking to those folks that are fairly mature from that standpoint. But are you seeing any variation in verticals and as well are these folks looking at building kind of a security utility so to speak, so that they can once again kind of loosely couple their security infrastructure with a lot of these SOA applications? Are they in some cases building into certain SOA containers because that's what they have to do? You know how do you see people starting to try to address that issue?

GP: Yeah, I mean, I think you hit a lot of key points so first to the industry-specific thing. I see exactly the same thing as Andrew sees where there's -- the way that people go into this is stratified by the industry that they in. And to some extent, it's also stratified by whether they're going B-to-C, or B-to-B, or inside the four walls, which is another sort of matrix you can look at in terms of what would people do and why.

So do I own both ends of the pipe for one thing? And I would agree with his characterization in terms of healthcare versus financial having totally separate concerns. I think it's interesting to look at the financial services industry and what they do and don't address. They've driven a lot of what we have in security and to some extent they really -- their concerns really don't match what healthcare, insurance, or manufacturing would seem to care about.

And so there's -- probably a lot of the financial services folks can learn from other industry sectors. The other point that Andrew raised around getting started and the sort of crawl, walk, run. These tools, Web services, SOAP, WSDL, they're really designed to empower developers and make developer's life easier, which is a great thing from delivering software standpoint.

From our security point of view; however, my sort of rule of thumb is anytime you're making the developer's life easy, you're also making the attacker's life easy. And so if you have a tool like Eclipse or Visual Studio, they are running your applicants and -- and it's automatically building Web services interfaces to your applications.

Then in some cases the developers either don't know, or don't understand the security implications -- they push F5, or compile, and build and deploy, and it goes out and you go and scan the server and low and behold, there's the whistle for all of the methods, for all of your critical data directly accessible on your mainframe.

And you sort of just published the map to the keys to the kingdom for all the world to see and done so unknowingly. So there's real problems from a security standpoint with crawl, walk. I'm not advocating for a top-down approach to all of this but I'm just saying there are some emergent behaviors that come out of just linking things together and not necessarily thinking it all the way through. You know that's sort of the crawl problem.

MR: Yeah. Go ahead.

GP: I didn't mean to break because one of the key issues is really for SOA. You want to offload that security processing from developers and I think your point that they're generally aren't enough security resources available. Some developers might not be proficient in the area of security, they may only just been learning about deploying SOA services.

And so that's why it's really important, I think, for you know, from the perspective of governance to provide a mechanism that really offloads that development and I think from the idea of a utility, I think it has a couple of implications but really I would say, yes, offloaded it to a dedicated solution that provides for centralized management of security policy and really set your developers free from having to worry about implementing first of all, security features like WS-Security, implementing PKI, and dealing with T-scores, and -- and so which they may not necessarily be resident experts in. And then offload that to a centralized solution.

FE: I guess what I would sort of adocate for is, is some sort of a hybrid. And I would say centralized in our -- in the classic definition of centralize is an example of something that's probably not going to work perfectly well in a SOA from the standpoint of security people think of things like role-based access control, and they assumed they have complete knowledge, and control over all the subjects, complete knowledge and control over all the objects, and complete knowledge and control over all the sessions.

And that's pretty clear clearly not going to work when we're linking all these disparate systems together. But that's where a lot of security people's thinking come from systems like RACF and these other systems where you owned the system. And then you sort of have the application security view of the world, which says that you need to hardened all of your code, you need to review all you lines of code exhaustively by gurus, and all of the endpoints need to be hardened to some very high level of assurance.

And that's a fantastic idea, but not necessarily very practical for a lot of businesses and so what -- what I would sort of characterized as a pragmatic way for it is a decentralized approach where you don't necessarily have one central point, but you have decentralized policy enforcement points that can create policy, manage policy, and distribute policy, and sort of deploy your policy out to the edges of your system in a way that makes sense for your business process, or your data flows that you need to deploy policy to. So in some cases --

MR: I...

GP: It could mean authentication or encryption and other cases it could be things like content filtering but these sort of decentralized points would be specifically tuned to the environments that they're in so there might be one for a B2C environment, one of B2B and a different one inside the four walls.

MR: Yeah, absolutely, that's a great point and I should clarify when I say centralized. I mean centralized policy management.

GP: Yeah, you're absolutely but the other side of that coin is distributed policy enforcement and you know I think really the concept that underlies that point of view is what's known as defense in depth where from a security perspective you really don't want to put all your eggs in one basket.

If you're only using a gateway solution and the gateway solution is compromised, essentially, the attacker has the keys to the kingdom so you want to implement defense in depth that addresses the gateway that addresses the intermediaries, that hardens the endpoints as well and turns every endpoint into a policy enforcement point on its own. So yeah, I think you have a great point.

If you really want to have more or less concentric rings of security all of which complement each other and provide kind of a fail-safe mechanism should any of these other issues kind of creep through.

MR: You bet. You -- you know what happens when you put all your eggs in one basket right?

GP: You watch the basket right?

MR: Yeah, very, very carefully. So that's actually a good discussion. And you know, we're kind of jumping around a little bit here and that's -- that's kind of intentional but I think a segue because we talked a little bit about kind of what you need to do and kind of distributed versus centralized and it really brings up -- before we kind of jump into the standards thing, it really brings up a real question about who is ultimately in control of SOA security.

You know SOA is, obviously, the purview of the application group, if not an application group within one of the business units and then we're talking about maybe centralizing the policy versus decentralizing the policy enforcement, and all that stuff. So you get into kind of what could be a potentially messy organizational model in terms of how you ensure that a lot of these policies are actually enforced.

You know a policy that's written down on paper is wonderful but if it's not enforced, it's kind of not worth the paper it's written on from that standpoint. So you know, what do you guys seeing in terms of organizational models to make SOA Security kind of real and enforce some of those activities within a lot of these more mature organizations that are starting to think about these activities? I know Andrew or Gunnar or even Fred, I mean, do you guys -- who -- who wants to take the first crack at that one?

FE: Let me take a first quick crack -- and the individuals and in this panel are superbly experienced in that. I want to point at two items for discussion. In order for the SOA Security to be seamlessly functional, I think that ultimately we have to do policy implementation and practices, and process models, and frameworks, and all of these nice buzz words. Verify and certify two items.

One is the identity and the other one is the integrity and confidentiality of the data that is crossing walls, and proxies and gateways. And so you've heard of terms like Federated Identity and stuff. So when you put these policies in place, ultimately, what it boils down to, in my opinion, and then I'll go quiet and for others' comments, is that instead of information is going to be communicated from one entity to another, which is going through the Internet.

And therefore, we have to make sure that the individual or the individuals not in the sense of human beings but in the sense of applications, let's say, is in fact who it claims it is, and the data that is communicated between the two sites is in fact properly is -- it's a proper and healthy set of information. So in our discussion, what it boils down, when you're talking about the legacy system where there's series of security features where vertically integrated from top-to-bottom for application of the highest level all the way to the operating system at the lowest level where more and more, in my opinion, as more and more we're moving to service oriented architecture.

The notion of security is going to be implementation horizontally where there is a peer-to-peer communication and the underlying systems are transparent to the peers across the globe or across the pond. And I would leave it at that then I will go mute and somebody else can jump in.

MR: That was useful. Gunnar, you have an opinion?

GP: Well, I couldn't agree more that identity management is an important enabling technology for any of this stuff to really work. And I and I'm sure everyone will agree with that. To the point of peer-to-peer, I think that the manageability of peer-to-peer security, historically, has not been great. Not that it couldn't succeed in the future and not that that probably is the end goal in a lot of cases.

But I think if you look -- if you take away your biases about what it should be and look at where the things that have been successfully deployed and are widely implemented in the enterprise. And again, I come back to the decentralized notion so -- so you have these things like directory servers, like LBAP and active directory, which are not by any means perfect but are widely deployed 499 of the Fortune 500 run their whole business on these things.

They scale very well. And again, I would call these decentralized systems so that you have as close to a distributed runtime as you can, but you know some more centralized policy management to Andrew's earlier point. And I think that leads more to a federation of view of the world and less to a strictly peer-to-peer environment as -- as much of a nice goal as that might be and we may eventually get there.

I think a lot of times what ends up happening is you're linking together Webs of trust or communities of trust that from a coarse-grain view give you what you need to succeed even if it's not the perfect security model. To your earlier point, just in two sentences, who's going to do all this work, I think was the nature of your question, Mike. And the reality is the software people flat-out do not know enough about security, and the security people flat-out do not know enough about software architecture to really comprehensively address this and, obviously I'm generalizing a little bit.

MR: Sure.

GP: So when you talk about speeding up application security with regards to SOA in your environment, what you're really looking for is somebody who -- who knows a little bit about either security or software architecture, and has a lots of desire and interest and capability to learn a tremendous amount of material in a short time and turn those into something that's actionable. So you're not going to find somebody in a nutshell like one person. One of my clients calls it like trying to find an Apache Webmaster in 1993.

MR: Yeah, right.

GP: So you really need these people. You really, really do need these people, but they are not out there. There are, and if they are you can't afford them or you can't find them so you have to grown your own and train your own and try to find somebody who has one of those either the SOA side or the security side pretty well nailed down and train the up and empower them to do some good stuff in your organization.

MR: Yep. Okay, that's -- that's great. Let's kind of talk a little bit about standards because, obviously, one of the things with SOA that it is about loosely coupling, it is about interoperability, and all that stuff means standards. So Fred, I know you're one of the guys that's spearheading at least The Open Group's work with a lot of the standards.

There's the kind of Liberty Alliance is out there with a lot of the WS Star types of standards. You know, so what are you guys seeing in terms of kind of the stabilization of the standards initiatives as well as kind of how well they're been adopted by a lot of the customers, and is it a constraint did things start to pop?

When did standards stabilize or folks still kind of waiting on the sidelines? So Fred, you want to take a quick crack at that and then we'll have the rest of the guys comment as well.

FE: Well, certainly, this is Fred speaking. And on the point of standards, of course, is we're dealing with a large enterprise systems, legacy plays a role as people have indicated in this forum that we're dealing with centralized, for example, ID recognition, that's in place already. So what we're doing is, I think, in the immediate future, by that I mean, in the next year or two were coming under certain guidelines that would utilize and promote the hybrid environment that was discussed here by.

By hybrid, I mean, a centralized set of -- of security policies as well a distributed set of security policies, and there are things that are central within The Open Group, which is the entity I'm involved with. One is on the SOA side itself which they purely focus on standards that are out there trying to promote -- this is a SOA working group I'm talking about. Trying to promote the communication transparent communication that is ultimately the nirvana of a true SOA environment.

Whether we get there and not is a whole different story. And the second thing is the Security Forum. And Security Forum certainly is focusing on the concept of authentication, authorization, confidentiality, data integrity, and phone support. And my team, which our members come from the --- both of these groups is trying to identify a set of guidelines per recommendation of these.

We're not trying to reinvent the wheel; we are basically reviewing and then promoting the concept through write-ups, and whitepapers, and guidelines. And my team is focused -- focusing on the present. My charter is to put the guidelines together, and preserve whitepapers, and -- and promoted it and this will happen through this -- to us this year as we come up.

And on that -- on that note, we are again -- the framework that we are putting together we're not specifically pointing to a specific set of standards although if you've heard of entities like Oasis, for example, and vendors such as IBM have some superb set of documentation in their red books, which I -- which I recommend folks who are interested to get more in-depth into what we are discussing here, which is at a high level, at the -- at strike level.

Do refer to the frame -- to the -- to the documentations as -- as well as the Web -- Websites that are available. And do go to Open Group if you have not done so and point to SOA and as well as the Security Forums. And there is a great deal of pointers to other -- other vendor communities that can promote and recommend a means of available technology that can be implemented.

And I want to underline a point, a comment that Gunnar made. It is very difficult to have a combination of a software security expert and a security expert combined them. It is mindset sort of a thing one has to inherently as the software developer needs to inherently be aware and constantly aware of the security requirements of what it is that he or she is trying to implement in their setup. So I don't know if I took the question to a wrong direction.

MR: No, no, that's good because it's a understanding of what Open Group is about. So you know, I guess one -- one of the other things that I would want at least somebody to expand on is to the degree of either the standards being kind of working and and allowing you to interoperate with and within a number of the different applications.

And -- and we got a question in here and again, remember everybody can hit on the “Ask A Question” button. One of our guests has asked a question about how you overlay WS-Security and WSI Profiles on existing applications. You know, are we going to need a new middleware environment and how is this going to affect overall performance?

Because you know the realities we all got our stuff right, and one of the advantages of SOA is to be able to provide a standard interface, or a set of standardized interfaces that could -- would allow that information to be utilized in other ways within other applications moving forward. So obviously you think you might have some kind of potentially middleware-ish oriented environment.

But how those that play in with the standards? What is that -- I mean, I think that's what our friend is -- is trying to get at. So I don't know, Andrew, do you have an opinion on that, or -- or Fred, or Gunnar, or I mean, anybody but just how do we kind of reconcile his need for middleware to make all this stuff work together?

AB: Yeah, I think they key issue is to offload that security functionality from the business logic of the application. The developer should really be 100% focused on the business logic and getting that right, and getting that stable, and should not have to go off and learn the WS-Security spec, should not have to go understand the WSI Profile that should all be handled by really by an offloaded, dedicated as you put it earlier, utility which is entirely possible today.

That's actually AmberPoint's model in which we provide distributed agents whose sole purpose in life is to monitor traffic and to do the kinds of security processing what we're talking about here. So, for example, taking an XML message, a SOAP message and attaching in the appropriate ways all of the WS-Security related tokens be those username, passwords, by those X509 digital certificates, digital signature.

And to do that, all on behalf of the application and really make it so that the customer, and the developer are really shielded from all of these issues of interoperability, and keeping up with the standards as as they emerged, and as their defined into the various profiles.

So really, really, key to offload that and use a governance solution as a force multiplier for the kind of, I think, what we've characterized here is really sort of hard to find security awareness and security -- just the security knowledge and capabilities, use this as a force multiplier to ensure that right kind of main expertise is propagated throughout the enterprise.

MR: Andrew, while -- while I got you here and my -- my share from -- from that standpoint. What I just hopefully pulled up your slide about first mile, middle mile and last mile in terms of where a lot of the security for SOA can actually be implemented. Can you walk us through this in -- in maybe two minutes and then we'll be able to take a couple of questions to wrap things up because I think this kind of puts things put a little bow around the whole concept of where you need to start thinking about security from an SOA context and kind of where a lot of these different interchanges are going to happen.

AB: Sure. Absolutely. And let's take to what Gunnar and I were discussing earlier this notion of defense in depth and the idea that you don't want to put all your eggs in one basket because there are architecturally speaking these different areas of concern within a SOA which have different security issues associated with them. And we kind of abstract that into the notion of first mile, middle mile, and last mile security.

And you know, just to start it with the first mile, what we're really talking about there is not -- we're not talking about policy enforcement in the first mile. We're only talking about service consumer enablement because one of the challenges of SOA is that there are a lot of tools that may make it easy to secure your services but then you're just placing the burden of implementing digital signatures and encryption and all these various security mechanisms on the consumers of your SOA, which is really going to compact agility in the long run as you update your security policies.

You're going to break your consumers and so what you need to look at there is really the type of functionality that AmberPoint provides wherein consumers can consume a description of the policies that they need to execute, the behaviors they need to adhere to be able to consume the services and to dynamically update themselves to meet those requirements. Middle-mile security is really about the role of intermediaries so these will gateways, ESBs, other types of middleware that's involved in an end-to-end transaction.

And you know, they're going to have specific roles and in a lot of cases, the functionality that you're looking at there has a lot to do with what we think of as identity federation and identity propagation. As you have a human end user, who's the customer of the backend SOA service, you really going to want to make sure that that user's identity travels through all of these intermediaries and arrives at the end service so that service can do customization, or access control, or whatever is necessary and that's a significant challenge when you're moving from the world by human types of identity and you're moving to the machine-to-machine types of identity that are typical of an SOA.

And another issue with middle mile security again is the need-to-know aspects in which an ESB is going to have to access some portions of that message or application request that's going through in order to, for example, determine how to route the message appropriately. However, you may not want to expose some of the information in the message to an intermediary that may be managed by a different group, that may be, in fact, you knows, geographically remote. And so some portions of the message should be available for mediation and other portions should be protected particularly for regulatory reasons.

And last mile security really has to do with endpoint enforcement so turning each of your endpoints into his own policy enforcement point so that it can enforce policies in the way that are appropriate to the type of application, and the platform that the applications is running on. So you may need to enforce the same policy on J2EE as on .NET. So how do you accomplice that? You know, of course, AmberPoint provides last mile solution in the form of agents, which turn these various endpoints into trusted containers and provide security processing on -- on the services they have. And so really talking about from beginning to end here, we're talking about the layered approach to security that takes into account the different roles that unless it's an application requests and -- and the various different collaborators in these composite applications may find themselves.

MR: Great. Great. So we -- we got a couple minutes left, let's take a couple of questions -- a bunch of questions came into the -- into a little Q&A box. And I appreciate everybody putting their ideas and in there. The first one comes in for Gunnar and it has to do with -- with training because, obviously, training is -- is one of those things where you had acknowledged before that not a lot of people come to the table with the skill sets both from an application as well a security standpoint to understand the depth of all -- of this issues.

So Gunnar, I know you do training, so what are some of the options for folks to kind of get smart on this front and when should they really address it within is it early on in the application development cycle, is it something that -- that when they realize they have a problem how -- how soon can they start looking at these things?

GP: Well, I think training is something you want to address upfront because a lot of these things, a lot of things Andrew talked about, and Fred talked about our issues that no matter how good your programmers are, if the system is not designed with some security in mind you're going to potentially open yourself up to some interesting security problems and so a little bit of training upfront, I think, goes a long way.

It is a new way of thinking about systems building security in during the software development lifecycle from the early stages of development factoring in security into your decisions. I happen to teach security training classes. I have a public class in a couple weeks in New York, which you can read on my blog at 1Raindrop. And I personally think it's really important thing and I've seen big improvements in my clients maturity of their security solution by investing some time in and having their people trained.

MR: Great. Great. I think that's -- that's a good answer. Here we got a little bit more of a technical question. I'm not sure whether Andrew, or Gunnar, you guys, or even Fred, you guys are -- are going to be able to answer this one but it has to do with cross-site scripting. And if it's, you know -- is cross-site scripting specifically an issue for SOA, is this something that you really have to worry about from a client-side attack standpoint? Is there anything you have to differently for SOA? You know, obviously, that's something that -- that a lot folks are worried about out there.

GP: You don't have to do anything differently. It is still an issue. Usually, where you see SOA is more machine-to-machine communication and cross-site scripting is usually targeting a client browser. Where it becomes a big issue with SOA though is SOA is about distributing and -- and providing interoperability so it can be a propagator of a process-scripting attack and that's something you definitely want to watch out for.

FE: I do agree with that but I also on the serious point, I want to be a bit more emphatic than Gunnar was on the fact that the earlier you start on a project implementing or being aware of security features, the less costly it's going to be in the long run. So I'm going to be bit more emphatic in that. Start at the earliest possible point. In fact, in my opinion start the early design stages with the security in mind.

MR: Yes.

GP: I hope I didn't sound like I was downplaying that because I think that's really important and there's a lot of interesting papers on threat modeling and abuse case modeling that you can do to -- to do really quantify your security designs upfront.

MR: Right

FE: Yes, I totally agree.

MR: And I -- and I agree. And you know, I think I want to be at least candid about the fact that in many cases that becomes very difficult to do especially early on in -- in the design phase it -- in most cases, the security folks have to evangelize why it's important.

GP: Right.

MR: You know application developers or about developing applications. I think we're starting to get a greater acknowledgment out they in the development communities about the fact that security is important, about the fact that they need to start thinking about this stuff earlier in the process but it's -- it's by no means a foregone conclusion. So in many cases, the security folks have to do a great amount of evangelizing and persuading and arm twisting but, obviously, the -- the economics don't lie. The sooner you can eliminate defects, the sooner you can kind of figure out and build data protection into the environment, the better things are going to be from that standpoint. So with that we're pretty much out of time. What I'll do is, obviously, you folks will be curried into a little tradeshow area where you can find out all about AmberPoint and Andrew's company. Fred, if -- if you wanted some folks to be able to get in touch with you about some of The Open Group activities around SOA Security, is there a Web site or -- or some kind of mailing list that folks should start monitoring to -- to keep track of you?

FE: Oh absolutely; OpenGroup.org is our Website. And anyone who is interested in -- if they can send me questions directly, my e-mail I can give it if -- if anybody is interested is F.Etermadieh, which is E-T-E-R-M-A-D-I-E-H@OpenGroup.org and I'll be more than glad to respond or at least point them in the right direction as they see fit. But do refer to OpenGroup.org and we do have quarterly meetings throughout the world if anybody is interested through their organization or membership they can attend, of course, as well as, of course, they can attend even if they are not a member.

MR: Great. Thank you. Gunnar, why don't one of you let everybody know where they can -- where they can track you down.

GP: Probably the easiest place to find out is just to punch 1 Raindrop into Google and that'll bring it to my blog, or my firm is Arctec Group. And you can go to ArctecGroup.net. One quick on -- on The Open Group for Fred is in terms of these decentralized patterns for deploying security and middleware, probably the best article I've send on that is -- is published by Open Group. It's a book called Security Design Patterns by Bob Blakely and Craig Heath and you can actually download it for free from Open Group. So I'd recommend everybody read that and look particularly at the secure proxy pattern.

MR: That great. That's fantastic. And with that Andrew, why don't you give us a little bit of your coordinates and then, I know, once we're done with that you'll be -- you'll be sheltered or shuttered into AmberPoint's little booth within -- within our tradeshow environment.

AB: Absolutely. Listeners can visit AmberPoint.com to obtain our civil security whitepaper. And also I would add our recent survey on SOA adoption in the industry, which is quite interesting from the prospective of what is the maturing level and the success rate of SOA in the real world. Also, I can be contacted directly at ABrown@AmberPoint.com.

MR: That's great. I want to thank Fred, I want to thank Gunnar, I want to thank Andrew and, obviously, AmberPoint as our sponsor and ebizQ our Godfather so to speak for today's event. This is Mike Rothman of Security Inside; I wish you all a fantastic day.