[Oisf-devel] Sensor ID in Unified2 Output

[Gionet, Jake]

Created as issue number 667.
https://redmine.openinfosecfoundation.org/issues/667


Thanks,
Jake


-----Original Message-----
From: oisf-devel-bounces at openinfosecfoundation.org [mailto:oisf-devel-bounces at openinfosecfoundation.org] On Behalf Of Victor Julien
Sent: Friday, December 07, 2012 3:16 AM
To: oisf-devel at openinfosecfoundation.org
Subject: Re: [Oisf-devel] Sensor ID in Unified2 Output

On 12/06/2012 05:35 PM, Gionet, Jake wrote:
> I'm basing this suggestion off of the link below, which seems to be 
> the most authoritative source of documentation for the Unified2 format 
> that I could find.
> 
> http://manual.snort.org/node44.html
> 
>  
> 
> Based on section 5.3.8 of the document above, the "Sensor ID" field in
> Unified2 alerts is completely unused.  It appears that Suricata 
> hardcodes this value to zero from looking at alert-unified2-alert.c 
> (line 361).
> 
>  
> 
> Would it be possible to populate this value via the configuration file? 
> In environments where there are many sensors logging to a central 
> logging device (i.e. enterprise deployment, SIEM logging, etc.) in
> Unified2 format, this would make it easier to distinguish what sensor 
> an alert came from.
> 
>  
> 
> In the event that this field is put into use sometime in the future, 
> the change could be backed out, as I assume it would be a relatively 
> simple change.

Sure, can you open a feature ticket for this?

> 
> -----Message Disclaimer-----
> 
> This e-mail message is intended only for the use of the individual or 
> entity to which it is addressed, and may contain information that is 
> privileged, confidential and exempt from disclosure under applicable 
> law. If you are not the intended recipient, any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this communication in error, please notify us 
> immediately by reply email to Connect at principal.com and delete or 
> destroy all copies of the original message and attachments thereto.
> Email sent to or from the Principal Financial Group or any of its 
> member companies may be retained as required by law or regulation.
> 
> Nothing in this message is intended to constitute an Electronic 
> signature for purposes of the Uniform Electronic Transactions Act 
> (UETA) or the Electronic Signatures in Global and National Commerce 
> Act
> ("E-Sign") unless a specific statement to the contrary is included in 
> this message.
> 
> While this communication may be used to promote or market a 
> transaction or an idea that is discussed in the publication, it is 
> intended to provide general information about the subject matter 
> covered and is provided with the understanding that The Principal is 
> not rendering legal, accounting, or tax advice. It is not a marketed 
> opinion and may not be used to avoid penalties under the Internal 
> Revenue Code. You should consult with appropriate counsel or other 
> advisors on all matters pertaining to legal, tax, or accounting obligations and requirements.
> (HT0512)
> 


This disclaimer is rather excessive for a mailing list. Besides, it doesn't make any sense to append it to a public message.


--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------

_______________________________________________
Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
Site: http://suricata-ids.org | Participate: http://suricata-ids.org/participate/
List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
Redmine: https://redmine.openinfosecfoundation.org/