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
|
