As Grant has laid out in his post earlier this week, file hashes can be a valuable source of information for a range of different SIEM use cases. Below we'll lay out how to actually implement his workflow in McAfee ESM:
To use McAfee ESM to detect and alert on changes to critical files, we will need to do the following:
- Identify a source of hash data that can be fed to the SIEM. In this case we'll be leveraging a custom script running on a Linux host, forwarding the hashes as syslog events, but there are other options.
- Create a custom type to hold hashes, and a custom parser to map fields into your new hash type, if needed
- Define a data source to receive the logs.
- Set up a dynamic watchlist to maintain the current list of known hashes.
- Create a correlation rule to fire on new hashes
- Define an alarm to trigger and alert you when the correlation rule fires.
The discussion below will break this up into 3 phases: setup, baselining, and daily operations.
To begin, we have a few items to configure.
- First we will create a string Custom Type called "Hash". This will be used to store file hashes. To define a custom type, select System Properties / Custom Types. I put mine on Custom Field 9. Here’s what it looks like.
I chose to index my hash data, to make it easy to perform quick searches in the ESM interface in the future. If you have very large numbers of file hashes you'll be storing, this may have performance implications for you, but should work fine in most environments.
- Next create a custom parsing rule for these logs in the policy editor. We’d want each event to parse out (at a minimum) the IP address/hostname, file name, and hash. How you construct this parsing rule will depend on the format of your hash data. In our example, hashes are fed to the McAfee Event Receiver over syslog, from a custom script running on each Linux host.
- Create a new data source to receive the syslogs from your system. Our example is a Linux host, IP address 220.127.116.11. Ensure your new rule is enabled in the policy for this data source, aggregation is disabled for your rule above, and policy is rolled out.
When I import my own sample events, the data as seen below:
- create a dynamic watchlist (we'll call it “Current Hashes”) that tracks all the file hashes in question. Schedule it to run daily. Here’s how I configured mine:
- Create a correlation rule to fire when Hash NOT IN [Current Hashes]. This rule will trigger any time the Correlation Engine sees a hash that it hasn't seen before. Save it, and ensure it’s enabled (and aggregation is disabled) in your correlation engine policy:
- This step is optional, but I also prefer to create an alarm to to notify me when the above correlation rule triggers. You'll need the signature ID for your new correlation rule created above.
Now that the basic configuration is complete, we need to baseline the system, bringing in the current list of all the known good hashes.
- Import current state hashes into system, so you’ve got the baseline hash events.
- Click “Run Now” on the dynamic watchlist. This will generate your initial watchlist of current hashes, as seen above.
3) Daily Operations
With the system fully configured and baselined, you are ready to sit back and wait for the fireworks to happen. Here's how this system works on a daily basis:
- Each day the current file hashes are recalculated and fed to the McAfee Event Receiver.
- Receiver imports/parses new hashes, and they are stored in the ESM.
- If a hash changes, it won’t be on the list of Current Hashes, and your correlation rule will trigger (as well as the optional alarm). Here’s an example showing the correlation rule trigger
- Later in the day (at the time you configured in the watchlist above), your dynamic watchlist will update itself, adding the new hash to the “Current Hashes” list, ensuring that you won’t get another Alarm/Correlation rule trigger for the same file in the future.