logging in the age of Web services


Nov 3, 2013 (3 years and 8 months ago)


Building Security In
Editors: John Steven, jsteven@cigital.com
Gunnar Peterson, gunnar@arctecgroup.net
Deborah A. Frincke, deborah.frincke@pnl.gov
COPublished by the ieee COmPuter and reliability sOCieties ■ 1540-7993/09/$25.00 © 2009 ieee ■ may/June 2009
more robust ways to protect Web
services, but they don’t provide
services for logging, audit log-
ging, and detection and response.
Moreover, Web services architec-
tures are generally built on state-
less protocols such as HTTP and
SOAP, which don’t support even
basic request-response correlation,
leading to a major security archi-
tecture and design challenge.
Logging and
Web Services
Logs offer an endless well of
valuable information about sys-
tems, networks, and applications.
Through logs, audit records, and
alerts, information systems often
give signs that something is bro-
ken (or “broken into”) or will be
broken soon. They can also reveal
larger weaknesses that might affect
regulatory compliance and even
corporate governance. However,
more often than not, system and
application logs contain raw data
rather than information, and thus
require extra effort to extract or
distill this data into something
useful, usable, and actionable.
At the very highest level, logs
are a vehicle of accountability. Of
course, an organization has many
other mechanisms for accountabil-
ity, but logs pervade all of its IT,
and if its IT isn’t accountable, the
organization probably isn’t either.
Various logs are also valuable for
regulatory compliance programs.
Many recent laws and mandates
have items related to audit logs—
for example, a detailed analy-
sis of the security requirements
and specifications outlined in the
Health Insurance Portability and
to solve. In this article, we describe
how audit logging can be built into
the Web services infrastructure.
Why Web Services?
Web services aim to deliver vir-
tualization, interoperability, and
reusability via technology imple-
mentations such as SOAP, service-
oriented architecture (SOA), and
Representational State Transfer
(REST). Interoperability in par-
ticular is paramount for enterprises
that must transact business across
multiple .NET, Java, open source,
and mainframe platforms. Add in
messaging connections to custom-
ers and partners located in different
countries or organizations, and the
challenges of getting protocols and
message formats to mesh together
seem overwhelming. This is the
problem that Web services attempt
to address. Unfortunately, howev-
er, most Web services implemen-
tations offer their own challenges
as well—namely, they don’t always
enable security by default, and they
often leave security decisions about
authentication, authorization, and
audit logging to the implementer,
which can cause serious long-term
problems down the road.
Web services security has two
parts: interface and implementa-
tion security and message secu-
rity. Interface and implementation
security uses traditional Web ap-
plication security controls such as
Secure Sockets Layer (SSL) and
access control lists (ACLs). For
message security, XML mecha-
nisms such as WS-Security, the
Security Assertion Markup Lan-
guage (SAML), XML Signature,
and XML Encryption can sign,
encrypt, and authenticate message
data, giving the sender greater
confidence that the message stays
confidential until delivery and the
recipient greater confidence in the
message’s authenticity.
Instead of relying on role-based
access control, in which security
services mediate the communica-
tions of subjects, objects, and ses-
sions in a central policy domain,
Web services evaluate a message’s
claims against a specific policy.
This claims-based access control
model lets the architect compose
security protocols along the same
lines as the application. Standards-
based XML security mechanisms
such as WS-Security, SAML,
XML Signature, and XML En-
cryption are powerful tools for
people building security architec-
tures in distributed systems to de-
liver message-level authentication,
integrity, and encryption services.
These standards offer new and
n today’s age of Web applications connected via Web
services, accountability has become both crucial and
harder to achieve. The management of authentica-
tion, authorization, and accountability in these ap-
plications is therefore a very important and difficult problem



Arctec Group
logging in the
age of Web services
Building Security In

