Introduction to Semantic Events and Attributes

[susanmarie_thomas]

Messages from the multiple log sources that feed into SAP Enterprise Threat Detection are normalized, so that you can search across logs. This blog is the first in a series that explains the normalized data model, which consists of semantic events and associated semantic attributes. 

Semantic events and attributes represent which software did what on behalf of which user, etc.  In this blog we concentrate on the software.

Most software usually reports only its own actions, and reports on other software only to the extent that it is involved in the action. In this regard log messages resemble a first-person monologue, e.g., for each blocking action it performs a web filter might say:

"I blocked an HTTP request from an HTTP client to an HTTP server."

In graphic terms, you may want a global view. Maybe you have in mind something like Picture 1.

But, the situation represented in logs has more in common with Picture 2.

Picture 1: An ideal of a global view

Picture 2: Logs mostly give you just a local view

In accordance with this observation about logs, the semantic event model, which is shown in Figure 1, is actor/action centric. A software actor performs some action.  Roles of other software involved in the action are assigned relative to the actor/action, reflecting the local view of the actor.

• Actor is the software that does the action.
• Initiator causes the actor to act. This is often the SAP terminal ID.
• Reporter reports the event. This is often the same as the actor.
• Target is a system or host that the actor asks to do something, e.g., the target of an RFC call.

Figure 1: Actor/Action Centric Semantic Event Model

Take as an example an RFC call from the SAP system ERP/000 to the SAP system ERP/102 as shown in Figure 2. Both systems send business transaction logs and security audit logs to SAP Enterprise Threat Detection.

Figure 2: SAP system ERP/000 makes an RFC call to ERP/102

The RFC client, ERP/000, performs the action call.

The RFC server, ERP/102 performs the action run.

The respective semantic events from the business transaction log are:

• Executable, RFC-enabled Function Module, Call  (the client event)
• Executable, RFC-enabled Function Module, Run  (the server event)

Note that extractors in SAP Enterprise Threat Detection process the logs and create message-type codes that are mapped to the semantic events.

Event names are chosen to create a good sorting order and have 3 main elements: Box, Object, Action

• A box  groups related events. Examples of boxes are: User Admin, System Admin, Executable, Database, etc.
• An object is the direct object of the action, e.g., RFC-enabled Function Module.
• An action is what is done by the actor, e.g., call.

Screen shot 1 shows how the software involved in the event is identified using semantic attributes.

The software type of the actor is identified by the attribute ServiceType. Other types are not explicitly identified, since they usually follow from the actor's type. The system that the software runs on is identified by SystemIdActor. For the call event, this is ERP/000, since it does the call. For the run event, it is ERP/102, since it runs the function module. Notice that the role of the software or host is the last word of the attribute name. You can think of everything in front of the role as being the attribute type, e.g., SystemId.

For the call event, the target of the call is identified by SystemIdTarget, and is ERP/102

For the run event, the initiator of the action is identified by SystemIdInitiator, and is ERP/000

Screen Shot 1: Software Roles for the call and run events (click to view)

There are actually three ways to identify the system or host playing a particular role, where <role> can be one of Actor, Initiator, Target, Reporter, or Intermediary. Intermediary is not used often, so is not explained here.

A system or host can be identified by:

• The pair SystemType<role>, SystemId<role>.  SystemType is ABAP for an SAP system. It is not shown in the screen shots.
• The pair NetworkHostname<role>, NetworkHostDomain<role>. These two together are a fully qualified domain name.
• NetworkIPAddress<role>

Screen shot 2 shows NetworkHostnameInitiator which contains the terminal ID of the terminal that initiated the RFC call.

Screen shot 2: Adds NetworkHostnameInitiator, EventLogType and Security Audit Log Event (click to view)

Screen shot 2 is a different view of the two business transaction events in screen shot 1. It also adds an event from the security audit log. The event source is distinguished by the EventLogType attribute. The security audit log only logs the server side of the call, the run event. On the other hand, it does specify that the run succeeded, whereas the business transaction log does not, since it exists primarily to record performance statistics.

An important point to note is that a message type from the security audit log is mapped to the same semantic event as a message type from the business transaction log, enabling both to be found with a search for one semantic event, thereby achieving the desired capability to search across logs.