New Wrinkle in PLM Security Controls

Computerworld - Our product life-cycle management (PLM) implementation has a number of security considerations, and I've been providing input on the security best practices that I think should be included when this application is rolled out.

The PLM application will become the repository for a lot of sensitive data, such as source code and design specifications, that's housed in various legacy applications. Those applications predate my arrival at the company, and they are lacking in several areas related to security. I want to be sure we start out on the right foot with this new application as part of my efforts to better protect the company's intellectual property.

It hasn't always been easy, though, and I don't imagine that I am very well liked among the members of the PLM team. Just this week, a new requirement for the PLM application came to my attention that was a bit alarming.

But let me review the history of this project before I get to the latest wrinkle. About four months ago, I met with the PLM team. Our first decision was to assign the data that will reside in the PLM application one of two classifications that are consistent with the company's data classification model: Confidential, and Confidential Special Handling. As things went along, I was expected to provide my security requirements. I was very specific while trying to be reasonable. I didn't ask for things that went beyond the scope of the project, were too expensive to implement or, like identity management, didn't fit in with the company's current security model.

I required that each user have a unique ID on the system - no more sharing of credentials, as has always been the case with our legacy applications. I want everything that happens in the PLM application and to the data stored in it to be audited: checkout, check-in, log-on, log-off and the granting of administrative privileges. We have to be able to document these things so we can properly investigate any theft of intellectual property. Our current systems don't provide this essential information, so our investigations have been stymied.

I also demanded that we apply the rule of least privilege so that users will have authorization to do only the things they need to do to accomplish their jobs. Our legacy applications lack this, and since data isn't segmented by authorization level, anyone with an account can gain access to data that's classified as Confidential Special Handling.

I also wanted to deploy Secure Sockets Layer between the clients and the Web server, but the business decided not to implement SSL. So I followed my standard practice in cases like this: I crafted an e-mail laying out the risks inherent in rejecting the SSL deployment, and then I had the program manager sign off on this risk accountability and acceptance document. Once he did, I forwarded it to the CIO. Now, should a breach occur that would have been prevented had we deployed SSL, I have documentation showing that I identified the threat but was overruled on the mitigation.