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 <jsir...@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
