Time for a long overdue post on one of the nuances of the McAfee ESM.
The core function of a SIEM is to provide automated analysis and correlation of data in disparate formats. To do this, the SIEM needs to understand how to interpret the data and the first step in that process is parsing. A parsing rule identifies each piece of the event that is important and maps it into the relevant field. Once the fields are populated, the SIEM is able to apply the analysis algorithms and rules to the data while also enabling provide search and reporting capabilities.
The parsing rules are divided up into categories, or rulesets, based on vendor and product. There are some rulesets that are not associated with a specific base device, such as, Postfix, Squid and FreeRADIUS. Applications like these can often run on Windows or Linux operating systems so it makes sense to enable them for data sources as needed in contrast to adding them to multiple base OS rulesets. The process to enable additional rules is the same process to enable custom rules* as well so this post will show both.
|*About the Rules|
|Parsing rules are generally composed of regular expressions (regex). If you're interested in learning more about regex, there are no shortage of guides and editors available. The McAfee Custom Parsing Rule Guide is the best place to start. From there, my go to editor is Regexr and I think this is a great basic reference. It doesn't need to be more complicated than that.|
1. Select the data source from the tree on the left and then click the Policy Editor icon on the icon bar above. This may be a device tied to an existing data source or it may be configured as: Vendor: Generic, Model: Advanced Syslog Parser for a custom ruleset.
2. If you're enabling existing rules for a data source, click the filter icon next to Device Type ID to choose from the list of rulesets.
3. If you're importing custom rules, go to File | Import | Rules and select the rules file.
4. To see the custom rules, clear out any populated fields in the Advanced search filter on the right. Scroll to the bottom and select 'user defined' under Origin. Press enter or click the green refresh circle in the icon bar above the filter.
5. Now whether you selected an existing ruleset or imported custom rules you should be looking at a list of rules to enable in the Policy Manager.
(If you do not, please see Step 4.)
a. Ensure that the data source for which the rules are to be enabled is shown at the top**.
- To enable a single rule, click on the word 'disabled' and choose 'enabled'.
- To enable a group of rules, you can select the first rule, scroll to the last rule and shift-click to select the rules.
b. Click the Action heading on the top header bar.
c. Select enabled on the dropdown.
- You will be prompted to enable the rules that are selected.
d. Click the Rollout button to roll out the policy.
- Save when prompted and click OK.
- The roll out window will close when it is finished. It can be minimized during the process.
** It is best practice that rules are only enabled in a sub-policy and no rules are enabled at the Default Policy level.
There still may be some events in transit so it may take up to two intervals of the ESM querying the Receiver (10 minutes by default) to see the parsing changes show up.
- When testing use the Get Events and Flows (instant gratification) button at the top of the Device Tree to manually have the ESM query the Receiver for new events.
- Don't forget to set the View time frame to "All" and consider any settings that might impact the age of events being inserted if there is a requirement to populate historical events.
- Make sure the time zone of the event time matches the time zone configured in the data source.
- Set "Support Generic Syslogs" to "Log "unknown syslog" event" under the data source while testing. Change it when complete. Best practice is to set to "Do nothing" for production. It improves performance.