Send findings for risk analysis using the Finding Report schema
The output from the behavioral analytics service is structured in the format of a Finding Report schema. The structured output of the Finding Report schema prepares to send the findings from the behavioral analytics service into the risk based alerting framework of Splunk Enterprise Security for further analysis.
The Findings report event class reports the results of behavioral analytics or detections.
Finding category
Name | Attribute | Group | Requirement | Type | Description |
---|---|---|---|---|---|
Category ID | category_id
|
Classification | Required | Integer | The category identifier of the event.
|
Class ID | class_id
|
Classification | Required | Integer | The class identifier describes the attributes available in an event. See specific usage.
|
Detection start time | detection_end_time
|
Primary | Recommended | Timestamp | The end time of a detection time period. |
Detection start time | detection_start_time
|
Primary | Recommended | Timestamp | The start time of a detection time period. |
Disposition ID | disposition_id
|
Classification | Required | Integer | The disposition ID of the event. Following are possible values for disposition IDs:
|
End time | end_time
|
Occurrence | Recommended | Timestamp | The time of the most recent event included in the Findings report. |
Event ID | event_id
|
Classification | Reserved | Integer | The event ID identifies the event's semantics and structure. The value is calculated by the logging system as: class_id * 1000 + disposition_id. Following are possible values for event IDs:
|
Event time | event_time
|
Occurrence | Recommended | String | The event occurrence time, representing the time when the event was created by the event producer.
The format is |
Finding (Splunk) | finding
|
Primary | Required | Finding | The finding reported by detection or analytics. |
Message | message
|
Primary | Recommended | String | The description of the Finding report. |
Metadata | metadata
|
context | Required | Metadata | The metadata associated with the event. |
Observables | observables
|
Primary | Recommended | Observable array | The observables associated with the findings. |
Origin | origin
|
Origination | Required | Event origin | The origin of where the event was created. |
Raw data | raw_data
|
Context | Reserved | String | The event data as received from the event source. |
Rule | rule
|
Primary | Required | Rule | The rules that reported the events. |
Start time | start_time
|
Occurrence | Recommended | Timestamp | The time of the least recent event included in the Finding report. |
Time | time
|
Occurrence | Required | Timestamp | The time when the finding was created. |
Metadata object
The metadata associated with the event.
Name | Attribute | Requirement | Type | Description |
---|---|---|---|---|
Log Name | log_name
|
Reserved | String | The name of the database, index, or archive where the event was logged by the logging system. |
Logged Time | log_time
|
Reserved | Timestamp | The time when the logging system collected and logged the event. This attribute is distinct from the event time because the event time typically contains the time extracted from the original event. Usually, the timestamp and the event time are different |
Unique ID | uid
|
Reserved | String | The unique identifier of an event system assigned by the logging system. |
Version | version
|
Required | String | The version of the event class, using Semantic Versioning Specification (SemVer). For example: 1.0.0. Event consumers user the version to determine the available event attributes. |
Rule object
The rule object associated with a policy or event
Name | Attribute | Requirement | Type | Description |
---|---|---|---|---|
Name | name
|
Required | String | The name of the rule that generated the event. |
Unique ID | uid
|
Recommended | String | The unique identifier of the rule that generated the event. |
Event origin object
The event origin is where the event was created.
Name | Attribute | Requirement | Type | Description |
---|---|---|---|---|
Device | device
|
Recommended | Device | The device that reported the event. |
Product | product
|
Recommended | Product | The product that reported the event |
Finding object
The finding object describes the results of detections or analytics.
Name | Attribute | Requirement | Type | Description |
---|---|---|---|---|
Confidence identifier (Splunk) | confidence_id
|
Recommended | Integer | The normalized confidence level refers to the accuracy of the rule that created the finding. A rule with a low confidence level means that the detection scope is wide and may create finding reports that may not be malicious in nature.
For more information on possible values for the |
Context identifier | context_id
|
Required | Integer array | The list of the context identifiers of the finding. For more information on possible values for the context_id attribute, see Values for context identifier
|
Impact identifier | impact_id
|
Recommended | Integer | The normalized impact of the finding. For more information on possible values for the impact_id attribute, see Values for impact identifier.
|
Reference event identifier | ref_event_uid
|
Required | String | The identifier of the event associated with the finding. |
Risk level | risk_level
|
Recommended | String | The normalized risk level. For more information on possible values for the risk_level attribute, see Values for risk level.
|
Risk Level ID | risk_level_id
|
Required | Integer | The normalized risk level ID. |
Type ID | type_id
|
Required | Integer | For more information on possible values for the type_id attribute, see Values for type of finding.
|
Values for confidence identifier
Use the following table for information on the possible values for the confidence_id
attribute:
Value | Confidence status | Description |
---|---|---|
-1
|
Other | The confidence is not mapped to the defined enum values. See the confidence attribute, which contains a data source specific value.
|
0
|
Unknown | No confidence is assigned |
1
|
Low | |
2
|
Medium | |
3
|
High |
Values for context identifiers
Use the following table for information on the possible values for the context_id
attribute:
Value | Context status | Description |
---|---|---|
-1
|
Other | The category label identifier is not in the predefined list. See the labels attribute, which may contain additional category labels.
|
0
|
Unknown | The context identifier is unknown. |
10
|
Source: Endpoint | Antivirus, firewall, or some other protection software running on a device. |
11
|
Source: AD | Microsoft Active Directory |
12
|
Source: Firewall | Network-based firewall or system that provides information about network connections beyond host names or IP addresses. For example: Netflow, DNS, and web proxy logs. |
13
|
Source: Application log | Single application data log. For example: Apache, JIRA, or Firefox logs. This label can be applied along with another source category label. The application log category does not include general operating system logs. |
14
|
Source: IPS | Network based
IDS/IPS. This is also a generic category label for products of external security logic. If the detection is based on the IP addresses, bytes, or security zone from PAN logs, only Firewall applies. If PAN categorized the event as malware detection and you rely on that determination, the IPS label also applies. Exception to this is Endpoint. |
15
|
Source: Cloud data | Cloud data logs. For example: Amazon, Box, Oce365, and so on. |
16
|
Source: Correlation | Multiple data source types or the underlying source is unknown. |
17
|
Source: Printer | Printer logs |
18
|
Source: Badge | Physical access control logs |
20
|
Scope: Internal | The finding has a network component and the direction of the initiated connection or traffic is internal. Both endpoints are considered internal and on-premises. |
21
|
Scope: External | The finding has a network connection and the direction of the initiated connection or traffic is external. Both endpoints are considered external. For example: Cloud data with an external source. |
22
|
Scope: Inbound | The finding has a network connection and the direction of the initiated connection or traffic is inbound. One of the endpoints is internal and the
other one is external. |
23
|
Scope: Outbound | The finding has a network connection and the direction of the initiated connection or traffic is outbound. One of the endpoints is internal and the other one is external. |
24
|
Scope: Local | The finding has no network component. For example: A local privilege escalation or a badge-based detection. |
25
|
Scope: Network | The finding has a network component but the direction of the initiated connection or traffic is unknown. |
30
|
Outcome: Blocked | Unsuccessful or blocked security malware. |
31
|
Outcome: Allowed | Malware is not blocked. Unless this category is explicitly set, it is assumed to be Allowed since this is the default value. |
40
|
Stage: Recon | The reconnaissance stage, such as scanning, DNS enumeration, or other observable attempts to gain information about the customer's network. |
41
|
Stage: Initial access | The initial access tactic represents the vector's adversaries, which are used to gain an initial foothold within a network. |
42
|
Stage: Execution | The execution tactic represents techniques that result in the execution of adversary-controlled code on a local or remote system. This tactic is often used in conjunction with initial access, as the means of executing code once access is obtained and lateral movement to expand access to remote systems on a network. |
43
|
Stage: Persistence | Persistence is any access, action, or configuration change to a system that gives an adversary a persistent presence on that system.
Adversaries need to maintain access to systems through interruptions such as system restarts, loss of credentials, or other failures that require a remote access tool to restart or an alternate back door for them to regain access. |
44
|
Stage: Privilege escalation | Privilege escalation is the result of actions that allows an adversary to obtain a higher level of permissions on a system or network. Certain tools or actions require a higher level of privilege to work and are likely necessary at many points during an operation. Adversaries can
enter a system with unprivileged access and must take advantage of a system weakness to obtain local administrator or |
45
|
Stage: Defense evasion | Defense evasion consists of techniques an adversary may use to evade detection or avoid other defenses. Sometimes these actions are the same as or variations of techniques in other categories that have the added benefit of subverting a particular defense or mitigation. Defense
evasion may be considered a set of attributes that the adversary applies to all other phases of the operation. |
46
|
Stage: Credential access | Credential access represents techniques resulting in access to or control over system, domain, or service credentials that are used within an
enterprise environment. Adversaries will likely attempt to obtain legitimate credentials from users or administrator accounts (local system administrator or domain users with administrator access) to use within the network. This allows the adversary to assume the identity of the account, with all the account's permissions on the system and the network. This makes it harder for defenders to detect the adversary. With sufficient access within a network, an adversary can create accounts for later use within the environment. |
47
|
Stage: Discovery | Discovery consists of techniques that allow the adversary to gain knowledge about the system and internal network. When adversaries gain
access to a new system, they must orient themselves to the areas over which they have control and the benefits of operating from that system. This helps to identify their current objective or overall goals during the intrusion. The operating system provides many native tools that aid in this post-compromise information-gathering phase. |
48
|
Stage: Lateral movement | Lateral movement consists of techniques that enable an adversary to access and control remote systems on a network and could, but does not
necessarily, include execution of tools on remote systems. The lateral movement techniques could allow an adversary to gather information from a system without needing additional tools, such as a remote access tool. |
49
|
Stage: Collection | Collection consists of techniques used to identify and gather information, such as sensitive files from a target network prior to exfiltration. This
category also covers locations on a system or network where the adversary may look for information to exfiltrate. |
50
|
Stage: Exfiltration | Exfiltration refers to techniques and attributes that result or aid in the adversary removing files and information from a target network. This
category also covers locations on a system or network where the adversary may look for information to exfiltrate. |
51
|
Stage: Command and control | The command and control tactic represents how adversaries communicate with systems under their control within a target network. There are many ways an adversary can establish command and control with various levels of covertness, depending on system configuration and network topology. Due to the wide degree of variation available to the adversary at the network level, only the most common factors are used to describe the differences in command and control. There are still a great many specific techniques within the documentation methods, largely due to how easy it is to define new protocols and use existing, legitimate protocols and network services for communication. |
60
|
Consequence: Infection | Installation of malware on one of the included devices |
61
|
Consequence: Reduced visibility | Reduction in log output or other data used for detection. Implies a deliberate attempt to hide an attacker's actions. |
62
|
Consequence: Data destruction | Destruction of data either through deletion or encryption. This is distinctly different from Reduced visibility because the goal is to destroy the data but not to hide the activity.
|
63
|
Consequence: Denial of service | Asset no longer performs it's normal functions. |
64
|
Consequence: Loss of control | Asset is no longer under a customer's control. |
70
|
Rares: Rare user | There was a rare user involved in this finding. This will typically be applied to a finding based on other entities, such as device, printer, service, and so on. |
71
|
Rares: Rare process | There was a rare process or application involved in this. This can apply to app detection such as PAN or Blue Coat, process names, or Perimeter Intrusion Detection (PID) systems. It can also be used with hashes or any other method of uniquely identifying executable code. |
72
|
Rares: Rare device | There was a rare physical device or virtual machine involved in this finding. This can be set if you are working with endpoint data, relying on identity resolution, or have a way to identify individual machines or instances. If you are relying on IP or network or domains for determination, the more specific RareNetwork or RareDomain should be used.
|
73
|
Rares: Rare domain | There was a rare domain involved in this finding. This can be an Active Directory domain, a DNS domain, a Kerberos realm, or a tenant identifier. Use domain for logical groupings of devices. |
74
|
Rares: Rare location | There was a rare network involved in this finding. This can be a be a geo-location based on IP or endpoint or a physical location based on badge data. |
80
|
Other: Peer group | The finding also considered the behavior of the user's peers. |
81
|
Other: Brute force | Attempt to gain access to a system by making a high volume of login attempts. |
82
|
Other: Policy violation | Violation of a company policy. |
83
|
Other: Threat intelligence | The finding is based on an external intelligence source that has an indicator of compromise, threatening location, or security malware. |
84
|
Other: Flight risk | This finding indicates that the user may plan on leaving the organization. |
85
|
Other: Removable storage | USB drive or other physical storage capable of easy removal. |
Values for impact identifiers
Use the following table for information on the possible values for the impact_id
attribute:
Value | Impact status | Description |
---|---|---|
-1
|
Other | The finding impact is not mapped. See the impact attribute, which contains a data source specific value.
|
0
|
Unknown | |
1
|
Low | |
2
|
Medium | |
3
|
High | |
4
|
Critical | |
5
|
Fatal |
Values for risk level identifiers
Use the following table for information on the possible values for the risk_level
attribute:
Value | Risk level status |
---|---|
0
|
Info |
1
|
Low |
2
|
Medium |
3
|
High |
4
|
Critical |
Values for type of finding
Use the following table for information on the possible values for the type_id
attribute:
Value | Type status | Description |
---|---|---|
-1
|
Other | The type is not mapped. See the type attribute, which may contain a data source specific value.
|
0
|
Unknown | |
1
|
Rule | |
2
|
Behavior | |
3
|
Information |
Product object
The product object describes a software product. Use the following table for information on the product attributes:
Name | Attribute | Requirement | Type | Description |
---|---|---|---|---|
Language | lang
|
Recommended | String | The two letter lower case language codes, as defined by ISO 639-1. For example: en (English); de (German); or fr (French)
|
Product ID | uid
|
Recommended | String | The unique identifier of the product. |
Product Name | name
|
Required | String | The name of the product |
Product Version | version
|
Recommended | String | The version of the product, as defined by the event source. For
example: |
Observable object
The observable object describes a software product. Use the following table for information on the observable attributes:
Name | Attribute | Requirement | Type | Description |
---|---|---|---|---|
Name | name | Required | String | The name of the observable attribute. For example: file.name .
|
Role IDs | role_ids
|
Required | Integer Array | The role identifiers that classify the observable. For more information on possible values for the role_ids attribute, see Values for role identifiers.
|
Type ID | type_id
|
Required | Integer | The observable value type identifier. For more information on possible values for the role_ids attribute, see Values for type identifier.
|
Value | value
|
Required | String | The value associated with the observable attribute. The meaning of the data depends on the observable type. |
Values for observable role identifiers
Use the following table for possible values of the role_ids
attribute for the observable:
Value | Role status | Description |
---|---|---|
-1
|
Other | The observable role is not mapped. |
0
|
Unknown | Unknown role |
1
|
Actor | |
2
|
Target | |
3
|
Attacker | |
4
|
Victim | |
5
|
Parent process | |
6
|
Child process | |
7
|
Known bad | |
8
|
Data loss | |
9
|
Observer |
Values for observable type identifiers
Use the following table for possible values of the type_id
attribute for the observable:
Value | Type status | Description |
---|---|---|
-1
|
Other | The observable data type is not mapped. See the type attribute, which may contain data source specific value.
|
0
|
Unknown | Unknown observable data type |
1
|
Device | |
2
|
Container | |
3
|
Endpoint | |
4
|
Host name | |
5
|
IP address | |
6
|
User | |
7
|
User name | |
8
|
||
9
|
Email address | |
10
|
URL | |
11
|
URL domain | |
12
|
File | |
13
|
File name | |
14
|
File hash | |
15
|
Process | |
16
|
Process name | |
17
|
Location |
Device object
The device object describes a software product. Use the following table for information on the product attributes:
Name | Attribute | Requirement | Type | Description |
---|---|---|---|---|
Hostname | hostname
|
recommended | Hostname | The device hostname. |
IP Address | ip
|
recommended | IP Address | The device IP address, in either IPv4 or IPv6 format. |
Instance ID | instance_uid
|
recommended | String | The unique identifier of a VM instance. |
Name | name
|
recommended | String | The alternate device name, ordinarily as assigned by an administrator. The Name could be any other string that helps to identify the device, such as a phone number; for example 310-555-1234. |
Network Interface ID | interface_uid
|
recommended | String | The unique identifier of the network interface. |
Type ID | type_id
|
required | Integer | The device type ID. For more information on possible values for the type_id attribute, see Values for device type identifiers.
|
Unique ID | uid
|
recommended | String | The unique identifier of the device. |
Values for device type identifiers
Use the following table for possible values of the type_id
attribute for the device:
Value | Type status | Description |
---|---|---|
-1
|
Other | The type is not mapped. See the type attribute, which may contain a data source specific value.
|
0
|
Unknown | The type is unknown. |
1
|
Server | |
2
|
Desktop | |
3
|
Laptop | |
4
|
Tablet | |
5
|
Mobile | |
6
|
Virtual | |
7
|
IoT | |
8
|
Browser |
Supported detections in behavioral analytics service | Data flow overview for behavioral analytics service |
This documentation applies to the following versions of Splunk® Enterprise Security: 7.0.0, 7.0.1, 7.0.2
Feedback submitted, thanks!