OK, our QA director came back from a training course and told us most of our 21CFR Part 11 controls look OK, but we need to institute something to prevent the daily users of the computers (four others) from being able to intentionally or accidentally delete the 21CFR Part 11 database file. We happen to use Agilent Security Pack (A.09) but apparently this is a Windows 2000 issue; we need to allow routine writing to this database file by all but need to prevent its deletion by all except administrator and/or password protect it from being deleted. Thanks, I'm not a computer wizard, so if you know how, please include all necessary steps.

I guess you are using the standalone version of ChemStation Plus with Security Pack.
I don't see such an issue with the Client/Server version (Oracle data base).
The clue is probably to find out the good W2000 security properties to apply to the bunch of files that make the database.
You should either ask Agilent or an IT guy.

From original poster: Right using standalone Chemstation, four computers. Our IT guys recommended before purchase to keep it as such, and off the company network, as there was no need to share data with outside locations. Also, this way relieves them of the responsibility and validations of archiving the data for 4 years and backing up the data. Agilent Help told us it was a Windows 2000 issue, but our crack IT guys have been down twice and said they'd need to research further (why do they seem to always travel in pairs???).

We run the Oracle database B.01.03 network version of ChemStore, the clients are all Windows NT4 running A.08.03 with security pack. We use policies to do the following:- lock down the user desktop, prevent access to applications and files through Explorer, limit the start menu and desktop to ChemStation sessions only and prevent right clicking. Access to the clock (which is synced with the server)is also limited to Administrators only. We also password protect the BIOS, format the harddrive to NTFS, turn off CD autorun and disable Windows help (as this can be a backdoor to control panel and other sensitive areas). In other words the users have access to run Chemstation sessions only. They can do nothing else. Our implementation is the most locked down I have seen to date. There are a few niggles with this version of ChemStore (i.e. does not transfer data to the database until it is processed otherwise stays on local harddrive)but we intend to upgrade next year.

I am not familiar with Windows 2000 but it can be setup to provide similar security to the policies we use on NT4.

Looks like there could be three responses from people at different sites in the same company here! For info, we have a networked ChemStore B2.01 and ChemStation B9.01

Since you are working with standalone ChemStation, this suggests you are using the Access database option, rather than Oracle (and I agree with my collegues that the networked version would be much better, especially if you may be looking to expand in the future and are working in a 21CFR11 compliant environment - this requires backups, etc. so you MUST have something in place for these and it is much easier from a single server than multiple separate computers. Time to get your QA director to have a talk with your IT manager about the consequences of not complying with 21CFR11!!).

When ChemStation/ChemStore is installed, the local (demonstration) database that is installed at the same time goes in to a directory with permissions that only allow administrators to get to it through Explorer. If you create your own database (as an administrator), ensure it is in this same directory. The functionality in ChemStation/ChemStore is designed so that it can get to this database, even if a "normal" user can not get to it through Explorer.

To ensure that normal users can not get to this directory, you need to have user accounts configured on the computer with you (as the administrator, who may need to change which database is being used) in the Administrators group and everyone else in the Users group. It is also a good idea to set the systems up so ONLY these users can log on and no one else. Your IT people should be able to set these up if you are not able to.

According to Agient, you don't need any other restictions apart from a few policies to stop access to the registry and a few other areas - your Agilent user materials will tell you what is needed here. However, having your computers tied down as indicated in the previous message does stop users from even thinking about trying anything. If you have a user who you think is capable of getting round anything like this, they should be the administrator!

From original poster:
OK we do have Access-type database, on four standalone computers. I finally called my neighbor who provided better and faster response to my question than did our IT twins. OK, administrator and co-administrator get Administrator privileges through Windows 2000, Control panel, passwords. For others, create Users login and a shared password, this group does not get administrative controls. Then sign on to Windows 2000 as administrator, and use Explorer to right-click on Chemstor directory, and tailor the security permissions so the new User group cannot delete files or subdirectories (of Chemstor, logically), as well as selected other restrictions, and only administrator and co-administrator can delete such files. This way, when someone is logged into Windows 2000 as User, nobody, not even aministrator, can get into Chemstore (administrator would need to log in to 2000 as administrator first, then log onto Chemstore to retrieve data, change accesses, or create studies). If onto 2000 as User, one cannot even "read" restored files from the Chemstore database, they're still protected. On day-to-day basis, there's no real need to get back into Chemstore, so this will work for us.

I think the whole ChemStation/ChemStore "security pack" issue is a hack. ChemStore was DESIGNED as an Access application which was hacked to Oracle for pharmaceutical companies that somehow have been brainwashed into believing Oracle = compliant and secure. The "network" Oracle version is just a quick ODBC hack that I could have put together in a weekend.

ChemStation is insecure by design because it was designed to be customizable and configurable. There is a command line feature in ChemStation and complete access to the registers that hold the chromatographic data (ChromReg and ChromRes). These can be manipulated either manually or via macros. Macros can manipulate the data registers and can be embeded such that they require no user input and are run covertly (within the print macro, for example).

The basic lesson is that no amount of bolt on measures can secure an application that wasn't designed to be secure. NT and Oracle are neither necessary or suficient for a secure application. The other lesson is that most lab/QA personnel have no programing background and are thus unqualified to evaluate the security of software.