Protecting Intellectual Property with PLM Products
Author:
This article is written by our contributing author Ken Lassesen. His bio can be found here .
Your firm critical Intellectual Property (IP) is often stored in products such as Enovia or Windchill. Intellectual property includes designs and specification of current and future products. The loss of this IP to competitors can have major financial consequences to your firm (as well as your job security). Enovia has a robust front-end protection of IP through its ENOVIA IP Export Enforcement offerings. Unfortunately, studies have shown that IT Departments leak most data – usually on a Tuesday.
Protection at the database level is something that is a little complex but may be done in a step-by-step method. IP may be lost via disgruntled employees or lax procedures. A few examples of losses of IP are:
- Hard drives replaced because of impending failures with the old drives donated to charities or simply put into a dumpster.
- Risk: Discarded drive may contain a full copy of the database, or backups which could be salvaged by competitors.
- Read more: A Hard Disk Shredding Story,
- Disgruntled employees: Any employee, contractor or consultant that has permission to log on to SQL Server has the potential ability to copy some, or all of the IP in SQL Server, even after they have been terminated if appropriate safeguards are not in place.
- Leaving ports open: Although you may have isolated SQL Server from the internet, modern hackers are often successful in getting malicious agents installed on internal company machines that access the internet. Once the agents are installed, they can proceed to search for access to the IP database.
When I attended several conferences on the Security Content Automation Protocol (SCAP) at the National Institute of Standards and Technology, it was interesting to hear how some agencies would glue over every USB and FireWire port on a database server and required any CD or DVD writer on the machines to be locked with a physical key. Clearly, some folks take data security very seriously, unfortunately the norm is less rigorous – perhaps lax in a few cases. For more information about this issue see: Data Theft.
I recently attended a talk by the futurist, Mark Anderson, and he commented, “In today’s world there are two types of data theft – Identity, which tends to be a Russian thing; Intellectual Property, which tends to be a Chinese thing.” He went on to indicate his belief is that the greatest risk to western wealth is IP theft.
In this post, I will look at the first aspect of improving security on Enovia or Windchill with both SQL Server 2005 and SQL Server 2008. In subsequent posts, I will drill down further into other ways of improving security.
Securing Mixed Security on SQL Server
Both Windchill and Enovia require either standard or mixed security so that the JAVA and C++ components may talk to SQL Server. The core problem in protecting unauthorized access to IP stored in SQL Server is securing login access to SQL Server. To gain access you need the login and the password. If you know the login then gaining access is much easier – you just have to find the password! A very common form of security exposure is not changing the default login from that shown in the installation documentation.
Since the default behavior for SQL Server does not disable a login after N failed attempts, an agent can just proceed to try every possible password combination -- a brute force attack. Often a faster dictionary attack on the password is sufficient. I will show you how to disable a login after N failed attempts in a future post.
A wise decision is to assume multiple malicious agents inside your network that are actively attempting to steal IP. The Stuxnet attack would have gone undetected for years if Stuxnet was not a destructive agent.
CAVAET: always use a random password generator. Do not assume that a simple substitution is safe. I recently saw a login of [eventosaur] using a password of [3v3nt05@ur]. Most hackers know this simple substitution (e->3, a->@, s->5, i->1 or !) and would include it in a dictionary attack.
Step 1: Avoid “Monkey see, Hacker see” use of the login shown in the documentation. I recommend using a password generator to create the login that is at least 16 characters, preferably a full 128 characters for both the login and the password. You should have no SQL Server logins used by a human and no login used by a group of people (i.e. the classic “Support” login should disappear). IP has a far greater value than a credit card transaction so your standards should exceed that of the PCI SSC Data Security Standards.
I recommend that the account(s) used by JAVA and C++ components be created as shown in the figure below.
Some notes:
- Login Name should be ‘unusable’ by a human consisting of long series of characters (128 ideally). The length of it makes it the login of last choice for a manual login.
- The password should be equally ‘unusuable’ by a human – being too long to remember
- You should set a policy of changing the password at least every month (weekly would be better). By checking ‘Enforce password expiration’, you will force the issue if you forget to change the password.
Why change the password every month? Employees may leave and could potentially leave hidden agents that know the current login/password combination. A change of password reduces the potential exposure period.
Step 2: This item is critical; make sure the “sa” account is disabled. If you need an account for an external consultant to use, make sure that it is the actual person’s name and disabled by default (See PCI literature on best practices here). The only enabled SQL login should be the one needed by the JAVA or C++ components.
Why? “sa” is a known login so it’s a security exposure. Your system is much more secure if a malicious agent has to search for both the login and the password.
Step 3: Make sure that no local accounts has a login except for services. Often, the local Administrator account is made a dbo when SQL Server is installed. You wish to remove this permission. Best practices are to rename the local Administrator account name to reduce risk -- see HOW TO: Rename the Administrator and Guest Account in Windows Server 2003. If someone can access the server as a local Administrator, the ability to copy SQL Server backups (and thus IP) exists.
In general, there should be no local account, i.e.{server}\{Name}, listed because you want all access to be under a centralized domain control.
Step 4: Make sure that there are no group accounts listed. This is a slightly more obtuse security risk seen with the use of Domain or Local Groups – all of these should be removed and the explicit users added instead. The reason is that the members of the group are snapshot and then added. Users subsequently added or removed from the group may not be updated in the Logins.
“Note If you use SQL Server integrated security, keep in mind that if you grant a Windows NT user group access to the SMS site database, this permission isnot dynamic**. As new users are added to the Windows NT user group, they are not given SQL Server security rights unless you add them individually . ” technet.microsoft.com
The failure to have a user removed when they are removed from a group creates a security risk.
Development Machines
The above guidance applies to both production and development SQL Server databases for the simple reason: both contain your firm’s IP property. A breach of a development SQL Server is as severe as a breach of the production SQL Server. This is NOT the case for most development SQL Servers; experienced developers starting with your firm will often be lax because “it’s just a development machine”. That is one dimension; the other dimension is that it is also an Intellectual Property machine. A good corporate practice is to prohibit the placement of the SQL Server database on any portable machines like laptops or net books (this will irritate some developers until it is explained to them).
Summary
A short checklist is:
- All SQL Accounts that are enabled should have:
- Logins that are created by password generators (to deny dictionary attacks)
- Have long passwords (128 characters) that are regularly changed and created by password generators
- Be used only by PLM components, never by a human
- No local accounts should have access to the database
- At the OS level, {Server}\Administrator should be renamed
- Use SQL Server standard security instead of mixed security
- No Group accounts should have access to the database
- The membership in this group may be stale data
- Treat the development environment identically to production for security.