angelo nappi
ServiceNow Employee
ServiceNow Employee

Part I

This will be a multi part series, first starting with a general understanding of privileged access account security in ServiceNow, with a follow up post on implementation specifics on an external credential vault.   ServiceNow uses an agentless approach to its Discovery, Service Mapping and Orchestration that provides for an easy to manage roll out across the enterprise. Deploying agent based solutions can be complex and difficult to manage, requiring attention to ensure that each agent deploys, possible reboot requirements, version control and testing for conflicts with anything else running on the host.

Rolling out credentials also has its challenges! You still need to make sure that the new devices are configured with the appropriate credentials to allow the MID Server to connect to perform its work.   To get the most value out of the IT Operations Management applications that leverage the agentless connections, the need for accounts with privileged access can raise flags from the IT Security office.   Privileged accounts are a high value target to intruders and were a special focus in June of 2015 by the US Federal Government Cybersecurity Sprint, where privilege account management was explicitly called out and agencies were given 30 days to perform a review, tighten controls and report results back to the Dept of Homeland Security.

Protection of credentials is not just a government focus as can be seen by efforts in commercial and healthcare industries with HIPAA and PCI-DSS standards calling for limitation of and auditing of use of accounts with escalated rights.   So what can be done to balance risk of administrative accounts versus the need to provide reliable IT services to consumers and employees?   ServiceNow provides hosted solutions to the world's top financial, government, healthcare, manufacturing and consumer industries that must meet these and other regulations at the risk of large fines and public relations challenges should there be a misuse of credentials.   In supporting our customers' need for compliance and protection of data, extensive security measures are in place with physical datacenter protections, self and customer driven intrusion testing, encryption, audit logs and role based access within the platform.

Management of credentials can be handled via two different storage approaches in order to meet your specific security needs.   The standard instance deployment is most commonly used and stores credentials in the Credentials [discovery_credentials] table on the customer's ServiceNow instance. Whenever a credential is stored or updated in this table, it is encrypted using a fixed key that is specific to the ServiceNow instance. Once credentials are entered into ServiceNow, they cannot be viewed.

When the MID Server requires credentials, it requests these from the customer's ServiceNow instance. The credentials are then transferred to the MID Server as follows:

  • The ServiceNow instance decrypts the credentials using the fixed instance key. 

  • ServiceNow then re-encrypts the credentials using a fixed Web Service key. 

  • ServiceNow then further encrypts the credentials using SSL, and sends them to the MID Server. 

  • The MID Server decrypts the credentials using SSL. 

  • The MID Server further decrypts the credentials using the fixed Web Service key. 


The second storage approach is to use a Privileged Identity Management solution that is installed on the customer network that stores, maintains and controls access to credentials. Examples of such solutions can be found at CyberArk, Thycotic and Centrify.   Use of an identity vault from one of these solutions would address one of the primary concerns of an IT Security group when dealing with the deployment of a cloud based solution: the storage of credentials in the cloud.   When a solution such as one listed is in place, all the credential information is stored on the customer network and only a reference to the vault is needed to be stored in the ServiceNow platform. When there is a need to perform an agentless action, the MID Server requests a credential and the platform provides the reference information back.   The MID Server uses that data to contact the identity vault to retrieve the needed credential such that it never leaves the boundary of the customer security perimeter.

Part II if this series covers an integration with the Thycotic solution.   Use of CyberArk is covered in the ServiceNow documentation site as well.

How to implement Thycotic Secret Server as an External Credential Store

Co-Author anders

Picture1.png