|
[This week, another special edition. In the October
21, 2002, issue of the IT Strategy Letter, I linked to a white
paper entitled Some
Security Considerations for Service Grids (PDF, 23pp.) in
which Martin Milani and John Seely Brown defended certain security
aspects of the Service Grid as put forth in an October 2001 HBR
article by Brown and John Hagel. In my review I questioned four
aspects of the Hagel-Brown article. On October 28, 2002,
I received the following in email from Martin Milani, which is
reprinted with his generous permission. Our mutual objective is
to encourage further discussion on the topic of the Service Grid.]
Per our view, the security service grid is not merely a replacement
for firewalls of any kind. In fact the enterprise will protect
is perimeter and connection to the service grid via firewalls.
In figure 2.4 [in the original white paper] we have a graphical
representation of how we envision the enterprise would connect
to a service grid, which includes firewalls on the edge of the
enterprise. We believe there are a number of different reasons
why the service grid is a key enabler and an important piece of
the webservices puzzle, one of those reasons is a reduction in
the complexity of security management but that is only one of
the many different advantages.
Let us discuss and address the four different points raised by
Doug at a more granular level:
Point 1
I think a service-grid provider may actually be more vulnerable
than an individual corporate IP address for two reasons. First,
a well-known service-grid provider may be considered more enticing
target by hackers, and therefore attract more such attacks. Second,
a DoS attack aimed at one service-grid customer can impact the
performance of other customers by denying the availability of
shared resources. IOW, if a hacker goes after my web service that's
advertised as responding at a WSN that we both use, your web service
may also suffer DoS. This wouldn't be the case if we didn't share
the resources.
Response 1
We would not argue about the fact that a service grid might be
a more enticing target for hackers. However, we would state that
the service grid construct would be designed and erected with
security as the core fundamental design pattern and the key architectural
design guideline, from perspectives of software and network design.
Service grids would be managed by security experts and monitored
and enhanced all the time. Service grid operators would be closely
working with and correlating efforts with multiple backbone providers
and ISPs. It is easy to see that it will be much more effective
in managing security than most enterprises could ever be for skill
reasons if nothing else. In the paper we have touched on quite
a few different ways the service grid could be protected, some
admittedly are quite complicated.
Point 2
I don't see how this is any better (but I admit, no worse)
than a single corporate connection through an XML firewall appliance.
Someone still has to manage the many point-to-point relationships
involving a wide variety of security technologies and standards.
It's just a standard outsource/DIY tradeoff. It isn't inherently
better or even easier if done by the service-grid vendor.
Response 2
From the firewall perspective only, an enterprise could use the
same technologies as a service grid provider would use to protect
its perimeter assuming it had the expertise and resources.. It
is also important to note that an XML firewall which is a new
and unproven technology only examines XML messages within the
SOAP protocol (http). We believe opening up you enterprise applications
to the outside world directly via SOAP is an extremely risky move!
Again without going into details here, XML level security is only
one of layers of security that is needed. In our paper we argue
the need for multi-layer and multi-tier framework.. We also provide
a glimpse of what opening up the internal applications to the
outside world might look like using the service gird services
as proxies hence protecting the internal applications. We also
strongly caution against the myth of "XML will cure cancer
and all evil" phenomenon.
Point 3
In practice, the service-grid customer still has the obligation
to determine and express to the provider all of the rules required
to create and enforce the security policies. There may only be
a single physical/virtual connection to the service grid, but
there are no fewer application-to-application (or, more precisely
business-to-business) relationships. The service-grid vendors
don't make business decisions for you. The only step they'll handle
is transcribing into their systems the rules you create.
Response 3
Yes, the business rules and security policies are created by the
enterprise. What the service grid operators would offer (and that
are extremely important) are neutral (third party) audit trails
and non-repudiation. Non-repudiation by definition is something
that only a trusted third party can reasonably provide. This is
why Escrow companies/clearing houses and law firms often handle
complex transactions. From a technical perspective non-repudiation
can only be supported if the same exact token technology is used
between two companies and that in fact would be prerequisite before
any application connectivity can resume. The service grid construct
will take care of this by offering non-repudiation in a multiple
certificate/token type technology world. Compliance to certain
security standards and rules could also only be verified by the
service grid real time. Laws such as the patriot act which require
companies to provide details of any transactions to law enforcement
in 48 hours or less makes this even more interesting, specially
when multiple organizations are involved in a transaction. The
service grid - acting as a trust broker - also manages trust.
In a multiple service provider world in which multiple parties
provide the same service (this is how the real world works); trust
and quality of service (both of which are products of the history
of previous interactions and transactions among different participants
) services could only be provided by a neural third party service
gird provider. Again we refer you to the paper regarding trust
and quality of service issues.
Point 4:
I've contended in the past that such mediation is only required
when the associated standards either haven't been agreed to or
haven't been universally adopted. Today, this is the case for
much of the web-services protocol stack, but over time it will
be less so. Milani & Brown may, in fact agree, if my inference
from the following is correct: It also speeds up the adoption
of web services by organizations, as they do not need to wait
for standards and the expensive and cumbersome task of replacing
already existing technologies and infrastructures.
Response 4:
We believe we are in agreement here. We still think comprehensive
Webservices standards are a long ways off. Even when all parties
do agree on certain standards for webservices, with history as
a witness we believe not everyone will adopt these standards,
CORBA and OSI are great examples.
In closing we would like to thank Doug for his review of our
paper and his thoughtful input. John Hagel, John Seely Brown and
I envision the world of websevices that is not limited to simple
application integration or one in which one can use a stock quote
providers piece of code to present a stock quote on a corner of
a web page. We believe ultimately, the world would comprise of
many sophisticated distributed software ecosystems that will run
and facilitate mission critical applications and business processes
and transactions among their constituents. We believe the world
will be multi-protocol and dynamic in which different technologies
will best address different needs for a very long time. RPC and
SOAP/http which toady's webservice's stack is based on will only
address certain areas of software architecture where they fit
specific needs best. There are many areas where RPC is not a well-suited
architecture for design and other paradigms would be much better
suited. In fact the first of the web-based applications such as
SMTP/mail, ftp, news and DNS did not use RPC like communication.
So in this chaos we call the technology world today, in order
to evolve, we believe the service grid concept is a fundamental
first step.
Martin Milani
October 28, 2002
(Reprinted with Permission)
|
