Published in ACM SIGSAC Review, Vol. 7, No. 1, Spring 1989.

SECURITY AUDITING
-- Fear of detection versus fear of detecting ¹ --

Bill Neugent
Heidelberg, West Germany

It would be easy to discount this example, except that it is not an isolated case. Recently, some coworkers told me of a system with which they were working. The system had a problem in that the audit data for one day took two days to process. Being security consultants, they told the system manager that the problem could be solved by only operating the system every other day. (They were smiling when they told me this, but one never knows for certain how to interpret a smile, especially from a security consultant.)

How have we come to be in this dilemma, in which we seem to have a choice between too little and too much auditing? Well, given their choice, most users simply vote to forego auditing. Since most systems are under the anarchic control of users, that is why most systems today have little auditing.

While one hesitates to tamper with this blissful natural ignorance, we know that it is wrong to forego auditing. Especially where sensitive systems are involved, we as a nation are too wise to let something so important as security rules be determined by so crude a mechanism as popular vote (which is why we reserve that entertaining but haphazard process for less important matters).

So, for our most sensitive systems, we rely on security consultants to decide what we should audit. Well. Security people are worry warts anyway, but when we unleash them on sensitive systems, we should expect them to be especially thorough. Normally these expectations are not disappointed, with the product resembling the “Security Auditing” chapter of the Bureaucrat’s Guide to Absolute Organizational Perfection. Indeed, it sometimes seems as though security experts, perhaps frustrated at being unable to achieve perfection in human behavior, strive instead for perfection in procedure. And so we end up with official audit policies that tell us to do such things as record all accesses by all users to all objects, and to record the time of each audit event to the nearest hundredth of a second.

Rules are valuable, as long as you’re not dumb enough to follow them. That is, a main value of rules is that people who wish to vary from the rules should be required to justify their variance by some argument more substantive than, “Well, the whole idea is just stupid.” Unfortunately, many well-meaning people confronted with the rules do not realize that such flexibility exists. These people thus are apt to try to follow all the rules --appropriate or not--and sometimes they simply give up altogether.

In any event, it should be clear now why we have these two opposing extremes. Yet surely there must be more reasonable approaches between these poles. Surely there must be a simple, effective computer audit equivalent to the device that lights up when someone lies, some equivalent to the little sister who tattles.

In fact, there is. I refer to the new and burgeoning field of intrusion detection, which promises to become the new Disneyworld of the security consultant imagination. There are two approaches for intrusion detection. One approach is to identify actions that have a high likelihood of being intrusions (e.g., “Pardon me, but don’t I know you?”).

The neat thing is that you don’t even have to understand the sentence. You can simply send your audit data to a remote intrusion detection server, and rely on it to do the spying and tattling for you. You don’t have to become a security expert yourself. That is, you don’t have to fit the bill as long as you foot it.

But where does this all lead? Where are we going with auditing? In the 1970s there was much emphasis on the right to privacy and much concern over close government oversight of individuals, accompanied by fears about government conspiracies to share computer data and use it improperly. (We government folks weren’t offended by this paranoia; in fact, we felt rather flattered at being thought sufficiently effective to engage in conspiracy.)

Today, however, times have changed. In balancing the need to defend against evil governments and evil people, one must consider that there are more people than governments and that the destructive potential of single individuals has grown enormously (although it often lessens when they get married). No longer can system managers simply entrust security to the good will and judgment of numerous users. There just is no choice but increased automated scrutiny.

So auditing is here to stay, and is growing in importance as our society places more reliance on computers. And so it is with a clear (as opposed to zeroized) conscience that we security consultants help devise more effective ways to scrutinize computer activities. It is with respectful concern, dear reader, that we define parameters for correct and incorrect computer manners.

Yes, the time has come to remove the burden of tedium from our honest security officers and to shift the burden of fear back to the culprits, where it belongs. For we security consultants know that, as long as attention is focused on miscreant users, it is not focused on us.

FOOTNOTES

1. As the subtitle implies, sometimes it’s not clear who is more intimidated by auditing, the potential perpetrator (who thinks he might thereby be caught) or the security officer (who knows he won’t thereby catch anyone).

ACM COPYRIGHT NOTICE. Copyright © 1989 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or permissions@acm.org. This copy is posted by permission of ACM and may not be redistributed.

Updated: 20-Oct-2005