device parser content releases need more transparency

Discussion created by Vladimir Previn on Oct 18, 2017
Latest reply on Nov 1, 2017 by Vladimir Previn

Like • Show 0 Likes0
Comment • 12

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.

Outcomes

12 Replies

Eric Partington Oct 18, 2017 10:58 PM
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.
1 person found this helpful
Like • Show 0 Likes0
Actions
- Vladimir Previn @ Eric Partington on Oct 18, 2017 11:48 PM
  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?
  Like • Show 0 Likes0
  Actions
  - Philip McLeod @ Vladimir Previn on Oct 19, 2017 5:05 PM
    +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.
    Like • Show 0 Likes0
    Actions
- Vladimir Previn @ Eric Partington on Oct 18, 2017 11:53 PM
  ps how about pulling the faulty parser from live and rolling back?
  Like • Show 0 Likes0
  Actions
Joe Gumke Oct 19, 2017 8:32 AM
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.
Like • Show 0 Likes0
Actions
- Eric Partington @ Joe Gumke on Oct 19, 2017 8:42 AM
  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
  Like • Show 0 Likes0
  Actions
  - Vladimir Previn @ Eric Partington on Oct 19, 2017 6:52 PM
    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
    Like • Show 0 Likes0
    Actions
  - Joe Gumke @ Eric Partington on Oct 20, 2017 7:58 AM
    Is RSA not going to document diffs in the tool ?When is RSA going to start using their populated fields to start documenting changes from previous versions they support ?
    
    Using the github adds another layer of complexity to analyzing parsers.
    The github was intended for a community based parser forum , so users can modify/update parsers in here as RSA struggles to support most event sources today. How do we ensure that these are RSA supported? How do we know that RSA parsers are up to date , and in sync with whats on live?
    Like • Show 0 Likes0
    Actions
- Vladimir Previn @ Joe Gumke on Oct 19, 2017 7:41 PM
  >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
  Like • Show 0 Likes0
  Actions
David Waugh Oct 19, 2017 8:54 AM
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.
Like • Show 1 Like1
Actions
- Vladimir Previn @ David Waugh on Oct 19, 2017 7:42 PM
  I get the feeling the envision parser/SIEM functions and even some of the lua parsers aren't an immediate priority at all...
  Like • Show 1 Like1
  Actions
Vladimir Previn Nov 1, 2017 5:50 PM
the extent of RSA not having their things together on the matter is simply astonishing to me winevent_nic 209,210 continued releases with faults for 2 weeks.
Like • Show 0 Likes0
Actions

Incoming Links

winevent_nic 209,210 continued releases with faults for 2 weeks.

device parser content releases need more transparency

Outcomes

Related Content

Recommended Content

Incoming Links