UDS development in RSA SA

[RSAAdmin]

Hi Folks,

This is the first time I am trying to develop an UDS for Trend Micro Vulnerability protection manager device

Steps which I followed are

1. Developing the parser using ESI tool

2.Extracting the ESI package to devicename.ini and devicenamemsg.xml files

3. Uploading the files to /etc/netwitness/ng/envision/etc/devices of log decoder

4.Adding key description for the key to index-concentrator-custom.xml file

5.Editing the table-map-custom.xml to change the variable and to add entries that do not exist in the file.

Do I need to follow any other step?

Also I have doubts in editing index file and the table-map file.

Can anyone help me on this?

Thanks,

Ajay

[Anonymous · Accepted solution]

That's pretty much what we're doing.

You will need to reload the parsers, either by restarting the decoder, or preferably by using the /decoder/parsers reload command via NwConsole/REST screens.  This will re-read table-map-custom.xml as well.  You'll need to restart the concentrator to get it to re-read index-concentrator-custom.xml
.

table-map-custom entries are generally of the format:

<mapping envisionName="sport" nwName="ip.srcport" flags="None" format="UInt16" envisionDisplayName="SourcePort|LocalPort|ServerPort", nulltokens="-|(null)" />

envisionName is the field the parser populates, and nwName is the meta key it's mapped to.

flags=None is the usual specification.  If you specify flags="Transient" then the meta is available to decoder app rules but is not saved.

I've not figured out the significance of the envisionDisplayName field.

nulltokens is useful for some meta values - any of the options in here will be not be stored. 

One of the biggest limitations of the ESI tool is that it requires you to remain within the EnVision table limitations which no longer apply in SA.   I'm hopeful of an SA-specific tool being available soon.

[RSAAdmin]

Hi AndyCunningham,

Thanks for the information. Also I have got some idea about the parsers in RSA SA.

The sample log looks like this :

Aug 12 16:39:50 server16 CEF:0|Trend Micro|Vulnerability Protection Manager|2.0.4618|610|User Session Validated|3|src=10.172.2.146 suser=System target=admin msg=IP: 10.173.0.3

In the above message I have made 610 as Message ID will there be any problem or should I use any other field as Msg ID?

[Anonymous]

That looks like CEF - if you're using 10.4 or later, can you just use the CEF parser?

610 does look like a good candidate for the message ID but I'd need to see a larger selection of logs to be sure.

[RSAAdmin]

I have attached the logs. In my parser I have made 610 as message ID. Where can I get CEF parser?

[Anonymous]

Hi Ajay@123,

you can download CEF parser from Live -> Keywords: CEF, Type: RSA Log Device.

And 610 really looks like message ID so I think, that you can use that if CEF parser will not work.

And don't forget to add 2.0 to parameter device in xml which you've created.

(

<VERSION

  xml="1"

  checksum=""

  revision="0"

  enVision=""

  device="2.0"/>

)

[RSAAdmin]

Thanks @DavidB12.

I will check this and will let you know about the progress.

[RSAAdmin]

Hi David,

The metas generated by the parser are:

time=

size=216

device.ip=

device.type=trend_micro_vulnerability_protection_manager

alias.host=server16

msg.id=610

event.desc="User Session Validated"

ip.src=10.x.x.x

user.dst=System

host.dst="admin"

How can I change device.type=trend_micro_vulnerability_protection_manager to something like tm_vpm so that it would be easier while creating use cases

[Anonymous]

I think you might be able to do it by adding to the Vendor2Device fields at the end of the cef.xml file, but we're waaaay into the realms of unsupported modifications.

I'd stick with the long name if I were you.

[RSAAdmin]

Thanks