Security incident response

[Community Alums]

Created one new custom role and created new Read ACL and added role 
Gave role to a user impersonated user not able to view sir record.

[andy_ojha]

Hey there,

A number of moving parts could be factoring in here - competing ACLs, our testing approach, etc.

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

#1  - What's the use-case that you are trying to solve for?
   --> Why stray away from the baseline SIR user roles that are provided today:
    - {sn_si.read}
    - {sn_si.analyst}
    - {sn_si.write}
    - n

What are we trying to achieve with that new custom task role - that can't be acheived using one of the baseline roles within SecOps SIR today?

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

#2  - How are you testing this?
   - Have you explicitly assigned this role to a user, and are interactively logging with that user account (not impersonating)?
  - Are you impersonating?

  - Are you copying and pasting a URL for a given SIR record?

 - How many SIR records actually exist today on the instance (at least 1 or more)?

 - What happens when you nav to `sn_si_incident.list`?
   --> Do records show up at all?
   --> Are records showing up, but some columns are blank on the records?

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

#3  - Those 2 <read> ACLs are not going to be enough to see the fields on the SIR Table 
   - The SIR table <sn_si_incident> has many more field level ACLs that need to similarly be accounted for
     - e.g. Number, Short Description, Description, etc.

[Community Alums]

1. What's the use-case that you are trying to solve for?

We created new role for user to work only on response task for that response task parent sir record should be visible and read only

2. How are you testing this? 

Impersonating that user

Are you copying and pasting a URL for a given SIR record?

No assigned one Response Task from that response task I will open parent sir record but no fields is visible

When i open record:

3.How many SIR records actually exist today on the instance (at least 1 or more)? 

More than 100 Records available

4.What happens when you nav to `sn_si_incident.list`?

records showing up, but some columns are blank on the records.

5.Those 2 <read> ACLs are not going to be enough to see the fields on the SIR Table 

Created new ACL with star is enough to see all fields?

[andy_ojha]

Hey there - that explanation helps clarify.

Unfortunately - those two read ACLs will not be enough.   

If you review the ACLs on the <sn_si_incident> table, there are a bunch of field level ACLs that you are fighting with now; which are evaluating to false - for example 'sn_si_incident.number', 'sn_si_incident.short_description'.

Another thought or approach you can look at, is using the 'Read access' |  <special_access_read> field on the Security Incident, to store the individual users themselves that require "read-only" access to the Security Incident.

Reference:
"When deciding whether to grant or deny access, the ACL is searched from the most specific to the most generic match"
- https://developer.servicenow.com/dev.do#!/learn/learning-plans/utah/new_to_servicenow/app_store_lear...

[Community Alums]

1. Another thought or approach you can look at, is using the 'Read access' |  <special_access_read> field on the Security Incident, to store the individual users themselves that require "read-only" access to the Security Incident?

Read access I know about it but every time a response ticket assigned I have to come and add user manual in Read access field. is there any work around other than this?

2.If you review the ACLs on the <sn_si_incident> table, there are a bunch of field level ACLs that you are fighting with now; which are evaluating to false - for example 'sn_si_incident.number', 'sn_si_incident.short_description'.

This ACL I created with star(*) is that not enough for all fields?