Accountability Act (HIPAA) re-
veals some items relevant to audit-
ing and logging, such as the audit,
logging, and monitoring controls
for systems that contain patient
information. Similarly, the Pay-
ment Card Industry Data Secu-
rity Standard (PCI DSS) explicitly
mentions logging, log collection,
and data retention and log analysis
for systems involved in credit-card
transactions. Clearly, the impor-
tance of logs for compliance will
only grow as standards become
the foundations for new regula-
tions that are sure to emerge.
An interesting challenge that’s
likewise sure to emerge is how to
handle logging in distributed envi-
ronments such as those of Web ser-
vices. Unlike operating system logs,
which are physically located on a
single machine or a single network
device, Web services are by their
nature distributed across multiple
systems, disparate technologies and
policies, and even organizational
domains. This creates many con-
straints on audit log design in terms
of both scope and strength. Given
these constraints, logging might
reside in different parts of Web ser-
vices architectures:
In the simplest case (two ma-•
chines talking to each other via
a Web service), we could prob-
ably log events occurring on both
machines, but we won’t have a
complete view of the overall ar-
chitecture. If we put a log on
each machine, we’ll need addi-
tional technologies for consistent
aggregation and reconciliation.
At each endpoint, Web ser-•
vices interaction involves mul-
tiple software components. At
the very least, this will involve
a Web server, an application
server, and most likely a database
server on each side. Moreover,
the application server might be
self-distributed, thus presenting
additional challenges to deter-
mine where to put the log.
Even under a distributed Web •
services architecture, we can
choose an approach in which
each individual component on
each individual machine creates
its own log. It’s not uncommon
to see applications log into their
own text files; similarly, it’s not
uncommon for Web services de-
signers to use the MS Windows
event log if their endpoint appli-
cations only run on this platform.
(Many application developers tend
to choose the Windows event log
because they consider it to be the
standard for logging.)
Reviewing these options leads
us to believe that—where practi-
cal—a Web services architecture
should have its own logging mech-
anism, so that each component
involved in that particular archi-
tecture has a uniform way of cre-
ating a log for later access from a
single point. Moreover, each com-
ponent in such a distributed system
should not only use a single mech-
anism but also use the same event
types to let the user reconstruct
what actually transpired in the in-
frastructure. It’s worth noting that
some of the events to log might be
distributed in nature themselves,
which could prevent anyone from
using a local log to describe them.
Therefore, the best way to perform
logging in a Web services archi-
tecture might be a fully distrib-
uted logging mechanism. Despite
its distributed nature, application
server logging is probably the cen-
tral part of Web services logging;
Web server logs are less helpful
because many Web services (espe-
cially SOAP), servers, and even ap-
plication firewalls specifically turn
off logging for HTTP POST tasks
because of the amount of data gen-
erated in these requests.
Classic Web services have a
clean separation of the message
document (typically XML) and
the implementation (Java, C#,
and so on), so logging location
varies based on intent. The Web
services framework often imple-
ments logging events based on
message content in an adapter,
handler, or interceptor type pat-
tern. This approach’s advantage is
that it executes logging rules after
message creation but before the
sender puts it on the network and
as soon as the recipient reads it off
the wire. Logging rules are thus
created and managed independent
of the code.
However, this approach can
miss some important events that
require getting into the code—for
example, logging messages is fine,
but nobody can infer exceptions
from them or determine what hap-
pened to the message after sending
it. Building the runtime code with
a set of events to watch for and log
gives much more actionable infor-
mation. After all, the code is the
arbiter of how the system will ul-
timately use the message.
An alternative approach adds
a Web services security gateway
between the service requester and
provider that proxies the com-
munication channel. The benefit
here for audit logging services is
that the gateway has access to the
full message to perform logging
operations. In addition, Web ser-
vices gateways are used to perform
application tasks such as message
transformation as well as security
services such as authentication and
authorization. Because the gate-
way has access to the full message
(header and body) and controls
policy-based events such as au-
thentication and authorization de-
An interesting challenge that’s likewise sure to emerge
is how to handle logging in distributed environments
such as those of Web services.
Building Security In
ieee seCurity & PriVaCy
cisions, the visibility and control
of events makes it a good locale for
writing audit log events.
What Should We Log?
Several types of logging events
can occur in a Web services infra-
structure. First, let’s consider the
most basic type of event: authen-
tication. When a Web services
client authenticates against a Web
service, this event should certain-
ly be logged. A typical scheme au-
thentication event would include
authentication credentials (user-
name and password) or informa-
tion about other mechanisms used
for authentication (such as tokens).
Due to possible use of single-sign-
on, authentication itself might be
distributed and happen on a dif-
ferent server, further highlight-
ing the need for Web services
logging to be distributed. As we
mentioned earlier, Web services
typically use two security mod-
els—interface and implementation
security and message security—
and authentication can happen
in either layer independently or
in different parts of the software
architecture. The log event model
must account for both types of
event and the fact that they can
occur asynchronously.
Other logging events include
authorization and access. Both
successful and failed attempts
to get access to data or services
must be logged. Although some
people focus on logging just the
failed attempts, successful ones
are equally important: if a Web
service client accesses data that it
isn’t supposed to, logs can provide
one of the few ways to know that
this has happened. Earlier, we
discussed the claims-based access
control model for Web services,
which doesn’t have a necessarily
hard boundary between authen-
tication events and authorization
events. The security architect
must define these event types and
results for the event log model.
Other logging events include
various failures, errors, and ex-
ceptions. It’s difficult to create a
specific list of errors and failures
that must be logged, but many of
the simple ones can point to po-
tentially significant security fail-
ures—for example, a corrupted
call to a Web service might indi-
cate a software bug or an attempt
to send corrupted requests for
exploitation. Specifically, WS er-
rors detected while validating the
request input are critical to log
because many attacks include spe-
cially formatted incorrect input
(malformed input) to exploit the
service’s back end. Resource ex-
haustion issues are also important
to log because they might indi-
cate a denial-of-service attack or
the consequences of a “benign”
software bug. Even log evidence
of an application server crash
might be critical evidence for an
incident investigation.
Web services are applications
that are as much configured as
they are coded. As such, numerous
management and policy systems
come into play, so key man-
agement operations, enterprise
service bus (ESB) federation, or-
chestration, and other intermedi-
aries must be logged as well. Table
1 gives a checklist to help guide
what might be valuable to log for a
Web services application.
he biggest challenge in logging
is where to generate, store, and
manage the log. A Windows Web
service requester might write to
the Windows event log, but the
message goes to a Java Web ser-
vice provider that, by default,
writes its own log to Websphere.
Even in this simple case we can
see that a complete end-to-end
log of something as clear cut as a
single request-response interac-
tion is a challenge.
Web services are designed to
offer a loosely coupled integration.
The service requester and service
are independent, often running in
separate technical and policy do-
mains. In fact, in almost all cases,
there’s no notion of a classic two-
phase commit transaction, even for
high-value transactions—instead,
Web services are “eventually con-
sistent,” meaning that the client
and server both independently
conduct computations and write
events. Later, through replication,
updates, and other means, these
events are reconciled for greater
consistency. What this approach
lacks in perfection, it makes up for
in its proven, massive scalability.
The net result of the Web ser-
vices logging problem is both a
challenge and an opportunity.
The challenge is that there’s no
cohesion or consistency in how
Table 1. Audit log checklist for a Web services applications.
CATegory WhAT evenTs To log
Authentication, authorization, and access Authentication/authorization decisions, system access, data access
Changes System/application changes (especially privilege changes), data changes (including creation
and destruction)
Threats Invalid input (schema validation failures)
Exhausted resources, capacity Limits reached (message throughput, replays), mixed availability issues
Startups and shutdowns Startups and shutdowns of systems and services
Faults and errors, backup success/failure Errors, faults, and other application issues
Building Security In

