Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more ➡
Standard view
Full view
of .
Add note
Save to My Library
Sync to mobile
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
IEEE 82 85 SOA Logging Chuvakin Petersen

IEEE 82 85 SOA Logging Chuvakin Petersen

Ratings: (0)|Views: 166|Likes:
Published by Anton Chuvakin

More info:

Published by: Anton Chuvakin on Jul 27, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See More
See less





Building Security In
Editors: John Steven, jsteven@cigital.comGunnar Peterson, gunnar@arctecgroup.netDeborah 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 Webservices, but they don’t provideservices or logging, audit log-ging, and detection and response.Moreover, Web services architec-tures are generally built on state-less protocols such as HTTP andSOAP, which don’t support evenbasic request-response correlation,leading to a major security archi-tecture and design challenge.
Logging and Web Services 
Logs oer an endless well o valuable inormation about sys-tems, networks, and applications.Through logs, audit records, andalerts, inormation systems otengive signs that something is bro-ken (or “broken into”) or will bebroken soon. They can also reveallarger weaknesses that might aectregulatory compliance and evencorporate governance. However,more oten than not, system andapplication logs contain raw datarather than inormation, and thusrequire extra eort to extract or distill this data into somethinguseul, usable, and actionable.
At the very highest level, logsare a vehicle o accountability. O course, an organization has manyother mechanisms or accountabil-ity, but logs pervade all o its IT,and i its IT isn’t accountable, theorganization probably isn’t either.Various logs are also valuable or regulatory compliance programs.Many recent laws and mandateshave items related to audit logs— or example, a detailed analy-sis o the security requirementsand specications outlined in theHealth Insurance Portability andto solve. In this article, we describehow audit logging can be built intothe Web services inrastructure.
Why Web Services? 
Web services aim to deliver vir-tualization, interoperability, andreusability via technology imple-mentations such as SOAP, service-oriented architecture (SOA), andRepresentational State Transer (REST). Interoperability in par-ticular is paramount or enterprisesthat must transact business acrossmultiple .NET, Java, open source,and mainrame platorms. Add inmessaging connections to custom-ers and partners located in dierentcountries or organizations, and thechallenges o getting protocols andmessage ormats to mesh together seem overwhelming. This is theproblem that Web services attemptto address. Unortunately, howev-er, most Web services implemen-tations oer their own challengesas well—namely, they don’t alwaysenable security by deault, and theyoten leave security decisions aboutauthentication, authorization, andaudit logging to the implementer,which can cause serious long-termproblems down the road.
Web services security has twoparts: interace and implementa-tion security and message secu-rity. Interace and implementationsecurity uses traditional Web ap-plication security controls such asSecure Sockets Layer (SSL) andaccess control lists (ACLs). For message security, XML mecha-nisms such as WS-Security, theSecurity Assertion Markup Lan-guage (SAML), XML Signature,and XML Encryption can sign,encrypt, and authenticate messagedata, giving the sender greater condence that the message stayscondential until delivery and therecipient greater condence in themessage’s authenticity.Instead o relying on role-basedaccess control, in which securityservices mediate the communica-tions o subjects, objects, and ses-sions in a central policy domain,Web services evaluate a message’sclaims against a specic policy.This claims-based access controlmodel lets the architect composesecurity protocols along the samelines as the application. Standards-based XML security mechanismssuch as WS-Security, SAML,XML Signature, and XML En-cryption are powerul tools or people building security architec-tures in distributed systems to de-liver message-level authentication,integrity, and encryption services.These standards oer new and
n today’s age o Web applications connected via Webservices, accountability has become both crucial andharder to achieve. The management o authentica-tion, authorization, and accountability in these ap-plications is thereore a very important and dicult problem
 Arctec Group 
