Hardening Jedox

When developing and testing software, Jedox carefully addresses all aspects of the so-called triangle of information security:

  • Confidentiality indicates that data is only accessible to authorized individuals, and only they are aware of whether and between whom information is exchanged. The Information Owner, through classification, decides who the intended audience of the information is.
  • Integrity indicates that the information has not been intercepted or tampered with and is protected from being intercepted or tampered with either intentionally or accidentally; and that only permitted and intended changes can be made to data and IT systems.
  • Availability is the guarantee that data and IT systems are available when they need to be accessed by the intended audience, such as by duplicating IT systems to keep unintended downtime as low as possible.

Furthermore, all Jedox developers are fully aware of and develop according to principles of the Open Web Application Security Project (OWASP).

The following list is not intended to be a comprehensive list of hardening tasks for the Jedox environment, and Jedox may add to the list over time:

  • Jedox software consists of multiple components. Install only the components you really need in the project. Do not install portions of Jedox that are not necessary for running a project. Not only does this reduce the risk for potential attack, but it also reduces the number of resources used, improving the performance of the Jedox system.
  • The Jedox setup will install demo data that can help you understand how Jedox works. This data includes:
    • OLAP DBs: Demo, Biker, fgrp2, rgrp2, modified system db (no demo users)
    • SVS Samples: ..\svs\sample_scripts\*
    • Jedox web files: ..\httpd\app\docroot\pr\jedox\* , ..\storage\h1-Demos
    • Excel demos: %SHAREDDOCS%\Jedox\* (Dimension templates also)

    You can opt out of installing this demo data during Setup.

    These options are also covered in unattended installation; the option is called UpdateDemoContent=true/false in config.inf.

  • If you are adding your own code to the solution, make sure this code follows the same rules as those above.
  • If you are adding your own PHP code, make sure you are using Jedox Web API and adding a check for a valid session and/or user.
  • To prevent users from writing custom macros for specific functions, you can disable those functions in macro_engine_config.xml. Use the parameter disable_functions in the ini_directives section.
  • If your code is using third-party libraries, make sure those libraries are up to standards, follow same rules, and are up to date.
  • If you are using SVS and SSO, make sure SSO scripts are not "too open", e.g. make sure there is no "allow all" access in those scripts.
  • Use the open_basedir PHP directive whenever possible (Apache, Spreadsheet Server, SVS).
  • Use CFG_COOKIE_SECURE in config.php to control cookie secure flags.
  • Use CFG_DISABLE_AUTOCOMPLETE = true config directive to disable the autocomplete feature of the web browser on the logon form.
  • Use CFG_HTTP_HOST = <HOSTNAME> config directive to explicitly set hostname value on the target host and "guess" it from $_SERVER['HTTP_HOST'] variable.
  • Use CFG_HTTP_HDRS = [] config directive to set additional HTTP headers. This can be used to enable Strict Transport Security or Content Security Policy. For example: CFG_HTTP_HDRS', [ 'X-MyHeader1: 123', 'MyHeader2: true' ]. For more details, see Web Services and Configurations.
  • Use CFG_ANTI_CLICKJACK_LEGACY = true in config.php to enable the anti-clickjacking settings.
  • Jedox Integrator: restrict the capabilities of Groovy script execution in jobs or Transform functions of type "Groovy". Details can be found in the article Security of Script Jobs and Functions.
  • Set up the failed-login-threshold in palo.ini to prevent any brute force login, and enable password-pattern parameters to check the password complexity when the password is changed or a password is assigned to a new user. For more details, see Custom Configurations for the In-Memory DB (OLAP).
  • If you are using the apache_custom directory /opt/jedox/ps/httpd/app/docroot/pr/custom to store data, it should be protected by using IP filtering on port 443. Only specific IP addresses should be allowed as incoming connections to port 443. Other incoming connections should be disallowed.

  • You can use Groovy Sandbox and JavaScript runtime checks to secure the execution of groovy and JavaScript scripts.

A chain is no stronger than its weakest link

Securing data is an important part of the power user/consultant role. One has to ensure that applications built on top of Jedox also follow all these rules.

Jedox software never exists on its own. It is part of a bigger ecosystem. Jedox runs on an operating system, on real or virtual hardware, and is incorporated into an existing corporate network (portal, SSO,…). Hardening Jedox alone will not make the system as whole secure if any other part of the system isn’t hardened too. Make sure the whole environment is hardened the same way Jedox is. Where applicable, all software components should be up to date, OS on the latest patch level, and antivirus software and firewall rules in place.

See also Jedox Security Overview for more information.

Updated September 27, 2022