ServiceNow Security Best Practices: Importance of Securing Your ServiceNow Instance
As ServiceNow becomes integral to managing organizational workflows and data, securing the platform is critical. It supports sensitive operations, and a security breach can have widespread implications. Ensuring robust security protects data integrity, preserves user trust, and maintains compliance with regulatory standards.
The Increasing Need for Strong Security Posture
The demand for robust security in ServiceNow has grown due to:
Data Sensitivity: ServiceNow instances often store highly sensitive information, such as employee details, financial data, and operational records. Unauthorized access to this data could result in significant legal, financial, and reputational damage.
Integration with Other Systems: As ServiceNow integrates with multiple third-party systems (e.g., HR, ERP, CRM), it becomes a critical hub within an organization's digital ecosystem. Securing these connections is essential to prevent attackers from exploiting the integration points.
Regulatory Compliance: Organizations must comply with various data protection regulations like GDPR, HIPAA, and SOX, which mandate stringent security controls. Implementing best practices in ServiceNow can help ensure compliance and avoid penalties.
Evolving Threat Landscape: The complexity and frequency of cyber-attacks are increasing. Attackers continuously look for new vulnerabilities in popular platforms like ServiceNow, making a strong security stance indispensable.
ServiceNow’s Built-in Security Capabilities
ServiceNow provides various security features, including multi-factor authentication (MFA), role-based access control (RBAC), encryption options, and the High-Security Plugin (HSP), designed to enhance protection. Leveraging these built-in capabilities is crucial for a resilient security framework.
Core Best Practices for Securing ServiceNow
1. Instance Hardening
Instance hardening ensures the ServiceNow instance is less vulnerable to attacks by applying secure configuration settings. Key hardening steps:
Secure access: Enable IP-based access controls to restrict unauthorized access.
Password policies: Enforce complexity, expiration, and lockout policies.
Encryption: Use TLS for data in transit and encrypt sensitive data at rest using Column Level Encryption (CLE) or Platform Encryption.
2. IP Address Access Control
Apply an IP access control to outbound traffic, inbound traffic, or bidirectional traffic. The system only blocks an IP address if a matching Deny rule exists and no matching Allow rule exists. By default, there are no restrictions on access to your instance.
Navigate to All > System Security > IP Address Access Control to see a list of your IP access controls. You might have to activate the IP Range Based Authentication [com.snc.ipauthenticator] plugin.
Complete the form. Note: To find your instance IP information, Log in to ServiceNow - NOW Support and Search for the My IP Information service catalog item.
Field
Description
Type
Type of access control rule to include.
Allow: Any IP address in this range can interact with this instance.
Deny: Any IP address in this range cannot interact with this instance unless it is listed in an Allow rule. Also, when adding deny rules, you cannot deny your own public IP address, or your instance will not update a deny rule.
Note: To support maintenance, upgrades, and Customer Service and Support, some ServiceNow internal IPs cannot be blocked by Deny rules.
Direction
Direction of the IP access control rule.
Inbound: Allows or denies inbound transactions. These are transactions initiated from outside of your instance.
Outbound: Allows or denies outbound transactions. These are transactions initiated from within your instance.
Bidirectional: Allows or denies both inbound and outbound transactions.
Active
When selected, the form is active.
Description
Description of the access control.
Range Start
Starting range of IP addresses to allow or deny. Note: These rules also affect transferring update sets. Add the target instance as an exception to ensure that IP address access control does not cause update sets to fail.
Range End
Ending range of IP addresses to allow or deny. Note: To limit access to specific VPN addresses only, enter a Deny range of 0.0.0.0 through 255.255.255.255 into the Deny field, and only enter the specific allowed VPN ranges.
3. Password Policies
Password policy criteria enable you to secure your password and adhere to the minimum password complexity requirements.
Navigate to All > Password Policy > Password Policies. Note: The default strong preset is enabled as a default password acceptance criterion. If you want to add new criteria, you can follow the steps.
Click New. The Password Policy New record page has the following sections that you must specify for setting your password:
Password Policy Criteria
Sequence Matching
Test Your Password
The above screenshot shows the Password Policy form in ServiceNow, highlighting the configuration settings for password requirements. It includes fields for setting parameters like minimum length, complexity, and expiration rules to ensure secure user authentication in the platform.
3. Specify the Name for your password policy.
4. In the Password Policy Criteria section, select the preset from the Password Strength Preset. The presets available are as follows:
Password Strength Preset
Description
Default
Selecting Default auto-populates the password characters required as follows:
One Minimum Uppercase Character
One Minimum Lowercase Character
One Minimum Numeric Character
Direction
Medium
One Minimum Uppercase Character
One Minimum Lowercase Character
One Minimum Numeric Character
One Minimum Special Character
High
Selecting High auto-populates the password characters as follows:
One Minimum Uppercase Character
Two Minimum Lowercase Character
One Minimum Numeric Character
Three Minimum Special Character
Default Strong
Selecting Default Strong auto-populates the password characters required based on characters as follows:
One Minimum Uppercase Character
One Minimum Lowercase Character
One Minimum Numeric Character
One Minimum Special Character
Custom
Selecting Custom auto-populates the password characters required based on characters as follows:
One Minimum Uppercase Character
One Minimum Lowercase Character
One Minimum Numeric Character
One Minimum Special Character
You can also customize the displayed Password Policy Script.
Advanced
Selecting Advanced displays the Password Rule Script and Password Strength Script. Based on your requirements, you can customize these scripts.
5. Specify the fields described in the table:
Field
Description
Minimum Password Length
Minimum length of the password. This option is displayed for all the presets except Advanced. Note: Minimum Password Length is a required field, and it is recommended that it be set to a minimum of 8–10 characters.
Maximum Password Length
The maximum length of the password. This option is displayed for all the presets except Advanced. Note: Maximum Password Length is an optional field, and it is recommended that you set it to a maximum of 100 characters.
Minimum Uppercase Character(s)
Minimum number of uppercase characters in the password, from 0 to 10.
Minimum Lowercase Character(s)
Minimum lowercase characters in the password, from 0 to 10.
Minimum Numeric Character(s)
Minimum numeric of characters in the password, from 0 to 10.
Minimum Special Character(s)
Minimum number of special characters in the password, from 0 to 10.
Included Special Characters
Allow a restricted set of special characters without any delimiter. For example, if you enter "$,!" users can only use "{placeholder}quot; and "!" as special characters in the password. No other special characters can be used, and a password with other special characters is not allowed.
Excluded Special Characters
Allow a restricted set of special characters without any delimiter. For example, when '@$!' is entered, users should not be able to use '@', '{placeholder}#39; and '!' as special characters in their passwords. Note: This option is available if the glide.password_policy.use_excluded_special_char property is enabled.
Disallow User Data
It is enabled to disallow the user data.
4. Encryption
ServiceNow uses advanced encryption techniques to secure sensitive data both in transit and at rest, ensuring compliance with industry standards and data security policies.
Data in Transit with TLS
ServiceNow leverages TLS (Transport Layer Security) to encrypt data during transmission. TLS creates a secure tunnel that prevents unauthorized access and interception of data as it moves between users’ browsers and ServiceNow servers. For optimal security, ServiceNow recommends configuring instances to support TLS 1.2 or higher, thus enhancing resistance to cyber threats during data exchange.
Data at Rest: Column Level Encryption (CLE)
Column Level Encryption allows administrators to selectively encrypt specific fields, like string, date/time, and attachments, at the database level. This approach provides granular encryption and allows only authorized users with assigned roles to access these fields. CLE also supports deterministic and non-deterministic encryption options, offering flexibility in how data is secured based on specific organizational needs. CLE integrates with ServiceNow’s Key Management Framework (KMF), which allows for role-based key management and supports Bring Your Own Key (BYOK) for enhanced control over encryption keys.
Platform Encryption
For broader encryption needs, Platform Encryption provides extensive data protection across all supported fields in a ServiceNow instance. Platform Encryption uses AES-256 bit encryption and includes a multi-layered key hierarchy (comprising master keys and customer-managed keys). This form of encryption secures the database comprehensively, covering replication traffic, backups, and activity logs without impacting data accessibility or system performance. It supports automated key rotation, allowing organizations to manage key lifecycles within the ServiceNow interface for continuous security upkeep.
Configuring Access Controls and User Permissions
Define roles and permissions meticulously to enforce the principle of least privilege.
Defining roles and permissions: Use RBAC to define roles that reflect job functions and grant only necessary permissions.
Managing user groups: Organize users into groups based on roles, ensuring access to required functions is minimized.
1. Roles
Roles control access to features and capabilities in applications and modules. Securing applications against unauthorized access starts with roles. These are the steps to create a Role:
1. Logged as an Administrator, navigate to the "User Administration" section, and select "Roles".
This screenshot displays the "Roles" section in ServiceNow, where administrators can manage and assign user roles to control access permissions. It provides an overview of different roles, including high-privilege roles, and ensures proper security governance within the platform.
2. In the Roles table, click on "New", and create roles for each type of user in your ServiceNow instance.
The above screenshot shows the Roles list in ServiceNow, highlighting the various roles assigned to users within the platform. It allows administrators to view, manage, and customize roles to ensure appropriate access control and security measures for users across the system.
Here, ServiceNow is displayed, with highlighted fields for the role's "Name" and "Description." The form allows administrators to create new roles by entering specific details for each role to define its purpose and permissions within the platform.
2. Groups
A group is a set of users who share a common purpose. Groups are a shortcut way of assigning roles to users. Rather than adding a role individually to each user, assign a role to a group. Group members have all of the roles assigned to a group. These are the steps to create a Group and assign the role/roles:
1. Navigate to the "User Administration" section and select "Groups".
This screenshot shows the "Groups" section in ServiceNow, where administrators can manage and organize user groups. The section allows for creating, modifying, and assigning roles to specific groups, facilitating effective user access management and collaboration within the platform.
2. In the Groups table, click on "New" and create groups for each type of role in your ServiceNow instance.
Here, it shows the "Groups" list in ServiceNow, showcasing the various user groups within the platform. Administrators can view and manage existing groups, making it easier to assign roles and permissions to specific users for streamlined workflow and access control.
3. Don’t submit the record, right click on the form header, and click on "Save".
This screenshot shows the "Group" form in ServiceNow, featuring empty fields for the group name, manager, description, group email, and parent. To save the record, users can right-click on the form header and select "Save," ensuring the group details are stored and ready for further management.
4. Click on the "Edit" button.
Above, the "Group" form in ServiceNow with its related lists is shown, highlighting the "Edit" option. Users can click on the "Edit" button to modify group-related information or manage associated records, ensuring efficient updates to group details and their connection
5. Add the Role that you created before and match it with the Group.
This screenshot highlights how to add roles to groups in ServiceNow. It shows the process of selecting a specific role and matching it with the appropriate group, enabling the assignment of permissions and access control for the group.
6. You can assign a role to a group to grant access to applications and modules to group members.
3. Access Control Lists (ACL)
Record ACL rules consist of table and field names.
The table name is the table that you want to secure. If other tables extend from this table, then the table is considered a parent table. ACL rules for parent tables apply to any table that extends the parent table.
The field name is the field that you want to secure. Some fields are part of multiple tables because of table extension. ACL rules for fields in a parent table apply to any table that extends the parent table.
ACL rules can secure the following record operations:
Operation
Description
create
Enables users to insert new records (rows) into a table.
read
Enables users to display records from a table.
write
Enables users to update records in a table.
delete
Enables users to remove records from a table or drop a table.
edit_task_relations
Enables users to extend the Task [task] table.
edit_ci_relations
Enables users to extend the Configuration Item [cmdb_ci] table.
save_as_template
Enables users to save a record as a template.
add_to_list
Prevents users from viewing or personalizing specific columns in the list mechanic. Note: Conditions and scripts are not supported.
list_edit
Enables users to update records (rows) from a list.
report_on
Enables users to report on tables.
report_view
Enables users to report on field ACLs.
personalize_choices
Enables users to configure the table or field.
Table ACL Rules
The user must first pass the ACL rule in the table. Since the base system includes STAR (*) table ACL rules that match every table, the user must always pass at least one table ACL rule. The base system provides additional table ACL rules to control access to specific tables.
Table ACL rules are processed in the following order:
Match the table name. For example, an incident.
Match the parent table name. For example, a task.
Match any table name (*). For example, *.
If a user fails all table ACL rules, the user cannot access any fields in the table. If a user passes a table ACL rule, the system then evaluates the field ACL rules.
Field ACL Rules
After a user passes a table ACL rule, field ACL rules are processed in the following order:
Match the table and field name. For example, incident.number.
Match the parent table and field name. For example, task.number.
Match any table (*) and field name. For example, *.number.
Match the table and any field (*). For example, an incident.*.
Match the parent table and any field (*). For example, a task.*.
Match any table (*) and any field (*). For example, *.*.
A user must pass the table ACL rule to be granted access to the table's fields. For example, the user must first pass the table ACL rule for the incident table to access the Number field in the incident table.
The first successful field ACL evaluation stops ACL rule processing at the field level. When a user passes a field ACL rule, the system stops searching for other matching field ACL rules. For example, if a user passes the field ACL rule for incident.number, the system stops searching for other ACL rules that secure the Number field in the incident table.
Access to query information of inferred data is restricted for protected fields, therefore preventing the return of predictive information.
Implementing High-Security Plugins and Features
Enabling the High-Security Plugin
The High-Security Plugin (HSP) centralizes security settings and allows you to configure default deny properties.
Benefits: It enhances security by centralizing critical settings.
Activation:
Navigate to System Definition > Plugins.
Search for the High Security Settings plugin and click Activate.
Configure settings, such as default deny, for additional protection.
Configuration:
Navigate to System Security > High-Security Settings.
The above screenshot displays ServiceNow's High-Security Settings properties, showcasing a list of deployment options. It allows administrators to configure various security features to strengthen system protection.
Property
Description
Instance Security Hardening Settings
glide.ui.escape_text
Escape XML values at the parser level for the user interface. Prevents reflected and stored cross-site scripting attacks. This property is not applicable in the Service Portal.
Escape XML
glide.ui.escape_all_script
Forces all expressions within Jelly JavaScript <script type="text/javascript"> 'tags to be escaped by default. Enforces escaping only if the type attribute in the <script> tag is empty, or if the value is text/javascript, text/ecmascript, application/javascript, application/ecmascript, or application/x-javascript.
Enable secure session cookies: Enable additional cookie security. If Yes, strict session cookie validation is enforced.
Secure session cookies
glide.security.password_reset.uri
For mobile Password Reset, URL that the user is taken to when the user clicks the Forgot password? button.
None
glide.security.strict.updates
Double-check security on inbound transactions during form submission (rights are always checked on form generation).
Double check inbound transactions
glide.security.strict.actions
Check conditions on UI actions before execution. Normally, conditions are checked only during form rendering.
Check UI action before execution
glide.security.use_csrf_token
Enable usage of a secure token to identify and validate incoming requests. This token is used to prevent cross-site request forgery attacks.
Anti-CSRF token
glide.ui.escape_html_list_field
Escape HTML for HTML fields in a list view.
Escape HTML
glide.html.escape_script
Escape JavaScript tags in HTML fields.
Escape Javascript
glide.ui.forgetme
Remove the Remember me check box from the login page.
Remove remember me
glide.smtp.auth
Authenticate with the SMTP server by using the user name and password properties. Note: This property is deprecated.
SMTP authentication (deprecated)
glide.script.use.sandbox
Run client-generated scripts (AJAXEvaluate and query conditions) inside a reduced-rights sandbox. If yes, only those business rules and scripts included in the Client callable check box set to yes are available, and certain back-end API calls are disallowed. For more information, see Script sandbox property.
Client generated scripts sandbox
glide.soap.strict_security
Enforce strict security on incoming SOAP requests. Requires incoming SOAP requests to go through the security manager for table and field access and checks SOAP users for the correct roles for using the web service.
SOAP request strict security
glide.basicauth.required.wsdl
Require authorization for incoming WSDL requests. Note: If you choose not to require authorization for incoming WSDL requests, you must modify the Access Control (ACL) rules to allow guest users to access the WSDL content.
WSDL request authorization
glide.basicauth.required.csv
Require basic authorization for incoming CSV requests.
CSV request authorization
glide.basicauth.required.excel
Require basic authorization for incoming Excel requests.
Excel request authorization
glide.basicauth.required.importprocessor
Require basic authorization for incoming import requests.
Import request authorization
glide.basicauth.required.pdf
Require basic authorization for incoming PDF requests.
PDF request authorization
glide.basicauth.required.rss
Require basic authorization for incoming RSS requests.
RSS request authorization
glide.basicauth.required.scriptedprocessor
Require basic authorization for incoming script requests.
Script request authorization
glide.basicauth.required.soap
Require basic authorization for incoming SOAP requests.
Basic auth: SOAP requests
glide.basicauth.required.unl
Require basic authorization for incoming unload requests.
Unload request authorization
glide.basicauth.required.xml
Require basic authorization for incoming XSD requests.
XSD request authorization
glide.cms.catalog_uri_relative
Enforce relative links from the URI parameter on /ess/catalog.do. If Yes, only relative URLs are permitted through the /ess/catalog.do page using the URI parameter. If No, all URLs are permitted, which may permit linking to external unauthorized content.
Enforce relative links
glide.set_x_frame_options
Enable this property to set the X-Frame-Options response header to SAMEORIGIN for all UI pages. The X-Frame-Options HTTP response header can be used to indicate whether a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this property to avoid clickjacking attacks by ensuring that their content is not embedded into other sites. https://developer.mozilla.org/en/the_x-frame-options_response_header
X-Frame-Options: SAMEORIGIN
glide.ui.attachment.download_mime_types
A list of comma-separated attachment mime types that do not render inline in the browser. Prevents cross-site scripting attacks. For example, text/html forces HTML files to be downloaded to the client as attachments rather than viewed inline in the browser.
Force download MIME types
glide.security.groupby_acl_check
When this property is enabled, ACL checks for GroupBy operations are performed for the group names based on the actual data from the groups.
None
glide.security.diag_txns_acl
If Yes, only the admin user or user from the allowed IP address can access stats.do, threads.do, and replication.do.
Performance monitoring (ACL)
glide.ui.security.codetag.allow_script
Allow embedded HTML (using [code] tags) to contain JavaScript tags.
Allow embedded HTML code
glide.script.allow.ajaxevaluate
Enable the AJAXEvaluate processor. The AJAXEvaluate API call allows the client to send and execute arbitrary scripts on the server.
Enable AJAXEvaluate
glide.login.autocomplete
Allow browsers to use auto-complete on password fields on login forms.
Password field auto-complete
Default Deny
Use the glide.sm.default_mode property to control the default behavior of the security manager when it finds that existing ACL rules are a part of wildcard table ACL rules.
When the High-Security Settings (com.glide.high_security) plugin is activated during initial instance installation, it creates this property, and wildcard ACL rules come into existence. To provide role-based access to system tables, these rules control a significant number of ACLs and most common record-based operations:
Read
Write
Create
Delete
Many tables are not protected unless you use the High-Security plugin with the default deny option enabled. The Now Platform uses a default deny security model that prevents non-administrator users from accessing objects unless they meet a matching ACL rule. Using this model removes many attack vectors, such as insecure scripts.
Using Multi-Factor Authentication (MFA)
MFA adds an extra layer of security, reducing the risk of unauthorized access.
Enforcing MFA: Apply MFA across all users, especially admins.
Step-by-Step Guide to Configuring MFA in ServiceNow
1. Log in as an Administrator, navigate to the "Multi-Factor Authentication" section, and select "Properties."
This screenshot shows the Multi-Factor Authentication (MFA) properties in ServiceNow. It demonstrates how administrators can access and configure MFA settings by logging in as an admin and navigating to the "Multi-Factor Authentication" section under properties.
2. Toggle the switch on the MFA settings page to enable Multi-Factor Authentication on your side. You can also change the properties below to customize MFA to meet your security requirements.
Here, the screenshot shows the various options available under Multi-Factor Authentication (MFA) settings in ServiceNow. It highlights the ability to change authentication properties with the option to save modifications.
Property
Description
Number of times a user can bypass Multi-Factor Authentication.
Number of times that a user can choose to skip the setup of MFA. Users can still log in to the instance even if they don't have their mobile device with them. If you disable this feature and then re-enable it, the counter starts over again. The default is 3.
The time in minutes the one-time code sent to the user's email address is valid.
Number of minutes that the reset code is valid. The default is 10.
Additional time in seconds is needed for the code to be valid and accommodate the clock skew. The maximum value is 60 seconds.
Number of additional seconds that the reset code is valid. The maximum is 60. The default is 10. Use this property to prevent login issues where the user is unable to enter the correct code in the default time allotted.
Enable the remember browser feature for multi-factor authentication.
Configure your instance to prompt users for MFA when they log in from a new device or browser. The default is yes.
Validity of browser fingerprint in hours.
After MFA remembers the browser, the user will not be challenged for MFA in the same browser for this duration. The default is 8 hours.
Maximum number of browsers a user can remember.
The number of browsers MFA remembers for this user.
The default value of the remember browser check box in the validate multi-factor page.
The default value of the remember-browser check box is on the validate multi-factor page.
Enable web authentication (FIDO2) based MFA.
Option to enable passwordless authentication methods such as hardware key and biometric authentication.
Secure Coding Practices for Custom ServiceNow Applications
Input/Output Sanitization
Sanitize all input to prevent injection attacks. Use server-side validation and escape HTML in outputs.
Implement input validation rules under System Properties > Security.
his screenshot shows the Security Settings properties in ServiceNow, where administrators can configure various security parameters for the platform.
Escaping and Embedded Script Support
Property
Description
glide.ui.security.allow_codetag
Supports embedding HTML code using the [code] tag.
Default value: Yes Note: Instance Security Hardening Settings: Allow embedded HTML code
glide.ui.security.codetag.allow_script
SAllows embedded HTML (using [code] tags) to contain Javascript tags. Note: Instance Security Hardening Settings:
Allow JavaScript tags in embedded HTML
glide.ui.escape_all_script
Forces all expressions within Jelly JavaScript <script type="text/javascript"> 'tags to be escaped by default. Enforces escaping only if the type attribute in the <script> tag is empty, or if the value is text/javascript, text/ecmascript, application/javascript, application/ecmascript, or application/x-javascript.
New/zbooted instances: true
Upgraded instances: false
Recommended value: Yes
Note: Instance Security Hardening Settings: Escape Jelly
Attachment Limits and Behavior
Property
Description
com.glide.attachment.max_size
Sets the maximum file attachment size in megabytes.
glide.attachment.role
Lists the roles (comma-separated) that can create attachments.
glide.attachment.extensions
Lists the file extensions (comma-separated) that can be attached to documents via the attachment dialog. Extensions should not include the dot (.). For example, xls, xlsx, doc, docx. Leave blank to allow all extensions. Note: Instance Security Hardening Settings: Restrict file extensions
glide.ui.attachment.force_download_all_mime_types
It forces the download of all multipurpose internet mail extensions (MIME) type attachment files.
Default value:
New/zbooted instances: Yes
Upgraded instances: No Note: Instance Security Hardening Settings: Force download MIME type
glide.security.file.mime_type.validation
Enables (Yes) or disables (No) MIME type validation for file attachments. File extensions configured via glide.attachment.extensions are checked for MIME type during upload.
Default value:
New/zbooted instances: Yes
Upgraded instances: No Note: Instance Security Hardening Settings: Upload MIME type restriction
Customer Uploads
These properties affect customer uploads only. They do not affect attachments.
Property
Description
glide.attachment.extensions
When you set this property to Yes, it turns on the ability to restrict the types of files that can be downloaded when they have been uploaded using the Upload File functionality of the Now Platform. Used with glide.ui.strict_customer_uploaded_content_types
Note: Instance Security Hardening Settings: Enable file download restrictions
glide.ui.strict_customer_uploaded_content_types
When this parameter includes a list of comma-delimited file types of the files that were uploaded using the Upload File functionality of the Now Platform, only these file types can be downloaded from the instance. Note: Instance Security Hardening Settings: Specify downloadable file types
glide.security.manager
Security Manager.
glide.sm.default_mode
Security manager default behavior in the absence of any ACLs on a table.
glide.security.strict.updates
Double-checks security on inbound transactions during form submission. Rights are always checked on form generation. Note: Instance Security Hardening Settings: Double check inbound transactions
glide.security.strict.actions
Check conditions on UI actions before execution. Normally, conditions are checked only during form rendering. Note: Instance Security Hardening Settings: Check UI action before execution
glide.security.granular.create
Enforces the creation rules on new records (as opposed to the writing rules, which may include creating and updating).
glide.security.explain.write.locks
Displays an explanation of locked form elements.
Cookies
Property
Description
glide.ui.forgetme
Remove the Remember Me check box from the login page when the instance uses either LDAP or DB logins. Users' logged-in sessions are timed out after X minutes of inactivity, where X is the glide.ui.session_timeout system property value.
Default value: Yes (New and Z-Booted instances Note: Instance Security Hardening Settings: Remove remember me
glide.ui.secure_cookies
Enables secure session cookies to enforce additional cookie security. If Yes, strict session cookie validation is enforced. With version 3 cookies enabled, additional security requirements are also enforced. Note: Instance Security Hardening Settings: Secure session cookies
glide.secure_cookie.debug
Secure session cookie debugging. Select this to enable extensive debugging of secure session cookie operations.
Security Restrictions for Execution of Scripts Originating from the Client
Property
Description
glide.script.use.sandbox
Run client-generated scripts (AJAXEvaluate and query conditions) inside a reduced-rights sandbox. If enabled, only those business rules and scripts included in the Client callable check box selected are available, and certain back-end application programming interface (API) calls are disallowed. Note: Instance Security Hardening Settings: Client generated scripts sandbox
Applies standard security access control lists (ACLs) to AJAXGlideRecord calls. Default Value: Yes, for new and upgraded instances. (If Yes, it cannot be changed to No.) Note: Instance Security Hardening Settings: Enabling AJAXGlideRecord ACL checking
Miscellaneous
Property
Description
com.glide.communications.trustmanager_trust_all
By default, the instance trusts a certificate's Certificate Authority (CA). Ensures that the instance accepts self-issued certificates. To validate a certificate's CA, set this property to No. Note: Instance Security Hardening Settings: Certificate trust
glide.outbound.sslv3.disabled
When active, it forces outbound connections from an instance to use the transport layer security (TLS) instead of the secure sockets layer (SSL). Note: Instance Security Hardening Settings: Disabling SSLv2/SSLv3
Session Management and Secure Access Control
Use ServiceNow’s Session Timeout and Session Management tools to reduce risks from inactive sessions.
Enable session timeout and configure lockout settings for multiple failed login attempts.
Configure a Maximum Active Time for User Sessions
By default, sessions expire only after a period of inactivity. Enforcing a maximum active session time ends sessions regardless of whether a user has been active recently, including whether they recently selected to extend a session. The active session timeout should be greater than the value configured for the inactive session timeout. For example, if sessions are configured to time out after 30 minutes of inactivity, the active session timeout should be greater than 30 minutes.
1. Log in as an Administrator, navigate to "sys_properties.list" using the navigation filter, and press "enter."
Here, It highlights the "sys_properties.list" option, which provides access to system properties where administrators can manage various configurations and settings for the platform.
2. Search for the following properties:
"glide.ui.active.session.life_span": Sets the maximum session time for authenticated user sessions.
This screenshot shows the "glide.ui.active.session.life_span" property in ServiceNow, highlighted for easy identification. This property controls the lifespan of active user sessions on the platform. Adjusting this setting helps manage session timeout durations for better security and user experience.
3. Enter the desired duration (in minutes) in the Value field for each property.
The value should be greater than the value of the corresponding properties for an inactive session timeout: glide.ui.session_timeout for authenticated users or glide.guest.session_timeout for guest users. By default, the inactive session timeout for both authenticated and guest users is 30 minutes.
4. Save the changes to apply the configured session timeouts.
Modify User Session Timeout After Inactivity
Specify when to time out user sessions after a period of inactivity. By default, after 30 minutes of inactivity in the application, the platform logs the user out automatically unless the "Remember Me" check box in the login screen is selected. Making the interval longer can lead to the unnecessary maintenance of inactive sessions in memory. Adjust this timeout setting to no more than a few hours, although up to 24 hours is workable.
Note:
Ajax calls to the server keep the session alive (such as Labels and Refreshing dashboards).
Polling keeps the session alive when the chat desktop is open (if the "Chat" plugin is installed).
Title
Description
Recommended value
The user specified timeout in minutes. 30 minutes is the recommended value, but this value may vary depending on functionality and security requirements. Do not set this value to more than one day.
Functional impact
(Medium) This remediation enforces the timely expiration of the user account. No functionality impact, however, the User experience is altered.
Functional impact
(Medium) This remediation enforces the timely expiration of the user account. No functionality impact, however, the User experience is altered.
Security risk
(Medium) User sessions being active for an indefinite amount of time is a security risk and should expire on a time-based configuration.
1. Logged in as an Administrator, navigate to the "System Properties" section and select "UI Properties."
Here, the above screenshot shows the "UI Properties" section in ServiceNow, accessed by an Administrator. It highlights the navigation to "System Properties" and then the selection of "UI Properties." This area allows admins to configure various aspects of the platform's user interface settings.
2. Search on the properties "Remove 'Remember Me” checkbox from the login page. And uncheck the checkbox.
To do this, you need to elevate your role to "security_admin"
This screenshot shows the system administrator profile in ServiceNow, highlighting the "Elevate Role" option. This feature allows administrators to temporarily elevate their privileges to perform high-security tasks within the platform.
It shows the login page in ServiceNow, highlighting the "Remember Me." It shows the checkbox options for selecting either "Yes" or "No." This feature allows users to save login credentials for future sessions.
3. Log in as an Administrator, navigate to "sys_properties.list" using the navigation filter, and press "enter".
Here, the screen shows the "sys_properties.list" in ServiceNow. It highlights various property entries that can be configured to manage system settings. Administrators use this to view and modify global settings in ServiceNow.
4. Search for the "glide.ui.session_timeout" property.
The screen displays the "glide.ui.session_timeout" property in ServiceNow, which controls the duration of the session timeout for users.
If "glide.ui.session_timeout" doesn’t exist, select the "New" button to add a new property using the following values:
Name: glide.ui.session_timeout
Description: Type a brief description. In this case, enter something like: “Override the default session timeout (30). This value is in minutes.
Type: Select the appropriate data type. In this case, select Integer.
Value: Change the default value from 30 minutes to a value of your choice.
Monitoring and Incident Response
Monitoring with the Instance Security Center
ServiceNow Security Center is an application that consists of a set of tools designed to help your organization maintain the security of your ServiceNow deployments. Using Security Center, you can improve security posture and strengthen compliance levels with a seamless user experience.
Important: The Instance Security Center (ISC) will reach the end of sales by September 2024. ServiceNow Security Center (SSC) is the recommended solution going forward.
Key Metrics:
Overview Page: Quick summary of security posture.
Security Hardening: Compliance with ServiceNow's security recommendations.
Security Scanner: Identifies misconfigurations and insecure behaviors.
Security Metrics: Monitors over 50 metrics for potential threats.
Customer Actions: Implements recommended actions to enhance security.
Best Practices: Guides for privacy and security configurations.
Learning Resources: Central repository for security documents.
Security Announcements: High visibility alerts for critical issues.
Posture Dashboards: Customizable dashboards for monitoring KPIs.
Security Policies: Manage and analyze security event notifications.
The above screenshot shows the Security Center in ServiceNow.This overviews the system's security, displaying the compliance score based on implemented security measures. It helps administrators track progress and identify areas needing improvement to strengthen security.
Setting Up Alerts for Potential Threats: The SSC allows you to configure alerts based on these metrics to proactively notify your security team about suspicious activities. For each type, you designate whether to receive notifications by email, push notifications in Now Mobile, or third-party messaging applications such as Slack or Microsoft Teams. Enable weekly digest notifications to stay updated on potential issues.
On the Instance Security Center home page, click the profile menu and Notification Preferences.
Notification Preference
Description
Admin Login
The user specified timeout in minutes. 30 minutes is the recommended value, but this value may vary depending on functionality and security requirements. Do not set this value to more than one day.
Functional impact
Send the selected type of notification whenever other users with assigned admin roles log in to this instance from a different IP address.
Admin Unlock
Send the selected type of notification whenever an account for a high-privilege user has been unlocked.
Failed Login
Send the selected type of notification whenever other users fail to log in to this instance in less than the number of attempts defined in the glide.user.max_unlock_attempts property. If you don't configure this property, the default value is 5.
To learn more about this property, see Specify lockout for failed login attempts.
HP Role Added
Send the selected type of notification whenever a high-privilege security role (including oauth_admin, admin, security_admin, and impersonator roles) is granted to another user.
To learn more about elevating user security, see Elevate to a Privileged Role and Elevated Privilege Roles.
Impersonation
Send the selected type of notification whenever another user is impersonating you.
To learn more about impersonating users, see Impersonate a user.
Security Elevation
Send the selected type of notification whenever other users are elevated to a security admin role in this instance.
Weekly Digest
Send a weekly digest on the selected type of notification. It includes:
A summary of all security activities that took place in this instance throughout the week. The current daily compliance score for the instance.
Logging and Event Management
ServiceNow provides detailed logs across various operations:
System Logs: Records all general activities, configuration changes, errors, and inbound/outbound connections.
Event Logs: Logs user login activities, including failures and privilege escalations.
Audit Logs: Essential for creating an audit trail of activities performed by users and ServiceNow personnel.
Transaction Logs: Track every web-based request, which can help identify unusual activities.
Note: You can find these logs on the "System Logs" menu.
This screenshot shows the "System Logs" menu in ServiceNow, highlighting various options such as System Log, client transaction, client integration & more. These options allow administrators to monitor and analyze system activities, errors, and transactions for troubleshooting and system performance optimization.
Best Practices for Tracking Security Events:
Use the Syslog Probe to forward logs to a Security Information and Event Management (SIEM) tool for comprehensive monitoring.
Enable table auditing for sensitive tables, especially those not audited by default (e.g., incident and change tables).
Monitor API Analytics to track and analyze REST and SOAP usage.
Setting Up Automated Responses for Suspicious Activities: Automate incident creation or set up workflows to notify your security team when predefined conditions (e.g., repeated failed logins) are met.
Keeping Your Instance Up to Date
Patch Management
Why Regular Updates Are Critical: Regular updates ensure your instance benefits from security fixes, performance improvements, and functional enhancements, which are critical to defending against new vulnerabilities.
Best Practices for Patching and Applying Security Updates:
Aim to install patches promptly as part of the ServiceNow Patching Program.
Major updates (two per year) provide new features and security enhancements. ServiceNow recommends updating at least once annually to avoid reaching end-of-life for your instance.
1. Navigate to Upgrade Center>Upgrade Preview.
Here, this screenshot shows the Preview Upgrade window in ServiceNow, which displays details of an upcoming system upgrade. This window helps administrators review and assess the upgrade before applying it to ensure a smooth transition.
1. Click on the Schedule Upgrade button and you will be redirected to a ServiceNow page. On that page, you can schedule your upgrade.
Testing Changes in a Non-Production Environment
Testing in a sub-production environment ensures that changes do not introduce security vulnerabilities or operational issues in production.
Email and Data Security
In ServiceNow, securing email communications is crucial to prevent phishing, malware attacks, and unauthorized access. ServiceNow provides robust email security features, including anti-malware scanning, SPF, and encryption, to protect instance email traffic.
Configuring Email Security Features
Using SPF and Anti-malware Measures
Malware scanning is performed by ServiceNow Antivirus Protection.
If a malicious email or attachment is detected, it is stored within an email quarantine area in a customer instance for inspection by their security personnel.
To configure the Antivirus Scanning, follow these steps:
1. Navigate to All > Antivirus > Configuration.
The screenshot displays the Antivirus Configuration window in ServiceNow, showing options to enable antivirus scanning and allow attachments to be downloaded when the antivirus scanner is unavailable, allowing administrators to manage security settings and ensure proper protection across the platform.
2. As you configure the feature, consider the following.
Options
Description
Enable Antivirus scanning
Antivirus scanning is active and enabled on the instance by default. Its toggle is set to the on position and appears green. Note: To set the property to be false, contact customer support.
Allow attachments to be downloaded when the Antivirus scanner is unavailable
If this option is set to the on position, antivirus scanning is bypassed if the scanner times out and a response can’t be obtained. In this situation, the file download proceeds without completing the scan. If the option is set to off, the file download is prohibited until the scan can be completed successfully.
List of Tables Excluded
Any file attachments associated with a table in this list are excluded from antivirus scanning. Proceed to Step 4 if you want to define the tables the system excludes from scanning.
Failed Login
Send the selected type of notification whenever other users fail to log in to this instance in less than the number of attempts defined in the glide.user.max_unlock_attempts property. If you don't configure this property, the default value is 5.
To learn more about this property, see Specify lockout for failed login attempts.
3. Select Save.
4. Exclude tables from the Antivirus scan by adding them to the List of Tables Excluded.
Navigate to System Definition → Dictionary.
Search for the table you want to exclude from the scan and select the table with the Type set to the collection.
In the Attributes tab, select New.
Add Exclude_from_antivirus_scan in the Attributes field and enter True in the Value field.
Select Submit.
Additionally, all emails inbound to the Now Platform are analyzed for malware and spam scoring, and the results are reflected in the x-headers added to the messages. Customers can use these as criteria for the Email Filters Plugin to act on if desired.
How to Set Email Domain Restrictions
Customers can control the domains and users their instance can send email to and receive from by using system address filters. These can be customized to meet customer requirements.
An organization may control inbound email with anti-spam technology using the Sender Policy Framework (SPF). If so, their email systems need to accept emails originating from their Now Platform instance. This is best achieved by configuring them to dynamically query the ServiceNow SPF records.
If SPF is not an option, another approach is to add the ServiceNow mail server IP addresses to the “allow” list. This does need to be monitored, as the addresses could be subject to change.
1. With the email_account_admin role, Navigate to All > System Mailboxes > Administration > Email Address Filters, and then select New.
The screenshot displays the Email Address Filter form in ServiceNow, showing fields such as Name, Type, Domains, and Exceptions. These options allow users to define filtering rules based on specific email addresses or domains, with exceptions to ensure certain emails are handled differently.
2. Enter the Name of the address filter.
3. Select the Filter Type:
Allow List: Allow all specified domains. All other domains are disallowed.
Deny List: Disallow all specified domains. All domains that don’t match the denied list domains are allowed.
4. In the Domains field:
Select the lock icon to unlock it and access the domains controlled by this filter.
Select an existing domain or enter a new domain:
If the filter Type is Allow List, select the Search icon. Select the domains for which all email addresses are allowed. To add a new domain, select New, enter the Domain, and select Submit.
If the filter Type is Deny List, select the Search icon. Select the domains for which all email addresses are disallowed. To add a new domain, select New, enter the Domain, and select Submit.
Note: You can specify a wildcard (*) in the domain name, for example*.com. If you create an email configuration that has multiple email address filters, all the filters evaluate the given email addresses. The filters determine whether the addresses are valid, and the message can be sent as an outbound email.
By default, the maximum number of domains that you can associate with an email address filter is 100. You can reconfigure this limit by setting the glide.email_address_filter.max_domains property.
Select the lock icon to lock the Domains field.
5. Specify any email addresses that are Exceptions to the domains specified in Step 4.
Select the lock icon to open the Email Address Filter Exceptions [sys_email_address_filt_except] table.
Click the search icon to choose an existing email address.
To add a new email address, select New, enter the email address exception, and select Submit.Note: You can specify a wildcard (*) in an email address exception.
By default, the maximum number of exceptions that you can associate with an email address filter is 1000. You can reconfigure this limit by setting the glide.email_address_filter.max_exceptions property.
Select the lock icon to lock the Exceptions field. The exception is added to the Email Address Filter Exceptions [sys_email_address_filt_except] table.
Select Submit. The email address filter is added to the Email Address Filters [sys_email_address_filter] table.
Best Practices
Use the Now Platform email filters feature set to deal with suspect inbound messages and limit accepted sender domains.
Ensure automatic account creation is configured securely or disabled if not needed. Ideally, customers should configure their email systems to accept mail from their instance by using the Sender Policy Framework.
If a customer already has a mature email security environment, they may consider using their own (or a third-party) infrastructure to send and receive instance-related emails, gaining the benefit of more precise perimeter email control.
Regular Security Audits and Reviews
Conducting Security Audits
Perform regular audits using ServiceNow’s Access Analyzer and Security Auditor tools.
How to Perform Audits: Schedule periodic checks, focusing on table access permissions and role assignments.
Leveraging Third-Party Tools for Deeper Analysis: Third-party tools or an SIEM integrated with ServiceNow logs provide an additional layer of analysis for security events, enabling more sophisticated threat detection and response.
Reviewing User Permissions and Access Levels
Review user access quarterly to ensure alignment with current job functions.
Using Access Control Tools: The ServiceNow Access Analyzer is a feature in the Vancouver release designed to clarify why a user, group, or role can or cannot access certain resources. It plays a crucial role in identity and access management by providing insights into granted vs. intended access, which helps mitigate digital risk and improve productivity. Access Analyzer guides platform admins, security admins, developers, and support teams through four key steps:
Define Evaluation Criteria: Users, groups, or roles can be selected to evaluate access controls over resources like tables, script includes, UI pages, and REST endpoints.
The above screenshot shows the "Analyze Access and Permissions" window in ServiceNow, highlighting the "Analyze by" field with options such as User, Group, and Role. This allows users to analyze access and permissions based on different criteria for improved management and security.
Here, the screenshot displays the "Analyze Access and Permissions" window in ServiceNow, highlighting the "Rule Type" field with options such as Table (record), Client Callable Script Include, UI Page, and REST Endpoints. These options allow users to analyze and configure access rules for various types of records and resources.
1. Review Access Results: The tool shows access status (allowed or denied) in order of evaluation, detailing the necessary ACL roles for actions like read, write, and report_on. Caution flags indicate the presence of scripts, advising a closer look at custom logic.
The screenshot displays the "Review Access" results for Abel Tuter in ServiceNow, showcasing the permissions and access levels assigned to the user.
2. Dive into Details: Provides a clear view of which access controls (business rules, ACLs, security attributes) apply and how operations affect access.
The screenshot shows the "Review Access" details in ServiceNow, focusing on the "Read" permissions for Debug Logs. It highlights the specific access level granted to the user, providing insight into the types of logs they can view and analyze within the system.
3. Act: Offers options to export results, adjust group assignments, modify access controls, and reanalyze criteria. Users can also test the impact of changes through historical review and re-evaluation.
Here, the screenshot displays the "Review Access" write results in ServiceNow, focusing on the "Write" permissions for Debug Logs. It highlights the access level, allowing the user to modify or write to the Debug Logs and providing insight into their ability to manage log data within the system.
These steps aim to make access analysis straightforward and actionable, helping organizations achieve stronger control over access policies.
Conclusion
Securing a ServiceNow instance is essential in today’s complex digital landscape, where sensitive data and critical workflows demand robust protection. By leveraging ServiceNow’s built-in security capabilities. such as the Security Center, High-Security Plugin, role-based access controls, encryption, and multi-factor authentication, organizations can establish a strong security posture that aligns with regulatory standards and mitigates emerging threats.
Ongoing monitoring and regular updates are equally crucial, ensuring that the platform remains resilient against evolving cyber threats. Adhering to ServiceNow’s security best practices enhances data protection and supports operational continuity, empowering organizations to safely and efficiently leverage ServiceNow’s full potential for business operations and growth.
In sum, a proactive approach to securing ServiceNow benefits both immediate security and long-term resilience, positioning the platform as a trusted foundation for digital transformation.
