ArcSight Rules - Suspicious, Malicious, or Delicious?
This post was inspired by a reader that asked about creating a channel in ArcSight ESM that would prioritize events based on previous behavior of a computer. I'll be as generic as possible as there are a lot of use cases for this type of logic. Resources Needed:
- Active Channel
- Active List
There used to be an example of this in the default content of ESM. Hopefully, it is still there.
Example Use Case (from reader):
Observe external computer scanning and set priority to 1. Observe a priority 1 computer attempt an exploit set it priority 2. Observe a successful exploit or C2 traffic from target ring a siren and blink a red light.
- Create an Active List (AL) called "Suspicious External Hosts" that keeps track of at least Source IP and Source Zone URI. Set TTL on AL to something reasonable for your organization. Could be one hour; could be 30 days.
- Create a rule with your definition of "scanning" with an Action of "Add to Active List". Put the source IP in the Suspicious External Hosts" AL. Make part of the rule condition NOT in AL to prevent repeat firing of the rule.
- Create an Active List called "Malicious External Hosts" just like Suspicious External hosts in Step 1.
- Create an Active List called "Targeted Internal Hosts" just like Suspicious External hosts in Step 1.
- Create a Rule looking for attempted exploit or attempted unauthorized access.
- Include a condition that the Source IP of this event be in the Suspicious AL. Add an Action of "Add to Active List". Put the source IP in the Malicious External Hosts" AL. Put a second Action of "Add to Active List". Add the Destination IP into the "Targeted Internal Hosts" AL.
- Create a rule looking for C2 traffic with a condition that the source IP be in the "Targeted Internal Hosts" AL. Add an Action of Notification which will send you an email when the rule fires.
- Same as Step 7 except looking for successful exploit instead of C2 traffic for the condition.
- Create one or more active channels that use the Name field and looks for the names of the Rules created above. Your analysts can either watch this channel to be proactive or wait for the notifications to come in. Really depends on their workload.
I would personally add another Active List and AL condition for Steps 7 and 8 to do what I call "throttling" to prevent the rule from firing excessively. I'll write about throttling rules later if anyone is interested. Essentially, it uses the SIEM's intelligence to prevent the "Boy Cried Wolf" syndrome and the reason for so many ignored email alerts in IT.
Make sure every field you use in the Condition tab is added to the Aggregation tab in the Rule. Otherwise, the Rule will never fire. Wish I had a dollar for every time I made that mistake.
Custom notification templates and the use of Flex String fields could come in very useful to make the notifications more actionable. This is also a topic for another time. Let me know if you're interested.
This is all off the top of my head. If I missed something, let me know and I'll be happy to update the post.