The purpose of this policy is to establish a standard for the administration of computing accounts that facilitate access or changes to Brown institutional data. An account, at minimum, consists of a user ID and a password; supplying account information will usually grant access to some set of services and resources. This policy establishes standards for issuing accounts, creating password values, and managing accounts.

This policy is applicable to those responsible for the management of user accounts or access to shared information or network devices. Such information can be held within a database, application or shared file space. This policy covers departmental accounts as well as those managed centrally.

3.1 Account Administration Standards

Accounts that access electronic computing and information resources require prudent oversight. The following security precautions should be part of account management:

3.1.1 Issuing Accounts

1. The owners of Brown data shall make decisions regarding access to their respective data (e.g., the Registrar will determine who has access to registration data, and what kind of access each user has). Account setup and modification shall require the signature (paper or electronic) of the requestor's supervisor.
2. The organization responsible for a resource shall issue a unique account to each individual authorized to access that networked computing and information resource. It is also responsible for the prompt deactivation of accounts when necessary, i.e., accounts for terminated individuals shall be removed/disabled/revoked from any computing system at the end of the individual's employment or when continued access is no longer required; and, the accounts of transferred individuals may require removal/disabling to ensure changes in access privileges are appropriate to the change in job function or location.
3. When establishing accounts, standard security principles of “least required access” to perform a function must always be used, where administratively feasible. For example, a root or administrative privileged account must not be used when a non-privileged account will do.
4. The identity of users must be authenticated before providing them with account and password details. If an automated process is used, then the account holder should be asked to provide several information items that in totality could only be known by the account holder. In addition, it is highly recommended that stricter levels of authentication (such as face-to-face) be used for those accounts with privileged access (e.g., user accounts used for email do not require an identity validation process as thorough as for those user accounts that can be used to modify department budgets).
5. Passwords for new accounts should NOT be emailed to remote users UNLESS the email is encrypted.
6. The date when the account was issued should be recorded in an audit log or captured electronically.
7. All managers of accounts with privileged access to Brown data must sign a Confidentiality Agreement Form that is kept in the department file under the care of a Human Resources representative or liaison.

3.1.2 Managing Accounts

1. All accounts shall be reviewed at least annually by the data owner to ensure that access and account privileges are commensurate with job function, need-to-know, and employment status. The Information Security Group (ISG) may also conduct periodic reviews for any system connected to the Brown network.
2. All guest accounts (for those who are not official members of the Brown community) with access to Brown computing resources shall contain an expiration date of one year or the work completion date, whichever occurs first. All guest accounts must be sponsored by the appropriate authorized member of the administrative entity managing the resource.

3.1.3 Departmental Accounts

For access to sensitive information managed by a department, account management should comply with the standards outlined above. In addition, naming conventions must not cause contention with centrally managed email addresses or usernames. Should the potential for contention arise, the applicable system(s) shall not be connected to the campus network until a mutually satisfactory arrangement is reached.

3.2 Shared Accounts

Use of shared accounts is not allowed. However, in some situations, a provision to support the functionality of a process, system, device (such as servers, switchers or routers) or application may be made (e.g., management of file shares). Such exceptions will require documentation which justifies the need for a shared account; a copy of the documentation will be shared with ISG.

Each shared account must have a designated owner who is responsible for the management of access to that account. The owner is also responsible for the above mentioned documentation, which should include a list of individuals who have access to the shared account. The documentation must be available upon request for an audit or a security assessment.

3.3 Administration of Password Changes

3.3.1 Procedures for password resets

1. The identity of users must be authenticated before providing them with ID and password details. In addition, it is required that stricter levels of authentication (such as face-to-face) be used for those accounts with privileged access.
2. Whenever possible, passkeys should be used to authenticate a user when resetting a password or activating a guest account, and should comply with the above standards. Passkeys provide one-time access to a system or application and require the user to change to a password of their choice upon initial login. Where passkeys are not feasible, pre-expired passwords should be used.
3. Automated password resets are available and may be utilized, provided that a recognized and approved method is used, such as multiple, random challenge and response questions.
4. Passwords must be reset over an encrypted tunnel (SSL, ssh, or VPN, for example).
5. Password change events should be recorded in an audit log.

3.3.2 Procedures for maintenance of "shared secrets"

Those responsible for access to systems/applications/servers, etc. protected by high-level super-passwords (or the equivalent) must have proper auditable procedures in place to maintain custody of those "shared secrets" in the event of an emergency and/or should the super-password holder becomes unavailable. These documented procedures, which must be appropriately secured, should delineate how these passwords are logically or physically accessed as well as who in the "chain of command" becomes responsible for access to and/or reset of the password.

Applications developed at Brown or purchased from a vendor should contain the following security precautions:

1. Where technically or administratively feasible, shared ID authentication should not be permitted.
2. Authentication should occur external to an application, i.e., applications should not implement their own authentication mechanism. Instead, external authentication services should be relied upon, provided by the host operating system, the web server, or the servlet container. [In general, applications programmers are not necessarily familiar with the techniques associated with security protocols, and may inadvertently create security holes. Security services available from these external environments are much more likely to provide a high level of security.]
3. Passwords must not be stored in clear text or in any easily reversible form.
4. Role-based access controls should be used whenever feasible, in order to support changes in staff or assigned duties.
5. Where technically or administratively feasible, systems should allow for lock-outs after a set number of failed attempts (ten is the recommended number). Access should then be locked for a minimum of ten minutes, unless a local system administrator intercedes. Lock-outs should be logged unless the log information includes password information.

• Acceptable Use
• Accounts and Access Information and Forms
• Accounts and Passwords (Services)
• Computing Passwords Policy
• Confidentiality Agreement Form