High Security Settings

From ServiceNow Wiki
Home > Administer > Security > General > High Security Settings
Jump to: navigation, search
Note
Note: This article applies to Fuji. For more current information, see High Security Settings at http://docs.servicenow.com

The ServiceNow Wiki is no longer being updated. Please refer to http://docs.servicenow.com for the latest product documentation.


Security

Warning
Warning: This functionality is intended for new instances. Configuring this application on an existing instance may cause changes to behavior. Please review the upgrade considerations before enabling.


1 Overview

High Security Settings provide these features:

  • Default property values: to harden security on your platform by centralizing all critical security settings to one location for management and auditing.
  • Default Deny Property: provides a security manager property to control the default security behavior for table access.
  • Security Administrator Role: provides a role to prevent modification of key security settings and resources. The Security Administrator role is not inherited by the admin role and must be explicitly assigned.
  • Elevated Privilege: allows users with the security admin role to operate in the context of a normal user and elevate to higher security role when needed.
  • Property Access Control: allows security administrators to set the roles required to read and write properties.
  • Transaction and system logs: are read only.
  • Access Control Rules: control what data users can access and how they can access it.

High Security Settings automatically activates the Contextual Security plugin if it is not already active. In addition, Platform Security Settings - High delivers the following settings and features in the context of increasing the security of your ServiceNow platform.

2 Upgrade Considerations

Before enabling High Security Settings on an existing instance:

  1. Review the following information to understand the new behavior:
  2. Enable the plugin on a sub-production instance. A recent clone of production is preferable.
  3. Test the revised functionality, especially the added ACLs and default-deny functionality. Continue testing until the system performs as expected.
    If users cannot access expected resources, ensure they have appropriate roles and ACL rules to grant them the access.
  4. Create update sets of any needed changes so you can apply them to production.

3 Properties

High security settings are controlled by the following properties, accessed from System Security > High Security Settings.

Note
Note: Access to System Security is restricted to users with the security_admin elevated privilege.
Name Description
glide.ui.escape_text Escape XML values at the parser level for the user interface. This will prevent reflected and stored cross site scripting attacks.

Default: Yes

glide.ui.escape_all_script Forces all scripts injected in Jelly to be escaped by default. Use NOESC: to preserve special characters.

Default: No

glide.ui.rotate_sessions Rotate HTTP session identifiers to reduce security vulnerabilities. See: http://www.owasp.org/index.php/Session_Management#Rotate_Session_Identifiers.

Default: Yes

If you are using the SAML 2.0 plugin for Single Sign-on authentication, set this feature to false. Otherwise, it interferes with the session information sharing that takes place between ServiceNow and the Identity Provider.

glide.ui.secure_cookies Enable secure session cookies: Enable additional cookie security. If selected, strict session cookie validation is enforced.

Default: Yes

glide.security.strict.updates Double check security on inbound transactions during form submission (rights are always checked on form generation).

Default: Yes

glide.security.strict.actions Check conditions on UI actions before execution; normally the conditions are only checked during form rendering.

Default: Yes

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.

Default: Yes

glide.ui.escape_html_list_field Escape HTML for HTML fields in a list view.

Default: Yes

glide.html.escape_script Escape JavaScript tags in HTML fields.

Default: Yes

glide.ui.forgetme Remove Remember me check box from login page.

Default: Yes

glide.smtp.auth Authenticate with the SMTP server by the user name and password properties.

Default: Yes

glide.script.use.sandbox Run client generated scripts (AJAXEvaluate and query conditions) inside of a reduced rights "sandbox". If enabled, only those business rules and script includes with the Client callable checkbox set to true are available and certain back-end API calls are disallowed.

Default: Yes

glide.soap.strict_security Enforce strict security on incoming SOAP requests. Checking this 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.

http://wiki.service-now.com/index.php?title=Contextual_Security
http://wiki.service-now.com/index.php?title=Web_Services

Default: Yes

glide.basicauth.required.wsdl Require authorization for incoming WSDL requests.

Default: Yes

Note: If you choose not to require authorization for incoming WSDL requests, you will need to modify the Access Control (ACL) rules to allow guest users to access the WSDL content.

glide.basicauth.required.csv Require basic authorization for incoming CSV requests.

Default: Yes

glide.basicauth.required.excel Require basic authorization for incoming Excel requests.

Default: Yes

glide.basicauth.required.importprocessor Require basic authorization for incoming import requests.

Default: Yes

glide.basicauth.required.pdf Require basic authorization for incoming PDF requests.

Default: Yes

glide.basicauth.required.rss Require basic authorization for incoming RSS requests.

Default: Yes

glide.basicauth.required.scriptedprocessor Require basic authorization for incoming script requests.

Default: Yes

glide.basicauth.required.soap Require basic authorization for incoming SOAP requests.

Default: Yes

