crowdstrike: improve windows events mappings in FDR data stream (#15342)

For all events:

* Add mapping aid to host.id.
* The following is valid for all events with the event.action ending
  with *Written, except for PeFileWritten, NewExecutableWritten,
  NewScriptWritten
  * event.category is not set for events ending with Written
  * event.action should be set to creation
* Add mapping ContextProcessId to process.entity_id
  (mapping ParentProcessId to process.parent.entity_id is already
  present) in network, file, configuration, registry, driver events.

Registry events (event.category=registry):

* Add support for following new events:
  * RegCrowdstrikeKeyUpdate
  * RegCrowdstrikeValueUpdate
* Remove extra backslash (\) in the start of registry.key.
* Populate registry.path when RegValueName is empty
  * Some events do not populate RegValueName. We can check if it is the
    case and use only RegObjectName if it is the only one available.
    Sample doc
* crowdstrike.RegOperationType
  * On RegOperationType 3 event.type is set to both change and creation,
    should be creation only
  * On RegOperationType 4 event.type is set change, but it is related to
    deletion, we should set it to deletion, and don't populate the
    event.type with change by default.

File events (event.category=file):

* crowdstrike.OriginalFilename is being mapped to
  process.pe.original_file_name:
  * We should map it to file.pe.original_file_name instead
* user.id is not populated  
  * We can use FileOperatorSid to populate it when present
* Set event.type to creation on FileDetectInfo events.
* For NewExecutableRenamed and FileRenameInfo event.action values:
  * Use crowdstrike.TargetFileName to populate file.path
    * We can extract the file name from to populate file.name
  * Use crowdstrike.SourceFileName to populate file.Ext.original.path
    * We can extract the file name from to populate
      file.Ext.original.name

Library events (event.category=library):

* crowdstrike.OriginalFilename is being mapped to
  process.pe.original_file_name:
  * We should map it to dll.pe.original_file_name instead
* dll.code_signature.trusted is being populated with true even for
  unsigned DLLs
  * The documentation says that ImageSignatureLevel 2 is ENTERPRISE
    (0x2), but when I tested with an unsigned DLL it was populated with
    2. However, we can combine it with ImageSignatureType so it becomes
    more reliable.
  * Here is a more specific logic so we can refine this:
    * If ImageSignatureType == 0 (NONE (0x0)):
      * Set dll.code_signature.exists to false
      * Set dll.code_signature.trusted to false
    * If ImageSignatureType >= 1 and ImageSignatureLevel is 0 or 1:
      * Set dll.code_signature.exists to true
      * Set dll.code_signature.trusted to false
    * If ImageSignatureType >= 1 and ImageSignatureLevel >= 2:
      * Set dll.code_signature.exists to true
      * Set dll.code_signature.trusted to true
* Drop process.pid, I mistakenly suggested that we could use
  ContextProcessId to populate it, but considering other events, this
  doesn’t make sense

Driver events for when (event.category is driver):

* crowdstrike.OriginalFilename is being mapped to
  process.pe.original_file_name:
  * We should map it to dll.pe.original_file_name instead
* CertificatePublisher can used to populate
  dll.code_signature.subject_name
* ImageFileName can used to populate dll.path
  * dll.name can be extracted from the ImageFileName path
* ContextProcessId can used to populate process.entity_id
* event.action can be set to load
* SHA256HashData can used to populate dll.hash.sha256
* MD5HashData can used to populate dll.hash.md5
* ServiceDisplayName can used to populate service.name

Additional adjustments:

* Misclassification of events as malware
  * Remove malware from event.category for the following events:
    * AssociateIndicator
    * SensitiveWmiQuery
      * Keep event.category process only, not malware
    * SuspiciousCreateSymbolicLink
      * Drop the malware value, keep the file
    * DetectionExcluded
        * Use event.category configuration, not malware
    * RegistryOperationDetectInfo
      * Drop the malware value, keep the registry

* Overuse of event.kind: alert
  * Using event.kind == alert too broadly promotes many irrelevant
    events to security alerts, Set event.kind to event for following
    events:
    * ErrorEvent
    * RansomwareOpenFile
    * RansomwareCreateFile
    * ModifyServiceBinary
    * DetectionExcluded
    * SensitiveWmiQuery
    * FileSystemOperationDetectInfo

Author: navnit-elastic

packages/crowdstrike/changelog.yml

@@ -1,4 +1,9 @@
 # newer versions go on top
+- version: "2.4.0"
+  changes:
+    - description: Enhance the field mappings for Windows events in the FDR data stream.
+      type: enhancement
+      link: https://github.com/elastic/integrations/pull/15342
 - version: "2.3.0"
   changes:
     - description: Migrate to /alerts/combined/alerts/v1 endpoint to pull alert data.

packages/crowdstrike/data_stream/fdr/_dev/test/pipeline/test-data.log-expected.json

@@ -278,6 +278,7 @@
             },
             "host": {
                 "hostname": "example-XXXXXXXXX",
+                "id": "11111111111111111111111111111111",
                 "name": "example-XXXXXXXXX",
                 "os": {
                     "type": "macos"

packages/crowdstrike/data_stream/fdr/_dev/test/pipeline/test-fdr-lengthy-field-delete.log-expected.json

@@ -58,6 +58,7 @@
             },
             "host": {
                 "hostname": "example-XXXXXXXXX",
+                "id": "1111",
                 "name": "example-XXXXXXXXX",
                 "os": {
                     "type": "macos"

packages/crowdstrike/data_stream/fdr/_dev/test/pipeline/test-fdr-lengthy-field-index.log-expected.json

@@ -59,6 +59,7 @@
             },
             "host": {
                 "hostname": "example-XXXXXXXXX",
+                "id": "1111",
                 "name": "example-XXXXXXXXX",
                 "os": {
                     "type": "macos"