In this installment of the Tips and Insights series, Adam Goff explains self parsing in Helix. Self parsing should be used for extending parsing to cover important unparsed events in Helix.
Hi I’m Adam Goff. I’m a Support Engineer here at FireEye. Today we are going to be talking about self parsing in Helix. Self parsing should be used for extending parsing to cover important unparsed events in Helix.
Based on customer demand we have added the ability for customers to build and implement additional parsing patterns in Helix. Customer parsing patterns affect only their instance of Helix and are not shared with other instances. Customer built parsing rules only apply to events left unparsed by the FireEye provided parsing. Custom parsing patterns can’t adjust the way existing FireEye parsing patterns parse your events. To begin this process you will need the pattern DB file that you will be uploading to Helix. I have two pattern DB file variance up on my screen. The top one and the bottom one. As you can see the pattern on the top one is very short. The pattern on the bottom one is very long. So maybe six fields parsed out of the top one. Forty fields parsed out of the bottom one. Both of these are valid and viable pattern DB’s. The top one focused more on only calling out the things that matter when you’re working with a specific dashboard or with rule alert generation. The bottom one is valid if you have multiple fields within a file that might not be related to security so much as related to your ability to operate within your processes in your SOC. Please note that these files are written in XML and you will be required to close every tag and your labels matter. So the labels are going to map to fields in Helix whenever this rule is hit by an event. And so if you notice we call out a meta class or we call out of class. The class is going to matter in dashboards and rules. The meta class is going to matter in rules. Your descriptions are all going to map to fields within Helix.
Once in Helix, to import the pattern DB we will click on the user icon on the top right. We will go to Helix settings. We will go to the parsing tab.
You have on the right the option to add a custom pattern DB file.
Our first example will be of a bad pattern DB file so you see what happens. Note the red failed XML schema check. So we do two different checks every time a files uploaded to Helix. The first check we do is to make sure that XML schema is correct.
And then the second check we do is to validate that the pattern is a valid pattern and follows our syntaxing for the pattern. As I described that I also showed what happens when a valid pattern is uploaded you will get that green success marker that had popped up on the screen. As you can see when we started we had two pattern DB’s and then when I successfully uploaded the pattern DB just now it became my top pattern DB. We also have the ability to delete and export those pattern DB’s. Also you will only have one active pattern DB . That active pattern DB will be replaced 15 minutes after the new one is uploaded because that is how long our validation process takes on the patterns. Now we see how to deploy custom parsing patterns in Helix. Thank you and stay tuned for more FireEye Tips and Insights.