Pro/User Data Management Committee White Paper

Pro/PDM 3.0 Data Security

April 1996

Requirement

A site needs to be able to restrict access to the data stored on a PDM server.

Problem

Today, there are three easy ways that data can be not only read by unauthorized users; but it can be modified or even deleted.

  1. A user who has root access to a pdm server can modify it's pdmservers.txt file to include other PDM servers of other sites. Root can switch-user to any other userid which has manager access to databases on the other servers. When PDM is started, the user can gain manager access to the data on the other server. The other site has no way to prevent this unauthorized access.
  2. Any user that has root access to a workstation on the AMP network could install the PDM client software locally on the machine. He could then modify the pdmservers.txt file on the workstation to include any PDM server on the AMP network. Again, root can switch-user to any userid and gain unauthorized access to any data stored in PDM at AMP.
  3. Any user with root access to an authorized client of a PDM server could create a local account as a userid which has manager access to a PDM database on the local server. As this other user, unauthorized access to the local server can be obtained.

There is no effective way to prevent unauthorized access to data stored in Pro/PDM 3.0.

Proposed Solution

Maintain a list which can be used to grant access for a userid for a specific hostname. The list would contain three fields for each userid@hostname level_of_access Asterisks, "*", could be placed in either of the first two fields to allow wildcards. This would allow a site the flexibility to restrict or open up access to their databases. When the connection is attempted to be made to the PDM server by a client, the user's userid and hostname are checked against the list. The level_of_access should be broken down into at least 3 levels:

If the level of access allows, that user could inform the Pro/PDM software that he would like his actions performed as a database (not software) administrator and perform "privileged tasks". This should be a toggle switch. A scheme to remind the user that they are operating as an administrator would be very useful, even if it was a code appended to the window banner.

A database administrator should be allowed to create and rename product databases, but should not be allowed to change the software configuration (dbpaths, etc) or modify the admin database. These tasks would be restricted to software administrators.

In addition, Pro/PDM should allow userid/password entry to be required on application startup to gain access to a server. This means that if a site wants to turn this option off, Pro/PDM would not require the user to login. However, if a site is concerned about the data security, this option could be enabled.

The proposed solution is only one way to solve the problems listed above. There are other solutions which would be acceptable as long as the problems indicated above would be corrected.

 

Principles

Below are some other priciples that should be considered:

  1. The security in Pro/PDM should be optional. If a particular customer requires no or little security, they should be able to install with the security level required.
  2. Security by application login (userid and password) is the preferred method of security.
  3. Never send the authenication information (userid and password) by clear text. It should be encrypted.
  4. The authentication security should not be the machine id alone. It should be by userid. Security by machine id can be an administrative nightmare.
  5. It is desirable for the authentication server to maintain the context, i.e., there is no need to login repeatedly for multiple applications during a session.
  6. Use an industry standard for the authentication method. Examples are:
  7. Most of the more popular commercial databases can use one of the industry standard authentication methods.

Useful Definitions

Authentication
Authentication is proving you are who you say you are. In a network context, this means that clients and servers must verify their identities before any requests are processed. Strong authentication of users and network applications protects against network spoofing.
 
Authorization
After a server has authenticated it's client, the server needs to determine the resources to which the client has access. This authorization service is provided in the application server. The authentication mechanism guarantees a user's identity but the authorization service is responsible for determining which portions of an application or its data is available to that user.
 
Data Integrity
Data integrity is a mechanism to determine whether a message arrived intact and unaltered. This may be an encrypted checksum of the packet. Data integrity degrades the performance somewhat but has less overhead than full data encryption.
 
Data Privacy
Data privacy hides the contents of messages from possible eavesdroppers. The method for achieving data privacy is most often encryption. There is a performance penalty for using data privacy.
 
Encryption
Scrambling data in such a way that it isn't readable. To read teh data again, the data must be unscrambled (decrypted).
 
Key
The object that is used while encrypting and decrypting data. If you know the key, then you can decrypt an encrypted message. The key is usually a 64-128 bit string.
 
Ticket
A ticket is your network identity. After you're authenticated, the network security service will issue the ticket. By giving the ticket to other network services, you can securely present your network credentials without logging in again. The servers are guaranteed that you are presenting the correct identity because the ticket originated from the security server.

Author

Jeff Brent, Amp Incorporated - jeff.brent@amp.com