Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

Enforce User/Role Setup Inadequate

Created: 15 Jul 2010 | 7 comments

I am trying to setup profiles for users to remediate incidents and I want to restrict them to

A) Policies they are responsible for OR
B) Incidents caused by users in their business unit OR
C) Scans of their file shares

The way the role criteria work I can do all three - but I have to create three separate roles because the criteria are all "AND". There is no option to "OR" them. If I put them all on the same role then they don't see anything beacuse no incidents match all three criteria.

However if I give multiple roles to a user they then have to include a role in the login if they want anything other than the default role.

This all feels really clunky. Why can't the use jsut have all the privileges of their roles combined when they log on? Or even have the facility to switch roles while logged on would be better.

Am I the only person wh feel that the Enforce User/Role setup could do with some improvement?

Comments 7 CommentsJump to latest comment

Naor Penso's picture

I do not know of a product that does not need improvements, If you know of such a prefect product please share smiley.
About the Roles, the Idea is that a user has only one role, and if he has more than one than the most restrict role would be the default.
These steps where taken with security concept kept in mind.
I do understand that there is a need to combine And/Or methodology in the definition of the role, and it would be best if you request a "feature enhancement" in that matter.
For now, I can think of a solution for you. In the response rule of the policies add an attribute such as: "assigned to :X"
in the Role management, ask to show only incidents that has the custom attribute "Assigned to:X"
That way you could show all of the incidents you wish, and the And/Or methodology would be transferred from the Role management to the policy/response management.

Kind Regards,
Naor Penso

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.
Thanks :)

Paul Berridge's picture

I like the idea of setting a custom attribute but I can't see how to set it based on a Business Unit.

I can create a new attribute - this is fine.
I can grant a role access to certain values of this attribute.

Now I want to set the attribute automatically if either of the two conditions are hit:

1) A policy their group is responsible is hit ( I can set the response rule for this)


2) A general policy is hit by someone in their business unit. (I can't do this because the only available response rule conditions are endpoint location, incident type, incident match count, protocol or endpoint destination, severity)

I agree that every software product ever written has flaws, and actually it's better for Vontu to have spent their development dollars on the detection engine rather than the UI. Hopefully this will evolve and mature if Symantec look after the product properly, because I think it is worth it.

Incidentally I have a separate problem with roles, any role that I add a Business Unit condition on cannot actually look at indicent details. It gets an error. I have a case open with Symantec on this but they don't seem to know how to fix it.

Would I be better off upgrading to 10.5 or 11.0?

Dan Tanna's picture

We have the same issue with Vontu.  I needed to be able to set up a DLP program in another country and the problem was that I could not set them up to run a DLP without seeing our data and Incidents in the US.  I had to restrict them from Server and User access but they can set up their own scans, create policies, as well as see thier Incidents. 

Dan Tanna's picture

Also, the whole multiple roles is not beneficial to us.  When we grant access to Vontu it is because the person now has it installed at their location and need to work the Incidents.  It never made sense to force multiple roles for a single person because if they can see any Incidents why force a log off and back on with another profile?  That makes no sense to me and it takes more time to get the work done.

Naor Penso's picture

This way, incidents gathered on the detection server in the US wont be shown to other users from other locations.

Kind Regards,
Naor Penso

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.
Thanks :)

Dan Tanna's picture

Yes, and thank you, the problem is that I am the Corp DLP who oversees the other areas so I need to see what they are monitoring.

Sidecar's picture

Not sure how practical this would be for others, but my company has an employee database that contains attributes such as email address, name, net username, business unit, division, country, etc. When an incident is created, automated lookup populates the attributes for the traffic sender. (We're only using these lookups for outbound traffic.)

We then create roles to limit access according to these attributes, in conjunction with policy groups and other criteria. There are a few roles, but each user only has one, and it has worked pretty well so far.

Policy management for a particular role (that has that capability at all) is limited by pre-defined policy group(s).

"Or" logic and grouping would be a nice enhancement...