logging in theage of Web service
Building Security In
Accountability Act (HIPAA) re-veals some items relevant to audit-ing and logging, such as the audit,logging, and monitoring controlsor systems that contain patientinormation. Similarly, the Pay-ment Card Industry Data Secu-rity Standard (PCI DSS) explicitlymentions logging, log collection,and data retention and log analysisor systems involved in credit-cardtransactions. Clearly, the impor-tance o logs or compliance willonly grow as standards becomethe oundations or new regula-tions that are sure to emerge.An interesting challenge that’slikewise sure to emerge is how tohandle logging in distributed envi-ronments such as those o Web ser-vices. Unlike operating system logs,which are physically located on asingle machine or a single networkdevice, Web services are by their nature distributed across multiplesystems, disparate technologies andpolicies, and even organizationaldomains. This creates many con-straints on audit log design in termso both scope and strength. Giventhese constraints, logging mightreside in dierent parts o Web ser-vices architectures:In the simplest case (two ma-
chines talking to each other viaa Web service), we could prob-ably log events occurring on bothmachines, but we won’t have acomplete view o the overall ar-chitecture. I we put a log oneach machine, we’ll need addi-tional technologies or consistentaggregation and reconciliation.At each endpoint, Web ser-
vices interaction involves mul-tiple sotware components. Atthe very least, this will involvea Web server, an applicationserver, and most likely a databaseserver on each side. Moreover,the application server might besel-distributed, thus presentingadditional challenges to deter-mine where to put the log.Even under a distributed Web
services architecture, we canchoose an approach in whicheach individual component oneach individual machine createsits own log. It’s not uncommonto see applications log into their own text les; similarly, it’s notuncommon or Web services de-signers to use the MS Windowsevent log i their endpoint appli-cations only run on this platorm.(Many application developers tendto choose the Windows event logbecause they consider it to be thestandard or logging.)Reviewing these options leadsus to believe that—where practi-cal—a Web services architectureshould have its own logging mech-anism, so that each componentinvolved in that particular archi-tecture has a uniorm way o cre-ating a log or later access rom asingle point. Moreover, each com-ponent in such a distributed systemshould not only use a single mech-anism but also use the same eventtypes to let the user reconstructwhat actually transpired in the in-rastructure. It’s worth noting thatsome o the events to log might bedistributed in nature themselves,which could prevent anyone romusing a local log to describe them.Thereore, the best way to perormlogging in a Web services archi-tecture might be a ully distrib-uted logging mechanism. Despiteits distributed nature, applicationserver logging is probably the cen-tral part o Web services logging;Web server logs are less helpulbecause many Web services (espe-cially SOAP), servers, and even ap-plication rewalls specically turno logging or HTTP POST tasksbecause o the amount o data gen-erated in these requests.Classic Web services have aclean separation o the messagedocument (typically XML) andthe implementation (Java, C#,and so on), so logging locationvaries based on intent. The Webservices ramework oten imple-ments logging events based onmessage content in an adapter,handler, or interceptor type pat-tern. This approach’s advantage isthat it executes logging rules ater message creation but beore thesender puts it on the network andas soon as the recipient reads it o the wire. Logging rules are thuscreated and managed independento the code.However, this approach canmiss some important events thatrequire getting into the code—or example, logging messages is ne,but nobody can iner exceptionsrom them or determine what hap-pened to the message ater sendingit. Building the runtime code witha set o events to watch or and loggives much more actionable inor-mation. Ater all, the code is thearbiter o how the system will ul-timately use the message.An alternative approach addsa Web services security gatewaybetween the service requester andprovider that proxies the com-munication channel. The benethere or audit logging services isthat the gateway has access to theull message to perorm loggingoperations. In addition, Web ser-vices gateways are used to perormapplication tasks such as messagetransormation as well as securityservices such as authentication andauthorization. Because the gate-way has access to the ull message(header and body) and controlspolicy-based events such as au-thentication and authorization de-
 An interesting challenge that’s likewise sure to emergeis how to handle logging in distributed environmentssuch as those of Web services.
Building Security In
ieee seCurity & PriVaCy
cisions, the visibility and controlo events makes it a good locale or writing audit log events.
What Should We Log? 
Several types o logging eventscan occur in a Web services inra-structure. First, let’s consider themost basic type o event: authen-tication. When a Web servicesclient authenticates against a Webservice, this event should certain-ly be logged. A typical scheme au-thentication event would includeauthentication credentials (user-name and password) or inorma-tion about other mechanisms usedor authentication (such as tokens).Due to possible use o single-sign-on, authentication itsel might bedistributed and happen on a di-erent server, urther highlight-ing the need or Web serviceslogging to be distributed. As wementioned earlier, Web servicestypically use two security mod-els—interace and implementationsecurity and message security— and authentication can happenin either layer independently or in dierent parts o the sotwarearchitecture. The log event modelmust account or both types o event and the act that they canoccur asynchronously.Other logging events includeauthorization and access. Bothsuccessul and ailed attemptsto get access to data or servicesmust be logged. Although somepeople ocus on logging just theailed attempts, successul onesare equally important: i a Webservice client accesses data that itisn’t supposed to, logs can provideone o the ew ways to know thatthis has happened. Earlier, wediscussed the claims-based accesscontrol model or Web services,which doesn’t have a necessarilyhard boundary between authen-tication events and authorizationevents. The security architectmust dene these event types andresults or the event log model.Other logging events includevarious ailures, errors, and ex-ceptions. It’s dicult to create aspecic list o errors and ailuresthat must be logged, but many o the simple ones can point to po-tentially signicant security ail-ures—or example, a corruptedcall to a Web service might indi-cate a sotware bug or an attemptto send corrupted requests or exploitation. Specically, WS er-rors detected while validating therequest input are critical to logbecause many attacks include spe-cially ormatted incorrect input(malormed input) to exploit theservice’s back end. Resource ex-haustion issues are also importantto log because they might indi-cate a denial-o-service attack or the consequences o a “benign”sotware bug. Even log evidenceo an application server crashmight be critical evidence or anincident investigation.Web services are applicationsthat are as much congured asthey are coded. As such, numerousmanagement and policy systemscome into play, so key man-agement operations, enterpriseservice bus (ESB) ederation, or-chestration, and other intermedi-aries must be logged as well. Table1 gives a checklist to help guidewhat might be valuable to log or aWeb services application.
he biggest challenge in loggingis where to generate, store, andmanage the log. A Windows Webservice requester might write tothe Windows event log, but themessage goes to a Java Web ser-vice provider that, by deault,writes its own log to Websphere.Even in this simple case we cansee that a complete end-to-endlog o something as clear cut as asingle request-response interac-tion is a challenge.Web services are designed tooer a loosely coupled integration.The service requester and serviceare independent, oten running inseparate technical and policy do-mains. In act, in almost all cases,there’s no notion o a classic two-phase commit transaction, even or high-value transactions—instead,Web services are “eventually con-sistent,” meaning that the clientand server both independentlyconduct computations and writeevents. Later, through replication,updates, and other means, theseevents are reconciled or greater consistency. What this approachlacks in perection, it makes up or in its proven, massive scalability.The net result o the Web ser-vices logging problem is both achallenge and an opportunity.The challenge is that there’s nocohesion or consistency in how
Tab 1. Audit  cckit f a Wb ic appicati.
CATegoryWhAT evenTs To log
 Authentication, authorization, and accessAuthentication/authorization decisions, system access, data accessChangesSystem/application changes (especially privilege changes), data changes (including creationand destruction)ThreatsInvalid input (schema validation failures)Exhausted resources, capacity Limits reached (message throughput, replays), mixed availability issuesStartups and shutdownsStartups and shutdowns of systems and servicesFaults and errors, backup success/failureErrors, faults, and other application issues

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->