Security in Windchill – Part 2 of 2
In my last post on the theme security I provided some general tips for creating a safer server environment and gave examples of what threats exist. The conclusion was that with good routines and with a complete backup we can manage most situations. Since my last post was published, major headlines around the world covered a virus called WannaCry. This was a so-called ransomware which encrypted disks and forced the owner to pay a sum of money to unlock them. Fortunately, this virus was quickly stopped, but it gave an indication of how serious this type of attack might be.
However, this post is more about what we can do in Windchill to protect us from threats outside and inside our company. Above all, it is about preventing unauthorized people from getting important information such as drawings and internal documents.
The risk of the usual HTTP protocol is that it does not encrypt the information that is being sent. If users log in via HTTP, it is possible for a third party to read the information sent, including passwords and usernames. A good first step to raising security levels is to encrypt information being sent between client and server by using HTTPS. With the HTTPS protocol, all data transmitted is encrypted and cannot be read by third parties. This prevents e.g. that passwords end up in the wrong hands. Setting up HTTPS is a relatively simple configuration and essentially requires only a signed SSL certificate. These can be arranged by a number of different suppliers and cost no more than hundred euros per year. If there are plans to give users outside the company access to the Windchill environment, e.g. vendors, partners etc. the company should think about how these users will login to Windchill. Can anyone listen and steal their login information if we do not use HTTPS?
In the simplest set of Windchill, users are locally located in Windchill's own user database. The password is set when the user is created, and usually the password isn’t changed on a regular basis or might even be the same as the username. I have seen this many times at different customers, and my recommendation is to not have passwords equal to username, it’s too easy to guess. There is a possibility to set a time limit for passwords, special character requirements or restrict password reuse. However, this is something that is usually already managed by the company's Active Directory (AD), so a long term solution might be a link between Windchill and your AD.
Instead of allowing Windchill to manage all users, passwords and policies, Windchill can be linked to the company's AD. This allows reuse of existing frameworks, which also allow a greater control of users. For example, accounts can be locked in too many incorrect login attempts and accounts can be disabled when users quit. It also allows users to have the same password for example for Windows and Windchill. I can imagine that this eliminates a risk when users need to remember multiple passwords.
User Rights in Windchill
The basis of all Windchill installations is the rights the users have. The rights control everything from who will see what to who will approve what for e.g. for production. But it can also affect security in such a way that the user has too much rights. As a consequence, people will be able to see information they should not be entitled to and, at worst, spread this outside the company. "Intellectual Property Theft" is becoming more common, and companies should keep in mind what roles should be able to do what. But also consider different rights for different locations in the world, for those companies that are represented in several regions. One way to enforce a more flexible but yet secure solutions is what’s explained in the next section.
A feature in Windchill used more and more often is Security labels. The purpose is to add an extra protection and provides the ability to control documents with different security classes. This is a simple but powerful solution and serves as an addition to the common rights in Windchill. A problem that may arise with restrictive access rights is that it reduces the possibility of collaboration, when general rights must be set. But with Security Labels (SL) we can define access individually for each object. The objects are then classified based on a number of custom classes, such as "Secret" and "Public" or "High" and "Low". We connect these objects with a link between each classification and a group. As a result, all members of the group associated with "Secret" will be able to see the items stamped with this SL. This ends the theme of security.
In summary, I can say that with fairly small efforts, the risk of information being lost or ending in the wrong hands is reduced. Remember to continuously evaluate who has access to the system and what protection is available to prevent attacks from outside. Additionally, check periodically that backups are done as they should. I've seen too many times how it has been years since the last backup with possible data loss as a result.