glide.basicauth.required.unl Require basic authorization for incoming unload requests.

Default: Yes

glide.basicauth.required.xml Require basic authorization for incoming XML requests.

Default: Yes

glide.basicauth.required.xsd Require basic authorization for incoming XSD requests.

Default: Yes

glide.cms.catalog_uri_relative Enforce relative links from the URI parameter on /ess/catalog.do. If checked, then only relative URLs are permitted through the /ess/catalog.do page using the parameter 'uri'. If unchecked, all URLs are permitted, which may permit linking to external unauthorized content.

Default: Yes

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 or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this 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

Default: Yes

glide.ui.attachment.download_mime_types A list of comma separated attachment mime types that do not render inline in the browser. This will prevent 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.

Default:

glide.ui.security.allow_codetag Allow support for embedding HTML code by using the [code] tag.

Default: Yes

glide.ui.security.codetag.allow_script Allow embedded HTML (using [code] tags) to contain JavaScript tags.

Default: No

glide.script.allow.ajaxevaluate Enable the AJAXEvaluate processor.

Default: No

glide.login.autocomplete Allow browsers to use autocomplete on password fields on login forms.

Default: No

The following properties have been defined in the sys_properties table, but are not visible on the High Security Settings page.

Name Description
glide.security.csrf_previous.allow Allow usage of an expired secure token to identify and validate incoming requests. This token is used to prevent cross site request forgery attacks.

Default: No

glide.security.csrf_previous.time_limit Time in seconds for a secure token to expire. It allows control over the length of time that the previous CSRF token is valid. When the user session expires, the secure token expires with it unless the "allowing reuse of expired tokens are allowed" property is enabled and it's within the time frame described by this property. This token is used to prevent cross-site request forgery attacks.

Default: 86400 seconds or 1 day

glide.security.csrf.strict.validation.mode This property enforces strict validation on CSRF tokens so that users cannot resubmit a request if the CSRF token does not match.

Default: false

4 Default Deny Property

Activating the High Security plugin creates the glide.sm.default_mode security property, which controls the security manager default behavior when the only matching ACL rules are the wildcard table ACL rules. The High Security application also includes a set of wildcard table ACL rules for the most common record-based operations: read, write, create, and delete as well as a significant number of ACLs to provide role-based access to system tables. For example, there are ACLs that grant sys_script access to the business_rule_admin role because that role is documented as being able to manage business rules.

The choices for the glide.sm.default_mode property are:

  • Deny Access: The wildcard table ACL rules restrict the read, write, create, and delete operations on all tables unless the user has the admin role or meets the requirements of another table ACL rule. Other operations, such as report_on and personalize_choices, are unaffected by this setting.
  • Allow Access: The wildcard table ACL rules allow the read, write, create, and delete operations on all tables unless there are specific table ACL rules in place to restrict such operations.
Note
Note: By default, the wildcard table ACL rules are the only ACL rules that check for the value of the glide.sm.default_mode property. If you want to control other operations with this setting, create your own ACL rules to check for this property value. See Using Access Control Rules.


When an instance is upgraded while running the High Security plugin, the glide.sm.default_mode property is set to Allow Access and can be changed to Deny Access.

When the High Security plugin is activated on a new instance, the glide.sm.default_mode property is set to Deny Access.

To change the property:

  1. Navigate to System Properties > Security.
  2. Select Deny Access or Allow Access for the Security manager default behavior.

SecurityManagerDefault.png

5 Security Administrator Role

When the High Security plugin is activated, a new role called security_admin is created and added to the default System Administrator user. This role is a peer to the admin role and, therefore, is not inherited by users who are assigned the admin role by default (base system System Administrator, for example). This new role is marked as an elevated privilege, which means the user who is assigned the role will need to be manually elevated to the role during an interactive session. The security_admin role protects resources in the platform such as ACL, properties, and records, that require security to bar access by the normal admin user.

6 Access Control List for Prior Versions

The following table lists Access Control List entries that were modified or created by the activation of this plugin to enhance security in prior versions.

Constraint Operation Type Access Control
sys_user_role (Roles) read all records
  • The "maint" and "nobody" roles cannot be read by any role except "maint"
  • all other roles can only be read by users with the "role_delegator", "itil", or "user_admin" roles
sys_user_role (Roles) delete all records
  • The "maint" and "nobody" roles cannot be deleted by any role except "maint"
  • all other roles can only be deleted by users with the "admin" role
reset_acl_rules (Reset ACL UI page) read UI Page This UI page has been removed from the platform. Furthermore access to this UI page is set to "nobody" so that existing modified pages will not be accessible
sys_app_module (Application Modules) write all records
  • Only users with roles that are set in the "roles" field in the application module record can modify it
  • The user with "admin" role can modify any application module that is set with a role that "admin" can inherit (all roles except "maint" and "security_admin")
