Log Categorizations

[Aniak5]

There has been significant uncertainty about the appropriate categorization of logs, particularly regarding network file activity placement in either the 'Application' or 'Network' category. Does the network file activity event class belong in the Network or Application category? Numerous logs exhibit potential overlap between categories, and usually, the final categorization is highly dependent on the use case.

Within our OCSF network activity sync discussions we have agreed that we need to create detailed descriptions of each OCSF category with explicit direction on the correct categorization of logs. We also agreed that final categorization is primarily a function of the underlying activities present in the logs. Potential examples of detailed descriptions for the Network and Application categories:

Network Activity
The Network Activity OCSF category is primarily meant to represent logs containing information about communication and traffic between devices over a network. These logs capture data related to the transmission and routing of data packets across a network. They emphasize details like IP addresses, port numbers, transport layer protocols (e.g., TCP, UDP), packet headers, and underlying application protocol information (e.g., HTTP, DNS). Network activity logs may come from various sources such as network taps or firewalls. The data within the Network Activity category is typically more detailed and granular compared to Application Activity. In Network Activity, we deal with individual data packets, which can be assembled to reconstruct a complete event, such as a file download. On the other hand, Application Activity provides a broader perspective, offering insights into high-level events but with less focus on the individual components. In summary, Network Activity delves into the finer details of data transmission, making it closely associated with the lower layers of the OSI stack.

Application Activity
The Application Activity OCSF category records data associated with actions, events, and operations executed by software applications or services on a system. It encompasses information like user interactions, error messages, application-specific events, timestamps, user IDs, and the execution flow within an application. In contrast to the Network Activity category, which deals with lower-level network details, Application Activity focuses on higher-level aspects of system and application behavior. The events in this category are primarily situated in the upper layers of the OSI stack, providing a more application-centric view of software operations.

In the network activity sync we came up with additional ideas on how to handle logs that could belong to multiple categories.

Create a profile for some categories such as Network and Application:

• Pros: Doesn't require a ton of additional classes.
• Cons: This could get confusing when mapping.

Create profiles to update activity ids in event classes (such as a file profile to be applied to the application category)

• Pros: Doesn't require a ton of additional classes.
• Cons: This could get confusing when mapping.

Create redundant event classes for specific use cases (such as a network file activity class in the network activity category and a file activity class within the application category).

• Pros: Less confusing and easier to determine where your logs belong.
• Cons: Redundant event classes.

Allow a soft membership to two event classes providing the log access to any attribute available within either class

• Pros: Alleviates the confusion of where a class belongs.
• Cons: Not sure this is remotely possible. The requirement of redundant attributes could cause issues (maybe take the lesser requirement from both?). How to specify which activity ids to apply? This can get super confusing too.