Risks

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

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

Certainly, central management of jobs is the basic usefulness of a job scheduling product, however, users should be aware of organizational risks:

• Frequently a few persons with access to the job scheduling product manage job executions for a larger number of servers in the network. You have to trust their honesty.
• At the same time an increasing number of attacks on data security is performed inside the IT operations department.

Mitigation Strategies

Product Security

Security is based on software design - the older the code base, the more vulnerabilities have to be assumed. For the simple reason that awareness for secure code design 10 years ago was not the same as today.

There is a proven track record of proprietary code that includes backdoors, e.g. for debugging purposes, that makes it hard to believe in security by obscurity.

Strategies to work around this:

• A rewrite of the product code base has been applied to the JS7 branch of JobScheduler. This allows to redesign the software in line with current standards and state of the art.
• Use of open source licensed code. This allows everybody to analyze the code for security flaws. This is what is performed automatically by an increasing number of tools that analyze vulnerabilities from source code. The JS7 source code repositories available with https://github.com/sos-berlin are automatically checked for vulnerabilities by Github.

Network Security

Some vendors implement proprietary protocols between job scheduling server and agents. However, it is ridiculous to assume a protocol to be secure just because "you don't know". The effort to re-engineer protocols falls back continuously and suggests better standards for secure connections.

Strategies to work around this:

• Use of standard protocols such as HTTPS with adjustable and proven security. The ciphers used to encrypt communication have to be adjusted after some time as increasing computing power invalidates older ciphers such as RSA (1977) that cannot be considered secure for the next future. ECDSA is the standard cipher ready for use that prolongs secure encryption for a foreseeable future.

Secure Deployment

The fact that in a central scheduling system just a few people control what jobs are executed on practically any server in the IT network for some organizations is a too high risk.

Strategies to work around this:

• JS7 makes use of digital signatures to sign deployable objects such as workflows and jobs. A number of security levels are offered that determine the degree of foreclosure, for example by forcing signatures to be applied to deployable objects outside of the JOC Cockpit application on a secure device.
• Certificates for digital signatures are in place with JS7 Agents that execute jobs. If the signature does not match available certificates then deployment is denied by an Agent. This mechanism does not prevent any authorized person to deploy workflows, but it prevents attackers from hijacking a user's identity and to deploy malicious code.

Centralized vs. Decentralized Architecture

A centralized architecture will focus and further risks to a few servers and people involved in job management. At the same time a decentralized architecture does not come without effort for knowledge acquisition, operations and maintenance.

Strategies to work around this:

• The JS7 can be used for central operation of jobs. With support for more than half a million job definitions and more than 30 000 parallel tasks there is sufficient capacity for central management of larger IT environments.
• At the same time the JS7 offers the option for a decentralized architecture by running any number of Controllers and Agents in parallel that work independently from a central JOC Cockpit. Rollout of JS7 components is fairly simple and can be streamlined for example by use of Docker® images and cloud server images. This allows to shift job management responsibility to departments and application management teams. Knowledge acquisition for daily operations and job management with JS7 requires by far less effort compared to other products due to its modern and intuitive user interface and straightforward approach for job design and job dependencies.