Security setup

Security baseline

By default the Tempus Serva is verifiably secure to all common threat vectors, such as

• SQL injection
• Cross-Site Scripting
• Session highjacking
• Login replays
• ...

Protective measure includes common hardening efforts, such as

• Data sanitization
• Request throtling
• CSRF tokens
• ...

The platform is security designed in accordance with OWASP version 4:

• Level 2: Compliant
• Level 3: +90% supported

In addition to this baseline additional features can be activated per installation.

Security built-in

Password policies (recommended)

Password should have rules in order to prevent guessing

• Requirements to length and complexity
• Maximum number of tries

How to: The polices can be changed in server configurations in the group Password policies

Note: The password polices will have no impact on SSO authentication

Multifactor authentication (recommended)

Two different options exist (choose one)

• MFA using codes sent to the users mobile via SMS
  • You will need to create an account for sending SMS
  • Cost is approx. 0,30 DKK per message)
• MFA using af dedicated app from
  • Apple
  • Google
  • Microsoft

SMS requires very little of the users, while App based MFA is considered (slightly) more secure.

Note: If using singlesignon (SSO) the MFA will not be used

Geolocation blocking (optional)

Geoblocking will allow the servers to deny requests from certain countries.

The geoblocking will match the clients IP against af Geo service. The county will be matched to the servers whitelist of country names.

How to: Change the system configurations starting with ipBlocker

• Activate setting ipBlockerActive
• Set allowed countries in ipBlockerAllowedCountries

Request throttling (optional)

As specified in OWASP v4 system should be able to limit the mount of request a user can carry out in a system.

Limitations can be set on

• Pages hit
• WebDAV requests
• Upload (size/count)
• REST operations

How to: Edit server configurations starting with limit

Brute force attacks (optional)

This protection is handled by not serving too many requests to the login page, regardless of the source in question. This will prevent brute force attacks on distributed accounts using multiple machines. In case the detection triggers, login requests will be ignored for at set amount of time, while allready logged in users can continue their work.

How to: Define systems configurations starting with bruteforce

Additional configurations

• File whitelisting (uploadWhitelist)
• OWASP compliance (owaspCompliance)

Security external

Virus scanning

Scanning of uploaded fiels are left to software installed on the system.

The upload feature will temporarily store the files on the file system, so that detection mechanisms can quarantine the files in case they are infected.

Storage encryption

Storage encryption is normally supported by the underlying technologies, with the possible exception of password hashes (handled with BCrypt).

MySQL (+8) supports multiple encryption schemes

• The whole database
• Single schema (each TS installation)

Read more about encryption for MySQL and MariaDB

O/S level encryption technology includes

• Windows: BitLocker
• Linux: LUKS

Transport encryption (https)

Minimum requirements are SSL certificates. On Linux these can easily be obtained for free via LetsEncrypt.

Optionally the server can also apply to HSTS, using the following guideline for Tomcat.

Denial of service attacks

Protection against DOS attacks are best handled using dedicated services such as Cloudflare.

Compliance built-in

Activity and data logging (optional)

Each entity can support the following

• Access log: User that has edited or viewed an item
• Status log: History of items time spent in each step
• Change log: Copy of old data along with timestamp and user that has changed the item (see below)

How to: Each option is activated on the entity Advanced page.

Pro tip: Especially the status log can be used for setting up performance charts on dashboards, as it can give detailed information of how much time was spent in each step.

Versioning (optional)

By default file versioning is supported on document fields.

In addition data revisions can be supported on each individual entity.

How to: Data revisions is activated on the entity Advanced page.

GDPR deletion policies (optional)

GDPR policies will enable automatic handling of stated deletion policies. The system will automatically remove or anonoumize data and files in the system.

How to:

1. Set up an action on a entity status
2. Check of deletion policy
3. Choose between anonoumization or deletion
4. Optionally select log data to also be deleted

In case you choose "anonoumization" you should define how each field should be handled

1. Click on a field
2. Click on Assignment
3. Check of anoumization
4. Optionally set value after change

Event and system logging (recommended)

The following events will be logged automatically

• User logins
  • Succesfull normal user logins are hidden
  • Also contains client IP (used for MFA)
• System events
  • User errors
  • Scheduled services
  • Administrator logins

Error events will include stacktraces if available.

The eventlog can be cleaned automatically on a regular schedule.

Compliance external

Request logging

The webserver itself can be set up to do make detailed logs in file , containing for example

• Request timestamp, IP and session ID
• Stacktraces on errors

Depending on your security setup you might want to log these to a central repository