Set record-level permissions in the Security Incident application

[Alex Litvak]

In the Security Incidents application. I’m looking for a technique on how to restrict access to the records. A user who is currently login can see and edit only records that he assigned to.

[andy_ojha]

Hey there,

Though this can certainly be achieved a number of ways with ServiceNow Platform features (ACLs) or SecOps features (Security Tags) - it will lead to some wrinkles with the day-to-day process, user adoption, user friction - and will result in technical debt for you to own...

• Just curious - why?
• What is the reason to restrict the SIR Analyst from seeing Security Incidents not assigned to them?

This is one of those -> "just because you can, should you..." scenarios.

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

As a Security Analyst working in a SOC and performing investigations -- one of the very first activities when triaging is asking "have we seen this before, if we have, what did we find, what did do about it, what was the outcome", etc...

• Restricting the SIR Analyst from seeing Security Incidents not assigned to them will remove this 
• This will severely hinder their ability to perform that first step in the triage process (have we seen this before, how many times, any patterns, what did we do) -- so that they can formulate a plan for the current Security Incident at hand 

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

Have we thought about:

1. Do we really need to restrict the SIR Analyst from all Security Incidents they are not assigned to, across the board?  Or, is the need really for a subset of Security Incidents, perhaps ones deemed more sensitive than others?
2. How will we account for the inability for Security Analyst's to effectively triage and do "lookbacks" to review similar Security Incidents (is this the first time this has happened, what happened last time, etc)?   
3. We essentially are removing their ability to correlate with previous Security Incidents and now must treat everything as net new - which certainly will impact investigations, accurate impact assessments and will lead to Analyst frustration and lead to friction and efficiency concerns 
4. How are we going to handle the Security Analyst user experience?  Baseline, the left navigation, reports, dashboards, workspace elements are all geared around the Analyst viewing Security Incidents across the board - now that you pull this back and restrict it - what is the plan?  Are we going to turn off baseline features and have to re-create them to avoid confusion - i.e. "hey I clicked this shortcut to see Security Incidents and I am receiving a message about Security Constraints preventing accessing"...

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

Would certainly recommend re-visiting your use-case and evaluate if this this the right approach - would share from experience, that this not only will have some technical debt for you, but will cause friction in your process.

That said - you could look at creating new ACLs and potentially maybe some new left nav modules and reports.

You might also look at restricting a subset of Security Incidents based on "need to know permissions" -> look into the Security Tags (Traffic Light Protocol - TLP) :

• https://docs.servicenow.com/bundle/vancouver-security-management/page/product/security-operations-co...

[Alex Litvak]

Hello,

 We want to restrict the SIR Analyst from seeing Security Incidents not assigned to them to accommodate requirements for the Forensics team. Those tickets have confidential information and should not be shared even across the same team. Please let me know how to adjust this in the SIR module without much work.

Thanks

[andy_ojha]

Hey there - that is some key info...

Repeating that back --> as a member of the Forensics Team - read/write access to the Security Incident should be restricted to the currently Assigned person?  Their Team member, that is also in the Forensics group, should not be allowed to read/update the Security Incident?

If that is the case - the Security Tag / Enforced Access wont work, as this limits access to a record based on role - rather than the Assigned to...

This would involve some surgery with ACLs, and maybe even custom roles.

[Alex Litvak]

Hello,

To utilize the “Enforce restriction” check box, the user must have the “sn_si.admin” role. Do you know which role could be assigned to the user to have the same privilege to the “Enforce restriction” check box but lover then admin? There are 12 roles inside of the admin.

Thanks