device parser content releases need more transparency

[VladimirPrevin]

thought we'd share another case experience relating to what we see is not a good example of managing SIEM parsers/comms with customers

A few days ago - winevent_nic device parser was update in Live. 16th Oct 2017 - around 1600 GMT

Parser Version: 209, Event Source Update: 111
4d4e5a2acb6012f7ad2529fbd48d363468bbb3c58629b0d861c7d66c71d8452f for the xml file

as of now the parser is still on live. (that's what 19 oct 2017 about 3am GMT) 

This among other things stopped parsing cmdline for things like powershell and wscript.

it’s worrying to see

a) a delay from the Live team in getting it pulled or replaced with reverted with a higher version  

b) no release note or git repo to track changes History for devices/winevent_nic/v20_winevent_nicmsg.xml - netwitness/nw-logparsers · GitHub 

c) no notification to customers (let me guess there won't be one when it's pulled)

d) dubious testing 

hoping to see people raise this with their A/Ms as well. 

[EricPartington]

https://github.com/netwitness

there are two projects there

nw-logparsers where you can see the raw log parsers, diff between versions, and event make your own pull and changes and commit them back to be reviewed by the live team.  Or you can contribute any custom parsers that you have developed and feel comfortable sharing to help others in the RSA NetWitness community.

The other project are some Yara rules that you could try in the Malware appliance I guess

Can't help you with the QA part, other than opening a case when you see issues like this... we  hope to have only positive changes when parsers change but ...

You  can probably get GitHub to notify you of changes to the project or to specific parsers but by GitFoo is a bit weak at the moment.

[VladimirPrevin]

thanks . that definitely helps with reverting more quickly instead of several hours via support.

[it doesn't look like support are aware of the resources either] 

> https://github.com/netwitness there are two projects there

Tried finding it but just https://www.google.com.au/search?q=rsa+device+parser+github  but had no luck 

>Can't help you with the QA part, other than opening a case when you see issues like this... we  hope to have only positive changes when parsers change but ...

better automated testing including critical meta key tracking please. 

>You  can probably get GitHub to notify you of changes to the project or to specific parsers but by GitFoo is a bit weak at the moment.

afaik not via the ui. probably only via a git clone + git diff script? 

[VladimirPrevin]

ps how about pulling the faulty parser from live and rolling back? 

[JoeGumke]

When is RSA going to start using their populated fields to start documenting changes from previous versions they support ?

For instance, look at this screenshot, there are various fields that could be used for populating needed information for users to make educated / informed decisions on whether they should pull this into their environment or not. RSA needs to start populating fields for diffs on what was made/how they improved the parser. The comments section would be agood start for RSA to populate updated changes made by RSA. Those scripts mentioned above are nice, but most small/medium companies wont have the time to pull down parsers, analyze this information, and identify if they need them or not in their environment.

[EricPartington]

you can see the diff between versions in GitHub on the web like this...

locate the parser

click the *.xml name

locate the history button on the right

click the name of the parser to view the diff between that version and the current version

and now you have the diff list of all the changes between the two versions

[david_waugh]

I've given up on RSA log parsers and modify them myself. The Official RSA Parser Update process is too slow and too manual.

The official process is:

1) Open a ticket with support

2) Support raise a ticket with Engineering

3) Engineering eventually modify the parser

4) The parser is then tested

5) The parser is then eventually released.

Why can't the product automatically upload anonymised log messages directly to RSA for correction? (After user check anonymised messages)

I suggested this when I worked at RSA but it was never a priority.

It's good to see that you can look at parsers on github, but it is yet another tool to look at and makes the system more complicated than it needs to be.

[PhilipMcLeod]

+1 on critical meta key tracking. Have seen event.description used as a catch-all on too many parsers causing frequent and unnecessary overflows. Infobloxnios being the worst offender.

[VladimirPrevin]

most people found the hist button , and the repo watch buttons but just saying

git diff only for specific file change ALERTING. 

I guess another way is to wait for the SA server live content update message and then just go check the repo. That kind of works 

[VladimirPrevin]

>but most small/medium companies wont have the time to pull down parsers, analyze this information, and identify if they need them or not in their environment.

+1