in my opinion, it is not good idea to create a parse rule like yours: (.+). In this case all syslog messages will be catched by that rule, so - regardless of the content of the message - all events will be classified by that rule. If you have a trouble with using of regex, you can try to use http://gskinner.com/RegExr/ webpage.
For example - in your case you can use the following regex - this is a version for enabled including the syslog header option:
(\S+): (\S+) : (\S+) ; PWD=(\S+) ; USER=(\S+) ; COMMAND=(.+)
Then you can map the six capturing groups to suitable variables, like user, command, process or so one.
Thank you for the response, though that isn't really what I was looking for so maybe I wasn't clear.
The only reason I used the .+ is to initially see what part of the event was considered the header if I left the "Include syslog header in regular expression match" unchecked. The regular expresion that I actually used is:
What I did find interesting as I was doing this is that there is actually a problem using a semi-colon in a regular expression in the ESM. If you use a semi-colon in the regular expression, the expression will get truncated at the point of the semi-colon and the rest of the expression will be removed. I actually had to replace the semi-colons with \S so that it would actually take my full expression.
Since my post, I have actually been able to generate events so my first question about the mapping of the header fields has been answered. If you have any insight on the second question regarding the process name, I would appreciate it.
To supplement Artek's post, I find it useful to print out (and hang up in your cube) the ascii table and hex codes for escaped characters. Quick reference.
If you are currently using ASP rules for something and are looking on how / what to parse for something coming in, copy the rule (and disable) and paste a raw log sample to use as sample data. When walking thru logic for the copied rule, you can see how it parses fields. Use that to understand logic and it doesn't really hurt provided you are using disabled duplicate rules (which is why you disable).
I will test these rules with my PC by using a syslog generator with sample data (use current timestamps though) and setting up my PC data source in a different policy testing only my test rules.