globalizing #SOA with web services

 1.30: web: cs/soa/globalizing SOA with web services
Filtering to Inspect XML: an Operational Framework for
Service Oriented Architecture Network Security
www.tacoma.uw.edu ... rbunge.pdf
Robert Bunge1, Sam Chung1, Barbara Endicott-Popovsky2, Don McLane1
1 Computing & Software Systems; Institute of Technology
University of Washington, Tacoma
{rbunge, chungsa, dmclane}@u.washington.edu
2 Center for Information Assurance and Cybersecurity
University of Washington, Seattle
endicott@u.washington.edu
1.30: summary of this paper:

. in the world of networking
the terms: firewall, proxy, and gateway,
are describing components of an
Intrusion Prevention System (IPS).
. XML-specific IPS is done by
XML firewalls, proxies, and gateways,
blocking deleterious XML traffic
at a local network’s edge.

[. the authors doing research in 2007
found little on XML Intrusion Detection;
but SOA itself is all about detection .
. SOA can use the Bromium idea of security
where you let the untrusted players act freely,
see what they do (using hardware-based isolators,
that turn modifies into copy&modifies)
and then roll-back any changes
that they weren't authorized to make .]

What is needed is a model that assimilates XML
into action items for perimeter security.

[perimeter security?
. don't be put off by the use of that term here;
because, in this context, SOA,
the whole point of that architecture
is to so micronize the code base,
that perimeter security equals object encapsulation .
. what this paper has done is explore how to
safely extend your SOA solution with web services .
. the combining of the SOA idea
with that of web services,
should mean nothing more than this:
the SOA functions your app seeks
may resolve to an app that is not local;
ie, by the abstract nature of SOA,
calls to specific unavailable routines
raise a look-up process instead
that finds an equivalent routine,
and reroutes your app's call to the generic .]

. there are many XML IPS products
and even some intrusion detections
combining software and hardware .
. they can selectively encrypt XML fields,
perform XML validation,
create a virtual firewall for
every service exposed to the outside world,
and for each unix user group .

. the authors show why such products are needed
and how they should be configured to improve security.

WS-Proxy is a design architecture for
the control of Web services communications.
WS-Proxy defines a special plug-in interface
to improve parser efficiency
by invoking differentiated parsing routines.
Policy declarations for WS-Proxy
may be specified via XPath, the XML query language.
For this research,
the authors implemented a model of WS-Proxy.

Unlike the systematic prescriptions available for
network or transport layer filtering,
suggestions for application layer processing of XML
reveal an ever-widening horizon of tools and protocols,
with little true direction on
how to begin engineering network security for SOA.
. they tighten the focus for network security designers,
compressing the many XML security options
into a manageable set of choices
with an operational framework for
designing and provisioning XML network security.

new vocabulary:
# FIX:
Filtering to Inspect XML;
# FIX point:
system or device whose function includes FIX;
# FIX list:
a set of options for the configuration of a FIX point.

All of these meanings of the common verb “to fix”
apply literally and directly to one or more activities of
XML processing required for network security.
Such commonly recommended XML security techniques
include:
authentication, authorization, and accounting
validation, verification,
screening and filtering
logging, auditing,
encryption and decryption
caching, transforming .

The most significant feature of FIX Point Proxy
is its specific focus on filters as a
design abstraction for the organization of
XML security inspection processes.

Selected filters from prototype FIX system:

== Filter: Function -- Rationale ==
# Transparent Mode:
Passes HTTP traffic. No XML  filters enabled
-- Baseline testing of TCP/IP functionality below XML sublayer
# Block WSDL:
Blocks viewing of WSDL files
-- Prevents reconnaissance of Web services internals
# Screen Illegal:
Characters Regex to limit element content to alphanumeric characters only
-- Prevents XML Injection strategy of passing XML as text values
# Limit Element Size:
Limits maximum element size to a selected value
-- Useful against Denial of Service and buffer overflow
# Authenticate User:
Parsers XML for authentication string
-- Models authentication within the XML sublayer
# Log Transactions:
Records transactions to file
-- Models auditing system. Also suggests approach to XML IDS.

Whether the system goal is intrusion prevention
(firewall, gateway, or proxy)
or intrusion detection (IDS),
the concept of XML filter selection still pertains.
For this reason, a FIX subsystem is needed
on any sort of network security device
designed to attend to XML.
. in so far as XML by its nature
transcends procedural limitations,
the FIX model may prove useful for
suggesting the development of a set of
optional filters
to be applied on a case by case basis.
This combining of standard procedures with a
specifiable set of options
reduces to the problem of XML network security
to something roughly comparable to
security designs and activities at other network levels.

. for the sake of simplifying policy,
network security interventions
should be associated with layers in
the TCP/IP Network Reference Model.
The chart below illustrates this strategy
as currently applied for devices such as
firewalls, IDS, and web proxy servers .

Network layers -- corresponding protocols,

and [security mechanisms]:

# Application Layer:
-- HTTP, FTP, SMTP
[Content Filtering, Encryption]
# Transport layer:
-- TCP, UDP [Port Filtering]
# Internetwork layer:
-- IP, ICMP [Packet Filtering]
# Data Link layer:
-- PPTP, L2TP [VPN Tunneling].

. but there's a problem when trying to
locate Web services
in a network reference model:
no correspondences with
SOAP, WSDL, UDDI, WS-Security, SAML .

. Web services are generally modeled as
resting on top of TCP/IP application protocols
such as HTTP. For Web services,
{HTTP, FTP or SMTP} are regarded as
transport bindings,
not as fully fledged application protocols
in there own right.
To resolve the problem of
proper layer assignment for Web services,
here is an authoritative reference
on the concept of “layer”:

reference on the concept of “layer”:

• Collect similar functions into the same layer.
• Create separate layers to handle functions that are
manifestly different in the process performed
or in the technology involved.
• Create a boundary where it may become useful to
later standardize the corresponding interface .
• Do not create so many layers as to
make difficult the system engineering task
describing and integrating these layers.
• in cases where distinct communication services need it,
(as when protocols differ substantially in
form, syntax, semantics, or processing requirements)
create further subgrouping of functions
by forming sublayers within a layer .

The XML sublayer

network layer -- protocols [sec tech]

# Application Layer's XML Sublayer:
-- WSFL: Service Flow
-- Static -> UDDI: Service Discovery
-- Direct -> UDDI: Service Publication
-- WSDL: Service Description
-- SOAP: XML-Based Messaging
-- WS-Security, SAML(Security Assertion Markup Language)
[FIX (Filtering to Inspect XML)]
# Application Layer's TCP/IP Sublayer
-- HTTP, FTP, SMTP: XML Transport .
-- MQ, RMI over IIOP: XML Transport .
[Content Filtering, Encryption]
# Transport layer:
-- TCP, UDP [Port Filtering]
# Internetwork layer:
-- IP, ICMP [Packet Filtering]
# Data Link layer:
-- PPTP, L2TP [VPN Tunneling].