The Security Cycle

Before discussing how and what to audit, you need to understand why to audit. There is a natural cycle associated with security that begins with prevention, moves to detection, and finishes with response. This cycle is described very well in Secrets and Lies: Digital Security in a Networked World by Bruce Schneier (John Wiley & Sons, 2000). What is important about understanding this cycle is that it helps you understand that security isn’t exclusively about access control.

Prevention, which includes access control, is the first process in the cycle. It describes all of the measures put in place to control who can do what and how they can do it. In the nondigital world, you see examples of this everywhere, such as locks on doors, electric fences, and security guards restricting access to buildings and building corridors. Many people refer to a system’s security to mean only the preventative security measures. While this may seem intuitive, it is incorrect.

Let’s look at a bank as a reference. The bank has security designed in from the beginning. The walls are reinforced brick and concrete. This prevents people from mounting a successful Exacto knife attack in which a burglar walks up to a building, usually a residential home, and slices through the siding and insulation, thus creating an instant portal into the structure. Inside the bank you see many other prevention measures such as a security guard, bulletproof glass, and a physical separation from customers, tellers, and money. The vault itself is constructed to prevent robbers from breaking the lock, the door, or slicing through the sides with a torch. The interesting part is that the vaults are not guaranteed to prevent access. They only slow access in attempts to prolong the robbery until the authorities arrive.

This brings us to the next step: detection. Detection can easily occur when the attack happens at a time when people are watching. A bank robbery during the midmorning will be detected by the people being robbed. If the robbery happens at night, on Sunday, or any of the numerous bank holidays, the detection may be more subtle. Enter motion detectors. These are excellent detection devices. It’s clear that the motion detectors cannot prevent the robbery. They can only detect it.

Once a security breach is detected, a response is usually desired. In the case of a bank robbery, the police will respond by rushing quickly to the bank. In the case of a residential home burglary, the home’s alarm system will notify the alarm company, who will then notify the police. They may first notify the homeowner; in the event that the detection is a false alarm, the homeowner will cancel the call to the police. False alarms happen more than actual break-ins. This is also true for computer systems.

Security begins with a clear and concise security policy. The policy is enforced through proper design and implementation complemented with varying access control capabilities. The lessons from security in the real world translate directly to the computer world. Invariably, something bad will happen. There is no way to build a computer application that is 100 percent secure. You have to rely on auditing for the detection mechanisms to support the overall database security. The response relies on the detection—the audit trail. The section, “Fine-Grained Auditing,” shows that the responses can be expedited by an alerting capability.

Auditing for Accountability

Many people use auditing to provide the detection capabilities just described to support their overall database security efforts. Others audit to satisfy compliance with mandatory regulations, corporate or organizational policies, or contractual agreements. Generally, the common thread among all of these is user accountability. You want to ensure users are doing only what they are supposed to. You want to capture privilege abuse and misuse. Auditing allows you to hold your users responsible for their actions by tracking their behavior.

When a person commits a crime, a picture that has captured them in the act can serve as very compelling evidence. An important aspect to auditing is that it can also serve as a deterrent for would-be bad guys. If you know that someone is watching, you are less likely to do something bad. Database auditing can be thought of as the security cameras that capture the actions and diabolical deeds as they unfold. Note that the cameras and auditing may capture both good or expected actions as well as the bad and unexpected actions.

Auditing Provides the Feedback Loop

One thing worse than being robbed is not even knowing that you’ve been robbed. Auditing can help. The audit records are the means of capturing the robbery. If you’re viewing the records and you see something has happened, then you can properly respond. Response may result in readjusting your access control mechanisms and expelling the user.

Two important things have to happen for effective auditing. First, you have to be auditing and auditing on the correct thing. This is analogous to saying you have to have security cameras turned on and facing the right direction. Second, you have to read and interpret the audit records.

The audit records act as a feedback mechanism into the prevention and access control mechanisms you’ve already established. They also play an important role in any investigative activities that occur either as a result of a breach or in anticipation of one. Without auditing, you may have no way of knowing whether your security is sound or whether your data has been read or modified by an unauthorized user.

Auditing Is Not Overhead

Some people feel that auditing introduces overhead which, when compared to the little value they derive from the audit records, is not worth it. This philosophy is flawed for several reasons.

Note 

Auditing is not overhead.

Auditing all actions by all users on all data is not useful and will make a system perform miserably. Auditing must be selective and, when done correctly, it targets the correct data, processes, and users. This means the audit records are, by definition, very useful. The audit records also have to be reviewed and acted on when necessary. This means there is a regular process of reviewing, archiving, and deleting the unneeded records as appropriate. Chances are good that this isn’t happening if the performance overhead issue is raised.

Auditing is an art that carefully balances capturing the needed audit records in a way that doesn’t introduce detrimental effects on performance. People who are unfamiliar with how and when to audit may in fact end up with a slower performing system with so many audit records that an administrator can’t distinguish the people doing legitimate work from the people with malevolent intentions.

The truth about auditing is that it is not overhead. If auditing is done for compliance reasons, or if it’s just being done to complete the security cycle, it’s necessary and a nonoptional aspect that must be incorporated into the system.

The same is true with other aspects of security. One could argue that access controls add overhead. Checks have to be performed to determine what users can see and do. All of this “overhead” is necessary to ensure the privacy and security of the data. Access controls are not blatantly discarded because there is some overhead associated with them. You accept the overhead associated with access controls, and the users accept it too. Auditing is simply the last phase in your security cycle, and it should not be discarded. You should accept auditing as the complementary security function that it is.