Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

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.

There is a proven track record of vendors' 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 include:

  • 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 anybody to analyze the code for security flaws . This and is what 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 falls back is continuously decreasing and only suggests better standards for secure connections.

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

Strategies to work around this include:

  • 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 out on JS7 Controllers and Agents and if the signature does not match available certificates then deployment is denied by an Agent. This mechanism does not prevent any an authorized person to deploy from deploying workflows , but 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 include:

  • 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 thousands of 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 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 to shift job management responsibility to be shifted to departments and application management teams. Knowledge JS7's modern & intuitive user interface and straightforward approach for job design & job dependencies means that 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 dependenciesthan that required for other products.