Getting a Handle on Access Security for 21 CFR Part 11 - - BioPharm International


Getting a Handle on Access Security for 21 CFR Part 11

BioPharm International

Password Policies
Password Policies Sharing passwords is a common violation of Part 11 requirements. An FDA warning letter describes a case in which an employee's user ID and password were publicly posted for other employees to use to access the data management system.

"During the injection another employee who did not have the established user name or password was observed obtaining access to the Data Management system utilizing the posted user name and password. Three previous employees, who had terminated employment in 1997 and 1998, still had access to critical and limited Data Management System functions on March 18, 1999."2

Authentication and confidentiality of passwords are void when they are shared between individuals. So, how can passwords be kept secure? In sections 11.200 (Identification mechanisms and controls) and 11.300 (Controls for identification codes/passwords), 21 CFR Part 11 states the following requirements for identification mechanisms used for the execution of an electronic signature: The identification mechanism shall be "used only by their genuine owners" and needs to be "administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals."

One common problem with secure passwords is that they can be hard to remember. If they were easy to remember, they could be guessed by another person or a password cracking program. In the early days of secure operating systems, system administrators worked out password policies. Sometimes the policies resulted in passwords that were so secure that ordinary users had to write them down in order to remember them. In practice, a trade-off is necessary to protect an individual's password from external access while remaining at least minimally convenient for the user.

Figure 2: Password policy settings in Windows 2000. The password policy defines rules for password strength and password aging.
Modern operating systems support security and password policies. A security policy governs system behaviors such as what security events are captured in the operating system's event log and the guidelines for locking a user account as a result of invalid login attempts. A password policy establishes criteria for creating new passwords (see Figure 2). Managing these settings is typically a system administration task fulfilled by corporate IT departments. Unfortunately, many applications do not leverage the tremendously important work already done on the operating system level.

It is quite common for personnel to struggle to remember more than a dozen different accounts with separate logins and passwords for the various systems they must use: operating system, email, LIMS, CDS, ERP, requirements management system, software defect tracking database, and others. One might argue that centralizing system authentication is like putting all your eggs into one basket: if the login and password combination is compromised, it may be compromised for all systems. This is particularly true if the same login and password combination is used to access websites and web-based applications and if credentials are passed through a non-secure connection. However, many users will attempt to use the same login name and possibly the same (or similar) passwords on all their systems anyway. Few individuals will invent their own algorithms to generate unique passwords for every application and website they use.

Managing separate user accounts and passwords — one for the operating system and one for the data system — can make the maintenance of Part 11-compliant systems even more difficult. Solutions that directly tie into the operating system security scheme appear to be the most pragmatic.

Authority Checks In order to comply with section 11.10, it is necessary to implement access restrictions. Apparently, it is not sufficient to merely restrict system access to a group of individuals without differentiating their responsibilities or knowledge. Users could inadvertently modify system settings in a way that affects the integrity or security of the records. This is particularly true for system administration settings. It is clear that system administration functions should be subject to written policies or other behavioral controls and should only be assigned to a limited number of users. In comment 83 of the rule, FDA explains:

"System access control is a basic security function because system integrity may be impeached even if the electronic records themselves are not directly accessed. For example, someone could access a system and change password requirements or otherwise override important security measures, enabling individuals to alter electronic records or read information that they were not authorized to see."

Part 11 uses the term "authority check." This does not mean that a system administrator must assign the access rights individually to each user. Organizations do not have to embed a list of authorized signers in every record to perform authority checks. For example, a record may be linked to an authority code that identifies the title or organizational unit of people who may sign the record. Thus, employees who have that corresponding code, or belong to that unit, would be able to sign the record.3

blog comments powered by Disqus



GPhA Issues Statement on Generic Drug Costs
November 20, 2014
Amgen Opens Single-Use Manufacturing Plant in Singapore
November 20, 2014
Manufacturing Issues Crucial to Combating Ebola
November 20, 2014
FDA Requests Comments on Generic Drug Submission Criteria
November 20, 2014
USP Joins Chinese Pharmacopoeia Commission for Annual Science Meeting
November 20, 2014
Author Guidelines
Source: BioPharm International,
Click here