<< Click to Display Table of Contents >> Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Best practices in the production environment > Security hardening > Recommended hardening

Overview

This section presents recommended security hardening to apply in the Bizagi Work portal which are relevant to Bizagi's configuration (application hardening).

 

 

These are recommendations that apply to your testing or pre-production (when you use one) environments as well as production environments. This section has the following recommendations:

 

•Include additional protection in Bizagi Web Services

•Delete unused folders in the production environment

•Rewrite values in server variables

•Customize the user's preferences form

•Database attribute encryption

 

For more information regarding the scope of these recommendations or other recommendations, refer to Security setup recommendations.

 

Including additional protection in Bizagi web services

By default Bizagi includes its built-in web services in the .\WebApplication\WebServices\ folder (inside the default path at C:\Bizagi\Projects\[your_project]\).

There are two types of web services published at this location: business-oriented web services which make up Bizagi's API, and web services which provide functionality used internally by Bizagi.

 

We strongly recommend that you provide an additional layer of security to restrict access to these web services, and to use separate folders for the two types of web services to implement different security measures for each.

You may even leave as inaccessible the business-oriented web services if your project will not be using them.

Even though you should use HTTPS configuration, you should explicitly configure the web services' folder and access with the measures described in the table below.

 

 

To do this, follow these steps:

 

•Separate the Web services

Separate those internal services from those which provide integration capabilities.

Internal Web services are: Cache.asmx, WFEQuery.asmx and WFAsynch.asmx.

 

To do this, create a new folder in the Web application's structure provided in Bizagi's Work portal (by default at C:\Bizagi\Projects\[your_project]\WebApplication\).

You can name this folder SOAPservices (or a different name of your choice):

 

 

Move all of the files located at the .\WebApplication\WebServices\ folder except Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, into this new folder:

 

 

Once you are done, verify that only Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, are still located at the .\WebApplication\WebServices\ folder.

 

•Set Basic authentication for the Web services for integration

Configure the IIS, so the .\WebApplication\SOAPservices\ folder containing Bizagi's Web services which promote application integration (i.e, WorkflowEngineSOA, EntityManagerSOA, QuerySOA), uses basic authentication.

Through this setting, external applications invoking these services will need to specify basic authentication credentials (user, password).

 

To do this, enable Basic Authentication and make sure Anonymous authentication is disabled for that folder:

 

 

Make sure that users allowed to access this content are granted privileges to its physical path (according to your registered domain).

For this grant permissions for the SOAPservices folder:

 

 

Click OK to save this configuration.

 

 

•Set an IP whitelist to access Web services

For the IIS configure that:

oThe .\WebApplication\WebServices\ folder containing Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, is accessible only by authorized IP addresses (in this specific case, only by the local server).

oThe .\WebApplication\SOAPservices\ folder containing business-oriented web services is accessible only by authorized IP addresses or an IP range of addresses (in this specific case, those IPs belonging to the external application invoking Bizagi).

 

To do this, include each allowed IP address explicitly by using the IP and Domain restriction feature in the IIS:

 

 

For the whitelist approach to work, make sure that your default feature settings deny access for unspecified clients (choose Deny):

 

 

Click OK to save this configuration.

 

Delete unused folders in the production environment

We recommend that you delete the folders whose use is oriented to the development environment.

This action is to avoid leakage of code information (a vulnerability known as Source code leakage).

 

You may delete the following folders located inside the jQuery folder (by default C:\Bizagi\Projects\[your_project]\WebApplication\jquery):

•automatictesting

•editor

•rendering

•renderingflat

•reporting

•testmobility

•workportal

•workportalflat

 

 

Delete as well:

•Readme.txt located at the desktop templates (by default at C:\Bizagi\Projects\[your_project]\WebApplication\jquery\overrides\templates\desktop\Readme.txt).

•Login.aspx located at the Admin folder (by default at C:\Bizagi\Projects\[your_project]\WebApplication\Admin\Login.aspx).

 

Rewrite values in server variables

We recommend that you 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.

 

 

To rewrite these values, perform the following steps:

 

Use the URL Rewrite option for the Bizagi Work portal (at the site folder level). Select View Server variables to make sure you have placed those three variables to rewrite.

 

If the option is not available in the IIS you must install it. Refer to URL rewrite.

 

 

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

 

 

Next, click Back to rules to add the rules that will rewrite values.

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

 

 

The properties for each rule will be :

•Name: A name according to your choice.

•Precondition: None.

•Matching scope: Server variable.

•Variable name: Enter 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.

 

 

•Action type: rewrite

•Value: EMPTY.

•Replace existing server variable value: On

 

 

You should be able to see the rules listed for the three variables:

 

 

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

 

 

Customize User's Preferences form

By default users have access to  the user's preferences in the Work Portal:

 

 

This form includes the Delegate feature. This feature lists all the users registered in the Work Portal.

 

 

We recommend that you edit the preferences form to hide the Delegated feature Refer to User preferences form. Delegate users must be defined by administrators or users who have access to the admin menu, as explained in Delegated User.

 

Database attributes encryption

We recommend using the attribute encryption option for critical attributes in your data model, for example, identification numbers. Refer to database attributes encryption.

 

It is recommended to use the following settings in your environment configuration:

 

•Hashing Algorithm: SHA 256

•Encryption algorithm: AES 256