ebizQ Event Center Roundtable: SOA Security -- The Real Deal or Much Ado About Nothing?
Complete Transcript: SOA Security -- The Real Deal or Much Ado
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,
To listen to a full replay, click
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.
April 19: Roundtable: Threatscape 2008
Targeted attacks and rising insider abuse have helped double the average company's financial losses in the last 12 months to $350K. Mike Rothman will lead another roundtable discussing practical integrated solutions like change detection, log management and correlation features to protect business-critical IT assets.
March 11: The Secrets of Flexible Data Exchange --
How to Implement Transformation as a Service
Infomatica's Karen Hsu and Ronen Schwartz will teach you how to create an agile data exchange, integrate any data consistently, build an extendable data integration platform and spend less time on custom data integration.
March 12: SOA Survey Results
An ovewhelming majority of SOA efforts remain scattered haphazardly across multiple business units or project teams. ebizQ's Joe McKendrick and IBM's Leif Davidsen will review findings and present actionable solutions.
March 13: Information Integrity -- Putting the Trust Back in SOAs
Information integrity has taken on an extremely important role in SOAs. The Bathwick Group's CTO Gary Barnett and IBM's Michael Curry will cover what aspects of your information infrastructure you should review.
March 18: Business Event Processing: The 'When' to BPM's 'What'
Knowing which business events matter, how they are related, and how to react is a key to successful management. IBM's Paul MacKay and ISO New England's Dick Brooks will show you how to detect meaningful patterns of events, respond quickly with effective action.
March 19: Roundtable: SOA and Web 2.0
Web 2.0 may appear merely social, it means business -- and using it with SOA can enable innovative new enterprise resources. ebizQ's Beth Gold-Bernstein, ZapThink's Ron Schmelzer and ZDNet Enterprise 2.0 blogger Dion Hinchcliffe discuss how to to exploit the natural synergy between SOA and Web 2.0.
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
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
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.
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
Learn More About Mike Rothman's Next ebizQ Roundtable: Threatscape 2008 on April 19
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
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.
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,
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.
Learn More About Mike Rothman's Next ebizQ Roundtable: Threatscape 2008 on April 19
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
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
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
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
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.
Learn More About Mike Rothman's Next ebizQ Roundtable: Threatscape 2008 on April 19
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
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
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
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
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 --
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
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
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
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.
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
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
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
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
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
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
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
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
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
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.
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.
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.
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
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.