This section presents recommended security hardening to apply in the Bizagi Work portal which are relevant to Bizagi's configuration (application hardening).
The following recommendations apply when Bizagi runs on a .NET platform independently from the Web server IIS version on which it runs.
In this section, we describe the configuration for an IIS Web server version 7.5, and such hardening is carried out according to the IIS capabilities.
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:
For more information regarding the scope of these recommendations or other recommendations, refer to Security setup recommendations.
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.
Web services for internal purposes of Bizagi
Define an IP whitelist which only includes the local Bizagi server's IP, as an authorized server allowed to access these web services..
Web services which are part of Bizagi API (business oriented)
Define an IP whitelist which only includes the identified and authorized external servers (or an IP range), as those allowed to invoke web services in Bizagi.
Configure basic authentication to access these web services. This way, external application would need to authenticate prior to invoking web services in Bizagi.
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.
You can even leave as inaccessible the business-oriented web services, or delete them, if your project will not use them.
When setting basic authentication for web service access, make sure that your other applications invoking such services will be able to authenticate.
•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.
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):
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).
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.
For some of these steps, make sure you have installed the URL Rewrite module for the IIS.
The module in its 2.0 version (for IIS versions 7, 7.5 and 8) is a plugin that can be downloaded directly from http://www.iis.net/downloads/microsoft/url-rewrite.
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.
•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.
•Ignore case: On.
•Action type: rewrite
•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:
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.
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