cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Secret/Secure projects

spikaart-2
1-Newbie

Secret/Secure projects

Hi all,

I'm looking for some advice on strategies for handling design work in our company that needs to be kept secure/secret from all users except those specified as having permission to access it. Additionally, those people who are given access should only have access for as long as they need it to do their work and then their access should be disabled.

I've done some looking into possible solutions like security labels, projects (project link), and using products with "private access". Can anyone in the group chime in on what they've done? What solutions have you implemented and what long term ramifications do I need to be aware of?

FYI we are a contract house building automation solutions so we produce large numbers of new designs to release on a yearly basis. Probably on the order of 400+ newly released assemblies each year with an average of 200 unique constituent parts/subassemblies. Rarely do any of these objects get revised once they reach the final released state. I point this out because managing each design in a separate product context may be a challenge. We currently manage all designs in a single context with sub-folders for each machine we're designing. This may play an important roll in a good strategy to handle Secret/Secure projects.

Any input you all can offer will be much appreciated.

Steve Pikaart

13 REPLIES 13

When you say you've looked into ProjectLink, does that mean you've looked into the collaboration actions between PDMLink and ProjectLink? Using the Add to Project/Send to PDM/PDM Checkout functionalities would allow you to give access to a group of users and then easily revoke it when necessary.

Hi Caitlin,

Yes it does mean that. Seems like a viable solution but no sure just how secure it is and how confident I can be that the information is not accessible to those who should not be able to see it. Sounds like you think ProjectLink would be a good solution. Yes? Do you know how Security Labels work and how "private" projects work? Are these also good solutions? If not, why?

BenLoosli
23-Emerald II
(To:spikaart-2)

I used to manage a site that had a couple of classified programs running and we had to keep the data secure from others in the company yet allow them access to the company wide standard parts libraries.

Security Labels take some thinking to implement but would also limit access to specific objects in the system. The Private Projects would work on all files in that project folder.

You do need a test server to set up security labels because when you do the setup, one typo can disable Windchill all together. This is documented in the Security Label guide. Also plan on at least a week to go through your users and assign them to the proper teams for the security labels and be sure to test it beforemoving to production.

I think you should explore PDM/Project sharing.

I'm not very familiar with security labels, so I can't speak to those.  Private access domains allow you to bypass any global rules set at the org level, thereby providing more restricted access. But, generally speaking, non-admin users should not have access to objects in contexts in which they aren't a member. This CS article gives an overview on that: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS212423

What you can do is ensure these users do not have access to the product context (which should be the default), and then add them to a project. Depending on the access you want to provide, you can either share or PDM checkout objects to the project (or a combination of both).

This would only allow them to view what you've explicitly shared -- they wouldn't be able to navigate back to the product context. They won't even be shown the name of the source product or the source folder. If there are child/parent parts or related objects, you'll need to explicitly share those as well -- they won't be given implicit access to any related data.

If you want to allow users to actually make changes to objects, you can use the PDM checkout option. They'll be able to work on the object from the project context, but the change won't be 'committed' until it's sent back to PDM. In order to send it to PDM, you'll either need to A) provide 'Modify' access to the source PDM object, or B) have a user with appropriate permissions do it on their behalf. You can maybe use some sort of notification/approval routing to do this.

Basically, the benefit of this is that if you have a product with 200 parts but only want to give access to 5, you don't have to worry about setting access control rules for 195 parts, or worry about any new parts that might be created, or if someone might make changes that would invalidate those rules you set up. You're also don't have to worry about conflicts with ongoing PDM work (only a specific version is shared until you update it, and you must have product permissions to update shared objects).

The WHC goes through a few use case scenarios and provides some more info: http://support.ptc.com/cs/help/windchill_hc/wc102_hc/InteropShareTypes.html

Linking PDMLink to ProjectLink is very insecure and buggy due to their unique histories development wise.  Very easy to accidentally provide too much access.

Best way around this, create unique product and library templates, delete all pre-existing roles except members. Leave members blank' roles blank.   Define new roles and add. Create groups for each role.  Each role should be only for a specific action, i.e. create part, create document, download file, you get the idea.  At the organization and product or library levels, delete any permission for things like documents, parts, change objects. Redefine them, all of these permissions, to the specific roles in the product correlated by permission to role name. Never assign permissions to or retain permissions for a team members' role. Add one group per role, no users individually.  Use the principal/participant administrator to add users or other groups to this role specific group.   It's a bit to to set it up, but for auditing and ensuring access is in fact controlled, this is the ONLY way that will be transparent between upgrades and other scenarios like patching, cleaning system in case data has to be segregated later on, etc.

Check your lifecycles, workflows, and team templates where applicable to ensure there are no extra privileges. Adjust accordingly.

To be honest, my favorite, but never implemented in production system is to use a workflow associated to a type of change notice authorizing approval to initiate work, continue work, or revise work. Task approvals must be digitally signed, no simple 'complete button' task. The workflow temporarily grants permissions, only to revoke them after the process task is completed.

As for protecting the actual stored content that is uploaded, customization is required to encrypt data during upload and decrypt at download (if desired).  Additionally a similar thing is required to handle obfuscation in the database along with other compliant controls.  This would ensure even database administrators have no context to what they are looking at but the data is still solid.

Obviously encrypting connections of all kinds, isolated disk storage, multi-factor (multiple levels of authentication) , and you got yourself a good locked down system assuming only the public key is stored on the server, and the private key is never transmitted.

