Page History

...

• 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 performed inside the IT operations department.

...

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

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

Strategies to work around this are:

• A rewrite of the product code base as has been applied to the JS7 branch of JobScheduler. This allows to redesign 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 to analyze the code for security flaws . This is what is and 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.

...

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 fails regularly and only suggests better standards for secure connections.

Strategies A strategy to work around this is:

• Use of standard protocols such as HTTPS with adjustable 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 for some organizations is a too high risk for some organizations.

Strategies to work around this are:

• JS7 makes use of Using digital signatures to sign deployable objects such as workflows and jobs. A 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.
• Certificates Placing certificates for digital signatures are in place with JS7 on the Agents that execute jobs. If This is carried on on JS7 Agents and if the signature does not match available certificates then deployment is denied by an the Agent. This mechanism does not prevent any an authorized person to deploy workflows, but from deploying workflows and it prevents attackers from hijacking a user's identity and to deploy deploying malicious code.

Centralized vs. Decentralized Architecture

A centralized architecture will focus and further 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 are:

• The Using 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 allowing any number of Controllers and Agents to work in parallel that work and 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 be shifted 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 JS7's modern and intuitive user interface and straightforward approach for job design and job dependencies mean that knowledge acquisition for daily operations and job management requires far less effort than that required for other products.