Privacy and Security at the University of Illinois

Purpose:

This page is intended to bring transparency to the systems and policies used when provisioning computer equipment to University of Illinois employees.

Background:

As a University of Illinois employee, you are a State of Illinois government worker.  All rules and regulations for state government employees do apply.

• Except as explicitly authorized by the comptroller of the state, no employee may sign any contracts on behalf of the University.
  • Multi-million-dollar grants
  • Clicking “I accept” to free software terms and conditions
  • All work is a matter of public record unless another law supersedes to make it private 
  • File names on computers used for University business are considered public information (Campus Administrative Manual, section on Appropriate Use of Computers and Network Systems, part IV, C, (4).)
  • For any work to not be public, there must be a legal reason
    • Student work may not be disclosed based on the Family Education Rights and Privacy Act (FERPA)
    • IRB protocols for personally-identifying information may restrict disclosure
    • Outside contracts for certain data may restrict publication
    • Research and Education materials defined in Section 7 (j) of the Illinois (5 ILCS 140) Freedom of Information Act allow instruction and research materials to be private

Using personal equipment does not alleviate or change these requirements.  If a University of Illinois employee performs University work on personal equipment, then any issues such as security standards or FOIA requests will also cover the personal equipment.  This means that if you have a FOIA request, you may be required to surrender your personal computer if it contains job-related data. (See this Inside Higher Ed article for a relevant example.)

University policies:

The University of Illinois has a slew of policies related to use and maintenance of computers.  The necessary precautions for a system are determined by the type of data contained on the system.  The U of I uses 4 data classifications, quickly summarized here in this Institutional Data Security Standards document (Box login required).

• Public – this data is freely available to the public and the release of such data is not considered a problem as it is supposed to be released.
• Internal – This data poses some risk if the data were to be released.  This includes unpublished research data or Personally Identifying (pi) information not already classified at a higher level.
• Sensitive – This includes data protected by FERPA that is not already classified as High-Risk.  Disclosure of this data would have serious adverse effects for the U of I.
• High-Risk – This includes data which disclosure or modification would severely impact the U of I, possibly including fines or other contract violations.

As virtually all computers in the iSchool will have some student data, they are classified as holding “Sensitive” data.  Hopefully, no “High-Risk” data is present without IT and campus security being informed.  With the “Sensitive” data (or even the “Internal” data) classification come several campus requirements.  Notable ones are listed below

• Systems must use a preconfigured, secure configuration (IT10.1)
  • DEP and imaging provide this.
  • Software Flaws must be identified and corrected (IT10.4)
    • For “Sensitive” data, a server-based management console must be used – Munki and MECM provide this.
    • Antivirus/antimalware software must be used (IT06.1)
      • CrowdStrike currently fulfills this requirement.
      • Sensitive data must be encrypted (IT15.3.2)
        • Whole-disk encryption fulfills this, using either BitLocker or FileVault.
        • Backups must be made periodically (IT01.1)
          • We use Code42 (previously CrashPlan) for this.

What each piece of the puzzle does:

MECM and DEP for initial configuration

MECM (Windows) and DEP (MacOS) are used to preconfigure the software on machines used in the iSchool.  When a machine is taken out of the box, a fresh copy of the operating system is installed and several security settings are enforced.  On both Windows and MacOS, settings include encrypting the hard drive (BitLocker or FileVault), enforcement of password-protected screen savers, and setting the clock to the campus servers.  A set of software is then installed, including Office, common browsers, and Adobe Acrobat.  For Windows, machines are joined to the campus Active Directory.  For MacOS, a new user account is created.  The preference would be to use AD for Mac as well, but it has proven to not be quite stable enough for use on roaming machines.

With Apple’s DEP, a system can be configured to only take a predefined configure script from our campus.  Doing this prevents data theft, as the computer is effectively a “brick” if someone steals the device and tries to either retrieve data or reinstall and use the equipment.  It is also possible to enable a “find my device” to track down stolen property.  Similar systems are being investigated for Windows right now but are not available at this time.

MECM and Munki for software patches

MECM (Windows) and Munki (MacOS) are used to keep software titles properly patched.  These systems maintain a list of packages available for download.  Some software is listed as “required” (Office, Browsers, etc) and the system will install them if they are not present.  Other titles are optional, and if a user selects them from the “store”, they will be installed.  A final set of packages are “updates”.  If these titles are found on a computer, they will be updated regardless of how they were installed.  Both MECM and Munki can forbid titles – force uninstall software.  We do not use this feature except in some extreme cases, such as a FlashPlayer remote root bug that was not going to be fixed.  We do not enforce “this is software we like” with endpoint systems.

CrowdStrike for Antivirus

The current campus-approved antivirus is CrowdStrike. To summarize, CrowdStrike sends hashes of binaries being run and the filenames they are opening as well as any firewall rules programs attempt to change.  Note from above that file and directory names are classified as public by campus. The Office of Privacy and Information Assurance has contractual language stating the privacy and ownership of data sent to CrowdStrike servers.

BitLocker and FileVault for encryption

BItlocker (Windows) and FileVault (MacOS) are used to ensure any sensitive data is encrypted in place.  MECM and DEP are able to escrow the keys, so if a machine is unable to start normally, we are able to unlock the drive.  This happens automatically and the keys are stored securely on campus systems.

CrashPlan for backups

CrashPlan is a cloud backup system which sends changed files periodically as systems are used.  The data is encrypted during transport and also on the servers at CrashPlan.  While we have opted not to do so, it is possible to keep the decryption keys on local machines only.  By doing so, it is not possible for CrashPlan to decrypt the backups.  This enhances security, however if the keys are lost locally (like the hard drive crashes), then there is no way to get the data back.  It also prevents web restores as the web server cannot decrypt drives.  If you would like to investigate keeping local copies of the key, we can work with you on this.

Each user of CrashPlan can select what to back up and what not to.  The default is to copy everything in C:\Users\<user> for Windows or /Users/<user> on MacOS.  CrashPlan comes with a set of rules which very effectively prevents temp files from being copied, but can be modified if needed.  It is easy to exclude a specific directory from the CrashPlan GUI or add extra directories to the backup set.