Balancing Act: Navigating the Advantages and Risks of ServiceNow’s New Security Attributes

One of the security milestones of the Vancouver Release of the ServiceNow platform is the introduction of a new form of access control check, Security Attributes (or ‘SA’s). These security attributes can be considered re-usable code-based checks that can be attached to ACLs. In some cases, they could even be used to entirely replace ACL scripts.  

This feature is great at enabling a DRY (‘Don’t repeat yourself’) methodology for security configurations – but with such an impactful feature, attention is required to ensure that it does not cause wide-reaching misconfiguration instead. This article will discuss the security implications of this feature and conclude with some recommendations for organizations seeking to migrate to Security Attributes in a secure manner.

Attribute Checks

Regular Access Controls had three (now four!) methods to perform validation within. Security Attributes have two. These are:

1. Scripted Check: Code-based checks written in Javascript, similar to that of the script on ACLs.
2. Lookup Check: Evaluate access based on an external lookup for a single field in a single table

As of now, I would not recommend creating Security Attributes that utilize a lookup check. How lookup fields actually function isn’t elaborated on within any official documentation. Additionally, out-of-the-box (OOB) Security Attributes that are marked as ‘system’ which contain lookup checks have their actual logic hidden from the end user. If you were to create an exact replica of these system checks and attach them to an ACL, there is a high chance that they would not function in the same manner. 

A limitation of the scripted check specifically is the inability to access the current object, something which ACL scripts and conditions do have access to. So to put it bluntly, attempting to implement record-level security based on the individual contents of a record cannot be done with Security Attributes.

Attribute Types

Just like all good programming methods and functions, Security Attributes will always have a return value as a result of the validation they perform. These can be one of the following:

• String
• Boolean
• Integer
• List
• Compound

Within an ACL, administrators can define what the expected return value for these types should be. In most cases, Security Attributes will be of a boolean (true/false) type. However there are applicable cases for using alternative types. A very basic example could be a Security Attribute (‘GetDepartmentID’) that returns the requesting user’s department via something like this in the script field:

answer = gs.getDepartmentID();

Within the ACL you could create the following Security Attribute condition to validate that the user’s department is HR:

GetDepartmentID – is – <HR Department ID>

The odd one out within this list is the compound type. A compound Security Attribute contains no script or condition defined on itself but rather acts as a parent Security Attribute can contain multiple child Security Attributes. In other words, it is composed of one or more already defined Security Attributes. Using a compound type allows multiple Security Attributes to be chained together using conditional operators such as OR (||) and AND (&&) among others.

Local vs Existing

One of the fields on an Security Attribute is the Is localized field. This isn’t a field that is defined by a user but rather defined by the platform automatically when a Security Attribute is set on an ACL. Below is where one would set a Security Attribute on an ACL record:

In the above example, ‘TestGroup’ is a Security Attribute of type ‘true/false’. Since it is not compound in nature, or defined as part of any other compound Security Attribute, it can only be selected under Local. Once this ACL is saved, the platform will automatically created a corresponding compound Security Attribute, as seen below:

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:

Let me elaborate on the above diagram by introducing two scenarios in which two user(s) attempt to access a resource under different circumstances. Assume there is an ND Security Attribute that validates if a user has been directly granted a given role:

1. User with the appropriate role authenticates to the platform and is granted a session
2. User accesses this data, Security Attribute is checked, data is returned
3. User’s role is removed from them, but they maintain an active session
4. User accesses this data, Security Attribute is not checked, data is returned

1. User without the appropriate role authenticates to the platform and is granted a session
2. User accesses this data, Security Attribute is checked, data is not returned
3. User is accidentally granted the required role, they still possess the same session
4. User accesses this data, Security Attribute is checked, data is returned
5. User has their role removed
6. User accesses this data, Security Attribute is not checked, data is returned

I feel that the result of both scenarios, but in particular the second, are problematic enough to incentivize opting for Dynamic Security Attributes instead.

Third-Party (OAuth) Integrations: Sessions are the new Access Token

With respect to ServiceNow, access token lifetime has typically been seen as the session equivalent for integration users, from a security perspective. But under the hood, that’s not really the case. In fact, integration users have the same session implementation as users, the JSESSIONID cookie. 

Until this point, integration users having a JSESSIONID has not been pertinent to anything security-wise outside of threat detection and is often entirely overlooked. But with the introduction of ND Security Attributes, session management for integration users is something that requires immediate attention even more so than for UI users. I say this because many integrations are nearly always ‘active’ as they are routinely pulling or pushing data to the platform. This is exacerbated further by the default ‘infinite’ lifetime duration for active sessions that many organizations still possess. 

Before you get any preconceived notions on how this risk could be reduced using familiar access management techniques that are typical to OAuth integrations, here are some hard security truths:

• Reducing the TTL of an access token does not reduce the TTL of the session, they are configured in separate places.
• Getting a fresh access token via a refresh token does not invalidate the integration user’s session. So revoking an access token in the hopes of ‘invalidating a session’ will not work.
• Most organizations do not block Basic Authentication for platform APIs. Integrations which also have their refresh token revoked can simply revert to leveraging basic authentication with their session to maintain the same level of access as before.

At this point, you’d probably be justified in wanting to temporarily lock-out the integration user to invalidate their session, and for isolated cases this isn’t the worst option. The other being modifying the ACL in some manner, an action that could negatively impact other users on the system. 

Conclusion

Security Attributes are a fresh concept and likely the first addition in a new wave of reusable access controls. As of this moment, they cannot be considered a total replacement for ACL conditions or scripts since organizations are still required to maintain their ACL conditions and scripts to implement record-level security.

From a security perspective, I’m not enthused with the introduction of per-session security with a lack of extensive documentation on the inherent risks of using it. Never neglect security fundamentals and their importance, such as session duration. Somewhere along the way, it seemed to have lost its credence among security practitioners. But as we see time and time again, good session security hygiene will always hold its weight as part of strong baseline security controls. It’s just time for us to recognize and systematically practice it.

Following these best practices is one thing, but maintaining them is another. Session-related controls only consist of a small handful among hundreds of others controls that are impacting security. With new access control features comes the burden of management. For a small team, this can be a herculean task. But what if it was all consolidated into a single pane of glass? It would make life managing it all much easier. This is exactly what AppOmni does day-in and day-out for the leading enterprises in the world. Providing an eagle-eye view of all their access controls, continuous monitoring of settings and modifications, and research-based scans (created off the back of articles such as this one!), it’s no wonder that over 20% of the Fortune 100 use AppOmni’s SaaS Security Platform as their SSPM of choice, and so should you.

---

---

Related Resources