Secure Modeling Best Practices
Setting up a secure model in ThingWorx is one of the most critical steps in model development to ensure that users have the correct access to the assets in the model and that security implications are considered for every step. Managing edge security is an important aspect of this process. In ThingWorx, you need to set up granular permissions on Remote Things by:
• Creating unique users that represent the Remote Things
• Assigning the users to the correct organization
• Creating unique application keys in the unique user context
 |
If you are using file upload functionality in your application, be aware that file upload allows users with appropriate access to upload any type of file content to the system. PTC does not guarantee that the files uploaded are safe and that the input comes from a trusted user.
|
The information in this topic is intended to provide tips on what not to do when setting up security in a model, as well as best practices for setting up a model to be as secure as possible.
Managing Edge Security
Managing Edge security is an important aspect of securing a model that begins with the model building and continues with secure deployments. The Edge is a barrier between the modeling environment in ThingWorx (Composer) and external data sources. There are many ways that Edge security is managed in ThingWorx, including using TLS/SSL communications to communicate between the Edge and the platform. Using TLS/SSL results in the following:
◦ Remote Things validate the server with certificates.
◦ Traffic is encrypted using TLS.
◦ Application keys authenticate the remote Things to the platform, and the user context associated with the application key restricts access within the platform.
Practices to Avoid
While there are steps you can take to make the Edge as secure as possible, some practices can detract from the overall system security. These practices include the following:
• Turning off SSL is not recommended. Even on cellular, certain networks have known flaws in the security architecture.
• Using certificates with known vulnerable hashes.
◦ Do not use MD5, SHA1, etc. Use something that is NIST recommended.
◦ Do not use self-signed certificates outside of development.
• Using the same application key for multiple devices. Connections are authenticated using application keys. If application keys are not unique across devices, it will be difficult to audit impersonated or malicious connections across connections.
• Using application keys with broad permissions. This can lead to assets being granted access that they should not have.
Practices to Use
• Use a trusted certificate authority.
• Use client certificate authorization – Mutual TLS.
|
|
Your system integrator is responsible for implementing this technology. Refer to the C SDK Users Guide for implementation details.
|
• Use application keys. When setting up application keys and ThingWorx users, always grant the least amount of privilege. It is not a best practice to assign a member of the Administrator group to an application key.
Setting up the Model
To fully secure your application, it is always best practice to secure using the following principles:
• Grant the least privilege
• Defense in depth
• Secure defaults
1. Set up Organizations
The first step in building a secure model for Edge devices is to properly set visibility to entities using an Organization. Organizations can provide system-wide visibility settings for users with appropriate access to your application.
2. Set up User Groups
Set up user groups to develop access controls based on user roles.
|
|
ThingWorx provides several predefined user groups. For more information, see User Groups.
|
3. Set up Users
Users provide granular access to data. After organizations and user groups are set up, one user should be created for every uniquely permissible entity on the platform. From an edge standpoint, this means creating one user for each edge device that will be connected to the platform.
4. Set up Application Keys
Application keys are used to gain secure access to the platform, and are linked to a user context to determine permissions. One application key should be created for each edge device that will be connected. There should be a 1:1 ratio for application keys and users / devices.
5. Set up Remote Things: Visibility, Design Time, and Run Time Permissions
After creating the Remote Thing, the first security context to set is the visibility. Visibility affects organizations and organizational units.
Next, set design time permissions. Design time permissions should only be given to trusted users who are meant to modify the behavior and the model within the application. Usually, this means that the user / device will not have design time permission, because the device should not be able to modify its own behavior.
Finally, set run time permissions for the user who represents the device so that the device can functionally contribute to the application. Run time permissions are important for granularity. At a minimum, set up run time permissions so that the user can only access the Thing. If necessary, more granularity can be set on properties.
Additional Tips for Setting up the Model
• It is a best practice to remove all design time permissions in a production environment to avoid possible regressions in business critical applications. All design should be implemented and validated inside a sandbox, and then deployed to a production environment only after a successful validation of the application.
• Users, application keys, and remote things can be created programmatically, but any services created to implement this feature should be tightly controlled within the security model of the application, and they adhere to the guidance as described in the previous section.
• If there are two Edge Things connecting through the same EMS or SDK, it is not possible to assign one application key to each edge thing. If the permission model for these devices needs to be separated, it is recommended that they are connected through separate SDKs to provide separate security contexts for each connection endpoint.
• If there are applications that require multiple data sources per Remote Things or if multiple users are accessing different pieces of the same Thing from a mashup, run time permissions can be set on individual properties and services.
• When working with any data storage type entity (wikis, blogs, data tables, streams, and value streams), it is recommended to provide service execute permissions to the Platform Subsystem GetDefaultDataPersistenceProviderName service. A user must have visibility to a least one persistence provider in the system to create new data storage type Things.