Data requirements for OCSF conversion

Edge Processors on Splunk Cloud Platform support OCSF conversions for specific source types and event types.

Edge Processors can convert specific types of data into OCSF format. The data must be associated with a supported source type and event type, and the schema of the data must meet certain event formatting requirements.

The following sections describe the requirements that the data must meet to be supported for OCSF conversion, organized by source type:

Note: The Edge Processor solution is updated periodically to add support for more source types and event types. Refer to this page for the latest support information.

For more information about converting data into OCSF format, see Convert data to OCSF format using an Edge Processor.

box:events

Description

The box:events source type corresponds to Box enterprise audit events.

OCSF conversion is supported for box:events events that are formatted as flat, single-level sequences of name-value pairs. The Splunk Add-on for Box emits events in this supported format.

Supported event types

The event_type field in the event data must contain one of the following values:

  • ADD_LOGIN_ACTIVITY_DEVICE

  • ADMIN_LOGIN

  • COLLABORATION_ACCEPT

  • COLLABORATION_EXPIRATION

  • COLLABORATION_INVITE

  • COLLABORATION_REMOVE

  • COLLABORATION_ROLE_CHANGE

  • DELETE

  • DOWNLOAD

  • EDIT

  • FAILED_LOGIN

  • ITEM_MODIFY

  • ITEM_OPEN

  • ITEM_SHARED_UPDATE

  • ITEM_SYNC

  • ITEM_UNSYNC

  • LOGIN

  • MOVE

  • PREVIEW

  • RENAME

  • SHARE

  • SHARE_EXPIRATION

  • UPLOAD

Expected data format

