Building Security In
• backup successes and ailuresthat aect availability.The ourth type is
:• exhausted resources, exceededcapacities, and so on;• connectivity issues and prob-lems; and• reached limits.The fnal type is “
:• invalid inputs and other likelyapplication abuses and• other security issues known toaect the application.Creating a comprehensive “whatto log” list or every applicationand organization is impossible.However, our list should provide auseul starting point or your cus-tom applications, especially thosedealing with regulated data suchas payment cards or sensitive per-sonal inormation.
What to Include
Next, what data should you logor 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 perectlyto logs and helps defne a useul,unambiguous log entry.On the basis o the six Ws, theollowing list provides a startingpoint or what to include:• The
helps answer “who” or those events relevantto user or administrator activi-ties. In addition, it’s helpul toinclude the name o the identityprovider or security realm thatvouched or the username, i that inormation is available.• The
helps answer “what”by indicating the aected systemcomponent or other object (suchas a user account, data resource,or fle).• The
also helps answer “what” by explaining whether the action aimed at the ob- ject succeeded or ailed. (Other types o status are possible, suchas “deerred.”)• The
help answer “where” andmust provide relevant applica-tion context, such as the initiator and target systems, applications,or components.• The
helps answer “romwhere” or messages related tonetwork connectivity or distrib-uted application operation.• The
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
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
helps answer “how”by providing the nature o theevent.• In addition, the
helps in-dicate the event’s importance.However, a uniorm scale or rating events by importance isimpossible because dierent or-ganizations will have dierentpriorities. (For example, di-erent companies might havedierent policies regarding in-ormation availability versusconfdentiality.)So, a useul 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 isuseul in logs, and computers candeal with
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