Skip to main content
more options

IT Security Requirements for Confidential Data

Version 1.1 - 23 Sep 08

To better safeguard the university's data, the IT Security Office requires the following practices for the electronic transmission and storage of Confidential data.

Please note that these requirements are in addition to those outlined in the Baseline IT Security Requirements.

Items labeled as a Suggestion reflect a beneficial practice that might become a requirement at some future date.

A. Confidential Data Classification

Policy 5.10, Security of Electronic Administrative Information, currently in draft, establishes three data security classifications:

Confidential
Restricted
Public

Unless otherwise classified, all data used in the conduct of university business is Restricted. An instance of university data that has been explicitly made available to the public, with no authentication required for network access, is Public.

The Confidential data classification currently comprises the following data elements, when they appear in conjunction with an individual's name or other identifier:

Social Security numbers
Credit card numbers
Driver's license numbers
Bank account numbers
Patient treatment information

This set may expand based on future regulatory requirements or designations made by the appropriate university data steward (as defined in University Policy 4.12). Future additions will be reviewed by an appropriate governance body before they are incorporated here.

These requirements apply to Confidential data that is under the custodianship of the university, and so do not pertain to your own personal information.

Please note that some data elements classified as Confidential data are subject to legal or regulatory requirements that go beyond those given here. Such requirements for Regulated Data must be fulfilled, along with these Cornell requirements. In particular, credit card numbers and how the university handles credit card transactions are subject to the Payment Card Industry Data Security Standard (PCI DSS). For more information, see https://www.pcisecuritystandards.org/.

B. Systems Subject to These Requirements

These requirements apply to any system that holds Confidential data, both on- and off-campus and even if not university-owned.

Here and elsewhere, a system is "holding" Confidential data when such data is stored locally on the system or when the system is regularly used to direct mount and has access to such data stored on network volumes or file systems.

  • Thus, for example, a Windows system where the primary user's domain password is sufficient to mount a file server volume and access directories with Confidential data would need to be secured as if such data was stored locally.
  • On the other hand, a system used to access Confidential data via an application, including database access, would not be viewed as holding such data.

C. Encryption Standards

In several places, these requirements specify a need to encrypt data, either for storage or for transmission. Some examples are given of viable encryption implementations but no comprehensive list is provided here.

The IT Security Office will approve a given method of encryption for use with Confidential data if it both (a) employs a contemporary algorithm and (b) is effectively implemented by the product in question. More detail, and a current list of approved encryption vehicles, can be found here.

D. Exceptions

For all computers or other IT resources that are not able to meet these security requirements, the following exception process must be followed:

  1. IT resources that cannot meet the requirements must be identified to the appropriate Unit Security Liaison. The Unit Security Liaison will work with the IT Security Office to determine alternate methods to remedy the specific risk being addressed.
  2. If no alternative can be found, the applicable data steward will be consulted to determine appropriate course of action.
  3. Both the IT Security Office and Unit Security Liaison will maintain a list of all IT resources that require an exception and review them on an annual basis.

E. All Computers

  1. Keep all operating system, server and application software up to date.
    • A local patch management process must ensure that all security/critical updates are installed as soon as possible, and no later than two business days after their release.
  2. Follow hardening guidelines for the operating system and any applications or services that connect to the network.
    • Along with the software vendor, credible sources for guidelines include NIST, CIS, NSA, SANS, FIRST.
    • Disable all network services, including specific application features, that are not needed for the system to fulfill its function.
    • Change any passwords with default values set by the vendor.
  3. Confidential data and data that is being made available for public access may not be on the same system.
    • An open web site, i.e. one that does not require authentication for access, may not be run on a system holding Confidential data.
    • Peer-to-peer (P2P) file-sharing software may not be run on a system holding Confidential data.
    • Confidential data and data available for public access may reside in different virtual machines running on the same system, as long as the host system and the host operating system meet all the requirements for a file or application server holding Confidential data.
  4. Activate operating system and, where possible, application logging, with logs retained for at least 90 days. At a minimum, the following must be logged:
    • Access to all audit logs;
    • Access to Confidential data;
    • Failed access attempts.
  5. Maintain an inventory of all systems holding Confidential data.
    • Review the inventory on a quarterly basis.
    • File a copy of the current inventory with the local IT head and the Unit Security Liaison.
  6. On a quarterly basis, audit and verify that only currently authorized personnel have accounts that grant access to Confidential data.

  7. Suggestion: Audit file, application and system privileges on a periodic basis.

F. Specific to Desktops and Laptops

  1. The account used for daily operations must be configured to not allow software installs, or must require the account password for an instal.

    Suggestion:Where feasible, consider not giving end users any accounts that permit software installation.
  2. On any system holding Confidential data, use a unique password, not shared with other systems, for local administrator accounts (accounts with elevated privileges).
    • In particular, the local admin password used by IT support staff must be different for each system that holds Confidential data.
    • Such passwords can be generated algorithmically as long as the unique portion is not a string that is stored electronically on the system.
  3. Confidential data stored locally on a system must be removed when no longer needed on an operational basis.
    • Every six months, use Spider or some equivalent to review what Confidential data is stored on the system, and where.
    Suggestion: No storage of Confidential data on individual staff machines.
  4. Confidential data must be encrypted on:
    1. any system that, even on a temporary basis, is not located on one of the Cornell campuses or some other formal university location; and
    2. any laptop or other portable device, including PDAs, smart phones and media, that ever leaves a secure location accessible only to authorized university personnel; and
    3. any other system that is not physically secured or in a secure location accessible only to authorized university personnel.
    • If full-volume encryption is used, the volume should be mounted only when the system is in active use. (Make sure that the encryption does not interfere with your ability to create and retrieve back-ups.)
    • Protect encryption keys against disclosure, misuse and loss. See University Policy 5.3, Use of Escrowed Encryption Keys.
    • Examples of portable media include: external hard drives, USB thumb drives, CDs DVDs, tapes, diskettes.
    • While Microsoft Office 2007 includes a facility for appropriately strong encryption of documents, the password-protection feature found in older versions of Word and Excel is not sufficient. Similar facilities in other applications may or may not fulfill this requirement.
    • Acceptable encryption solutions include but are not limited to EFS under Windows 2000 and later, BitLocker under Windows Vista and Server 2008, FileVault under Mac OS X, CyberAngel, TrueCrypt.

      Suggestion: Encrypt all instances of Confidential data under the custodianship of individual staff members.
  5. Unless the Confidential data is protected by encryption, only authorized university personnel may have access to the system.

