Audit refers to the use of automated mechanisms that cause the creation and storage in a secure computerized log of a computer system activity called an audit log. Accounting is a property that provides unambiguous tracking of the own actions of any logical object.
The audit mechanism is based on data supplied by the identification / authentication mechanism, since only this mechanism generates data that allows to identify the subject of the system whose activity is controlled. The audit mechanism, in turn, provides data for analyzing the security of a computer system, including identifying possible causes that caused the system to become insecure.
The audit mechanism is intended to:
- to view:
– attempts to access individual objects;
– activity of processes and users;
– use of systems protection mechanisms; - to detect attempts to circumvent protection mechanisms by authorized users and violators;
- to identify the use of privileges greater than what the user needs;
- for use as a protective measure, informing violators that all their actions are recorded;
- for use as a guarantee of reliability for authorized users, providing them with the assurance that all attempts to bypass the protection system will be recorded.
The users of the audit mechanism can be divided into two categories – auditors and the users of the audit mechanism themselves.
Auditors configure the audit mechanism by selecting events in the system that need to be recorded, and also analyze audit events. The audit mechanism must be protected from unauthorized modifications. In this case, it is necessary to control access to the configuration of the audit mechanism, allowing it to be performed only by system auditors.
The audit mechanism should record all system activities, which can be considered as potentially related to deliberate attacks. The term “safety critical” is often used to describe such activities.
Operations whose audit must be performed include:
- use by the user of identification / authentication mechanisms;
- access of subjects to objects;
- the use of computer system administration mechanisms;
- actions of the administrator or other privileged users;
- printing documents;
- other events affecting the security of the system.
Auditing non-security events can lead to large amounts of audit data and make analysis difficult. Selecting events for registration is a non-trivial task and requires an understanding of the nature of security breaches.
The audit mechanism should not have a harmful or undesirable effect on the normal functioning of the computing system, prompting system administrators to remove audit schemes in the interest of doing the job. Ideally, users of a computer system should not notice any impact of the audit subsystem on the functioning of the computer system, however, some impact of event logging on system performance is inevitable.
There are two main methods for selecting audit events: pre-selection and post-selection of events.
When using the event pre-selection method, the auditor selects the events that are being audited. Events not selected by the auditor are not recorded. The advantage of this approach is better performance compared to the post-selection method. The disadvantages include the need for a preliminary assessment of events that need to be recorded, which may affect the quality of the analysis.
When using the post-event selection method, all events are logged in the system. The auditor selects from all registered events with which the system security analysis is carried out. The advantage of this approach is the completeness of the picture of events in the system used for security analysis. The disadvantages include the loss of performance compared to the method of pre-selection of events and the large amount of audit data received.
Audit data intended to be stored in a journal should be well-defined pieces of information called audit records. This uniformity greatly facilitates the task of developing means of interpreting audit data.
Audit entries typically include:
- date and time of the event;
- user ID;
- type of event;
- result of the event.
For an event of access to an object, the name of the object to which access was made is fixed.
For identification / authentication events, the event source (for example, the terminal from which the computer was accessed) is usually taken into account.
For an event that changes the security policy of the system, an event description must be logged.
In addition, the following additional requirements for the audit subsystem can be described.
- Data compression. Due to the fact that a large amount of data is usually recorded, it is advisable to use archiving during their storage. Unarchiving audit data is done when the auditor accesses the journal.
- Several audit logs. One of the audit logs may reflect the activities of the user, while the other – the operator, and the third – the administrator. This separation of audit data flow facilitates analysis. To restore a possible sequence of events, each audit record must contain a time stamp.
- Presentation of audit data in a form convenient for the auditor. The audit engine can write data in a binary representation. However, you need a data viewer in a convenient way.
The Windows operating system has three audit logs:
- a system log that stores records of events that Microsoft has identified as critical for the functioning of events (system failure, component failure, etc.);
- application log, events in which user applications add;
- a security log containing records of security-related events (logging on to the system, access to files, etc.); access to this log is available only to system administrators.
Windows defines the following main categories of audit events:
- Privilege use – use of privileges;
- System – system events;
- Object access – access to objects;
- Process tracking – process activity;
- Logon – login;
- Account logon – login information;
- Policy change – security policy change;
- Account management – account management.
Microsoft has provided an event viewer to view events in audit logs. The system administrator can determine the response of the system to the audit log overflow: system shutdown, prohibition of the functioning of the audit subsystem or deletion of old records.
The functionality of the audit mechanism is described as follows.
Each system object is associated with a system audit list, which consists of two types: system audit ACE and system audit-object ACE. These types determine which operations performed on objects by specific users or groups are subject to audit. Audit data is stored in the system audit log. Registration can be subject to both successful and unsuccessful operations. System audit objects contain identifiers that indicate the types of objects or subobjects and an optional identifier that controls the transfer of system audit objects to child objects of specific types.
Audit events can be generated by the object manager based on the results of access control checks. They can also be generated directly by the application programming interface functions available to user applications. The kernel mode code has the same right.