Audit Trails

Audit trails are the auxiliary records that are created which record transactions and other events. Of the many reasons for having audit trails, here are a few:

check.png Enforcement of accountability: Employees tend to be more accountable for their actions when they know that audit trails capture the details of those actions.

check.png Investigation: Investigators who need to trace the actions of an individual’s activities can rely on audit trails to see what that person did.

check.png Event reconstruction: Analysts may need to understand and reconstruct a complex event. Without audit trails, event reconstruction could be an exercise in futility.

check.png Problem identification: Audit trails can help an analyst or engineer identify and rectify the root cause of a problem.

Audit or audit trail?

To audit is an activity, and an audit is the output of the activity — the verification of accuracy of an application or system.

An audit trail is a record of events, without regard to correctness or accuracy of the event. It just reports an event.

Anatomy of an audit record

instantanswer.eps The basic components of an audit record are

check.png Date and time: When the event occurred

check.png Who: The person who performed the event

check.png Where: The location at which the person performed the event (for instance, which terminal or workstation the person used during the event)

check.png Details: Information about the event (such as original and changed settings)

Types of audit trails

Audit trails (also known as audit logs or just logs) come in several shapes and sizes. They include myriad log files and formats, such as cryptic sendmail logs and syslog entries, system login records, network trace logs, and transaction logs from applications.

Audit trails lack one important feature: consistency of format. It’s as though everyone who ever wrote a program that generates an audit log crawled into a cave and invented his own audit log file format.

How to go looking for trouble

After you set up your audit logs and have the operating system tools, utilities, and applications logging events, how do you differentiate between normal activities and events that indicate real trouble?

Audit trails — the justification for time synchronization

System and network administrators have long recognized the value in synchronizing the time-of-day clocks in their systems with recognized standards, such as the U.S. National Bureau of Standards (NBS) atomic clock. Although this synchronization may just seem like a cool 007 thing to do, systems really do need to have their time-of-day clocks synchronized to within fractions of a second.

Imagine a situation in which you’re trying to piece together a complex set of events that took place on several computers. The order in which events take place on several systems is highly significant. But what if the time-of-day clocks on these systems are several seconds or minutes apart? If the systems’ clocks aren’t synchronized, you can find it difficult, if not impossible, to determine the actual order in which events occurred.

This is really a two-fold problem. First, how do you determine whether an audit log entry is a routine event or an event indicating a problem? Second, how do you parse (or analyze) all of the information that is collected? It is often more practical to perform random sampling of the various log files on a regular basis so that you know the information is being properly collected and can recognize when something is wrong (for example, a log file that is normally only a few kilobytes in size suddenly grows to several megabytes).

Most modern operating systems and software applications lack the tools to parse audit logs and send appropriate messages to your pager, mobile phone, or e-mail inbox. However, many third-party software packages can collect and parse this information, and wake you up in the middle of the night when something really bad is happening.

Problem management and audit trails

So what do you do when you see trouble brewing in the audit logs? Follow these steps:

1. Determine whether the audit trail entry indicates genuine trouble or whether the entry is a false-positive.

If the entry is a false-positive, then create an exception (if your auditing application allows it) and document the nature of the event. If real trouble exists, determine the appropriate response and, if the situation warrants, sound the alarm and rally the troops.

2. Conduct a root cause analysis.

Audit trails are used to troubleshoot and reconstruct events, and root cause analysis is ideal in this situation. The analysis should lead to resolution of the problem — and eventually, the capability to prevent the problem in the future.

Without the audit trail, you’re groping in the dark (a bad thing in the security business) — clueless as to what happened, and clueless as to how to prevent it from happening again.

Retaining audit logs

Many administrators forget to consider the many, many gigabytes of audit logs produced every day by a firewall or an intrusion detection system (IDS), but they find out soon enough when the system runs out of disk space — or worse yet, log files that you actually need for an investigation are overwritten by newer log files.

We can’t tell you how long you should keep your audit logs, but it would be irresponsible for you to just chuck ’em without finding out from someone authoritative how long they should be kept. In many industries, audit log retention ultimately becomes a legal issue (complying with federal, state, and local laws), especially with applications. Find out how long audit logs need to be kept, and then figure out how to keep them.

Protection of audit logs

The integrity of audit logs is an absolute necessity, and this is another one of those difficult situations that may keep you up at night.

instantanswer.eps Audit logs must be protected against sabotage and other attacks that would prevent audit logs from properly and reliably recording events.

Here’s the problem: Audit logs are usually just data files on a computer. A determined person who wants to cause trouble and/or erase his tracks is going to look around for the audit logs and try to alter them. Do you really think you can absolutely prevent this? No way. But you can come close.

With some creativity, you can utilize a few techniques on the really important audit logs, such as writing them directly to a sequential access device (tape drive) or a write-only device (CD-ROM), or sneaking them off the subject system over the network to another system.

None of these techniques is foolproof, but these methods can make it more difficult for determined intruders (or malicious insiders) to cause the kind of trouble that they have in mind.

Audit logging can also be the source of a Denial of Service (DoS) attack. For example, an intruder or insider who wants to perform some illicit, usually audited, transaction(s) is naturally worried about the audit log recording his dirty deed. However, he can launch a DoS attack on the audit log: Either he can perform thousands (or millions) of transactions or he can consume disk space in some other way to cause the audit-trail mechanism to run out of available disk space. After the audit-logging mechanism is gagged, the intruder can transact away, and the audit log won’t record a thing, unless the system is designed to stop processing transactions if it is unable to write audit-log entries.

Here we circle back to the idea that protecting audit logs is vitally important. If they’re disk-based, you need some mechanism in place that can move them quickly off the system in case an intruder tries to destroy them.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.186.219