Advanced recommendations

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration > Bizagi server configuration > Bizagi Engine .NET platform configuration > Security setup recommendations >

Advanced recommendations

 

Overview

This section presents security recommendations to apply in Bizagi Work portal, regarding aspects which are relevant to Bizagi's configuration (application hardening).

 

In order to carry out the recommendations presented below, note that you should have already followed what described at Intermediate recommendations.

 

note_pin

The following recommendations apply when Bizagi runs in a .NET platform, independently from the Web server IIS version on which it runs.

In this section, recommended configuration is described by taking as an example an IIS Web server version 7.5, and such hardening is carried out according to the IIS capabilities.

 

 

Advanced recommendations

These apply to your testing or pre-production environment as well (when using one).

This section presents specific aspects which are recommended to mitigate a different set of vulnerabilities.

 

note_pin

For some of the below steps, you will need to make sure you have installed the URL Rewrite module for the IIS.

Such module in its 2.0 version (for IIS versions 7, 7.5 and 8), is featured as a plugin that can be downloaded directly from http://www.iis.net/downloads/microsoft/url-rewrite.

 

1. Rewriting values in server variables

It is recommended to configure rules that rewrite certain values which may leak information regarding the server (this action seeks to mitigate the vulnerability known as information leakage).

Values providing IIS server information are disclosed by default in the following variables: RESPONSE_SERVER, RESPONSE_X-ASPNET-VERSION, and RESPONSE_X-POWERED-BY.

 

In order to rewrite these values, perform the following steps:

 

Use the URL Rewrite option for the Bizagi Work portal (at the site folder level), y click View Server variables to ensure you have placed those 3 variables to rewrite:

 

SecurityS_Rewritevars01

 

Use the Add option 3 times, to include these variables one by one. In the end you should be able to see them all listed:

 

SecurityS_Rewritevars02

 

Next, go back to the URL Rewrite initial display (e.g, by clicking on Back to rules) to add the rules that will rewrite values.

For each one of the 3 variables (RESPONSE_SERVER, RESPONSE_X-ASPNET-VERSION, and RESPONSE_X-POWERED-BY), click on Add rule(s).. and select the blank type of rule for the Outbound category.

 

SecurityS_Rewritevars03

 

The properties for each rule will be :

Name: A name according to your choice.

Precondition: None.

Matching scope: Server variable.

Variable name: Enter for each rule, the name of the corresponding variable to rewrite (RESPONSE_SERVER, RESPONSE_X-ASPNET-VERSION, or RESPONSE_X-POWERED-BY).

Variable value: Matches the pattern.

Using: Regular expression.

Pattern: .+

Ignore case: On.

 

SecurityS_Rewritevars04

 

Action type: rewrite

Value: EMPTY.

Replace existing server variable value: On

 

SecurityS_Rewritevars05

 

Upon ending the creation of rules, you should be able to see them listed for the 3 variables:

 

SecurityS_Rewritevars06

 

Similarly, from a browser, you should be able to inspect these values as sent by the server:

 

SecurityS_Rewritevars07

 

 

2. Using secure headers

It is recommended to establish secure headers in order to avoid disclosing information which may be used for potential attacks (to mitigate a vulnerability known as ClickJacking).

These headers are configured by defining the use of the following values:

 

Header

Value

x-content-type-options

nosniff

x-dns-prefetch-control

off

x-frame-controls

SAMEORIGIN

x-xss-protection

1; mode=block

Strict-Transport-Security

Strict-Transport-Security: max-age=31536000; includeSubDomains

content-security-policy

default-src: ‘self

 

NOTE: Here you may add up other URLs different from the application's one itself (depicted as "self"), when applies. For more information, refer to https://www.owasp.org/index.php/Content_Security_Policy

 

To accomplish the above,  perform these steps:

 

Use the HTTP Response Headers option for Bizagi Work portal (at the site folder level), add each one of the headers with their values as listed above (by using the Add option):

 

SecurityS_RespHeader01

 

Once you have done this, you should be able to see them all listed:

 

SecurityS_RespHeader02

 

 

Important

For Bizagi, security is an aspect of critical importance.

Therefore, Bizagi releases periodical new versions which feature multiple improvements and fixes for issues detected in previous versions.

Fixes for those detected issues may include definitive solutions for security vulnerabilities.

 

It is strongly recommended to consider a periodical upgrade in your solution to Bizagi's newest releases, by always following the usual guidelines for an upgrade procedure such as:

Plan, coordinate and test appropriately these upgrades.

Rely on the different environments (development, testing, pre-production when applicable, and production).

Previously take proper contingency measures (e.g backups).

Evaluate customizations or additional security configurations such as the ones listed above, so that stakeholders are aware that it is part of the plan to reconfigure certain aspects after the upgrade.

 

note_pin

When having customizations or applying hardening measures such as the ones above, one of the two alternatives needs to be followed when carrying out a version upgrade:

 

1. If doing this through Bizagi Management Console, you will need to reconfigure and verify that such measures are still applied after the upgrade (and backing up customizations before doing so is recommended).

Note that by default, the upgrade done by the Management Console will not consider if you have done modifications to the original files and file structure.

 

2. You may choose to do this through a manual procedure (without using Bizagi Management Console).

If you do, make sure you consider all the relevant components and files that you need to replace manually for the Work Portal and Scheduler, while avoiding overwriting your configured customizations or the already applied hardening measures.

 

For highly critical security issues, Bizagi may consider issuing hot fixes and recommend to apply them without the need to await for a newer version.