Update Okta pipeline to reflect field names

[kelnage]

When creating new Sigma rules for Okta, it turned out that the naming of the fields is not as consistent as it originally seemed, and that certain all field names should use full stops, whereas the majority use underscores. The existing Okta pipeline assumed all field names use underscores, so should be updated to reflect this inconsistency.

An up-to-date YAML pipeline used for correctly converting the Sigma Okta rules is as follows:

name: Okta JSON pipeline
priority: 20
transformations:
  - id: loki_okta_event_json_formatter
    type: set_custom_attribute
    attribute: loki_parser
    value: json
    rule_conditions:
    - type: logsource
      product: okta
      service: okta
  - id: loki_okta_field_name_mapping
    type: field_name_mapping
    mapping:
      eventtype: eventType
      legacyeventtype: legacyEventType
      actor.alternateid: actor_alternateId
      actor.displayname: actor_displayName
      client.useragent.rawuseragent: client_userAgent_rawUserAgent
      client.useragent.os: client_userAgent_os
      client.useragent.browser: client_userAgent_browser
      client.geographicalcontext.geolocation.lat: client_geographicalContext_geolocation_lat
      client.geographicalcontext.geolocation.lon: client_geographicalContext_geolocation_lon
      client.geographicalcontext.city: client_geographicalContext_city
      client.geographicalcontext.state: client_geographicalContext_state
      client.geographicalcontext.country: client_geographicalContext_country
      client.geographicalcontext.postalcode: client_geographicalContext_postalCode
      client.ipaddress: client_ipAddress
      debugcontext.debugdata.requesturi: debugContext_debugData_requestUri
      debugcontext.debugdata.originalprincipal.id: debugContext_debugData_originalPrincipal_id
      debugcontext.debugdata.originalprincipal.type: debugContext_debugData_originalPrincipal_type
      debugcontext.debugdata.originalprincipal.alternateid: debugContext_debugData_originalPrincipal_alternateId
      debugcontext.debugdata.originalprincipal.displayname: debugContext_debugData_originalPrincipal_displayName
      debugcontext.debugdata.behaviors: debugContext_debugData_behaviors
      debugcontext.debugdata.logonlysecuritydata: debugContext_debugData_logOnlySecurityData
      authenticationcontext.authenticationprovider: authenticationContext_authenticationProvider
      authenticationcontext.authenticationstep: authenticationContext_authenticationStep
      authenticationcontext.credentialprovider: authenticationContext_credentialProvider
      authenticationcontext.credentialtype: authenticationContext_credentialType
      authenticationcontext.issuer.id: authenticationContext_issuer_id
      authenticationcontext.issuer.type: authenticationContext_issuer_type
      authenticationcontext.externalsessionid: authenticationContext_externalSessionId
      authenticationcontext.interface: authenticationContext_interface
      securitycontext.asnumber: securityContext_asNumber
      securitycontext.asorg: securityContext_asOrg
      securitycontext.isp: securityContext_isp
      securitycontext.domain: securityContext_domain
      securitycontext.isproxy: securityContext_isProxy
      target.alternateid: target_alternateId
      target.displayname: target_displayName
      target.detailentry: target_detailEntry
    rule_conditions:
    - type: logsource
      product: okta
      service: okta
  - id: loki_okta_field_event_prefix
    type: field_name_prefix
    prefix: event_
    rule_conditions:
    - type: logsource
      product: okta
      service: okta

[kelnage]

As of SigmaHQ/sigma#4509, it seems the field names used in the Sigma Okta rules now all use dotted notation (and so this pipeline does not currently work correctly on some rules). This is, however, a good thing, as it improves their consistency and may allow us to use a pipeline on the field name for that aspect, rather than maintaining a manual mapping - however, the case sensitivity of the fields has not changed (i.e., in the rules they are all lower case), so that will still need to be worked around.

I have updated the JSON pipeline above to reflect this change.