Filtering by Tag: rules

ArcSight Rule Testing Tip

One thing I learned today is patience when testing an ArcSight rule on old events.  This has always sort of been voodoo to me.  Maybe everyone knows this already, but I thought I'd share. When testing a new rule using the "Test" button (see image to left) in the Rule definition window there is a behavior difference.   It essentially uses an Active Channel and inserts your test rule into that stream of events.

So, it looks like any other active channel with one exception.  The channel will speed through messages (examples below) such as  showing you "Percentage Complete", telling you it is Retrieving events, and may even show a message saying "No data matches this query".    This does not necessarily mean your rule does not work.

Just let the Active Channel sit there for a few minutes and you may get results.  Apparently, when ESM says it is done, it is not done.

This has tripped me up many times and I finally figured out it was lying to me today when my ADHD kicked in.  I came back to the channel later and had results.

So, I learned something new today after seven years of using ESM.   Sort of embarrasing, but hopefully it can help you test your rules better before putting them in production.

Until next time... Wyman

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
  • Rule
  • Notification

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.

Basic solution:

  1. 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.
  2. 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.
  3. Create an Active List called "Malicious External Hosts" just like Suspicious External hosts in Step 1.
  4. Create an Active List called "Targeted Internal Hosts" just like Suspicious External hosts in Step 1.
  5. Create a Rule looking for attempted exploit or attempted unauthorized access.
  6. 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.
  7. 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.
  8. Same as Step 7 except looking for successful exploit instead of C2 traffic for the condition.
  9. 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.

Closing Tips

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.

ArcSight Rules - ESM is not meant to be broken

One of the most important content types you will create in ArcSight ESM will be rules.  In this post, I will try to offer some guidance based on the past seven years I've been exposed to ESM. The heart of the correlation engine is driven by rules.  The decisions your rules make will ultimately drive the decisions and workflow in your detection and response program.  You can get a false sense of security or wind up trying to drink water from a fire hose if you're not careful.

I have overwhelmed myself a few times working with rules.  At other times, I've waited and wondered why a rule was not firing only to find out I forgot a key condition or aggregation field.  Hopefully, you will further along after reading this post.

With rules there are four key areas to pay attention to:

1. Conditions * Order your condition filter from most specific to least specific condition.  This will allow ESM to quickly eliminate events that do not match. * Use = instead of !=.  This also helps ESM eliminate events quicker. * When possible use exact case.  This will reduce the resources the rule needs. * Using indexed fields reduces load on the database server. 2. Aggregation * Keep timeframe to less than five minutes.  Partial matches have be kept in memory. * For timeframes > than five minutes use Active List to eliminate partial matches. * Any field used in the rule condition must be added on the Aggregation tab or the rule will never fire.  This has bitten me many times. 3. Actions * Use notification templates to help make email alerts more readable.  The easiest way to do this is using a combination of the "Set event field" action plus some magic on the manager in $ARCSIGHT_HOME/config.  Details will come in a later blog post. * Actions also are where you would add/remove things from Active Lists to help with throttling or prioritization. 4. Throttling * This is a term I use.  It is using an Active List in the Condition statement of a rule to keep the rule from firing all the time.  Essentially, the first time your rule fires, it can add values to an Active List.  The condition would include a check of that Active List.  If the value exists, then the condition of the rule would not be met.  This eliminates what I call "The boy cried Wolf" syndrome.  We've all had monitoring systems that email mail bomb us when there is a problem in the network.  This use of Throttling unleashes the power of ArcSight ESM to make your monitoring much more intelligent.

ArcSight ESM rules are a very powerful and flexible resource if you use them well. Things like this are what turn a SIEM into a way to augment your existing headcount.  It frees your people up to work on higher quality problems instead of wading through tons of false positives.  I hope this overview has been helpful and will go into detail on some of these in later posts.

How do you use rules in ArcSight (or another SIEM) to make your team more effective?