metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Elliston Ball <>
Subject Re: Name conventions for parsers
Date Thu, 06 Oct 2016 12:02:13 GMT
> On 6 Oct 2016, at 12:22, Yohann Lepage <> wrote:
> 2016-10-06 12:21 GMT+02:00 <>:
>> I would think that instead we work to make each parser able to handle all
>> the known outputs (and document explicitly what outputs per parser are
>> supported) from a product and go back to vendor_product, with versions of
>> the product supported/tested and version of the parser being stored in code
>> and documentation only.
> +1

+1 - this is similar to the evolving schema problem, and probably belongs in code.

>> I'm currently working on mechanisms to get logs into Metron most
>> efficiently because all of my syslog comes in one big pipe.
> I have a similar use case. Most of the time, admins are ok to forward
> logs from rsyslog/syslog-ng to the SIEM as they don't want to install
> an agent  ( *.* @@siem.intra:514;).
> The result is that you receive a mix of log
> (sudo/apache/mysql/audit/etc) from the same device and the SIEM have
> to deals with it.
> So, it would be really useful that Metron could handle a syslog flow
> and automatically apply the right parser for each log. In order to
> help Metron, a config could be provide by the "Security Platform
> Engineer" to preselect a list of parser per device (as you know what
> type of logs a device  should send).  This feature exists in
> commercial SIEM.

+1 for this too. One question though, do you think it’s viable to do this by device. I would
expect multiple types of syslog coming from the same physical device, especially when dealing
with things like server logs. 

This could be handled with minimal parse and routing in NiFi potentially, but that may make
setup more complex than the sort of mapping you’re talking about here. Thoughts? 

View raw message