It is -understood that the customer's SMF data is kept on-line for one day and then written out to tape(s) for longer-term storage. In addition to the standard exception reporting program outlined in this paper, it must be possible for the security officer to look at the detail records associated with a particular user, a particular terminal, a particular job, or a particular file, in order to produce in detail the time sequence of operations actually performed during the job or session. It is not suggested that detailed time sequences of operation be performed for every user at all times; rather, it has been found necessary in order to in greater detail what is going on, to be able to examine the individual accounting records making up a job or a session, particularly for those job sessions which exhibit parameter values outside of the statistical bounds established by the surveillance program.

In the case of the SMF records, it is possible for a user to spawn batch jobs from the VM system. It must be possible for all of the activities of a given user to be traced to the various machines which may be used in accomplishing his or her work. The experience with the model system indicates that it is important that the records making up a session or a job or a unit of work be presented contiguously rather than intermixing the records on the basis of an arbitrary time stamp associated with each record. In practice, this may mean detail entries will be tracked on the VM system to the point where a job is batched to the JES3 job distribution system, then through all the job steps of the batched job, and then back to VM to show the continuation of the activities on the VM in parallel with or while the batch job was running one or more of the batch systems.

In general, there is a requirement to be able to track jobs or sessions based on a variety of kinds of information; for example, terminal identifiers or specific devices referred to and the like. The requirement is to be able to either show all records with the same terminal identifier or the same device address, or sometimes to use the terminal identifier device address or other characteristics to identify the job and then to show all details for that particular job.

For instance, if there is reason to suspect that there is unwarranted file access activity against a particular file, one may wish to examine all details of activity against that file regardless of the individual programs making the references, in which case the fileid would act as a pointer, into the first SMF record that contained its identifier. From that,record, the job identifier would be obtained and then the detail for- the entire job could be displayed or acquired.

Summary

The computer base security audit and surveillance system can be an effective tool in security control and management of ADP resources. User, data set, and program profiles can provide security personnel with information regarding exceptional use of the system. While it is expected that nearly all such exceptional use will be benign, this approach makes it possible to detect possible misuse of the system. It gives security personnel important automated tools to help provide early detection of unauthorized, ^malicious activity directed against ADP assets.

In the preceding sections, an outline of a system design and the basis for providing statistical detection of abnormal use was developed. The surveillance and detection system is a filter screening out the mass of users of any system who are not doing anything untoward* In general, what constitutes "abnormality" is parametric. It can be set for any given environment. While the bulk of the report focused on the identification of abnormal use by individual users, statistics similar to those described for individual users can be accumulated for the user population as a whole, and the entire population screened for the purpose of identifying potential detailed

With the use of statistical parameters such as those described above, the system can report abnormalities; that is, usage outside of the range of those parameters. This does not mean that a particular episode involves anything wrong; it merely means that something is statistically different from previous accumulated use of the system for that entity; that is, user, file, program, and so forth. If abnormal symptoms do not recur, it is likely that nothing much is happening; however, if the symptoms continue to show up, then the subject involved could be investigated further by more conventional means.

In any real-life situation, computer systems often have thousands of users and tens of thousands of programs in data files. It is necessary to reduce the volume of history data implied by these numbers in various ways. First, if there are individuals whose use of the system is subject to surveillance because of the sensitivity of their jobs or for any other reason, he or she becomes a subject of interest. The selection of job (that is, session, tasks, runs, etc.) records can and should be made on that user's identity to include such individuals. The system designs sketched in the preceding sections indicate the use of such selection functions.

Note that most of the tests applied to systems use are equally applicable to specific files, and, as the section indicated, one could use a pre-pass to collect user's identification for those users referring to a specific named object: file, device, system, and the like.

Rather than attempt to treat all members of a large population with this system, at all times, a sampling technique can be applied to select subsets of the total population for examination either over a particular period of time such as two weeks or for a gross examination against gross parameters established for the population as a whole. Of the two approaches, the detail examination for several weeks appears a priori to be the preferred method.