Introduction and Scope

University Human Resource Policy 601, Treatment of Confidential Information, lists a number of different types of information which should be treated as confidential and defines a number of employee responsibilities related to the handling of such information.  These security guidelines provide a set of practices to be followed when University IT systems transmit, process, or store such confidential information.  Note that the information described in policy 601 as confidential is not exhaustive, and additional specific data elements may need to be treated as confidential.  These may be identified through formal data classification processes, designation by the responsible data steward, or other authoritative sources.

The guidelines that follow apply to the infrastructure supporting University IT services, including servers, storage, network devices, and third party services under contract with the university (those in scope for the Policy on the Use of External Service Providers) when those IT systems process, transmit, or store confidential information as defined by University policy or when those systems have otherwise been determined to represent a risk requiring security controls such as those below.

Questions about these guidelines should be directed to security@uchicago.edu

Guidelines

1. Privileged Account Management

IT personnel often require elevated privileges in order to perform specific duties related to the management and support of IT systems.  The following standards apply to the creation of accounts (or credentials) with elevated privileges and the use of such privileges.

1. [1.1] University Human Resource Policy 601 defines computer passwords, and certainly passwords for privileged accounts, as confidential information. Privileged accounts will only be created in order to enable staff to perform their assigned duties.
2. [1.2] Staff members who have roles within a group that by its nature requires privileged access in order to perform the ordinary duties performed by members of that group are assumed to have authority to have such access and require no additional approval.  For example, Windows administrators in a Windows server administration organizational unit are assumed to be authorized to have Windows administrator accounts on the servers that their group manages.  Privileged account creation for others must be approved as follows:
   1. [1.2.1] by the Service Owner of the service utilizing the IT system over which the account will have authority, or
   2. [1.2.2] by someone in a supervisory capacity over the staff person creating the privileged account
3. [1.3] Privileged account creation, deletion, and modification events will be logged as specified below in section 3.
4. [1.4] Network access by privileged accounts is only allowed through secure mechanisms and protocols to protect the account and the context or session in which it is acting.  Examples of means for complying with this requirement include but are not limited to
   1. [1.4.1] using VPN or IPSEC tunnel for communications,
   2. [1.4.2] using WPA2 but not WEP for wireless connections,
   3. [1.4.3] using NTLMv2 or Kerberos but not NTLMv1 or LMHASH for Windows authentication, and
   4. [1.4.4] not transmitting or storing credentials in browser cookies or URL strings (or storing them in browser caches)
5. [1.5] CNetIDs used for privileged access should be validated for Silver compliance, cf. InCommon Silver FAQ.
6. [1.6] Local credentials or other non-CNetID password-based credentials must meet or exceed the complexity and change frequency requirements of Silver credentials.
7. [1.7] Privileged account users will only use their  privileged access as required to perform their assigned duties.
8. [1.8] Elevation of privileges, e.g. through the use of “sudo”, must be logged.

2. User Account Management

Some user accounts are given access to confidential information and therefore appropriate security controls should be established governing their creation and use.  Establishing the security policies which apply to such accounts is the responsibility of the Business Owner of the service for which the accounts are authorized. Controls similar to those defined for privileged accounts in section 1 above may be appropriate.

3. Audit Records (Logging) and Accountability

1. [3.1] Where practical, IT systems must be configured to create an audit trail for the following events:
   1. [3.1.1] create, replace, update, and delete events for confidential data or data related to the management of IT systems
   2. [3.1.2] authentication events (both success and failure)
   3. [3.1.3] administrative activities that affect the operation or security of the IT system
   4. [3.1.4] any events indicating a violation of security policy.
2. [3.2] Where practical, audit records must contain sufficient information to establish
   1. [3.2.1] what type of event occurred,
   2. [3.2.2] when (date and time) the event occurred,
   3. [3.2.3] where the event occurred, the source of the event,
   4. [3.2.4] the outcome (success or failure) of the event,
   5. [3.2.5] and the identity of any user associated with the event.