sys_app_application (Application) write all records
  • Only users with roles that are set in the "roles" field in the application record can modify it
  • The user with "admin" role can modify any application that is set with a role that "admin" can inherit (all roles except "maint" and "security_admin")
sys_properties (Properties) read all records
  • Only users with roles that are set in the "read_roles" field in the properties record can read it
  • The user with "admin" role can read any property that is set with a role that "admin" can inherit (all roles except "maint" and "security_admin")
sys_properties (Properties) write all records
  • Only users with roles that are set in the "write_roles" field in the properties record can modify it
  • The user with "admin" role can modify any property that is set with a role that "admin" can inherit (all roles except "maint" and "security_admin")
sys_properties (Properties) delete all records
  • Only users with roles that are set in the "write_roles" field in the properties record can delete it
  • The user with "admin" role can delete any property that is set with a role that "admin" can inherit (all roles except "maint" and "security_admin")
sys_security_acl (Access Control List) write all records Only users that have elevated to the "security_admin" role can modify records in sys_security_acl table
sys_security_acl (Access Control List) delete all records Only users that have elevated to the "security_admin" role can delete records in sys_security_acl table
sys_security_acl_role (Access Roles) write all records Only users that have elevated to the "security_admin" role can modify records in sys_security_acl_roles table
sys_security_acl_role (Access Roles) delete all records Only users that have elevated to the "security_admin" role can delete records in sys_security_acl_roles table
migrate_security (Migrate Security UI page) read UI Page Access to this UI page is only granted to the user who elevates to the "security_admin" role
syslog (Log Entry) write all records Modification of records to this table has been set to the "nobody" role which means records cannot be modified
syslog (Log Entry) delete all records Deletion of records to this table has been set to the "nobody" role which means records cannot be deleted
sysevent (Event) write all records Modification of records to this table has been set to the "nobody" role which means records cannot be modified
sysevent (Event) delete all records Deletion of records to this table has been set to the "nobody" role which means records cannot be deleted

7 Property Access Control

Two additional columns are created in the sys_properties (Properties) table.

  • read_roles: a comma-separated list of role names that are allowed to read all fields of this property
  • write_roles: a comma-separated list of role names that are allowed to write/modify all fields of this property

Properties listed in the Properties table have read_roles of admin, and write_roles of security_admin. This means that users with the admin role can view and read the property values, but must elevate to the security_admin role to modify them.

8 Elevated Privilege

An elevated privilege is a role that has the elevated_privilege field set to true. After the plugin is activated, a new security_admin elevated privilege is created and assigned to the default System Administrator user. This role grants modification access to the High Security Settings and allows the user to modify the Access Control List, directly import XML files, and access the Scripts - Background module. A user can get an elevated privilege role in his session only by manually elevating to it. The role is in the user's session only for the duration of the session. Session timeout or log-out removes the role.

The security admin role with elevated privileges

A role that is an elevated_privilege does not appear in an assigned user's session when the user logs in. The user must manually elevate to that role. See the following section for details.

8.1 Elevating to a Privileged Role

When a user is assigned a role that is an elevated privilege, a lock icon Icon-elevated.png appears next to the user's name in the header.

The welcome header lock

To elevate to a privileged role:

  1. Click the icon to select the roles for which elevated privileges are activated. The following dialog box appears.
    Elevating to the security admin role

  2. Select an elevated role and click OK. This grants the user elevated privileges to all resources controlled by the role for the remainder of the session. When the user logs out, the elevated privileges are terminated and must be reestablished at the next login. When elevated privileges are activated, the icon has an unlocked appearance.
    Elevated privileges are activated

    If the user's session expires, so do the elevated privileges.
  3. To reestablish the elevated privilege, click the lock icon, select the role, and click OK.
Note
Note: Any edits being made when the page reloads are lost.


8.2 Forcing Administrators to Manually Elevate

Administrators can enable the glide.security.strict_elevate_privilege property to force all users with the administrator role to manually select the role that they want to elevate to when they click the lock icon. When this property is disabled, only the security_admin role requires manual selection. When this property is enabled, all elevated roles require manual selection.

Manually elevating to both the security admin and soap roles

9 Notifications

Activation of high security settings also activates security warning messages. The following is an example of a message that appears after an approval. Click Continue to complete the action without error.

Highsecuritywarning.png

10 Activating High Security Settings

The High Security Settings plugin is active by default on all new ServiceNow instances. If it is not active on your instance, you can request the plugin. See Activating ServiceNow Plugins.

11 Enhancements

11.1 Dublin

  • The default value of an existing property, glide.security.csrf.strict.validation.mode, was changed from true to false. This property enforces strict validation on CSRF tokens so that users cannot resubmit a request if the CSRF token does not match.
Was this article helpful?
Yes, I found what I needed
No, I need more assistance