ESM roles

[binkie_jhs1]

All,

I'm tasked with putting down some roles for use in ESM. Trying to get rbac implemented properly.
My question to you is, which roles for users have you defined in your ESM environment? And what permission have you given to them?

We would like to get rid of (most of) all the admins.

Off course there is the

'Administrator' - Can do everything (does that makes them dangerous?)
'Author' - 'Do stuff' with Resources (Rules, Lists, Filters, Dashboards, Cases/Queries, KBs, Reports, Views) Also know as 'Analyzer Administrator'
'Operator' - analyze events, acknowledge notifications, view reports, case and KBs

And from the 101 guide:
'Analyst' - About the same as the 'Operator'
'Business User' - Review reports, dashboard, notifications and cases. Can be a 'Web usage only' user
'Super User' - Wears shirt with big S on the chest, same powers as 'Author'

Do you actually use these roles?

Have you defined any other roles, and are they being used?

I suspect having users who can only view (specific) reports is an other role. Have you delegated the adding of Connectors?

Lots of questions, but really would like to know how others have approached this issue.

thanks, jhs

[chrisb1]

I don't really use the built-in roles because I like to start off with a tight ACL and loosen it up as access to the data is needed.

I have a few roles that are in place or being put in place once the content is completed to support them:

Intel Admin - Only access to Wintel server logs

Unix Admin - Only access to Unix server logs

DBA - only access to DB servers and DB logs

Exchange Admin - Only access to email traffic and logs of email servers

Risk & Invenstigations - Only access to login/logout data, web traffic, and email traffic

Compliance & Privacy - Only access to medical record logs

Each of these roles has content I've created for them to support the bulk of their workload, but obviously they are welcome to create their own, except for trends and data monitors.  They are only able to see the content from within their role in the specific folders.

As far as creating connectors go, I'm the only person who does it .

[a2g]

I like to start off inexperienced customer administrators with 'Operator/Analyst'. It lets them see everything and only contribute to Public.

Once the team is defined I typically end up creating custom groups based on what they need; it ends up being different every time.

A.

[DBurr1]

Do you use filters to restrict certain users access to certain data? We function in a model similar to an MSSP and I'm having an issue with a filter applied to restrict users from one group to seeing only their data (based on customerURI set at the connector). The filter works for data they create in active channels and the like but when they view stock content like dashboards they see all the data from all the groups. When they drill down they see only the data that pertains to them but that drill down data will only be subset of the data they see in the dashboard. I don't have to create seperate dashboards for each group, do I? Thanks

[a2g]

Basically, yes, you do have to create different Data Monitors and Dashboards if you want to restrict the results for users.  The reason is that user event  Filters restrict results returned by the user's query, but Data Monitors run independent of that.  So when a user pulls up a Dashboard, it contains results that have been collected independent of the viewer.  Data Monitor will gather statistics even if it's never viewed. 

[binkie_jhs1]

Thanks all,

I'll start of by creating a separate root group, define some high level groups (ArcSight defaults & like chrisb suggested.) As more granular access is needed, I'll add sub groups. I hope this will give me a proper framework for future deployments. Easily extendible by adding the (Business specific) sub groups.

Now I need to create myself a good format to document these settings. Using the 'ACLReportGen.sh' script will show about 150 rows with ACL's, expanding that a bit to include the customer. That's a lot of ACL's to put down & than even add the customer specifics.

cheers, jhs

[Conficker]

I think the "Different every time'' comment to be very accurate. No two SOC's are the same and neither are the roles and responsibilities, contained within them, try as you might it is difficult to pigeon hole users into specific roles and constraints. Starting this way also highlighted the hard core users from the pretenders. As such a settled user base resulted.