Hello,
In my company's SIEM, there is a significant amount of traffic with service type = OTHER.
What is the significance of all this traffic? Is there a way to correctly link device ips to the correct service type? I tried following this documentation (Decoder: Map IP Address to Service Type ), but it doesn't seem to work properly.
Any advice or help is greatly appreciated!
Thank you.
Lucas,
The link you shared is specifically for Log Decoder -> Parser mapping and would not be applicable to Packet (Network) Decoder.
The Service Type = OTHER falls into 2 categories:
1. Datasets for which RSA has deemed uninteresting traffic (for the most part, forensically) and does not parse it.
2. Datasets for which is custom or unique to your environment that we have no parser support for it.
In either case, the process would be to take sample PCAPs of that traffic, analyze it and write a parser if required. For example, we (RSA) do not have an official Spotify parser for example but several community members have written them and can be used on an as-is basis. You can also write custom parsers -- see link below.
Hi Naushad,
Thank you for the quick response. I'll read through the documentation you provided.
Cheers!
Lucas,
As an addition to what Naushad has said. There is another time you can see the Service = Other thought it fits in with one of Naushad's examples. This is usually when a session is larger than can fit into the decoder's assembler buffer, either by time or size. As an example, lets say you were downloading a 1GB file from the internet. The decoder would pickup the download request and the file would start to download to the end user. The decoder won't be able to contain the entire 1GB file in the assembler/parser memory. So the decoder, in an effort to be as efficient as possible, will only hold about 30MB or 30 seconds of this session at a time, whichever happens first. It will then run the parsers over it and it will see that it was a HTTP file download. It will generate all the meta and interesting stuff and write it to disk. However the file itself is still downloading. So the decoder creates a new synthetic (split) session for the remainder of the download. In this case several split sessions due to the file size. As the initial headers were in the first part of the session there is nothing at the beginning of this new split session that identifies what it is. No HTTP headers or anything of that nature, only the basic source/destination IP address and ports generally. The decoder denotes these split sessions as Service = Other since it doesn't have the beginning tags that the first part of the full download session had and the decoder can't identify what the session is. Later versions of Netwitness are able to show on the first session all the the split session meta so you can see when this artificial split happens and you have all your data in one place.
As you can see this falls under what Naushad called "uninteresting traffic" for the decoder as there isn't any header information for it to parse.
I hope this helps.
Lucas,
The link you shared is specifically for Log Decoder -> Parser mapping and would not be applicable to Packet (Network) Decoder.
The Service Type = OTHER falls into 2 categories:
1. Datasets for which RSA has deemed uninteresting traffic (for the most part, forensically) and does not parse it.
2. Datasets for which is custom or unique to your environment that we have no parser support for it.
In either case, the process would be to take sample PCAPs of that traffic, analyze it and write a parser if required. For example, we (RSA) do not have an official Spotify parser for example but several community members have written them and can be used on an as-is basis. You can also write custom parsers -- see link below.
https://community.rsa.com/docs/DOC-41370