loosely coupled services log these
events: decisions are localized, so
what to log, how to log it, and
how to interpret the results are
left up to each service, and vari-
ous endpoints will likely do it
differently. On the flip side, when
the audit log browser executes the
algorithms to generate the “even-
tually consistent events,” where
do they go to read what hap-
pened? They go to the logs! By
being a data source of last resort,
logs have achieved something
close to first-class citizenship in
Web services architectures.
One thing you can’t say about
most Web services and XML ar-
chitectural concerns is that they
lack standards. From a security
standpoint, WS-Security, WS-
Trust, and WS-SecurityPolicy
provide useful, standardized tools
for building a robust security ar-
chitecture that supports the mul-
tiple token types, trust domains,
and expressive policies that inte-
grated systems require. However,
the standards bodies have left us
high and dry on logging; vari-
ous attempts have launched over
the years, but so far the industry
hasn’t adopted anything wide-
spread. We’re on our own when
it comes to deciding what to log,
meaning that not only do we have
the challenge of where to log, but
we also lack consistency in log
and event types.
As Web applications and ser-
vices evolve and become even
more important for organizations
of all sizes, taking control of Web
services logging for increased ac-
countability, security, resiliency,
and regulatory standard satisfac-
tion likewise becomes crucial.
G. Peterson and H. Lipson, “Se-1.
curity Concepts, Challenges, and
Design Considerations for Web
Services Integration,” Carnegie
Mellon Univ. and Cigital, 2006;
W. Vogels, “Eventually Consis-2.
tent,” ACM Queue, 4 Dec. 2008;
Anton Chuvakin is involved with PCI
DSS compliance at Qualys. His technical
interests include vulnerability manage-
ment, log management, and security
compliance issues. Chuvakin has a PhD
in physics from SUNY Stony Brook. Con-
tact him at www.chuvakin.org.
Gunnar Peterson is managing principal
of Arctec Group. His research interests
include security in distributed systems,
and software security. He is a visiting
scientist at Carnegie Mellon Univer-
sity’s Software Engineering Institute. He
maintains an information security blog
at http://1raindrop.typepad.com.
Advertising Sales
Mid Atlantic
Lisa Rinaldo
Phone: +1 732 772 0160
Fax: +1 732 772 0164
Email: lr.ieeemedia@ieee.org
New England
John Restchack
Phone: +1 212 419 7578
Fax: +1 212 419 7589
Email: j.restchack@ieee.org
Thomas M. Flynn
Phone: +1 770 645 2944
Fax: +1 770 993 4423
Email: flynntom@
Darcy Giovingo
Phone: +1 847 498 4520
Fax: +1 847 498 5911
Email: dg.ieeemedia@
Northwest/Southern CA
Tim Matteson
Phone: +1 310 836 4064
Fax: +1 310 836 4067
Email: tm.ieeemedia@
Tim Matteson
Phone: +1 310 836 4064
Fax: +1 310 836 4067
Email: tm.ieeemedia@
Hilary Turnbull
Phone: +44 1875 825700
Fax: +44 1875 825701
Email: impress@
US East
Joseph M. Donnelly
Phone: +1 732 526 7119
Email: jmd.ieeemedia@ieee.org
US Central
Darcy Giovingo
Phone: +1 847 498 4520
Fax: +1 847 498 5911
Email: dg.ieeemedia@ieee.org
US West
Lynne Stickrod
Phone: +1 415 931 9782
Fax: +1 415 931 9782
Email: ls.ieeemedia@ieee.org
Sven Anacker
Phone: +49 202 27169 11
Fax: +49 202 27169 20
Email: sanacker@
Advertiser Page
Black Hat Cover 4
Advertising Personnel
marion delaney
ieee media,
advertising dir.
Phone: +1 415 863 4717
Email: md.ieeemedia@ieee.org
marian anderson
sr. advertising
Phone: +1 714 821 8380
Fax: +1 714 821 4010
Email: manderson@computer.org
sandy brown
sr. business
development mgr.
Phone: +1 714 821 8380
Fax: +1 714 821 4010
Email: sb.ieeemedia@ieee.org
AdvertiSer informAtion • mAy/June 2009