Overview #These fields in the schema are the XDAS Fields defined specifically for audit events.
The XDAS JSON Schema shows the structure of the fields.
Some or all of these fields may also be relevant to other types of event, but information of this sort is required for auditing services.
The XDASv2 JSON record format is open. By that, we mean that any additional fields may be added to the record at any place, as long as they don't conflict with the field values defined for audit by the XDASv2 standard.
Thus, if there is a particular type of correlation data, such as a workflow identifier, or a session identifier that can be used as correlation data points between events within a particular workflow or client session, you may add these fields. Simply choose a non-conflicting name for your field.
|Source (Optional)||The source of an event identifies the event service of another system from which this event was originally defined and converted to an XDAS event. Since many events are generated directly by XDAS clients, the source field is optional.|
|Initiator||The initiator of an event is the authenticated entity that initially provoked creation of the event. Note that an initiator need not be identified. If the entity can't be identified - perhaps an entity is attempting to login, thus provoking the generation of a login event by an observer - then as much information about the origin of the event as possible should be specified. NOTE: In the special case of a login event, the authenticated identity of the initiator is not yet known until after the login attempt has succeeded. Therefore a failed login event should not give the identity of the target account as the identity of the initiator.|
An initiator is described in terms of an account and an entity (described below), as well as an optional set of assertions. These assertions describe, in terms of a set of name/value pairs, the attributes of the initiator identity. Some initiators are not known by a specific account, but are known only by a set of assertions (SAML2, for instance) that describe the rights of the actor. The schema is not defined for these assertions, as they will be different for each class and potentially for each individual object.
|Action||The action identifies the event that is being recorded. This field provides the XDASv2 event identifier, as well as an outcome code (success, or failure class), and the time the event occurred, with as much accuracy as possible.|
|Event||The event field is the key to XDAS events. Event encapsulates a taxonomical identifier and a short descriptive name for human readability.|
|Id||The event Id code represents the event identifier, defined by the XDASv2 standard event Taxonomy, and extensions defined by the Novell CSS product.|
|Name||The event name is a human readable representation of the event identifier. The event name is optional, but recommended for readability.|
|Data||The event data provides additional descriptive information about the event.|
|Log||The log field contains standard syslog-like log-level values, in terms of Severity and Facility numeric identifiers. The log field is optional, as well as every sub-field within the log field. These values should only be used when necessary, as they generally represent judgment calls on the part of the instrumentor. Such judgment calls are best left to analysis software or engineers once the event data is collected.|
|Outcome||For details on outcome codes, see Section A.3, Outcome Codes.|
|Time||The event time is the time recorded by the observer at the point the event was committed to the event service. Time values are gathered by the XDAS client helper library. Thus, there is no reason to be concerned about values stored in this field, as the helper library will attempt to be as accurate as possible when generating time information.|
|Offset||The offset field contains a value representing the number of seconds since midnight, January 1, 1970 - otherwise known as the Linux epoch.|
|Sequence||The sequence field contains a unique numeric value identifying this event from another event which may have been recorded within the same second. For the most part, this value should be taken as a monotonically increasing numeric value that begins at zero and continues until the next second boundary, at which point, it begins again at zero.|
|Tolerance||The tolerance value is a value between 0 and 100, indicating the tolerance of the clock used to record the time in offset. Values of zero indicate the clock is very accurate. Values of 100 indicate that the clock should not be trusted.|
|Certainty||The certainty value is a value between 0 and 100, indicating the percentage certainty of the tolerance value. Zero means there is no certainty of the tolerance, and thus, it shouldn't be trusted to any degree of accuracy. A value of 100 indicates that the tolerance value is very accurate.|
|Source||The time source is information indicating the source of time for the observer system. This may be a URL for a time server, or simply a local time source, such as a hardware clock.|
|Zone||The time zone is the new time zone string representing the time zone of this clock.|
|Target (Optional)||The target of an event is the account or protected resource upon which the initiator is attempting to act, thereby provoking the generation of an event. A target is described in terms of an account and an entity (described below), as well as an optional and unspecified Data object. The Data object is a set of name/value pairs describing class-specific attributes of the actor. The schema does not define the actual fields, as different classes will have a unique set of data attributes (if any).|
|Observer||The observer of an event is the authenticated identity of an entity (service) that is monitoring the system, and generating events based on initiator actions. An observer is described in terms of an account and an entity (described below).|
|Referenced Classes||The observer, initiator, and target fields contain references to the account and entity classes defined separately within the schema. These other classes identify key attributes of the three primary actors within an audit event.|
|Account Class||The account class represents the identity of the actor. This identity is relative to an authentication realm or Domain. Both an account name and an account Id are provides, although only the Id is really required. The Name is for human readability.|
|Account Domain||The account Domain defines the authentication authority of the actor. Account identifiers mean very little without an authentication authority.|
|Account Name||The account Name is optional, providing human readability.|
|Account Id||The account Id is a unique identifier of the account within the authentication Domain.|
|Entity Class||The entity class describes the location of the actor. This location is defined in terms of a system access end point (IP network) address and a system access end point (host/domain) name. Additional fields are also available to describe the service and component names within the software that manages the above end points.|
|Entity SysAddr||An IP address describing the access end point of the software actor. The IP address is displayed as IP Address:Port. For example:|
Note that internal event IP address is displayed as 0.0.0.0:0.
|Entity SysName||A host/domain name describing the access end point of the software actor.|
|Entity SvcName||A service name further describing the service that manages the above end point.|
|Entity SvcComp||A service component name describing the component within the above service.|
More Information #There might be more information for this subject on one of the following:
XDAS Field Definitions NetIQ