This message originated from Cribl Community Slack.
Click here to view the original link.
Morning all! I am working with my Azure Event Hubs source and I would like to use a Drop function in our SIEM pipeline to remove: AdvancedThreatHunting-DeviceNetworkEvents that come back with the property 'ActionType' where the action was successful. These have low Security value for our detections and is the lion share of these events. Having an issue with my pipeline chaining down into the properties. Looking for some quick guidance!
Solved
Cribl Stream: Using Drop function to filter nested properties in SIEM
Best answer by vscherbakov530
Looks like
View originalActionType is nested under properties, so the filter needs properties.ActionType. As written it’s checking a top-level field that doesn’t exist, so the Drop matches nothing (assuming the parser is extracting to top level).
One thing to check before you turn it on: do any of your SIEM rules query DeviceNetworkEvents directly? Successful connections tend to be what network detections key on (threat intel IP matches, beaconing, inbound RDP/SMB). If most of the volume is ZSATunnel like this sample, dropping on properties.InitiatingProcessFileName === 'zsatunnel.exe' might get you most of the reduction with less risk.
Can you share a sample event, and what you've tried?
{"time":"2026-10-09T12:18:40.0703962Z","operationName":"Publish","category":"AdvancedHunting-DeviceNetworkEvents","_TimeReceivedBySvc":"2026-10-09T12:17:41.3654750Z","properties":{"DeviceName":"REDACTED","DeviceId":"99e7b49ad20daa71cad429c07470daf65626aaed","ReportId":7114,"RemoteIP":"::REDACTED","RemotePort":50836,"LocalIP":"REDACTED","LocalPort":9000,"Protocol":"Tcp","InitiatingProcessCreationTime":"2026-10-09T12:09:38.6545653Z","InitiatingProcessId":16300,"InitiatingProcessCommandLine":"\"ZSATunnel.exe\"","InitiatingProcessParentCreationTime":"2026-10-09T12:09:11.9342877Z","InitiatingProcessParentId":1828,"InitiatingProcessParentFileName":"services.exe","InitiatingProcessSHA1":"2608f7f8e5b80b83c50d3f79ffd91e84f9860707","InitiatingProcessMD5":"d81683d3abde18b0e281f51692d6704e","InitiatingProcessFolderPath":"c:\\program files\\zscaler\\zsatunnel\\zsatunnel.exe","InitiatingProcessAccountName":"system","InitiatingProcessAccountDomain":"nt authority","InitiatingProcessAccountSid":"S-1-5-18","InitiatingProcessFileName":"zsatunnel.exe","InitiatingProcessIntegrityLevel":"System","InitiatingProcessTokenElevation":"TokenElevationTypeDefault","LocalIPType":"FourToSixMapping","RemoteIPType":"FourToSixMapping","ActionType":"InboundConnectionAccepted","InitiatingProcessSHA256":"fcbb0b052b2edf79af61a9158206abb9c878826d4a66eb7f31da34db074f84bc","InitiatingProcessFileSize":13359888,"InitiatingProcessVersionInfoCompanyName":"Zscaler Inc.","InitiatingProcessVersionInfoProductName":"Zscaler","InitiatingProcessVersionInfoProductVersion":"4.8.0.151","InitiatingProcessVersionInfoInternalFileName":"ZSATunnel.exe","InitiatingProcessVersionInfoOriginalFileName":"ZSATunnel.exe","InitiatingProcessVersionInfoFileDescription":"ZscalerTunnel","InitiatingProcessUniqueId":"40813871623045519","Timestamp":"2026-10-09T12:17:00.3628986Z","MachineGroup":"UnassignedGroup"},"Tenant":"DefaultTenant"}
Is the event parsed, or is that a string?
This is my current Pipeline on these events:
{
"id": "GPS-Azure-Event-Hubs",
"conf": {
"output": "default",
"streamtags": [],
"groups": {},
"asyncFuncTimeout": 1000,
"functions": [
{
"filter": "true",
"conf": {
"comment": "Summary of work:\n\n-Unroll JSON array of events into individual events\n-Drop original array field\n-Parse events and drop empty/null fields\n-Drop potentially un-needed heartbeat and health metric logs\n-Dynamic Sampling (description below):\n\nThe dynamic sampling function is meant to sample Azure monitor logs for container logs, based on the resource ID and category so that sampling targets can have more cardinality.\n\nLogarithmic is selected to do sampling on a curve\n\nThe idea being to sample container logs as, on deployment, these have a lot of noise and can cause large bursts of logging. The Sample key is looking for resourceID and category so that every log type from every server is treated independently"
},
"id": "comment"
},
{
"filter": "true",
"conf": {
"srcExpr": "records",
"dstField": "_raw"
},
"id": "unroll",
"disabled": false,
"description": "golden child"
},
{
"filter": "true",
"conf": {
"printUndefineds": false,
"add": [],
"remove": [
"records"
]
},
"id": "eval",
"disabled": false
},
{
"filter": "true",
"conf": {
"mode": "extract",
"type": "json",
"srcField": "_raw",
"fieldFilterExpr": "value != null && value != '' && value !== 'N/A'",
"remove": [
"tenantId"
]
},
"id": "serde",
"disabled": false
},
{
"filter": "category === 'AdvancedHunting-DeviceNetworkEvents' && \r\nActionType === 'ConnectionSuccess'",
"conf": {},
"id": "drop",
"description": "This Function Drop Successful Network Events that have Low SIEM value. These are not dropped for the Full Data Route.",
"disabled": true
},
{
"filter": "category == 'AzureDiagnostics' && operationName == 'Heartbeat' || category == 'Perf'",
"conf": {},
"id": "drop",
"disabled": false
},
{
"id": "dynamic_sampling",
"filter": "category == 'ContainerLog'",
"disabled": true,
"conf": {
"mode": "log",
"keyExpr": "
${resourceId}:${Category}",
"samplePeriod": 30,
"minEvents": 50,
"maxSampleRate": 100
}
}
],
"description": "Azure Event Hub Event breaking and null value reduction pipeline"
}
}Looks like
ActionType is nested under properties, so the filter needs properties.ActionType. As written it’s checking a top-level field that doesn’t exist, so the Drop matches nothing (assuming the parser is extracting to top level).
One thing to check before you turn it on: do any of your SIEM rules query DeviceNetworkEvents directly? Successful connections tend to be what network detections key on (threat intel IP matches, beaconing, inbound RDP/SMB). If most of the volume is ZSATunnel like this sample, dropping on properties.InitiatingProcessFileName === 'zsatunnel.exe' might get you most of the reduction with less risk.Nice catch, @user
@user Thank you for this insight! I am checking with our MSSP whom manages our CSE Detection rules within SumoLogic regularly prior to making any production changes. Working toward my 'Security vs audit' reductions across all sources to get down to our true Security log ingest costs at the SIEM level. I'll update as I go!
@user
Makes sense, good call running it by them. Curious how your MSSP checks it: do they review the rule logic against the proposed drop, or run sample events through, or do something else?
They have internal mappers within SumoLogic that aligns what Logs are being utilized for certain Detections. It's been a nice validation step for both log reduction, and understanding our Detection ecosystem and our MITRE Mappings, etc.
Sign up
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.