Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
IEEE How to App Logging Gunnar+Anton-2010

IEEE How to App Logging Gunnar+Anton-2010

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

More info:

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

Availability:

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

07/27/2011

pdf

text

original

 
Building Security In
Editors: John Steven, jsteven@cigital.comGunnar Peterson, gunnar@arctecgroup.net
82
COPUBLISHEDBYTHEIEEECOMPUTERANDRELIABILITYSOCIETIES
1540-7993/10/$26.00©2010IEEE
JULY/AUGUST2010
logs are suitable or manual, semi-automated, and automated analy-sis. Ideally, you can analyze themwithout having the applicationthat produced them—and def-nitely without having the appli-cation developer on call. Fromthe log management viewpoint,the logs can be centralized or analysis and retention. Finally,they won’t slow the system downand can be proven reliable, i usedas orensic evidence.
What to Log 
So, what types o events should you log?The frst type is
authentication,authorization, and access
events:• successul and ailed authentica-tion or authorization decisions;• system access, data access, andapplication component access;andremote access, including rom oneapplication component to another in a distributed environment.The second type is
changes
:system or application changes(especially privilege changes),• data changes (including creationand destruction), and• application and component in-stallation and changes.The third type is
availability issues
:• startups and shutdowns o sys-tems, applications, and applica-tion modules or components;• aults and errors, especially er-rors aecting the application’savailability; anddevelopers and architects and tosecurity proessionals.
 Application Logging Today 
Organizations have fnally gottennetwork device logging and—tosome extent—server logging un-der control. However, ater get-ting used to neat Cisco AdaptiveSecurity Appliance or other fre-wall logs and Linux “passwordaccepted” messages, security in-cident investigators trying to re-spond to the next wave o attackshave been thrust into the horrifcworld o application logging.Problems with many applica-tion logs are truly staggering. Logsare oten missing, they omit criti-cal details, or they have no stan-dard orm or content. On top o this, many security practitionersmust deal with debugging logsmasquerading as security auditlogs. Table 1 illustrates the keydierences between the two.Debugging logs appear inapplication rameworks morerequently than well-designed se-curity audit logs. However, usingthem or investigations is otenan exercise in rustration becausethey might not contain key detailsneeded or incident response andorensics.So, sometimes we must dealwith log messages like these:
Aug 11 09:11:19 xx nullpif ? exit! 0
(which carriesabsolutely no meaning),
Message 202 User tran-sitioning priv level
 (which conveniently omits theactual user identity—the useo “secret” numeric codes alsocauses trouble i no documenta-tion is available), or 
userenv[error] 1040 XYZ-CORP\wsupx No descrip-tion
 
available
(which scorespoints or both honesty and use-lessness).In light o this, how do weguide application developers andarchitects toward creating secu-rity audit logs that are useul or orensics and monitoring and thathelp satisy compliance mandatessuch as the Payment Card Indus-try Data Security Standard (PCIDSS)? We can start by establish-ing criteria or good security au-dit logs (which we just call “logs”rom now on).
Logging Criteria 
From a high level, the best logstell you exactly what happened,and when, where, and how. Such
 A
s threats shit toward applications and as morecompanies struggle with compliance man-dates, the need or useul, comprehensiveapplication logging can only increase. Herewe provide guidance on application logging to application
A
nton
 C
huvAkin
SecurityWarrior Consulting 
G
unnAr
 P
eterson
 Arctec Group 
HowtoDoApplicationLoggingRight
 
