As you can see, the Is localized field is selected. Within the first screenshot you may have noticed another radio button labeled Existing. If Existing was selected instead of Local on the ACL, an already present (non-system created) compound Security Attribute can be selected. As a result, no new Security Attribute is created and as a result the Security Attribute in question will not have the Is localized field set.

To put all of this data in a nutshell:

• Local: Select one or more Security Attributes of any type, chaining them together with conditional operators. Upon saving the ACL, a new SA will be created which contains all of the selected checks. These new Security Attributes will be defined with ‘Is localized’ on the SA record, and may not be re-used on other ACLs.
• Existing:  Select a single compound-type Security Attribute to form the base of the check. Additional Security Attributes can be added to the checks by chaining conditional operators within the Security Attribute’s condition field on the ACL. Adding additional Security Attributes will not create a new SA encompassing all the checks performed in the ACL.

Dynamic vs Non-Dynamic (‘ND’) Checks

The most important aspect of a Security Attribute (from a security perspective) is without a doubt the ability to create it as having a dynamic or non-dynamic check, through selecting or deselecting the Is dynamic checkbox. This will massively affect when a security check is performed when a user attempts to access a resource protected by the Security Attribute. 

• Non-Dynamic: The security attribute check must only be satisfied successfully once. Once satisfied, the Security Attribute check is not performed again until the user’s session is invalidated. 
• Dynamic: The security attribute check must be satisfied every time a resource is accessed. This is the default setting.

Oddly enough the inclusion of a once-per-session check is an unfamiliar practice compared to what ServiceNow administrators are used to. Historically, other access control implementations on the platform such as an ACL’s role, condition, or script requirements, and User Criteria, all perform checks on a per-transaction basis. It is likely that this per-session check was introduced with the intention of providing a balance between security and DB performance. 

It would be easy to stop here and simply ask organizations to explicitly leverage dynamic checks alone, but it’s only through understanding the risk of ND Security Attributes that one could justify doing so. Within The Risk of Non-Dynamic Checks section I will elaborate further about the source of these risks along with their potential impact to security.

Immutability and Persistence

One very unique behavior of Security Attributes that is dissimilar to other familiar access controls, is their inability to be modified or even deleted, they can only be marked as inactive. If an organization wishes to revise their controls, they must either directly harden other areas of the ACL further or more realistically, create a new Security Attribute and attach it to the ACL.

My only concern here is hygiene. Over time, this characteristic may result in a clumsy administrator being inundated with months or even years old Security Attributes that have been consistently revised, with each attempt now forever sitting dormant on their platform. To improve the overall management experience, I highly recommend to filter out inactive Security Attributes by default. This can be done by modifying the module link as follows:

1. Click the Edit Module button next to the Security Attribute module in the Application Navigator.
2. Select the Link Type section, and under Filter add Active is True.

Monitoring of Attribute Changes

Lastly, the introduction of Security Attributes also came with a centralized place for organizations to manage the relationships between Security Attributes and the ACLs where they have been defined. This can be accessed through the Security Attribute Audits module which will list the contents of the underlying table that stores these relationships, v_security_attribute_audit.

At this time, the primary reason one would scrutinize this data and become familiar with its format, instead of simply filtering on the ACL itself, is because:

• It includes the date that the Security Attribute was associated with the ACL, which the ACL view does not.
• The existence of a Table Name field suggests that other access-control elements may utilize Security Attributes in the future. In which case having a centralized location for monitoring makes complete sense.
• It’s faster to load Security Attributes alone than it is to load ACLs, as there will likely always be less.

The Risk of Non-Dynamic Checks

Note that everything in the following subsections are exclusive to the ‘per-session’ or ‘non-dynamic’ (‘ND’) Security Attributes. These terms are used interchangeably throughout.

Because non-dynamic checks only require that a security attribute check is satisfied successfully once — rather than every time a resource is accessed — they introduce unique security considerations. 

Let’s walk through security concerns relating to non-dynamic checks, and discuss how organizations can properly set up Security Attributes to avoid risks such as widespread misconfigurations.

Active Session Durations Default to Lifetime

This is less so a risk of ND Security Attributes themselves but moreso a combination of their behavior alongside system defaults. More specifically, the default active session lifetime. As per the ServiceNow documentation, active sessions do not have a maximum duration. This can be verified by deploying a new Developer instance and observing the value of the following system properties is set to 0 (infinite lifetime):

• glide.ui.active.session.life_span: Dictates active session duration for authenticated users
• glide.guest.active.session.life_span: Dictates active session duration for unauthenticated users

Prior to Security Attributes, active session duration was really a hardening mechanism to mitigate damage done as a result of a compromised session. But with the introduction of ND Security Attributes, I see a sensible active session duration as even more of a first-class citizen in your security arsenal as it is one of the only defensive techniques in your arsenal that can passively mitigate unintended access granted by ND Security Attributes specifically.

Now that you’re aware of the insecure defaults for active session duration, you will understand that your platform’s session duration value will set the tone for how catastrophic the possible risks discussed in the following sections are, if at all. 

Success and Failure are not Equal Citizens

One would imagine that if per-session checks claim to be ‘evaluated per session’, then a user failing to pass the Security Attribute a single time in the current session will result in continuous denied access for the remainder of that specific session. This would be a fair assumption considering that in the inverse case, a user successfully passing the Security Attribute once will result in them being granted access for the remainder of that specific session regardless of them no longer passing the Security Attribute checks.

Except, that assumption would be wrong. These per-session checks do not view granting access and denying access as equal. In fact, the term ‘per-session’ only really applies after a user has successfully been granted access. In reality it is actually a per-transaction check until a point in which access has been granted. The diagram below will help visualize this logic: