Exploring Code Signing
Summarize
Summary of Exploring Code Signing
Code Signing in ServiceNow provides cryptographic verification to ensure that only authorized scripts execute on MID Servers, protecting the integrity of integrations with external systems. It creates digital signatures for data, verifying authenticity and preventing unauthorized or altered ECC queue records from being processed. This feature is part of the ServiceNow Vault module and requires access granted by the Customer Service and Support team.
Show less
Code Signing leverages the Key Management Framework (KMF) with digital certificates and industry-standard asymmetric encryption. It operates within a secure Circle of Trust (COT) architecture between trusted and protected instances, where Code Signing is enabled on the protected instance to verify incoming data and maintain system security.
How Code Signing Protects Your Environment
Without Code Signing, malicious actors could alter ServiceNow records to execute harmful SQL commands via the MID Server. Implementing Code Signing ensures that only data signed by a trusted instance is accepted and executed by the MID Server. The MID Server verifies digital signatures on all incoming requests and rejects those without valid signatures, logging and notifying the protected instance of any rejections. This process substantially reduces potential security vulnerabilities.
Benefits of Implementing Code Signing
- Execution Control: Only scripts verified through cryptographic signatures are allowed to run on MID Servers.
- Tamper Detection: Any unauthorized modifications to signed records are detected and blocked immediately.
- Automated Protection: Security enforcement is automatic, requiring no manual intervention.
- Comprehensive Logging: All failed signature verifications generate detailed audit records for tracking and compliance.
Code Signing Validation and Jobs
Administrators with the Security Administrator role can use Code Signing encryption jobs to sign data within metadata tables configured for Code Signing:
- Sign Update Sets: Signs records matching signature configurations within an update set and adds signature records and verification certificates to it.
- Mass Sign Records: Signs all records matching a specific metadata table’s signature configuration.
- Mass Sign Attachments: Signs all attachments related to tables configured for signature verification.
These jobs ensure that data is properly signed at build time to maintain integrity and security throughout deployment and execution.
Code Signing provides cryptographic verification to ensure that only authorized scripts can execute on MID Servers. Code Signing prevents unauthorized or tampered ECC queue records from being processed by MID Servers, maintaining the integrity of integrations between ServiceNow and external systems.
Code Signing creates digital signatures for your data, which are later checked to confirm the authenticity and integrity of the data. Code Signing is a module licensed as a component of ServiceNow Vault.
|
Code Signing declares the intent behind the operation being performed and validates whether the resource or record may be used for the intended purpose. To facilitate Code Signing, the Key Management Framework (KMF) uses digital certificates and industry standard asymmetric encryption for digital signatures. Use Code Signing internally on the platform and infrastructure side. Code signing provides a way to sign the content of specific tables or of a subset of records in a given metadata table. |
Code Signing uses a secure Circle of Trust (COT) between your trusted and protected instances to ensure that only authorized, secure trusted instances can access the Code Signing feature.
How Code Signing protects your environment
Without Code Signing, an attacker who gains access to ServiceNow records can modify SQL statements in a protected instance. When the MID Server processes this data source request, it would execute the malicious SQL commands, potentially compromising system integrity and security.
When you implement a Circle of Trust architecture with Code Signing, transfer of data to the MID Server follows the following verification process. This process helps ensure that only authorized code originating from the trusted instance can execute on the MID Server. The processes reduces potential attack vectors that could otherwise compromise your systems.
- Digital signatures are applied to data sources created or updated within the trusted instance.
- Use the Code signing process to transfer the signed data from the trusted instance to the protected instance
- The MID Server verifies the digital signature on all incoming requests, automatically rejecting any requests lacking valid signatures.
- If the MID Server rejects a request, it logs this rejection and sends a notification to the protected instance.
Benefits of implementing Code Signing
Code Signing provides several key advantages:
- Execution Control
- Only cryptographically verified scripts can run on MID Servers
- Tamper Detection
- Any modifications to signed records are immediately identified and blocked.
- Automated Protection
- The system handles security enforcement without requiring manual intervention.
- Comprehensive Logging
- All signature verification failures generate detailed audit records.
Code Signing validation and jobs
All the metadata tables with valid configurations are signed at build time using the Code Signing metadata plugin (com.glide.code_signing). If you choose to sign tables, admin users with the Security Administrator role have access to Code Signing encryption jobs:
- Sign update sets.
- Mass sign records.
- Mass sign attachments.
- Sign update set
- This job signs records that match a signature configuration in the update set. The job also adds all the new signature records and the verification certificates to the update set.
Figure 1. KMF signature record for update set - Mass sign records
-
This job signs all the records that match the signature configuration applied on a specific metadata table.
- Mass sign attachments
- This job signs all the attachment records that are attached to a table that matches a specified signature configuration.
Figure 2. Encryption job to mass sign records