How do security roles work?

[juliesutton]

How do the roles actually work?  I want to use the roles on the security incident form (Read access, Watch list, Privileged access, Work notes list) but only on a case by case basis. 

Do I need to add anyone that might involved in an incident to the sn_si roles first and then only add them to the incident?  Does that prevent them from seeing other incidents unless they are added?

Thanks,

Julie Sutton

[andy_ojha · Accepted solution]

Hey there,

For the scenario and features you mentioned - it's somewhat related to "Security Roles" but not entirely.

The use-case you mentioned, is actually a neat feature built into the Security Incident Response Application.

A Security Analyst can explicitly grant an individual user ad-hoc access to a given Security Incident record (single record at a time), on a case-by-case basis, and at a certain flavour of access (read, write, recieve work note updates, etc.)

• This user being granted ad-hoc access is not an "SIR User" / they do not have any of the SIR Roles assigned to them like (basic, read, analyst, write)

Using this feature, does not require granting a special role to users ahead of time.

All that is required, is to set the explicit user on the Security Incident record, in one of the "Special Access" aka "Privileged Access" fields that you mentioned.

The Security Incident Response Application, will dynamically grant these users a role (based on least privilege), and the Application already has the appropriate Access Control Lists (ACLs) built-in to support this.

Would recommend trying this out in a sub-production instance, and impersonating the "non-Security" person, to see what their experience is like accessing the Security Incidents they've been granted ad-hoc access to.

There's been a few posts on this, where you might find some useful context:

• https://community.servicenow.com/community?id=community_question&sys_id=e4dd62cbdba3a740f0612183ca961963
• https://community.servicenow.com/community?id=community_question&sys_id=d81b06f9db737bc86064eeb5ca9619f8

-----------------------------

Here's a snippet from another post on this:

sn_si.special_access

Using <sn_si.special_access>, there is no need to explicitly assign this <role> to a Group or User ahead of time.

When you navigate to an SIR record, and look at the "special permissions" fields such as `Read access` and `Privileged access` -> by putting a user into these fields, the system will automatically grant them this role.  Then, when that user logs into SN, they have a limited view into the SIR app (even without having any sn_si.* <roles>). 

These users will only be able either 'read' or 'edit' explicit SIR records, where they have been granted access to -> i.e. `Read access` and `Privileged access`.

They will nav to "Security Incident" -> "Incidents" -> "Visible to me"... to see their relevant SIRs.

Reference - sn_si.special_access

[JennyHu]

Hi @./andy-b2poYQ== ,

Is it a best practice to remove individual users from the "Read Access" field once the Security Incident is closed?  What happens if that non security person changes their role and no longer should be reading the security incident?  If we remove users from the "Read Access" field, the sn_si.special_access role still stays with that user.  Do we need to take an extra step to remove the sn_si.special_access role from the user manually or does the system have some automated job to clean up the special access role?  

Thanks!

Jenny

[Prasad Dhumal]

User logins to servicenow and access a record...but before system shows that record to user, it try to find ACL for same object and also try to find mathcing rule.
So whatever object user trying to access, system will first check do i have similar kind of access rule for that object?...if the ans is NO so system did not find any mathcing rule, any ACL for that object then access is granted to the user. That means user can access that record. BUT if match is found that means system found YES, there is mathcing rule in system for that particular object, then it basically evaluates the ACL. means whatever condition it would have in that particular ACL, that will try to evaluate and then it will pass the ACL if user matches those conditions and then user will grant access and if user does not match the conditions then system will not grant access to that user.