Best Practices for Securing Your Windchill Solution
The following list provides some basic actions you can take to help secure your Windchill solution. Some of the actions include customizing files. For information about customization best practices, see the Windchill Customization Guide.
 |
This information is provided only to assist you with secure configuration of Windchill. PTC does not provide support for any third-party products mentioned here, nor is PTC responsible for your security infrastructure.
|
1. Always deploy Windchill in a controlled, secured, and trusted network which is accessible only by the trusted users. This includes all deployed Windchill clusters.
2. Configure the web server to use HTTPS.
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.
For more information about setting up your web server for HTTPS, see Configuring HTTPS for Apache and Windchill.
|
|
As a secure deployment guideline PTC strongly recommends you configure HTTP-Strict-Transport-Security (HSTS) in your Windchill installation.
|
3. Modify the length of the encryption key used to protect sensitive information from 128 bits (default) to 256 bits. For more information, see Modify Encryption Key Length.
4. Protect data at rest by turning on Oracle Transparent Data Encryption (TDE). Encrypting the data in the Windchill database will prevent data visibility from unauthorized access. This provides an additional layer of protection for your IP and reduces the overall attack surface of your Windchill solution.
For more information, see Oracle Database Encryption Using Transparent Data Encryption (TDE).
5. Remove the following from the Windchill web-accessible directories on a production server:
◦ implementation examples
◦ sample code
◦ API documentation
Examples of these include, but are not limited to:
◦ <Windchill>/codebase/infoengine/docs/apidocs
◦ <Windchill>/codebase/netmarkets/jsp/apiDocs
◦ <Windchill>/codebase/netmarkets/jsp/carambola
◦ <Windchill>/codebase/wt/clients/library
◦ <Windchill>/codebase/wt/clients/filevault/*.doc
◦ <Windchill>/codebase/CustomizerDoc
◦ <Windchill>/codebase/wt/fv/docs
◦ <Windchill>/codebase/com/ptc/core/HTMLtemplateutil/examples
◦ <Windchill>/codebase/config/logicrepository/xml/explorer/structureexplorer/configurablelinksexample
◦ <Windchill>/codebase/CambridgeDocs3/SampleData
◦ <Windchill>/codebase/registry/ixb/samples
where <Windchill> is the location where Windchill is installed.
6. Securing the WEB-INF directory.
Check the contents of <Windchill>\codebase\WEB-INF directory and the directory accessibility. The default Apache configuration is expected to deny access to that directory and the directory contents from all the web clients. However, it is recommended that you perform the verification to ensure that the directory contents are not accessible. To determine the URL prefix or the pattern that might allow access to this directory, check the configuration in <APACHE_HOME>/conf/conf.d/30-app-Windchill-Auth.conf file. Check and validate if web access is restricted for all the configured alternate URL patterns. If accessible, take corrective action. For more information, refer Support Article CS375403.
a. To determine if this directory is open, access http://<Windchill_URL>/WEB-INF/webapp.properties.
b. If the file is displayed after authentication then the directory is accessible.
7. Secure RMI (Remote Method Invocation).
For more information, see the configuration guidance in Firewalls.
8. Cross-site request forgery (CSRF) protection is enabled by default to protect data-altering actions in Windchill against CSRF attacks. For more information, see Cross-Site Request Forgery.
9. Establish a strong password policy for your Windchill solution. Strong passwords have the following characteristics:
◦ Have a minimum password length
◦ Contain uppercase, lowercase, numeric, and special characters
◦ Do not contain the user name or the organization name
◦ Have an expiration
◦ Include account lockout after a specified number of log on attempts. By default, WindchillDS will lock an account when an incorrect password is entered 5 times in a row. The lock is effective for 15 minutes.
10. Change the passwords of default accounts created during data loading. These often include wcadmin or demo. When setting a new password, use a strong password by following the strong password characteristics listed previously.
For more information, see User Password Management Options.
11. Remove users from Windchill when they leave the company. By fully removing a user from Windchill you will avoid any problems if the username is reused for a different person in the future. Use the following steps to fully remove a user:
a. Remove the user from your directory service or remove Windchill visibility to the user entry.
b. Use the Delete from Windchill action from the Participant Administration utility.
For more information about deleting users from Windchill, see Deleting Users.
12. Ensure that Directory Listing is disabled on your web server. Out of the box, HTTP Server does not allow directory browsing.
13. Enable auditing for critical events. Creating regular records of logged events is valuable when investigating any suspicious activity. Out of the box, Windchill records system usage, organization usage, download events, and any potential CSRF events.
Consider logging the following auditing events:
◦ User logons
◦ User logouts (available with forms based authentication only)
◦ User password changes
◦ All access control modifications:
▪ Access permission and policy changes
▪ Changes to teams, roles, and groups
◦ Content additions, deletions, or moves:
▪ Import
▪ Export
▪ Download
▪ View Representations
▪ Sharing across contexts
◦ Object or participant creation or deletion
◦ Life cycle state changes
◦ Security label modification (if security labels are enabled)
For information about enabling audit events, see Configuring Audit Event Recording.
If you enable audit event logging, you should also consider preventing the purging of audit records from Windchill by removing Delete permission on all auditing tables from the Windchill database application user. To remove the permission,
a. Login to the database as the database administrator using the Oracle SQLplus utility.
b. Create a Windchill database application user if one does not already exist. The user can be created by executing the <Windchill>\db\sql\create_wc_app_user.sql script.
c. Remove the Delete permission on the Windchill audit tables for the Windchill database application user using the following: SQL> revoke delete on <WC_db_user>.AuditRecord from <WC_db_user> where <WC_db_user> is the database application user name.
d. Stop the Windchill server.
e. Run the following commands in a windchill shell to update the database properties with the database application user information:
xconfmanager -s wt.pom.dbUser=<WC_db_user> -t "db/db.properties"
xconfmanager -s wt.pom.dbPassword=<WC_db_user_password> -t
"db/db.properties"
xconfmanager -p
xconfmanager -s wt.pom.dbPassword=<WC_db_user_password> -t
"db/db.properties"
xconfmanager -p
f. Start the Windchill server.
14. In order to help protect against a potential Denial of Service (DoS) attack, ensure that the rate limiting is enforced for Windchill deployments. PTC recommends not relying solely on Apache configuration to ensure the rate-limiting is enforced.
◦ Improve the security of Windchill deployments by using Firewall (or other Load Balancer) with suitable rules and policies to control the traffic reaching Apache. Consult your internal security team to decide on rules and policies for your environment.
For more on Firewall in Windchill configurations, refer Firewalls.
◦ Apache HTTP Server provides secure configuration guidance and tips. For more information, see Security tips. Windchill uses the default configuration settings for Apache. These settings should be tuned to customer requirements, but might not provide complete rate-limiting enforcement for Windchill.
15. Consider the following for managing logs:
◦ Grant operating system permissions appropriately on the log files
◦ Generate log statistics and perform log analysis on a server other than the one that generates the logs.
◦ Monitor growth of web server log files and investigate
▪ Any unusual size increase
▪ Unusual number of HTTP response errors such as 40x or 50x
◦ Implement scripts to examine logs in real time or after set intervals
◦ Enable certain logging functions on a production system only when troubleshooting an issue. For example, use the following steps to record client error log messages to the method server log:
1. Navigate to Site 
> > . The Server Status window opens.
> > . The Server Status window opens.2. Click the Monitoring Tools link. The System Health Monitoring Tools window opens.
3. Click the Log Levels link.
4. Enable logging with the following settings:
▪ Select Server Managers, Method Servers, and Servlet Engines under Server Processes.
▪ Enter wt.log4javascript in the Logger field.
▪ Set the logging level to ERROR
5. Click Set to enable the logging.
After troubleshooting, disable the logging function by setting the logging level to OFF.
◦ Use the monitoring tools to analyze the logs. For more information, see Using the Monitoring Tools.
16. Follow the security guidelines listed below when customizing Windchill code:
◦ Protect actions that create, update, or delete data from cross-site request forgery attacks.
◦ Use prepared or parameterized statements in SQL queries. This will prevent SQL injection attacks.
◦ Consider any data coming from an external resource untrusted. An application is vulnerable to injection attacks if untrusted data is not properly handled. Examples of untrusted data include the following:
▪ Data stored in the Windchill database that originally came from a user or external system. For example, object name, number, or description.
▪ Data coming from the client (including request parameters, form fields, hidden fields, query strings, HTTP headers, and the URL).
▪ Data stored in LDAP that originally came from a user or external system, such as a username.
▪ Data stored in any external database
◦ Validate all untrusted data for correct data types, format, and length. Untrusted data includes form fields, query strings, HTTP headers, cookies, and the URL.
◦ Use proper encoding based on context, such as HTML encoding, JavaScript encoding, or URL encoding, on all data that is rendered in the browser (client) to prevent Cross Site Scripting (XSS) attacks.
◦ Ensure that classes implementing RemoteAccess are not bypassing access control, elevating privileges, or inappropriately accessing the file system.
◦ Delete all unused code.
For more information, see the OWASP top 10 guidelines (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).