Hello,
If you consider setting up two connectors that should work too with defining the Environment Variable field.
Environment Field Name |
Optional
Describes the name of the field where the environment name is stored.
If the environment field isn't found, the environment is the default environment.
Default value is "" .
|
On the SIEM side you would need to define in your rules metadata which environment each alert from that rule should go to:
detection_ruleLabels_<metatagname> --- you should be able to see this in the case info

So rather than doing what you propose above you can create two connectors and have that metadata attached to the rules on the SIEM side.
Anything that matches:
detection_ruleLabels_env1 -> send to SOAR env1
detection_ruleLabels_env2 -> send to SOAR env2
Hello,
If you consider setting up two connectors that should work too with defining the Environment Variable field.
Environment Field Name |
Optional
Describes the name of the field where the environment name is stored.
If the environment field isn't found, the environment is the default environment.
Default value is "" .
|
On the SIEM side you would need to define in your rules metadata which environment each alert from that rule should go to:
detection_ruleLabels_<metatagname> --- you should be able to see this in the case info

So rather than doing what you propose above you can create two connectors and have that metadata attached to the rules on the SIEM side.
Anything that matches:
detection_ruleLabels_env1 -> send to SOAR env1
detection_ruleLabels_env2 -> send to SOAR env2
That seems like a good approach, thanks! It does still however mean I have to retrospectively add this meta to all of my rules and not just a small subset, then a null check on the other.
Okay so use a env variable only in one of the environments and only modify the rules for that and the specific action trigger in SOAR.
Then you could use the other env as null.
Okay so use a env variable only in one of the environments and only modify the rules for that and the specific action trigger in SOAR.
Then you could use the other env as null.
My question is how do we get that null check on the dynamic filter list? Without any rules it will ingest all rules that have detected an alert in SIEM.
You wouldnt need to do that if you did it with 2 connectors.
Or just create a catch all trigger in a playbook and set it as priority 3 with the trigger of any <- that would catch all your NULL pairs.
Then set your other playbooks with specifics based on events types or specific log sources, etc...
These are the supported filters for this under the dynamic list