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. 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.
|
|
As a secure deployment guideline PTC strongly recommends you configure HTTP-Strict-Transport-Security (HSTS) in your Windchill installation.
|
2. 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.
3. 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.
4. 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.
5. Securing the WEB-INF directory.
Check to see if the contents of
<Windchill>\codebase\WEB-INF are accessible. The default Apache configuration is expected to deny access to that directory and its contents from all web clients. However, Due to a regression in the default configuration of Apache in Windchill 11.0, the contents of that directory may be accessible from web clients. Even though this issue has been addressed in 11.0 CPS releases and maintenance releases, it is still recommended that you perform the verification and if accessible then take corrective action. More information about this issue is available in
Support Article CS256080a. To determine if this directory is open, access the following URL: http://<yourhostname>/Windchill/WEB-INF/webapp.properties
b. If the file is displayed after authentication then the directory is accessible.
6. 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.
7. 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.
8. 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.
9. 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.
10. Ensure that Directory Listing is disabled on your web server. Out of the box, HTTP Server does not allow directory browsing.
11. 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)
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
f. Start the Windchill server.
12. 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 > > . 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.
13. 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.
> > . The Server Status window opens.