Installing Windchill Risk and Reliability > Enterprise Edition > Best Practices for Securely Configuring Windchill Risk and Reliability
Best Practices for Securely Configuring Windchill Risk and Reliability
This section provides information about the actions that you need to take to securely configure the Windchill Risk and Reliability solution on your system.
* 
This information is provided only to assist you to securely configure Windchill Risk and Reliability. PTC neither provides support for any third-party products mentioned here, nor is PTC responsible for your security infrastructure.
1. Configuring the web server to use HTTPS and to disable HTTP
HTTPS uses the Secure Socket Layer/Transport Layer Security (SSL/TLS) to protect web application data from unauthorized disclosure and modification when it is transmitted between the browser (client) and the web server.
Enabling HTTPS–Refer the Enabling HTTPS section to make Windchill Risk and Reliability work with HTTPS.
Disable HTTP–To access Windchill Risk and Reliability Internet Information (IIS) server, add the following settings. This is to make sure that Windchill Risk and Reliability Web services are accessible only over HTTPS. Follow the configuration steps below to disable HTTP.
1. Open IIS server.
2. Select applicable website to apply the settings.
3. Go to SSL Settings on the right-side pane.
4. Select the Require SSL checkbox and select Apply.
5. This setting enables only HTTPS access to Windchill Risk and Reliability and disables HTTP.
2. Account and Password Related Best Practices
a. Follow a strong password policy for your Windchill Risk and Reliability solution while creating user passwords. Ensure that the following best practices are considered:
The password must have a minimum length and must contain uppercase, lowercase, numeric, and special characters.
The password must not contain the username or the organization name.
Do not use previously used passwords.
The password must have an expiration time.
b. Include an account lockout after a specified number of unsuccessful login attempts.
Follow the configuration steps below for account lockout:
a. Open the Windchill Risk and Reliability Administrator.
b. Select Tools > Options > General. Select Lock User account after X Successive login failures and set it to an applicable value such as 3 unsuccessful attempts or as suitable.
c. Change the password of accounts created during the default installation in various components such as IIS administrative password. These often include default passwords such as admin or password. When setting a new password, use a strong password by following the strong password characteristics listed above.
Remove users from Windchill Risk and Reliability when they leave the company. By fully removing a user from Windchill Risk and Reliability, you can avoid any problems if the username is reused for a different user in the future.
d. If the user you want to delete is the only user in the Administrators group, you must designate another user as an administrator before deleting this user account.
To fully remove a user, perform the following steps:
a. In the Users pane, perform one of the following actions:
Right-click the user and select Delete.
Select the user and select Edit > Delete. The Delete User window opens.
b. Click Yes to confirm the deletion.
For more information about deleting users from Windchill Risk and Reliability, see the “Deleting User” in Windchill Risk and Reliability Administrator Guide.
3. Securing Cookies
a. Open IIS Manager and on the left-hand tree, click the site you want to manage.
b. Double click the Configuration Editor icon.
c. In the Section drop down list, set the value as system.web/httpCookies and press ENTER.
d. For the domain, write fully qualified name of the server in the format: <subdomain>.<domain>.com.
e. Set the httpOnlyCookies attribute to True.
f. Similarly, set the requireSSL attribute to True.
g. Click Apply to save changes.
h. Restart IIS server.
4. Setting Response Security Header
Add the HTTP response headers to a web site using the Internet Information (IIS) Manager. For more information, see Add a custom HTTP response header to a web site that is hosted by IIS in the Microsoft troubleshooting documentation.
HTTP response headers are name-value pairs of strings that are sent back from a server with the content you requested. They are typically used to transfer technical information such as how a browser should cache content, what type of content it is, the software running on the server and so on. HTTP response headers are used to transmit security policies to the browser. By passing security policies back to the client in this manner, hosts can ensure a much safer browsing experience for their visitors and reduce the risk for everyone involved.
a. Configuration steps for Strict Transport Security Header, X-content type options Header, and X-Frame Options Header
i. Open IIS Manager and on the left-hand tree, click the site you want to manage.
ii. Double-click the HTTP Response Headers icon.
iii. Right-click the header list and select Add.
iv. For the name, type Strict-Transport-Security and for the value, type in your desired option, for example, "max-age=31536000 ; includeSubDomains".
v. Add value nosniff for X-Content-Type-Options entry.
vi. Add X-FRAME-OPTIONS for name, and for the value, type in your desired option, for example, SAMEORIGIN.
b. Configuring the Cache Control
i. Open IIS Manager and on the left-hand tree, click the site you want to manage.
ii. From right-side pane, double-click Configuration Editor.
iii. In the Configuration Editor window, for the Section drop-down list, set system.webServer/staticContent as the value, and press ENTER.
iv. For the cacheControlCustom attribute under the clientCache section, type no-cache, no-store, must-revalidate as the value.
v. Click Apply to save the changes.
vi. Restart IIS server after making all the above configurations.
5. Removing the headers that expose server information such as the type and version of software running on the server and the frameworks that are powering it. Follow the steps below to remove exposed headers with sensitive information:
a. Removing headers for specific website
i. Open IIS Manager and on the left-hand tree, click on the specific site.
ii. Double-click the Configuration Editor icon.
iii. In the Section drop down list, set system.web/httpRuntime as the value and press ENTER.
iv. Set enableVersionHeader attribute to False.
v. Click Apply to save the changes.
vi. Restart IIS server after making all the above configurations.
b. Removing server header
i. Open IIS Manager and on the left-hand tree, click the root node, that is, server name.
ii. Double-click the Configuration Editor icon.
iii. In the Section drop-down list, set system.webServer/security/ requestFiltering as the value, and press ENTER.
iv. Set the removeServerHeader attribute to True.
v. In the Section drop down list, set system.webServer/httpProtocol as the value, and press ENTER.
vi. Browse to the customHeaders attribute values.
vii. If there is an X-Powered-By entry, select it and click Remove from the right most pane.
viii. Click Apply to save the changes.
ix. Restart IIS server after making all the above configurations.
6. Disabling Insecure HTTP Methods.
Insecure HTTP methods other than GET and POST must be disabled on the web server. These methods allow additional functionality that an attacker can use to conduct further attacks against the environment and its users. Follow the steps below to disable insecure HTTP methods.
a. Open IIS Managerand on the left-side tree, click the site you want to manage.
b. Double-click the Request Filtering icon from right-side pane.
c. Select the HTTP Verbs tab and click the Deny verb link from the Actions section.
d. For the verb, type OPTIONS and click OK.
e. Repeat the step above for TRACE.
f. Restart IIS server.
g. Request filtering option should match following snapshot.
7. Securing log files to ensure the access is restricted. When managing logs, consider the following points:
a. Grant operating system permissions appropriately on the log files.
b. Monitor growth of web server log files and investigate:
Any unusual increase in size.
Unusual number of HTTP response errors such as 40x or 50x.