Introduction

The critical point when it comes to job scheduling is the fact that it perfectly implements code injection across your network - which is what usually is called a vulnerability.

• Jobs are code, frequently shell commands, that are forwarded to remote servers and are executed in unattended mode.
• Users have to open their network and make their firewalls look like swiss cheese to allow a central server where a job scheduling product is operated to access any remote servers in their network.

The JS7 introduces digital signing for deployment of objects such as workflows and jobs.

• Digital signatures are created automatically and do not increase effort for deployment of objects.
• The security mechanism includes to have certificates for digital signatures ready with the Controller and the Agents that execute jobs. If the signature does not match available certificates then deployment is denied. This mechanism does not prevent an authorized person from deploying workflows and it prevents attackers from hijacking a user's identity and deploying malicious code.

Digital Signing

Digital signing is applied to Workflows, File Order Sources and Job Resources when performing JS7 - Deployment.

• The signing process is performed by JOC Cockpit and includes
  • the user to be assigned a private key and a certificate (X.509) or a public/private key (PGP),
  • to create a signature from the JSON representation of the respective inventory object by use of the user's private key.
• The verification process is performed by the Controller and Agent that is assigned the respective workflow and job:
  • Both Controller and Agents look up available X.509 certificates and PGP public keys from files with the following locations:
    • Unix
      • X.509 certificates: ./config/private/trusted-x509-keys
      • PGP public key: ./config/private/trusted-pgp-keys
    • Windows
      • X.509 certificates: .\config\private\trusted-x509-keys
      • PGP public key: .\config\private\trusted-pgp-keys
  • If a certificate or public key is found then the signature of the deployed object is verified like this:
    • X.509: 
      • the Root CA certificate or Intermediate CA certificate has to be in place that was used originally to sign the user's private key or
      • the user's certificate has to be in place.
      • Using the Root CA certificate or Intermediate CA certificates simplifies certificate management as a single certificate file only has to be present with any Controller or Agent instance. At the same time, security-aware administrators might prefer to deploy individual user certificates to Controller and Agent instances for more fine-grained control to which Agent workflows and other objects can be deployed by a specific user.
    • PGP: the public key available for the given user who signed the deployed object has to be present.
  • Controller and Agent instances make use of any certificate files and public key files found in the directories mentioned above. If non of the files matches the signature of a deployable object then deployment is denied.

Security Levels

JOC Cockpit is installed for one of the following security levels, see JS7 - Security Architecture.

Depending on the JOC Cockpit security level in use the signing process includes the following steps:

• Security Level Low
  • Inventory objects are automatically signed with the private key that is stored with the root account.
  • Signing is automatically applied when performing the Deploy operation.
• Security Level Medium
  • Inventory objects are automatically signed with the private key that is stored with the current user's account.
  • Signing is automatically applied when performing the Deploy operation.
• Security Level High
  • Inventory objects are signed outside of JOC Cockpit:
    • Inventory objects are exported using the Export operation that offers the option for signing.
    • The export archive is transferred to a secure device, e.g. to a secure desktop machine.
    • The export archive is extracted and each inventory object file included is individually signed. 
      • There is no pre-requisite about the tools used for signing. For example the OpenSSL command line utility can be used and tools such as OpenPGP Kleopatra can be used.
      • The signing step includes to create a signature file for each inventory file with the same name and the extension .asc.
    • The signed inventory files and signature files are added to the same or to a new .zip archive file.
  • The archive file that includes signatures for inventory objects is imported to JOC Cockpit. The deployment step is performed inline with the import step.