DT-414-add-missing-processors

docs/appendix/field-formats/csl.mdx

@@ -0,0 +1,37 @@
+---
+pagination_prev: null
+pagination_next: null
+---
+
+# CSL
+
+The Common Security Log (CSL) is a standardized schema developed by Microsoft for Azure Sentinel (now Microsoft Sentinel). It provides:
+
+**Common Fields**:
+
+|Field Category|Fields|Description|
+|:-:|:--|:--|
+|Base Fields|`TimeGenerated`, `Type`, `TenantId`, `SourceSystem`, `Computer`|Core fields for event identification and source tracking|
+|Identity Fields|`AccountName`, `AccountDomain`, `UserPrincipalName`, `UserId`|User identification and authentication tracking|
+|Network Fields|`SourceIP`, `DestinationIP`, `SourcePort`, `DestinationPort`|Network communication endpoints|
+|Security Fields|`Activity`, `Status`, `ResultType`, `ResultDescription`|Security operation outcomes and status information|
+
+**Schema Categories**:
+
+|Category|Fields|Purpose|
+|:-:|:--|:--|
+|Authentication|`LogonType`, `AuthenticationMethod`, `LogonProcessName`, `ImpersonationLevel`|Track authentication events and access control|
+|Network Session|`Protocol`, `Direction`, `BytesSent`, `BytesReceived`, `Duration`|Monitor network communications and traffic patterns|
+|Process|`ProcessName`, `CommandLine`, `ProcessId`, `ParentProcessName`|Track process creation and execution|
+|File|`FileName`, `FilePath`, `FileHash`, `FileOperation`|Monitor file access and modifications|
+|Registry|`RegistryKey`, `RegistryValueName`, `RegistryValueData`|Track registry changes and access|
+
+**Event Types**:
+
+|Type|Event Classes|Description|
+|--:|:--|:--|
+|Authentication|`SignInLogs`, `AuditLogs`, `AADNonInteractiveUserSignInLogs`|Authentication-related events and outcomes|
+|Security|`SecurityEvent`, `SecurityAlert`, `SecurityIncident`|Security-related events and alerts|
+|Network|`AzureNetworkAnalytics`, `CommonSecurityLog`, `DnsEvents`|Network activity and communications|
+|Identity|`IdentityInfo`, `IdentityDirectoryEvents`, `IdentityLogonEvents`|Identity and directory service events|
+|Endpoint|`DeviceEvents`, `DeviceProcessEvents`, `DeviceFileEvents`|Endpoint detection and response events|

docs/configuration/pipelines/handling-failures.mdx

@@ -52,7 +52,7 @@ For cascading errors, multiple `on_failure` processors can be nested.
 
 ## Pipelines
 
-The `on_failure` can also be specified for the pipeline. When a processor fails, in the absence of a processor-level `on_failure` setting, **Director** uses the pipeline-level setting as a fallback. However, in that case it does not attempt to run the remaining processors.
+The `on_failure` option can also be specified for the pipeline. When a processor fails, in the absence of a processor-level `on_failure` setting, **DataStream** uses the pipeline-level setting as a fallback. However, in that case it does not attempt to run the remaining processors.
 
 ```yaml
 pipelines:
@@ -61,7 +61,8 @@ pipelines:
       - set:
           field: _index
           value: failed-{{{ _ingest.on_failure_processor_tag }}}
-          description: "Processor failed"```
+          description: "Processor failed"
+```
 
 ## Metadata
 

docs/configuration/pipelines/processors/kv.mdx

@@ -5,7 +5,7 @@ sidebar_custom_props:
   customCategory: Parse
 ---
 
-# KV Pair
+# KV
 
 <span className="theme-doc-version-badge badge badge--primary">Parse</span><span className="theme-doc-version-badge badge badge--secondary">Elastic Compatible</span>