CISSP For Dummies

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

• Enforcement of accountability: Employees who know that audit trails capture the details of their actions tend to be more accountable for their actions.

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

Audit is an activity and 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. It’s just a reporting of an event.

• Event reconstruction: Analysts may need to understand and reconstruct a complex event. Without audit trails, this could be an effort in futility . . . and humility.

• Problem identification: Audit trails can help an analyst or engineer get to the root cause of some sort of a problem.

Anatomy of an audit record

 Instant Answer   The basic components of an audit record are

• Date and time of the event

• Who performed the event

• Where the event was performed (for instance, which terminal or workstation was associated with the event)

• Details about the event (such as old and new values)

Types of audit trails

Audit trails (also known as audit logs, or just logs) come in several shapes and sizes. They include the cryptic sendmail logs and syslog entries, login logs, network trace logs, and also 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. Audit log formats have as much compatibility as taillight lenses share for Fords, Chevys, Toyotas, and Hondas.

This lack of consistency presents a great opportunity to become super-rich by writing the next killer app: audit log consolidation and correlation applications. Imagine ordinary citizens practically bowing down to you when they find that you’ve written an audit log correlation utility - that, or they’re just getting out of the way of your Hummer.

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 may just seem like a cool 007 thing to do, there is a real justification for systems 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 of events that 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, it can be difficult to determine the actual order in which events occurred when several systems are involved.

Finding trouble in them thar logs

After your audit logs are set up and the operating system tools, utilities, and applications are writing to them, how do you differentiate between normal humdrum events and events that indicate big trouble?

This is really two problems in one:

• First, how do you determine whether an audit log entry is a routine event or an event indicating a problem? You’ll have to just work hard to figure these out. You have to RTFM (Read The . . . ’er, Funny Manual) and learn from experience.

• Second, do you really believe that someone is actually watching all your organization’s audit logs? Not a chance. Nobody eats the parsley garnish on his plate, and nobody reads audit logs. So how do you find out whether something serious is going south? Perform sampling and look at the logs now and then.

This is a hard problem. Most modern operating systems lack the tools to parse (not to be confused with pars-ley) audit logs and send panic messages to your pager, mobile phone, or e-mail inbox. You need to shop around for public domain (free, poor documentation and support) or commercial (expensive, poor documentation and support) software packages that collect, parse, and wake you up at midnight when something really bad is happening.

Problem management and audit trails

In this most fascinating topic of information security, we can practically hear readers asking in unison, “What do we do when we see trouble brewing in the audit log?”

You do two things:

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

   Ask your more experienced colleagues for help. If real trouble exists, then presumably you have a sound-the-alarm escalation process, whereby you let the cat out of the bag and tell someone that the payroll application is on fire. (Accounts payable, of course, would have a much lower priority.)

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 ability to avoid 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 avoid it. Time for a career change.

Retaining audit logs

Many administrators forget to consider the many, many gigabytes of audit log material 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.

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 are supposed to be kept, and then figure out how to keep them.

Chances are that you’ll back up audit logs to tape because having years’ worth of audit logs on most systems isn’t feasible. This introduces a new problem: You need to pick a medium (tape or CD, for example) that will last for the required time period. No, tapes and even CDs aren’t forever - they have finite lifetimes that are frequently less than the number of years that a lot of this stuff needs to be kept.

 Tip   Call in an expert to consult on your retention policy if needed; it beats being out of compliance with the law, and you don’t want Cold Case Files knocking on your door someday asking you questions that you really cannot recall the answers to.

Part of the Will my media last for n years? problem is just that. Not only do you have to determine just how long the bits will stay on the tape, but you also have to worry about media obsolescence. In other words, if you back up your long-term storage audit log info to SuperDLT tape, you have to ask whether SuperDLT will even exist in 15 years. Will the local computer museum even have a working SuperDLT drive? Probably not. This is the quandary of long-term data storage: picking a medium that will be around in a decade for which you can still get hardware support and software drivers in the unlikely event that you will have to actually recover and read this data. Now you know the real reason why IT professionals change jobs every few years. Good luck.

Protection of audit logs

We’re really not talking down to you when we say that the protection of audit logs is an important issue. The integrity of audit logs is an absolute necessity, but this is another one of those difficult situations that may keep you up at night.

 Instant Answer   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 just data files on a computer. A determined person who wants to either cause trouble 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 and an expert on this topic, you can utilize a few techniques to use on the really important audit logs, such as writing them directly to a sequential access device (tape drive), a write-only device (CD-ROM), or sneaking them off the subject system over the network to another system.

None of these techniques are foolproof, but these methods can make it more difficult for determined intruders (or insiders) to cause the kind of trouble that they have in mind. Their most important function is to act as a deterrent, just like using The Club on your car’s steering wheel. Perhaps the no-good-doers will notice your nifty audit logging mechanism and move on.

Audit logging can be the object of a Denial of Service (DOS) attack, believe it or not. Here’s what can happen. An intruder/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/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 now-deaf audit log won’t hear a thing.

We circle back to the idea that protecting audit logs is vitally important. If they’re disk-based, some mechanism (usually tape/CD backup) needs to quickly grab them off the system in case an intruder is going to try to destroy them.

If your intruder is truly nasty and wants to burn down the data center after performing his secret transactions, this should cause you to consider that onsite storage of audit logs is really insufficient. Even without intruders, accidental fires, earthquakes, floods, and other events can ruin both your servers and the audit logs on CDs or tapes in the same room. Off-site storage isn’t just an option, but a necessity.