3. [3.3] IT systems capable of synchronizing internal system clocks using NTP must do so.
4. [3.4] Where practical, logged events should be sent to a secure logging facility external to the system creating the audit records.
5. [3.5] Audit records created in the processing, transmission, or storing of confidential information should be treated as confidential information.
6. [3.6] Where not practical to do any of the above, the reasons for such must be documented.

4. Configuration Management

1. [4.1] Only system services and protocols necessary to the function or management of the business needs should be enabled.  System services and protocols unnecessary to the function or management of the IT system must be disabled where possible.
2. [4.2] The following protocols, or services and related network ports are prohibited:
   1. [4.2.1] telnet
   2. [4.2.2] ftp
   3. [4.2.3] rlogin
   4. [4.2.4] rcp
3. [4.3] Where practical, baseline configurations should be developed, documented, and maintained under configuration control.
4. [4.4] Changes to baseline configurations will be managed in accord with applicable change management procedures.

5. Identification and Authentication

1. [5.1] Privileged operations initiated by an individual using a shared, organizational, or system service account should be uniquely traceable to that individual.
2. [5.2] Authentication mechanisms should not provide feedback during authentication transactions that may be exploited or used by unauthorized individuals to compromise the authentication process.

6. System and Information Integrity

1. [6.1] Security related patches must be applied within a time-frame determined according to the risk represented by the vulnerability being addressed.
2. [6.2] Host-based firewalls, IP white lists (e.g. iptables), and the like should be employed where practical as an additional layer of defense.
3. [6.3] IT systems that process, transmit, or store confidential information must be managed to protect against malicious code such as viruses, Trojans, and keyloggers.
   1. [6.3.1] Where available, measures to protect against malicious code must be employed at workstations and servers relevant to the operation of such IT systems.  These measures should protect against malicious code that is:
      1. [6.3.1.1] transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means; or
      2. [6.3.1.2] inserted through the exploitation of information system vulnerabilities.
   2. [6.3.2] Malicious code protection installations (such as Symantec Endpoint Protection or McAfee Complete Endpoint Protection) must be updated whenever new releases are available in accord with applicable configuration management procedures.
   3. [6.3.3] Malicious code protection installations must be configured to:
      1. [6.3.3.1] perform periodic scans of the information system and real-time scans of files from external sources as the files are downloaded, opened, or executed; and
      2. [6.3.3.2] block or quarantine malicious code and send alerts to administrators in response to malicious code detection.
4. [6.4] When confidential information leaves the boundaries of the system, the information should be encrypted or otherwise made safe and secure.  Ways to accomplish this include but are not limited to the following.
   1. [6.4.1] Destruction – Media leaving operational control, such as a hard drive being returned due to a failure, may be destroyed or rendered unusable by following an appropriate media destruction process.
   2. [6.4.2] De-identification – Data elements can be altered such that they no longer convey the information originally deemed confidential.  For example, personally identifying information being sent to a test system may be altered so that it no longer identifies an actual person.
   3. [6.4.3] Encryption – any confidential information that cannot otherwise be secured through destruction or de-identification must be encrypted.  Encryption must be done in accordance with the current University standards for such, cf. Statement on Minimum Encryption Standards  Note that computer passwords transmitted over public networks constitute confidential information leaving the system boundaries and would therefore have to be encrypted.

7. Security Incident Response

1. [7.1] Report suspected security incidents to IT Security as soon as practical.
2. [7.2] Fully cooperate with IT Security in the handling of security incidents.

8. Security Awareness and Training

1. [8.1] Security Liaisons and other interested parties responsible for the management and support of IT systems should actively participate in security communications lists, and act upon security alerts, advisories and directives relevant to the IT systems under their care.
2. [8.2] Security Liaisons and other interested parties responsible for the management and support of IT systems should take advantage of security awareness training when offered.