The event data must follow these formatting conventions:

  • The event data is formatted as a sequence of name-value pairs.

  • Each name-value pair consists of a field name, an equals sign ( = ), and a field value.

  • Name-value pairs can be separated by commas ( , ) or whitespace characters.

  • Enclosing field values in double quotation marks ( " ) is optional.

    • Unquoted values end at the next comma or whitespace character.

    • Quoted values can contain commas and whitespace characters.

    • Inside quoted values, double quotation marks must be escaped as \" and backslashes must be escaped as \\.

  • An empty field value must be represented by an empty pair of double quotation marks ( "" ).

Trailing commas at the end of the event are accepted. Whitespace characters around field names, equals signs, values, and commas are ignored.

For example, these formatting variations are valid:
CODE 
name1="value1", name2="value2",
name1 = "value1" , name2 = "value2"
name1=value1 name2=value2
name1="I said, \"Hi\"" name2="C:\\Program Files\\Splunk"

Expand this section for an example of a box:events event that is supported for OCSF conversion.

CODE 
source_type="user",source_id="12345678907",source_name="DummyUser07",source_login="dummy.user07@qaz.com",created_by_type="user",created_by_id="12345678907",created_by_name="DummyUser07",created_by_login="dummy.user07@qaz.com",action_by_type="user",action_by_id="12345678901",action_by_name="DummyUser01",action_by_login="dummy.user01@xyz.com",created_at="2021-09-09T03:17:32-07:00",event_id="95b20215-02bd-448b-9457-bc57fb7caadc",event_type="ADMIN_LOGIN",ip_address="11.44.33.22",type="event",session_id="",additional_details="",account_id=12345678901

cisco:asa

Description

The cisco:asa source type corresponds to Cisco Adaptive Security Appliance (ASA) events.

OCSF conversion is supported for cisco:asa events that are formatted as syslog messages. Cisco ASA devices and the Splunk Add-on for Cisco ASA emit events in this supported format.

Supported event types

The message ID must be one of the following:

  • 113019

  • 113039

  • 602303

  • 602304

  • 611101

  • 611103

  • 716001

  • 716002

  • 716006

  • 716038

  • 722022

  • 722023

  • 722029

  • 722031

  • 722033

  • 722034

  • 722051

  • 723001

  • 723002

Expected data format

The event data must follow this format, where the <syslog_header> is optional:
CODE 
<syslog_header> %ASA-<level>-<message_id>: <message>

Whitespace characters around the colon ( : ) are accepted.

The following table describes the accepted format for each placeholder:

Placeholder

Accepted format

<syslog_prefix>

An optional syslog message header in this format:

CODE 
<PRI><timestamp> <host_name>:

Whitespace characters around the colon ( : ) are accepted.

The following are the accepted formats for each placeholder in the header:

  • <PRI> is a 3-digit number enclosed in angle brackets ( < > ).

  • <timestamp> is a date and time in one of these formats:

    • RFC 3164 with a two-digit or four-digit representation of the year. For example: Jan 01 2024 10:45:26.

    • RFC 3339 as used by the RFC 5424 syslog protocol. For example: 2024-01-01T10:45:26Z.

  • <host_name> is an IP address or host name. This value can contain 1 to 255 printable US-ASCII characters, excluding spaces.

<level>

A single-digit number between 0 and 7, inclusive.

<message_id>

A six-digit number between 100000 and 999999. Must be one of the numbers listed in the "Supported event types" section.

<message>

A text string containing the Cisco ASA message.

Expand this section for an example of a cisco:asa event that includes the syslog message header and is supported for OCSF conversion.

CODE 
<164>Jan 06 2024 10:10:09 10.148.184.17 : %ASA-4-113019: Group = puddee, Username = nankin, IP = 82.137.233.222, Session disconnected. Session Type: TCP, Duration: 0h:30m:05s, Bytes xmt: 30951, Bytes rcv: 5237, Reason: User Requested

Expand this section for an example of a cisco:asa event that does not have the syslog message header and is supported for OCSF conversion.

CODE 
%ASA-4-113019: Group = AnyConnect-TG, Username = admin, IP = 192.168.0.5, Session disconnected. Session Type: SSL, Duration: 0h:30m:05s, Bytes xmt: 18010, Bytes rcv: 5237, Reason: Idle Timeout

infoblox:dhcp

Description

The infoblox:dhcp source type corresponds to Infoblox Dynamic Host Configuration Protocol (DHCP) events.

OCSF conversion is supported for infoblox:dhcp events that are formatted as syslog messages. Infoblox Network Identity Operating System (NIOS) and the Splunk Add-on for Infoblox emit events in this supported format.

Supported event types

The event type must be one of the following:

  • DHCPACK

  • DHCPEXPIRE

  • DHCPRELEASE

Expected data format

The event data must follow this format, where the <syslog_header> is optional:
CODE 
<syslog_header>: <message>

The following table describes the accepted format for each placeholder:

Placeholder

Accepted format

<syslog_prefix>
An optional syslog message header in this format, where <PRI>, <process_name>, and <pid> are optional:
CODE 
<PRI><timestamp> <server> <process_name><pid>:
The following are the accepted formats for each placeholder in the header:

  • <PRI> is an optional 3-digit number enclosed in angle brackets ( < > ).

  • <timestamp> is is a date and time in one of these formats:

    • RFC 3164 with a two-digit or four-digit representation of the year. For example: Jan 01 2024 10:45:26.

    • RFC 3339 as used by the RFC 5424 syslog protocol. For example: 2024-01-01T10:45:26Z.

  • <server> is an IP address or host name. This value can contain 1 to 255 printable US-ASCII characters, excluding whitespace characters and square brackets ( [ ] ).

  • <process_name> is an optional process name, typically dhcpd. This value can contain 1 to 48 printable US-ASCII characters, excluding whitespace characters and square brackets ( [ ] ).

  • <pid> is an optional process ID. This value itself can contain 1 to 128 printable US-ASCII characters, and must be enclosed in square brackets ( [ ] ).

<message>

The DHCP message body. This message does not need to follow a specific format or syntax.

Expand this section for an example of a infoblox:dhcp event that is supported for OCSF conversion.

CODE 
<30>May 19 2022 11:30:20 10.160.20.42 dhcpd[10006]: DHCPACK on 10.127.16.36 to 00:e0:4c:08:00:7e (PF345215) via eth2 relay 10.127.16.1 lease-duration 43200 (RENEW) uid 01:00:e0:4c:08:00:7e

o365:management:activity

Description

The o365:management:activity source type corresponds to audit events that are visible through the Office 365 Management Activity API.

OCSF conversion is supported for o365:management:activity events that are formatted as JSON objects. The Office 365 Management Activity API and the Splunk Add-on for Microsoft Office 365 emit events in this supported format.

Supported event types

The event data must have a top-level field named Operation containing one of the following values:

  • FileCopied

  • FileDeleted

  • FileDownloaded

  • FileModified

  • FileMoved

  • FileRenamed

  • FileRestored

  • FileUploaded

  • SharingRevoked

  • SharingSet

  • UserLoggedIn

  • UserLoginFailed

Expected data format

The event data must follow these formatting conventions:

  • The complete event must be a valid JSON object at the top level. It cannot be wrapped in a syslog message header or any other text.

  • Whitespace characters used to format or indent the event are ignored.

Expand this section for an example of a o365:management:activity event that is supported for OCSF conversion.

JSON 
{
  "ClientIP": "1.1.1.1",
  "CorrelationId": "abcdef1234-1111-2222-3333-abcabc1212",
  "CreationTime": "2021-08-06T05:39:24",
  "DestinationFileExtension": "json",
  "DestinationFileName": "a1.json",
  "DestinationRelativeUrl": "Shared Documents",
  "EventSource": "SharePoint",
  "HighPriorityMediaProcessing": false,
  "Id": "a1a1a1a1-a1a1-a1a1-a1a1-aaaa1111",
  "ItemType": "File",
  "ListId": "a1a1a1a1-a1a1-a1a1-a1a1-aaaa1111",
  "ListItemUniqueId": "3efa0a3a-fcdf-4ff9-9174-6cb08e9e1f72",
  "ObjectId": "https://example.com/believe/basin.aspx?back=boatbird=agreement",
  "Operation": "FileCopied",
  "OrganizationId": "abcdef1234-a1a1-a1a1-a1a1-a1a1a1a1",
  "RecordType": 6,
  "Site": "abc123ab12-a1b2-a1b2-a1b2-abab1212",
  "SiteUrl": "http://www.example.org/bird",
  "SourceFileExtension": "json",
  "SourceFileName": "a.json",
  "SourceRelativeUrl": "Shared Documents",
  "UserAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36",
  "UserId": "abc@myxample.dummy.com",
  "UserKey": "i:0h.f|membership|abcdef@live.com",
  "UserType": 0,
  "Version": 1,
  "WebId": "a1b2c3d4-aaaa-1111-3333-abcd1234",
  "Workload": "SharePoint"
}

o365:reporting:messagetrace

Description

The o365:reporting:messagetrace source type corresponds to Message Trace events collected through the Exchange Online Reporting Web Service (RWS) API.

OCSF conversion is supported for o365:reporting:messagetrace events that are formatted as JSON objects. The Exchange Online RWS API and the Splunk Add-on for Microsoft Office 365 emit events in this supported format.

Supported event types

All Message Trace events are supported. Message Trace events are not categorized into sub-types.

Expected data format

The event data must follow these formatting conventions:

  • The complete event must be a valid JSON object at the top level. It cannot be wrapped in a syslog message header or any other text.

  • Whitespace characters used to format or indent the event are ignored.

Expand this section for an example of a o365:reporting:messagetrace event that is supported for OCSF conversion.

JSON 
{
  "Organization": "exampledomain.onmicrosoft.com",
  "MessageId": "198658196.2eb547a3-e65f-465d-9636-e3619c9d7b71.1729263037387.JavaMail.OMRAP-RF-Email.351f52b1ab9c",
  "Received": "2024-10-18T14:54:36.3616847",
  "SenderAddress": "reg.reporting.do.not.reply@example.com",
  "RecipientAddress": "user@exampledomain.com",
  "Subject": "Report 2024-10-17 - 90440",
  "Status": "Delivered",
  "ToIP": null,
  "FromIP": "208.67.222.222",
  "Size": 53066,
  "MessageTraceId": "1896433f-f63a-43be-ce4f-08dcef84c8d0",
  "Index": 1603
}

OktaIM2:log

Description

The OktaIM2:log source type corresponds to system log events coming from Okta Rest API endpoints.

OCSF conversion is supported for OktaIM2:log events that are formatted as JSON objects. The Okta Rest API and the Splunk Add-on for Okta Identity Cloud emit events in this supported format.

Supported event types

The event data must have a top-level field named eventType containing one of the following values:

  • device.enrollment.create

  • user.account.lock

  • user.account.report_suspicious_activity_by_enduser

  • user.authentication.auth_via_mfa

Expected data format

The event data must follow these formatting conventions:

  • The complete event must be a valid JSON object at the top level. It cannot be wrapped in a syslog message header or any other text.

  • Whitespace characters used to format or indent the event are ignored.

Expand this section for an example of a OktaIM2:log event that is supported for OCSF conversion.

JSON 
{
  "actor": {
    "id": "99999e0dp9HGFD44l3p9",
    "type": "User",
    "alternateId": "johndoe@testing.com",
    "displayName": "John Doe",
    "detailEntry": null
  },
  "client": {
    "userAgent": {
      "rawUserAgent": "ZZZZ5M4eQEC/SZSeTz/W4A 0811A9DDDD.com.okta.android.auth/7.39.0 DeviceSDK/1.0.33 Android/14 Google/Pixel_8_Pro",
      "os": "Android",
      "browser": "UNKNOWN"
    },
    "zone": "null",
    "device": "Mobile",
    "id": null,
    "ipAddress": "8.8.8.8",
    "geographicalContext": {
      "city": "St Louis",
      "state": "Missouri",
      "country": "United States",
      "postalCode": "63139",
      "geolocation": {
        "lat": 38.6142,
        "lon": -90.291
      }
    }
  },
  "device": null,
  "authenticationContext": {
    "authenticationProvider": null,
    "credentialProvider": null,
    "credentialType": null,
    "issuer": null,
    "interface": null,
    "authenticationStep": 0,
    "externalSessionId": "dddVks9UFwNTga4Tsn66ZiEWg"
  },
  "displayMessage": "Enroll new device",
  "eventType": "device.enrollment.create",
  "outcome": {
    "result": "SUCCESS",
    "reason": null
  },
  "published": "2024-07-19T15:08:48.711Z",
  "securityContext": {
    "asNumber": 7018,
    "asOrg": "at&t corp.",
    "isp": "att services inc",
    "domain": "sbcglobal.net",
    "isProxy": false
  },
  "severity": "INFO",
  "debugContext": {
    "debugData": {
      "requestId": "99990fe49950e4a6452c90831d391833",
      "requestUri": "/idp/authenticators",
      "url": "/idp/authenticators?"
    }
  },
  "legacyEventType": null,
  "transaction": {
    "type": "WEB",
    "id": "99990fe49950e4a6452c90831d391833",
    "detail": {}
  },
  "uuid": "dddd7dd7-45e0-11ef-a3fd-9f39525a2143",
  "version": "0",
  "request": {
    "ipChain": [
      {
        "ip": "8.8.8.8",
        "geographicalContext": {
          "city": "St Louis",
          "state": "Missouri",
          "country": "United States",
          "postalCode": "63139",
          "geolocation": {
            "lat": 38.6142,
            "lon": -90.291
          }
        },
        "version": "V4",
        "source": null
      }
    ]
  },
  "target": [
    {
      "id": "dddd1kwrfmC7rxJ0i2p7",
      "type": "UDDevice",
      "alternateId": "unknown",
      "displayName": "Pixel 8 Pro",
      "detailEntry": {
        "oktaDeviceId": "dddd1kwrfmC7rxJ0i2p7",
        "osVersion": "14:2024-07-05",
        "managed": "false",
        "osPlatform": "ANDROID",
        "tpmPresent": "false",
        "deviceStatus": "CREATED"
      }
    }
  ]
}

pan:globalprotect

Description

The pan:globalprotect source type corresponds to Palo Alto Networks GlobalProtect events.

OCSF conversion is supported for pan:globalprotect events that are formatted as comma-separated values (CSV) records. Various Palo Alto Networks products and the Splunk Add-on for Palo Alto Networks emit events in this supported format.

Supported event types

The eventid field in the event data must contain one of the following values:

  • gateway-auth

  • gateway-connected

  • gateway-logout

  • gateway-setup-ipsec

  • gateway-switch-to-ssl

  • portal-auth

Additionally, in events where the eventid value is gateway-connected, the tunnel_type field must not be empty.

Expected data format

The event must be formatted as a CSV record without a CSV header row. The event can optionally start with a syslog header that is separated from the event body by a space character.

The supported event format is as follows:
CODE 
<syslog_prefix> <csv_value_1>,<csv_value_2>,...,<csv_value_49>

The following table describes the accepted format for each placeholder:

Placeholder Accepted format
<syslog_prefix>
An optional syslog message header in this format:
CODE 
<PRI><timestamp> <host_name>
The following are the accepted formats for each placeholder in the header:

  • <PRI> is a 3-digit number enclosed in angle brackets ( < > ).

  • <timestamp> is a date and time in one of these formats:

    • RFC 3164 with a two-digit or four-digit representation of the year. For example: Jan 01 2024 10:45:26.

    • RFC 3339 as used by the RFC 5424 syslog protocol. For example: 2024-01-01T10:45:26Z.

  • <host_name> is an IP address or host name. This value can contain 1 to 255 printable US-ASCII characters, excluding spaces.
<csv_value>

A value stored in a GlobalProtect event field.

The value follows these formatting conventions:

  • A value that contains a comma must be enclosed in double quotation marks ( " ).

  • Inside quoted values, double quotation marks must be escaped as "".

  • Whitespace characters inside the field values significant, and are not automatically trimmed.

Each <csv_value> is associated with a GlobalProtect event field based on its position in the CSV. For example, the second field in a GlobalProtect event is receive_time, so the second value listed in the CSV is stored as the value of the receive_time field. For complete information about the positional fields in a GlobalProtect event, see https://docs.paloaltonetworks.com/ngfw/administration/monitoring/use-syslog-for-monitoring/syslog-field-descriptions/globalprotect-log-fields in the Palo Alto Networks documentation.

OCSF conversion accepts the first 49 values in the CSV record, which includes the GlobalProtect event fields up to and including vsys_id.

  • If the record has fewer than 49 values, the missing trailing fields are stored as empty strings.

  • If the record has more than 49 values, the extra values are ignored.

The OCSF conversion process resolves conflicting information between the syslog header and the CSV record as follows:

  • The <host_name> value from the header takes precedence over the device_name value in the record.

  • The time_generated value in the record takes precedence over the <timestamp> value in the header.

Expand this section for an example of a pan:globalprotect event that is supported for OCSF conversion.

CODE 
Mar 8 00:11:14 southwest-industry-times 1,2024/03/08 00:11:14,655565706273954,GLOBALPROTECT,0,2561,2024/03/08 00:11:14,vsys1,gateway-logout,logout,,,splunkcorp\involve,US,S86W3OMRIK5D,103.116.104.54,0.0.0.0,10.24.185.76,0.0.0.0,5c:c5:4c:98:13:ea,S86W3OMRIK5D,6.1.2,Mac,Apple Mac OS X 14.2.1,1,,,client logout,success,,10,,0,victoria-test-dispatch,7314632246311369647,0x0,2024-03-08T00:11:14.231+00:00,,,,,,0,0,0,0,,southwest-industry-times,0

WinEventLog

Description

The WinEventLog source type corresponds to Windows Event Log data in multiline text format.

OCSF conversion is supported for WinEventLog events. Windows machines and the Splunk Add-on for Microsoft Windows emit events in the supported format.

Supported event types

The EventCode field in the event data must contain one of the following values:

  • 1102

  • 4103

  • 4104

  • 4624

  • 4625

  • 4634

  • 4648

  • 4661

  • 4662

  • 4663

  • 4672

  • 4673

  • 4688

  • 4689

  • 4720

  • 4722

  • 4723

  • 4724

  • 4726

  • 4728

  • 4729

  • 4732

  • 4733

  • 4740

  • 4756

  • 4757

  • 4768

  • 4769

  • 4770

  • 4771

  • 4776

  • 4781

  • 5140

  • 5145

Additionally, in certain cases, the LogName field in the event data must contain a specific value:

  • In PowerShell events, which are denoted by the EventCode field containing 4103 or 4104, the LogName value must be Microsoft-Windows-PowerShell/Operational.

  • In security events, where the EventCode value is any of the numbers in the "Supported event types" list other than 4103 or 4104, the LogName value must be Security.

Expected data format

The event data must be formatted as newline-separated lines of text. For example:
CODE 
11/24/2016 09:00:06 AM
LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4625
...
Subject:
    Security ID:        S-1-0-0
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0
Logon Type:         3
...

The contents of the event must follow these conventions:

  • The end of each line can be denoted by a line feed character (\n) or the combination of a carriage return character and a line feed character (\r\n).

  • The first line of text is a timestamp.
    Note: The OCSF conversion process does not require the timestamp to be in a specific format, but the typical timestamp format in WinEventLog events is <month>/<day>/<year> <time>. For example: 01/15/2015 03:20:28 AM.
  • Subsequent lines in the event can be either of the following:

    • A field-value pair consisting of a field name, a separator, and a field value.

    • A section name consisting of a field name and a separator. An empty field is recognized as a section if it is followed by one or more nested field-value pairs on subsequent lines. Nested field-value pairs must be indented with spaces or tabs.

      In the previous example, Subject: is a section name. This section contains the nested fields Security ID, Account Name, Account Domain, and Logon ID.

  • A field name can include ASCII letters, digits, spaces, tabs, parentheses ( ), hyphens ( - ), and underscores ( _ ).

  • The separator can be an equals sign ( = ) or a colon ( : ).

The OCSF conversion process omits the following elements from the event:

  • Empty lines and comment lines that begin with an ampersand ( # ).

  • Whitespace characters around the separator.

  • Field-value pairs that use unsupported characters.

If the same field name appears more than once in the same level of the event, the value in the field that appears later takes precedence.

Expand this section for an example of a WinEventLog event that is supported for OCSF conversion.

JSON 
01/15/2015 03:20:28 AM
LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4624
EventType=0
Type=Information
ComputerName=szusoidc1.soi.dir.acme080.com
TaskCategory=Logon
OpCode=Info
RecordNumber=989284571
CaseID=AD_4624_1_1
Keywords=Audit Success
Message=An account was successfully logged on.
Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0
Logon Type:         3
New Logon:
    Security ID:        SOI\iiwu
    Account Name:       iiwu
    Account Domain:     SOI
    Logon ID:       0xd22e9734
    Logon GUID:     {1498989B-4798-8546-4F20-18536E283594}
Process Information:
    Process ID:     0x0
    Process Name:       -
Network Information:
    Workstation Name:
    Source Network Address: 10.0.140.130
    Source Port:        64090
Detailed Authentication Information:
    Logon Process:      Kerberos
    Authentication Package: Kerberos
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

XMLWinEventLog

Description

The XMLWinEventLog source type corresponds to Windows Event Log data in XML format.

OCSF conversion is supported for XMLWinEventLog events. Windows machines and the Splunk Add-on for Microsoft Windows emit events in this supported format.

Supported event types

The EventID element in the event data must contain one of the following values:

  • 1102

  • 4103

  • 4104

  • 4624

  • 4625

  • 4634

  • 4648

  • 4661

  • 4662

  • 4663

  • 4672

  • 4673

  • 4688

  • 4689

  • 4720

  • 4722

  • 4723

  • 4724

  • 4726

  • 4728

  • 4729

  • 4732

  • 4733

  • 4740

  • 4756

  • 4757

  • 4768

  • 4769

  • 4770

  • 4771

  • 4776

  • 4781

  • 5140

  • 5145

Additionally, in certain cases, the Channel element in the event data must contain a specific value:

  • In PowerShell events, which are denoted by the EventID element containing 4103 or 4104, the Channel element must contain Microsoft-Windows-PowerShell/Operational.

  • In security events, where the EventID value is any of the numbers in the "Supported event types" list other than 4103 or 4104, the Channel element must contain Security.

Expected data format

The event data must be an XML document with the following structure:

  • The root element is <Event>.

  • The next level of elements includes <System> and either <EventData> or <UserData>.

  • Event fields and values are stored in elements that are further nested inside <System>, <EventData>, or <UserData>.

For example:

CODE 
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="..." Guid="..."/>
    <EventID>4624</EventID>
    <TimeCreated SystemTime="..."/>
    <Channel>Security</Channel>
    <Computer>...</Computer>
    ...
  </System>
  <EventData>
    <Data Name="TargetUserName">...</Data>
    <Data Name="LogonType">3</Data>
    ...
  </EventData>
</Event>

The OCSF conversion process omits the following parts if they are included in the event:

  • XML declaration

  • Namespace prefixes and namespace URIs

  • Leading or trailing whitespace characters before or after text values

  • Empty values and the placeholder value -

  • XML comments, processing instructions, and directives

If the same event field name appears more than once in the same level of the event, the value in the field that appears later takes precedence.

Expand this section for an example of a XMLWinEventLog event that is supported for OCSF conversion.

JSON 
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
    <System>
        <Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}'/>
        <EventID>4624</EventID>
        <Version>2</Version>
        <Level>0</Level>
        <Task>12544</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8020000000000000</Keywords>
        <TimeCreated SystemTime='2021-12-02T19:27:11.683979800Z'/>
        <EventRecordID>280520</EventRecordID>
        <Correlation ActivityID='{A712B501-E77A-0000-13B5-12A77AE7D701}'/>
        <Execution ProcessID='572' ThreadID='1288'/>
        <Channel>Security</Channel>
        <Computer>IP-0ACA0AA5</Computer>
        <Security/>
    </System>
    <EventData>
        <Data Name='SubjectUserSid'>NULL SID</Data>
        <Data Name='SubjectUserName'>-</Data>
        <Data Name='SubjectDomainName'>-</Data>
        <Data Name='SubjectLogonId'>0x0</Data>
        <Data Name='TargetUserSid'>IP-0ACA0AA5\splunker</Data>
        <Data Name='TargetUserName'>splunker</Data>
        <Data Name='TargetDomainName'>IP-0ACA0AA5</Data>
        <Data Name='TargetLogonId'>0x397e71a</Data>
        <Data Name='LogonType'>3</Data>
        <Data Name='LogonProcessName'>NtLmSsp </Data>
        <Data Name='AuthenticationPackageName'>NTLM</Data>
        <Data Name='WorkstationName'>-</Data>
        <Data Name='LogonGuid'>{00000000-0000-0000-0000-000000000000}</Data>
        <Data Name='TransmittedServices'>-</Data>
        <Data Name='LmPackageName'>NTLM V2</Data>
        <Data Name='KeyLength'>128</Data>
        <Data Name='ProcessId'>0x0</Data>
        <Data Name='ProcessName'>-</Data>
        <Data Name='IpAddress'>10.136.158.250</Data>
        <Data Name='IpPort'>0</Data>
        <Data Name='ImpersonationLevel'>%%1833</Data>
        <Data Name='RestrictedAdminMode'>-</Data>
        <Data Name='TargetOutboundUserName'>-</Data>
        <Data Name='TargetOutboundDomainName'>-</Data>
        <Data Name='VirtualAccount'>%%1843</Data>
        <Data Name='TargetLinkedLogonId'>0x0</Data>
        <Data Name='ElevatedToken'>%%1842</Data>
    </EventData>
</Event>