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

Basically risks boil down to network security and personal responsibility.

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 proprietary code that includes backdoors, e.g. for debugging purposes, that make it hard to believe in security by obscurity.

There are two strategies to work around this:

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