A good starting point is the SP800-14 NIST special publication on securing computer systems. It covers audit trails from a high-level perspective. The intent of this article is to highlight and explore some of the audit log concepts laid out in the publication.
Before we begin, there is a very important caveat to bear in mind - log data doesnt help if it isnt reviewed! As todays systems are often generating thousands of lines of data per day, if not per hour, manual review isnt very realistic. Log centralization and analysis tools should be used to automatically alert on certain conditions as well as help facilitate meaningful log review. Lets focus now on the details.
Inevitably, someone asks why event data should be logged on a given system. Essentially there are four categories of reasons:
What to Log?
Essentially, for each system monitored and likely event condition there must be enough data logged for determinations to be made. At a minimum, you need to be able to answer the standard who, what and when questions.
The data logged must be retained long enough to answer questions, but not indefinitely. Storage space costs money and at a certain point, depending on the data, the cost of storage is greater than the probable value of the log data.
The same can be said for costs associated with performance degradation that the log analysis tools suffer if the data sets are simply allowed to grow indefinitely.
Security of Logs
For the log data to be useful, it must be secured from unauthorized access and integrity problems. This means there should be proper segregation of duties between those who administer system/network accounts and those who can access the log data.
The idea is to not have someone who can do both or else the risk, real or perceived, is that an account can be created for malicious purposes, activity performed, the account deleted and then the logs altered to not show what happened. Bottom-line, access to the logs must be restricted to ensure their integrity. This necessitates access controls as well as the use of hardened systems.
Consideration must be given to the location of the logs as well moving logs to a central spot or at least off the sample platform can give added security in the event that a given platform fails or is compromised. In other words, if system X has catastrophic failure and the log data is on X, then the most recent log data may be lost. However, if Xs data is stored on Y, then if X fails, the log data isnt lost and can be immediately available for analysis. This can apply to hosts within a data center as well as across data centers when geographic redundancy is viewed as important.
Pulling it All Together
The trick is to understand what will be logged for each system. Log review is a control put in place to mitigate risks to an acceptable level. The intent is to only log what is necessary and to be able to ensure that management agrees, which means talking to each systems stakeholders. Be sure to involve IT operations, security, end-user support, the business and the legal department.
Work with the stakeholders and populate a matrix wherein each system is listed and then details are spelled out in terms of: what data must be logged for security and operational considerations, how long it will be retained, how it will be destroyed, who should have access, who will be responsible to review it, how often it will be reviewed and how the review will be evidenced. The latter is from a compliance perspective if log reviews are a required control, how can they be evidenced to auditors?
Finally, be sure to get senior management to formally approve the matrix, associated policies and procedures. The idea is to be able to attest both that reviews are happening and that senior management agrees with the activity being performed.
Audit logs are beneficial to have for a number of reasons. To be effective, IT must understand log requirements for each system, then document what will be logged for each system and get managements approval. This will reduce ambiguity over the details of logging and facilitate proper management.
Note: A sample log matrix template will be placed on the authors website at http://www.spaffordconsulting.com/articles.html next to the link to this article.