Ensuring IT infrastructure and data are secure has become a central issue for businesses as digital transformation is increasingly adopted. The frequency and severity of cyber attacks has increased due to the tremendous change in the technological landscape. Companies who use ServiceNow are at an advantage as the Now Platform has built-in security mechanisms. However, users need to configure their instances according to their own requirements and security policies to properly leverage the extensive capabilities of ServiceNow's security features.
Best Practices for Securing Your ServiceNow Instance
Test on a Non-production Instance
It's important to test any configuration changes on a non-production instance first before introducing them on a working instance. This would allow you to understand how the changes are going to affect your instance security without affecting performance.
Update Security Contact Details
The security contact stored in the customer account and accessible in the Now Support Portal should always be up to date. This contact will be given security-related information. The contact should have a proper understanding of the security policies to act on information relayed to them which may include security issues, alerts and information on software updates.
Activate the ServiceNow High Security Plugin
ServiceNow provides a High Security Plugin to easily secure your instance. This plugin is installed and activated by default in new instances but in older instances it needs to be manually activated. The default "deny" property can be enabled to deny read, write, create and delete tables unless explicit permission is provided for a user or role.
Use Instance Hardening
Frequently monitor and assess your instance’s security level by consulting ServiceNow’s Instance Security Center which provides a simple overview of configuration and security activity. Potential issues can be alerted by enabling notifications. The Hardening Tool and Event Ribbon can be used to identify and address areas that improve security. Use the Secure Coding Guide for reference to ensure ServiceNow developers follow security best practices.
Secure Email Communications
To deal with suspicious emails, use the email filters feature-set. You can set domain restrictions using system address filters so users and instances can send to and receive emails from specific domains only. The Sender Policy Framework (SPF) controls inbound emails. The automatic account creation feature should be enabled only when necessary and even then, it should be configured securely. If the email security environment allows it, you can set up your own email servers for more security.
Monitor Sensitive Logs
Identify suspicious activities and security incidents by monitoring logs that contain important security information. The syslog probe can be used to feed selected logs to a syslog server like SIEM for increased monitoring. You can disable browser SQL error messages to prevent external attackers from exploiting it. Enable table editing to track and view changes made to the data.
Guard Access Control
Ensure the default login credentials are changed as soon as possible. Restrict access to your instance from unknown IP addresses and ensure that complex passwords and passphrases are used. Remove the "Remember Me" feature which caches login credentials from the login page. When possible, use SAML along with Multi-Factor Authentication (MFA) for authentication. If necessary, you can limit uploads, downloads and file attachments for greater access control. The ServiceNow Access Control plugin can be used to control ServiceNow’s access to the instance.
Enforce MID Server Security
Ensure physical security of the MID server by storing it in a secure environment that has controlled access and good physical security. Connectivity between the MID server and internal and external server should be minimal and only for required services and infrastructure. Protect MID server data with encryption by encrypting credentials, supplying SSL/TLS certificates during network authentication, and enforcing certificate validation.
Follow Encryption Protocols
Web browsers should be configured to use TLS 1.2 or higher while connecting to the instance. Web proxies and other gateways can also ensure that this encryption protocol is followed. REST/SOAP services connecting to the instance can use certificate-based authentication. Other traffic should use TLS as much as possible.
Update Software and Patches
Install platform updates and patches as soon as they are available to ensure security of the instance and customers. This would also ensure compliance with the EOL policy necessary for continuous support.
Mobile Application Security
For authentication, always use MFA and refrain from storing record data locally on a device. Built-in controls should be used for application access, clipboard and similar requirements. Common Enterprise Mobility Management (EMM) and Mobile Device Management (MDM) platforms can be used to manage devices.