[DISCUSS] Multitenancy for Metron

[James Sirota <js...@hortonworks.com>]

Hi Guys,

As a community we probably need to tackle the question of how we handle multi tenancy with Metron and John is already starting to ask the right questions.  I wanted to open this up for a community discussion.  What does multi tenancy mean to you and ideally how would you like Metron to address this feature?  I filed METRON-105 to capture the proposed architecture and features that come out of this discussion thread.

Thanks,
James

Re: [DISCUSS] Multitenancy for Metron

[James Sirota <js...@hortonworks.com>]

Hi Jon,

Metron addresses pulling information into a common db with a concept of enrichment.  Think of it like pivot tables in excel.  We have the data loaders project which is an extensible framework dedicated to staging various sources of data into Hbase.  We also support polling and bulk loading the data to keep it current as well as aging it out.  Conceptually to meet the use case you are talking about you would setup a user enrichment (data from LDAP), hosts enrichment (data from asset db)., etc., and enrich the messages in real time with this information.  So you get a running 360 degree view of your data as it’s streaming through your system.  We do this for a variety of reasons (mainly ML), but you can benefit from this feature by having everything enriched in-line.  This way you don’t have to pull your data into a SQL DB and run joins over it.  Everything is already done for you in real time.  Further more, you get the advantage of real time because IPs tend to change with time, users log on and off systems, etc., so you want to capture this information as the event is occurring to maximize the accuracy.  This is what Metron gives you.

Thanks,
James  




On 4/10/16, 3:55 PM, "Zeolla@GMail.com" <ze...@gmail.com> wrote:

>Lurker here (hi!).  I'm also a potential user of metron in the near future
>(hence the lurking), but I've been waiting for the right features to make
>it worth the move, and one of those is multi-tenancy.
>
>My comments:
>To me, this primarily means a UI with strong access control/RBAC to the
>data, access based enumeration (no broken counts when viewing reports,
>filters, etc.), and dashboarding (more of a nice to have - just about
>everyone I with with just wants the data, not a visualization).
>
>For this to really work for me, it would need a way to frequently pull
>information into either a local or remote db (combination of host scanning,
>network monitoring, and a formal asset db information), and the ability to
>map roles (via LDAP groups) to groups of assets (db).  This is something
>I've been looking to do for a while, but even most mainstream SIEM vendors
>fail to do it well, if at all.
>
>I work as a security engineer at a very open college, so In order to entice
>people to send me their data (network taps, syslog, etc.) I need to give
>them something in return.  Depending on the situation, I'm effectively
>either functioning as an MSSP or an ISP.  In the situation where I'm trying
>to get additional data, what I provide back to my customers would be access
>to the information they sent me, post processing (Bro log, pcap, etc.
>access).  Of course, this is very sensitive stuff, highly
>compartmentalized, and somewhat dynamic (subnets fluctuate on a weekly
>basis), so it needs to be server side access control.
>
>Happy to discuss further,
>
>Jon
>
>On Sun, Apr 10, 2016, 18:30 James Sirota <js...@hortonworks.com> wrote:
>
>> Hi Guys,
>>
>> As a community we probably need to tackle the question of how we handle
>> multi tenancy with Metron and John is already starting to ask the right
>> questions.  I wanted to open this up for a community discussion.  What does
>> multi tenancy mean to you and ideally how would you like Metron to address
>> this feature?  I filed METRON-105 to capture the proposed architecture and
>> features that come out of this discussion thread.
>>
>> Thanks,
>> James
>>
>-- 
>
>Jon

Re: [DISCUSS] Multitenancy for Metron

["Zeolla@GMail.com" <ze...@gmail.com>]

Lurker here (hi!).  I'm also a potential user of metron in the near future
(hence the lurking), but I've been waiting for the right features to make
it worth the move, and one of those is multi-tenancy.

My comments:
To me, this primarily means a UI with strong access control/RBAC to the
data, access based enumeration (no broken counts when viewing reports,
filters, etc.), and dashboarding (more of a nice to have - just about
everyone I with with just wants the data, not a visualization).

For this to really work for me, it would need a way to frequently pull
information into either a local or remote db (combination of host scanning,
network monitoring, and a formal asset db information), and the ability to
map roles (via LDAP groups) to groups of assets (db).  This is something
I've been looking to do for a while, but even most mainstream SIEM vendors
fail to do it well, if at all.

I work as a security engineer at a very open college, so In order to entice
people to send me their data (network taps, syslog, etc.) I need to give
them something in return.  Depending on the situation, I'm effectively
either functioning as an MSSP or an ISP.  In the situation where I'm trying
to get additional data, what I provide back to my customers would be access
to the information they sent me, post processing (Bro log, pcap, etc.
access).  Of course, this is very sensitive stuff, highly
compartmentalized, and somewhat dynamic (subnets fluctuate on a weekly
basis), so it needs to be server side access control.

Happy to discuss further,

Jon

On Sun, Apr 10, 2016, 18:30 James Sirota <js...@hortonworks.com> wrote:

> Hi Guys,
>
> As a community we probably need to tackle the question of how we handle
> multi tenancy with Metron and John is already starting to ask the right
> questions.  I wanted to open this up for a community discussion.  What does
> multi tenancy mean to you and ideally how would you like Metron to address
> this feature?  I filed METRON-105 to capture the proposed architecture and
> features that come out of this discussion thread.
>
> Thanks,
> James
>
-- 

Jon