Building Security In
www.computer.org/security
83
backup successes and ailuresthat aect availability.The ourth type is
resource issues
:exhausted resources, exceededcapacities, and so on;connectivity issues and prob-lems; and• reached limits.The fnal type is “
badness”
or 
threats
:• invalid inputs and other likelyapplication abuses and• other security issues known toaect the application.Creating a comprehensive “whatto log” list or every applicationand organization is impossible.However, our list should provide auseul starting point or your cus-tom applications, especially thosedealing with regulated data suchas payment cards or sensitive per-sonal inormation.
What to Include 
Next, what data should you logor each event, and at what level o detail should you log it? The phi-losophy o relevant log details goesback to ancient Greece (http://en.wikipedia.org/wiki/Five_Ws)and ocuses on the “Six Ws”:• Who was involved?• What happened?Where did it happen?When did it happen?Why did it happen?• How did it happen?(No, we can’t explain why thesixth W is actually an H.) Thisancient wisdom applies perectlyto logs and helps defne a useul,unambiguous log entry.On the basis o the six Ws, theollowing list provides a startingpoint or what to include:• The
username 
helps answer “who” or those events relevantto user or administrator activi-ties. In addition, it’s helpul toinclude the name o the identityprovider or security realm thatvouched or the username, i that inormation is available.• The
object 
helps answer “what”by indicating the aected systemcomponent or other object (suchas a user account, data resource,or fle).• The
status
also helps answer “what” by explaining whether the action aimed at the ob- ject succeeded or ailed. (Other types o status are possible, suchas “deerred.”)• The
system
,
application
, or 
compo-nent 
help answer “where” andmust provide relevant applica-tion context, such as the initiator and target systems, applications,or components.• The
source 
helps answer “romwhere” or messages related tonetwork connectivity or distrib-uted application operation.• The
time stamp
and
time zone 
 help answer “when.” The timezone is essential or distribut-ed applications. In addition tothe time stamp and time zone,some high-volume systems use atransaction ID.• The
reason
helps answer “why,”so that log analysis doesn’t re-quire much digging or a hid-den reason. Remember, the log’scustomers are the security andaudit personnel.• The
action
helps answer “how”by providing the nature o theevent.• In addition, the
 priority
helps in-dicate the event’s importance.However, a uniorm scale or rating events by importance isimpossible because dierent or-ganizations will have dierentpriorities. (For example, di-erent companies might havedierent policies regarding in-ormation availability versusconfdentiality.)So, a useul log message mightlook like this:
2010/12/31 10:00:01AMGMT+7 priority=3,system=mainserver,module=authentication,source=127.0.0.1,user=anton(idp:solar),action=login,object=database,status=failed,reason=“passwordincorrect”
This message has a feld explain-ing the ailure’s reason. Also, itisn’t in XML; human readability isuseul in logs, and computers candeal with
name=value
pairs justas well as with XML.
What Not to Include 
Certain details should never belogged. Some examples are ob-vious: logs should never containapplication or system passwords.
Table 1. Comparing security audit logs and debugging logs.
Security audit logsDebugging logs
Intended consumersSecurity and audit personnelSystem operators and developers When the logger is onAlwaysSometimesMessage contentAttacks, activities, and faultsFaults, failures, and errorsScope of what to logKnown in advanceUnknownLength of usefulnessYearsHours or days
 
Building Security In
84
IEEESECURITY&PRIVACY
(Sadly, this sometimes still hap-pens with Web applications.)
Centralization 
As we mentioned beore, easycentralization o logs is essentialor distributed log analysis acrosseither multiple systems or mul-tiple application components o adistributed application. Althoughsyslog has been a awed but deacto standard o log centralizationowing to its easy User DatagramProtocol delivery, modern cross-platorm application rameworkscall or the publish/subscribemodel or log delivery. In thiscase, a security-monitoring toolcan request a subscription to a par-ticular type o logged event—andreceive all relevant logs in nearlyreal time, i needed.
Know Your Customer 
When you add logging unc-tionality to your application, you’re not just building securityin, you’re building visibility in.
1
 That visibility is the inormationin the log that will be viewed by your log’s customer—the inci-dent responder. To maximize thelog’s useulness, you must un-derstand the incident responder’srequirements. These might be aparticular audit record ormat, in-tegration with network securitymonitors, or listening or specifctypes o events.One thing is or sure: ap-plication developers can gather context that’s simply unavailableanywhere else in the system.The application is the concreteimplementation o the sotware’sstructure and behaviors rom thebusiness logic, business rules, en-terprise policies, and Web rontends to the data structures andstorage. This gives the applicationcontext, which is everything toan incident responder.
Locating the Logging Service 
The logging service’s location re-lates directly to the type o eventsthe logger can see and the dataand context available to the log-ger. The logger is responsible or discerning the event type, gather-ing context, and writing inorma-tion. To discern events, the logger must be able to view the event’ssource, its payload, and the object.Additional context includes suchinormation as the authority andsecurity domains.Given a Web application attacksuch as SQL injection, a logger inthe presentation layer might beunable to discriminate valid inputrom invalid input (an attack). Butin the business logic layer (wherebusiness rules are applied) or dataaccess layer (where SQL state-ments and data connections aremade), increased knowledge o theobject environment provides bet-ter visibility or the application as awhole, and specifcally the logger,to ag input as a possible attack.Table 2 describes how a typi-cal three-layer architecture de-ends against SQL injection. Italso gives an example o how thevisibility at each layer drives whatthe logger reports.The same malicious user inputmight be reported dierently ateach layer. To help correlate thesereports, the logger oten adds atransaction or message exchangeID to acilitate log analysis whenreconstituting the events.
Sanitizing Audit Records 
Typically, logging subsystems areplaced to detect events aroundsensitive assets, which means thatthey’ll come into contact withsensitive data. Sanitizers can flter and remove sensitive data romlogs. A sanitizer’s location (seeFigure 1) is important because itdetermines whether sensitive datais fltered by the log browser or removed rom persistent storage(sensitive data is never stored inthe log).
Storage Forecast— Cloudy with a Chance of Compromise 
Most systems store logs inside theenterprise, but as with many ITareas, the cloud oers new op-portunities and potential solu-tions and problems. The cloudhas proven to be an eective wayto store data. However, becausein the cloud storage model, thedata is stored and possibly pro-cessed outside enterprise secu-rity, challenges remain owingto requirements or encryptionand other controls. For example,PCI DSS provides a starting pointor log storage requirements, butmeeting them might be dicultin a cloud model.
I
n addition to our basic con-clusion—You must log!—we
Table 2. Defending against SQL injection attacks.
LayerInjection defenseWhat the logger will report
Presentation layerForm input validationAn invalid-input event—that is, a failed white list or blacklistinput validation eventBusiness logic layerBusiness logic, rules, or policies A failed authentication, authorization, or access event—that is, failed validation based on business logic, rules, or policiesData access layerPrepared statement oparameterized query A resource issue event—that is, an SQL syntax error event

You're Reading a Free Preview

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