Audit Events are generated internally. Each time an audited method is called or an audited data object is modified, audit framework generates audit events. There are two types of Audit Events. One which monitors user actions for example, user login/out, add/delete user and another which monitors system actions/health, for example, process start/stop.
Some of these events used to be called Internal Events (mainly for system actions/health monitoring). So the functionality of Audit Events is similar to Internal Events. Audit Events can be logged into log files, saved into database, and sent out as Audit Event at the same time. (Internal Events are only sent out as events.).
All System Events populate the following attributes:
ST (Sensor Type) field: For internal events it is set to "I" and for performance events it is set to "P"
Event ID: A unique UUID for the event
Event Time: The time the event was generated
Source: The UUID of the process that generated the event
Sensor Name: The name of the process that generated the event (for example, DAS_Binary)
RV32 (Device Category): Set to "ESEC"
Collector: "Performance" for performance events and "Internal" for internal events
In addition to the common attributes, every system event also sets the resource, subresource, the severity, the event name and the message tags. For internal events, the event name specific enough to identify the exact meaning of the event (for example, UserAuthenticationFailed). The message tags add some specific detail; in the above example the message tag will contain the name of the user, the OS name if available and the machine name). For performance events the event name is generic describing the type of statistical data and the data itself is in the message tag.
Performance events are sent directly to the database. To view them, do a quick query.
For more information, see "System Events for Sentinel".