|
|
|
Policy 6125
AUTHENTICATION POLICY
I. PURPOSE
The purpose of this policy is to ensure that the person supplying an identity
is the person to whom the supplied identity has been assigned.
There are industry-standard methods for authenticating the identity of users. Generally, it is accepted that the forms of authentication come in three types -- something the user knows (e.g., a password), something the user carries (e.g., an ID card), or something about the user (e.g., a fingerprint). A combination of at least two of these is necessary to adequately ensure appropriate access to the most sensitive/confidential information, while a simple password or ID card may be adequate for less sensitive (e.g., non-restricted) information.
A. COV IRTM Information Technology Security Standards
1. Each Agency must ensure that Users are authenticated prior to accessing the systems which are "owned" by that Agency.
2. Each Agency must establish a formal authentication control policy that establishes the criteria for administering authentication safegaurds (e.g., a formal password policy that includes the criteria for password aging, history, length and composition).
3. Each Agency must store all sensitive data used in authenticating the user, including passwords, in protected files.
4. Web-enable
sd transactions that require user authentication, or transfer of sensitive data, or that involve the transfer of funds, must use encryption (e.g. SSLv3).
II. POLICY
Eight (8) standard levels of authentication for access to services are currently recognized and selection of the appropriate method will be commensurate with the type of access and the sensitivity of the data involved. The data owner or designee for the data area involved will, with input from others, make the decision about the level and type of authentication that will be deployed:
A. Network Address/Physical Location: May be used where it is
only important to restrict access to data or a particular service to persons
using a specific or any
B. Public/Anonymous: Applications, systems, or services which provide read-only access to data which has been classified as "public", and for which wider internal or external dissemination is desirable, will be considered candidates for access via public or "guest" accounts where no username and/or authenticating password is required.
C. Personal Identification Number (PIN): PIN authentication will be available for use as a security measure for selected "special-purpose" inquiry/update transactions or services (i.e., self-service processes -- those that provide individuals with access only to their own records and information). PIN authentication may be appropriate for such applications as student registration, individual student access to their individual academic or advising records, etc. The PIN validation dialogue should be done via a secure communications method. That is, the PIN supplied should be protected from interception on the network between the user's desktop and the server accepting the PIN.
D. Password: Password protection may be used for applications where access to data or information systems requires individual (personal) identification, and where this single password is sufficient to authenticate this identity. It must be determined that unauthorized access to the data will cause minimal harm to the data, the individual who may be the subject of the data, and the associated University operation. That is, where near-absolute individual accountability does not have to be guaranteed for access to the data or application system.
E. Secure Password: The password data should be encrypted, or the network topology must be such that opportunity for someone to intercept the password in transit is minimized. Secure password may be used for applications where access to data or information systems requires individual (personal) identification, and where this single password is sufficient to authenticate this identity. The secure password should be used where a high-level of individual accountability must be guaranteed for access to the data or application system.
F. Password/Secure Password/Authentication Device: This level of protection makes use of password token technology as an additional means of user authentication, in addition to a password, when near-absolute individual accountability must be guaranteed. These devices add an additional security mechanism that requires that the user physically possess the device and know the associated PIN, in addition to knowing the password associated with the account. Since this is a two-part authentication process and physical possession of the device is required in addition to the password, the validation dialogue need not be accomplished via a secure communications method. However, because it is the case that users might select the same password for this access that they have chosen for other accesses that may require only password access, the secure communications method is still recommended.
G. Pass phrase: Pass phrases are generally used for public/private key authentication. A public/private key system defines a mathematical relationship between the public key that is known by all, and the private key, that is known only to the user. Without the pass phrase to "unlock" the private key, the user cannot gain access. Pass phrases differ from passwords in that they are much longer (typically 20 to 40 characters) and contain spaces. Their greater length makes pass phrases more secure against "dictionary attacks." All of the rules above that apply to passwords apply to pass phrases.
H. SNMP Community Strings: The SNMP community string is like a userid or password that allows access to a router’s or other device’s statistics. SNMP community strings are used only by devices which support the SNMP protocol. There are actually three community strings for SNMP-speaking devices:
1. SNMP Read-only community string – enables a remote device to retrieve “read-only” information from a device.
2. SNMP Read-Write community string – allows a remote device to read information from a device and to modify settings on that device.
3. SNMP Trap community string – used when sending SNMP Traps to another device.
All sensitive data and information used for authentication, either stored or in transit, must be protected. The data must be encrypted according to the Acceptable Encryption Policy and only the minimum amount of access necessary should be granted to allow the authentication process to function.
Approved by the Board of Visitors April 1, 2005.