G. Specific to Application and File Servers

  1. Must be housed in a physically secure computer room or data center.
    • Entry must be logged and the logs retained for at least five days.

      Suggestion: Where feasible, log exits as well.
    • Video monitoring is an acceptable solution to this requirement.
    • Visitors not permitted except under escort.
  2. An individual's access to a store of Confidential data should be via an account assigned for the sole use of that individual.
    • This requirement is not to be interpreted as disallowing access to an encrypted dataset via a shared encryption key.
  3. Confidential data should be removed from file servers when it is no longer needed on an operational basis. To the extent feasible, this also applies to Confidential data stored in databases and other application frameworks.

    Suggestion: Use dual-factor authentication for root/administrator access to these systems. (When campus-wide mechanisms are in place for dual-factor authentication on all standard platforms, this will become a requirement.)

H. Specific to Public Workstations and Kiosks

  1. Such systems may never be used for administrative processing of Confidential data.

I. Network Security

  1. The edge ACL or other packet-filtering mechanism on any subnet with systems housing Confidential Data must employ a default-deny strategy that prohibits unnecessary inbound internal and external connections and that strictly limits access to the systems with Confidential data.

    Suggestion: Where off-campus connectivity is not needed, put the system into a non-routable space (10 space).
  2. Any system holding or accessing Confidential data that is on a campus wireless connection must use RedRover-Secure, or a departmental wireless network with equivalent or stronger security (authentication required, encrypted transmission).
  3. Any remote, off-campus access to a system containing Confidential data must use an encrypted connection.
    • Examples of encrypted network transport include: ssh/sftp, SSL/TLS, a VPN with encryption enabled.
  4. Fully document the list of services, protocols and systems permitted access into such subnets.
    • A subnet's ACL list or firewall rule set suffices to fulfill this requirement.
    • Review this documentation on a semiannual basis.
    • File a copy of the current documentation with the local IT head and the Unit Security Liaison.

J. Additional Encryption Requirements

  1. Confidential data must be encrypted when it is transmitted via e-mail.
    • While Microsoft Office 2007 includes a facility for appropriately strong encryption of e-mail attachments, the password-protection feature found in older versions of Word and Excel is not sufficient. Similar facilities in other applications may or may not fulfill this requirement.

      Note that the Dropbox service (https:// dropbox.cornell.edu [currently dropbox.sas.cornell.edu but to be renamed]) provides a secure, web-based vehicle for exchanging files with other people holding Cornell NetIDs.
  2. Confidential data may not be transmitted via instant messaging (AIM, etc) or text messaging (SMS).
    • This would be permissible if the transmission were encrypted, but encryption is not available with the standard, commercial IM and SMS offerings.
  3. Confidential data must be encrypted when it is accessed via the web.
  4. Confidential data must be encrypted when it is transmitted over non-Cornell networks.

    Suggestion: Whenever feasible, it should also be encrypted when transmitted within Cornell networks.
  5. If passwords that grant access to Confidential data are stored on a networked device, they must be encrypted.
    • While Microsoft Office 2007 includes a facility for appropriately strong encryption, the password-protection feature found in older versions of Word and Excel is not sufficient. Similar facilities in other applications may or may not fulfill this requirement.

K. Additional Process and Documentation Requirements

The IT Security Office will provide templates and/or more specific guidelines for fulfilling items listed here.

  1. Define and document incident response and escalation procedures for a potential loss of Confidential data.
    • Review these processes on a semiannual basis.
  2. Document how Confidential data flows into and out of the local business unit and local applications.
    • Review this documentation on a semiannual basis.
    • File a copy of the current documentation with the local IT head and the Unit Security Liaison.
    • The relevant central unit will be responsible for fulfilling this requirement for any campus-wide application or service that handles Confidential data.
  3. When a unit grants any non-governmental external entity access to Confidential data, that entity must provide documentation of:
    1. how this data will be transmitted, processed, stored and secured; and
    2. how such data is monitored and what incident response mechanisms are in place.
    • Review this documentation on an annual basis.
  4. Follow a documented process for disposal of Confidential data when no longer needed for legal, regulatory or business needs.
    • Ensure that local and university data retention guidelines are met.
    • This process needs to include an approach to data / media destruction.
    • Review this documentation on an annual basis.
    • File a copy of the current documentation with the local IT head and the Unit Security Liaison.
  5. All users with access to Confidential data must execute a yearly attestation of the awareness of the relevant policies, risk and protective measures.
    • An individual's electronic access to Confidential data does not convey any right to share that data with unauthorized personnel.