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 access any remote servers in their network.

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

• Frequently It is often the case that 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 are performed inside the IT operations department.

Mitigation Strategies

Basically risks boil down to network security and personal responsibility.

Product Security

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

There 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. In addition there is a proven track record of vendors' proprietary code that includes including backdoors, e.g. for debugging purposes, that make makes it hard to believe in security by obscurity.

There are two strategies Strategies to work around this include:

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

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 is continuously decreasing and only suggests better standards for secure connections.

A strategy to work around this is include:

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

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 is too high a risk for some organizations.

Strategies to work around this include:

• Using digital signatures to sign deployable objects such as workflows and jobs. This approach is used in JS7 and 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.
• Placing certificates for digital signatures on the Agents that execute jobs. This is carried out on JS7 Controllers and Agents and if the signature does not match available certificates then deployment is denied. This mechanism does not prevent an authorized person from deploying workflows but it prevents attackers from hijacking a user's identity and deploying malicious code.

Centralized vs. Decentralized Architecture

A centralized architecture will focus and concentrate 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 include:

• Using the JS7 for central operation of jobs. With support for more than half a million job definitions and thousands of parallel tasks there is sufficient capacity for central management of larger IT environments.
• At the same time JS7 offers the option for a decentralized architecture by allowing any number of Controllers and Agents to work in parallel and to be operated independently from a central JOC Cockpit. Rollout of JS7 products is fairly simple and can be streamlined, for example by use of container images and cloud server images. This allows job management responsibility to be shifted to departments and application management teams. JS7's modern & intuitive user interface and straightforward approach for job design & job dependencies means that knowledge acquisition for daily operations and job management requires far less effort than that required for other products.