Actual hacking of the system would provide no intelligence and any middle man attack would break functionality alerting users to a breach.

You would need a different front end web server to provide access to Windchill as default configuration is locked down tight, there are still openings.

Okay, maybe it does need to be this secure, but I have no idea how secure you need.

Anything else is fresh flowers, in a couple days you'll decide it is time for new flowers and discard the old.

I am sure or would be surprised if I do not generate further comments from others after posting this response.

Good luck.

Hello Steven

it looks that you have different flavour depending on experience. Mine goes quite the opposite way to what David replied.

I have used PJL (ProjectLink) very successfully for "secret" projects. One of them was the closure of a site. So we needed to proactively prepare the recipients sites for the new production while the site that was going to close did not know how that work was in preparation.

We were able to share to the project PDM data, create new iterations in the project itself without anyone knowing. Even inside the project we created folders to also control who could see what within the project as the recipient sites were not aware of what was going on at the other recipients sites.

I appreciate that the project manager must be quite Windchill astute to understand the management of the objects, access permissions etc and the Query Builder also helped to ensure authorisation was granted appropriately.

The beauty of this was when it was made official and public knowledge, we were able to push the new data into PDM and have them fit the group standards immediately as all the work was done within group standards.

If I were in your shoes I would simply use ProjectLink but also ensure that my Windchill configuration (especially ACL) is appropriate.

It is all good to say that such company is doing that but your Domain Policy could be very different (eg I know that some companies create access permissions at the top level, so everytime a new context is created people have access to it automatically, including projects. If that is the case then the entire structure must be reviewed).

I am quite interested in knowing what you decide to solve that situation for your company.

I do not know security label so will not comment.

Yeah, avoid security labels, they are either content is visible to person, or not.  More effort to configure, relies on user to classify content. Users then lean torwards customizing to automatically set the object's security label. I find them useful for workflow based tasks and users can never edit them.  I would add to my statement from yesterday configuring access controls at a folder level is not a good unless you force content to go to only one folder and deny move, saveas, or copy/paste permissions.  Further, folder level permissions can impact performance of the system.

I am a big advocate of multiple organizations in Windchill to segregate data, but it does complicate policies if you are coming up to speed about how things work.

Also, as pointed out you must entrust system to the project manager, which I have found to be very bad decision in the past.

A well designed and secure system omits the need for people dependencies to ensure security.  Build a fortress, test the fortress, do not let those inside fortress to alter any settings that would be akin to adding a new passageway into your fortress.

A big factor in other responses will be user base size, how the system is hosted, what other systems can push or extract information, other customizations, and network hierarchy.

To use PJL / PDML interactions would require me to request from PTC, proof it has been tested well. Legacy code still resides in the system without elaborating for security reasons.

TomU
23-Emerald IV
(To:spikaart-2)

Be careful as well how you publish things.  You may want to look at using positioning assemblies.  The default, out of the box publishing method will include all required objects in the resulting representation, regardless of where they are located in the system.  That means if someone (who has clearance) creates an assembly outside of the secure area that references some secure object, that secure object will be full visible in the insecure object's representation.  By using positioning assemblies, the object's name will still be visible, but the users in the insecure area will be unable to load it.  (This is true for both restricted products or libraries and security labels.)

If you have remote file servers, you also need to review what content is allowed to replicate to them.  There is a way to give the remote file server only certain permissions.

ddemay
1-Newbie
(To:TomU)

Good catch Tom. 

We are considering positioning assemblies for many reasons beyond this. Thanks for the heads up though. Good to know that.

Private Products.

PJL was designed to be collaborative. But, more importantly;

- You can never Check into PDM this data, because your PDM system is not setup to handle this "secret" data

- Most ACL configurations have probably been done at the PDM domain level, this means you have to rethink and test everything since the PDM domain does not apply to PJL.

- PJL is not setup for change management, promotion requests etc. So, are those important to you?

- Projects can be deleted

Security labels are great, for what they are intended to be. But they take more time and you don't need the capabilities associated with it.

Don't be too afraid about creating multiple product contexts, yes they 'live forever' or close to it, but private domain was setup to do exactly what you need.

Dan, I'm leaning this way (private products). There is still some decision making to do but I will update this thread once that decision is made. And I will give the pro's and con's relative to what we decided.

Thanks all for your input. It's much appreciated!

Hi there,

We've been doing this since day 1 of our use of Windchill. It takes a combination of the context setup and the access control rules in the Policy Administrator.

First, set up all of your access control rules by role, i.e. Guest would be read-only, and try to avoid rules that have Principal/ALL. Make sure all of your contexts have the same role set, perhaps set up a template for them that has all the roles you would need for the main change objects.

Then set up the "secret" contexts only adding members involved with it.

The moment you put them in a role, boom, they can see everything in that context and have all the access that has been set on that role. Once they're finished with that product, take them out of the role.

With this setup if someone is not a member of a context they will never, ever find it or anything inside it, even on a search, so you have perfectly hidden data.

On the flip side, if you have a context where you do want every user within an Organization to see the data (such as a product context or library that contains general COTS fasteners, fittings etc), a quick trick is to put the Organization itself into the Guest role provided you've been setting the user accounts to that Organization. Now everybody can read those files but not edit them; we call these contexts Public ones.

Hope that helps.

Top Tags