Page History

...

• 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.

...

Strategies to work around this areinclude:

• 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 and is performed automatically by an increasing number of tools that analyze vulnerabilities in source code. The JS7 source code repositories available 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 from time to time as increasing computing power invalidates older ciphers such as RSA (1977), which can no longer be considered secure for the future. ECDSA is the standard cipher that is ready for use and prolongs secure encryption for a foreseeable time.

...

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

Strategies to work around this areinclude:

• 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 and but it prevents attackers from hijacking a user's identity and deploying malicious code.

...

Strategies to work around this areinclude:

• 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 components products is fairly simple and can be streamlined, for example by use of Docker® container images and cloud server images. This allows job management responsibility to be shifted to departments and application management teams. JS7's modern and & intuitive user interface and straightforward approach for job design and & job dependencies mean means that knowledge acquisition for daily operations and job management requires far less effort than that required for other products.

...