Cornell University IT Security Office

Preparing Cornell for Computer
Security Incidents Involving
the Loss of Sensitive Data

This paper is also available as a PDF file

Executive Summary

Recent stories in the national media point to an increase in computer security compromises at higher education institutions that have resulted in the potential loss of confidential data. According to material presented by United Educators, "Computer security incidents at educational institutions have received unprecedented media attention in 2005." To manage through these crises some universities have spent hundreds of thousands of dollars in customer notifications, user support or hiring outside crises management consultants.

To help ensure appropriate handling and managing of such a crisis, Cornell needs to comprehensively understand what data require protection and where these data reside within our computing infrastructure. Furthermore, effective incident handling also requires the ability to make informed decisions that will protect the university¹s reputation and therefore demand the development and implementation of response mechanisms for such a crisis before one occurs.

This document supports the position that Cornell must make some changes in order to most appropriately and efficiently handle compromises to computers that process or store institutional data. Five specific recommendations are made:

1. Organize a Data Loss Response Team comprised of the appropriate executives/administrators to ensure effective incident handling that addresses all of the university's potential concerns.
2. Define the institutional data that merit special concern.
3. Promote consistent incident response techniques and analysis by requiring the IT Security Office to be involved with each incident that includes institutional data.
4. Understand and document how Cornell institutional data are processed, where these data are stored and managed across the university.
5. Establish minimum security standards for computer systems that store institutional data.

Introduction

Like most universities, Cornell relies heavily on access to institutional data that are stored on-line. Much of these data are confidential. While security technologies and prevention are extremely important, we must acknowledge that no solution is perfect and the risk of data compromise will always remain. We must be prepared to knowledgeably, efficiently and appropriately respond when information technology systems are compromised and there is a risk that confidential data were stolen or otherwise acquired.

This document will provide some examples of computer and data compromises in higher education, describe the data that Cornell must protect and then recommend a process for ensuring Cornell is prepared to appropriately handle such incidents.

The Current Security Situation

Implementing and maintaining data security within universities is particularly challenging. The diverse computing needs of the university community, the general desire for openness to facilitate research, and the requirements to support a broadly defined community make attempts to infallibly control access to information technology services difficult, if not unfeasible.

The broad distribution of institutional data across university infrastructures further complicates data protection efforts. As with all universities, Cornell has a difficult time identifying where all institutional data are stored, how they are transmitted and who has access to these data. For example, while Cornell has a responsibility to protect educational records (grades for example), these are typically stored centrally in the student records system, within each college, and within hundreds of individual professors¹ computer systems. Other types of institutional data are similarly distributed across campus. This means that protecting institutional data is not as simple as installing appliances like firewalls or the development of singular rigorous authentication and authorization systems for central "main frames" — rather all users of computer systems must understand Cornell's security obligations when handling sensitive institutional data.

Two major factors are currently forcing universities to: think differently about the ways they address the confidentiality and integrity of their data; make larger investments in their security infrastructures; hire dedicated security personnel; and openly report compromises even in the absence of concrete evidence of data loss:

1. Under existing federal, state and local legislation universities are responsible for the confidentiality and integrity of data within their institution. Some of the most important examples of such legislation, with more that can be expected in the future, are:
1. The Family Educational Rights and Privacy Act (FERPA) – protection of student records,
2. Gramm-Leach-Bliley Act (GLBA) – protection of financial records,
3. The Health Insurance Portability and Accountability Act (HIPAA) – protection of health care records,
4. California's Personal Information Privacy Bill – notification of computer security breach for California residents,
5. New York Information Security Breach and Notification Act – required notification if there is reasonable belief that data were inappropriately acquired.

Reference Appendix A for more detailed information of the legislations mentioned above.

2. As computer security compromises and the potential for identity theft become more well known and publicized, the members of the community that universities support (students, alumni, donors, etc.) will demand to have their personal information well protected and, in the event that sensitive data may have been exposed, require that they be notified of such incidents.

Today there are many eye-opening examples within higher education of computer compromise that resulted in the unauthorized access and acquisition of records such as social security numbers, grades and donor information. United Educators recently published summary information of 5 computer security incidents in higher education during 2005. A table containing summary information for the first six months of 2005 is included in Appendix B.

While some current legislation requires formal reporting and notification of impacted parties for certain classes of data compromise, many institutions are taking a broader approach by defining a formal notification process when the potential for data compromise and unauthorized data acquisition has been discovered. This aggressive approach is in response to community expectations and demands for information. Representatives from Tufts University recently captured this growing sentiment when they analyzed their need to report a security incident that occurred on an alumni data system. This excerpt is taken from The Boston Globe, April 12, 2005.

"There's been absolutely nothing untoward since Dec. 19," Jay said. At the time, Tufts officials saw no reason to warn alumni, as the school found no evidence that any personal data had been accessed. But then came news of the alumni computer breach at Boston College, as well as thefts of personal information at California State University, the University of California at Berkeley, Northwestern University, and the commercial database vendor ChoicePoint Inc.

The spate of scary headlines made Tufts officials rethink their silence. "We started seeing these across the country," said Jay. "As we gathered more information on this, we decided it would be better to be super cautious." Jay estimated that the mailing would cost Tufts about $41,000. "We certainly think that it's worth it," she said.

Institutional Data

There are different flavors of institutional data at Cornell with varying levels of confidentiality needs and associated concern. Some of our data are for public distribution while others are not. Our concern is with institutional data that are not supposed to be publicly available. Unauthorized access to sensitive institutional data demands special response. Some characteristics of our more sensitive institutional data are listed below.

• Personally identifiable information (PII) is of particular concern due to recent legislation requiring both reporting and notification of unauthorized access. These data are tightly associated with identity theft. This type of data includes name associated with social security number, driver's license number, credit card numbers or bank account numbers with associated PIN.
• Legislatively protected data are data that are subject to some government regulatory oversight. This includes data such as FERPA (student records), HIPAA (medical records), and GLBA (financial records). See Appendix A for further descriptions of legislative examples.
• Other sensitive data where unauthorized disclosure of which could lead to a business, financial and/or reputational loss. These data include business related data such as payroll information, other benefit information, work history and other personnel information, alumni contributions, budget information, controversial research topics and chemicals or other materials used for research.

It must be noted that these data characterizations outlined above are not mutually exclusive. For example, a system compromise that results in the loss or acquisition of social security numbers may fall in all three of these categories.

Responding to the Loss of Protected Data

For all security incidents that involve unauthorized access to or the potential acquisition of data, key questions must be answered to ensure the incident is well managed and appropriately responded to.

• Are these data protected by federal, state or local law?
• Do we report this compromise to law enforcement authorities?
• Do we notify people who were potentially affected by the loss of data and what do we say?
• How is this notification going to be accomplished?
• How do we respond to or how do we notify the press?
• How do we address community concerns and complaints?
• How do we stop this event from happening again?

This is particularly true for computer systems that process institutional data. To answer these questions, campus personnel in both the executive/administrative and technical realms are needed. The collective knowledge and views of several departments across campus is required to ensure a consistently informed decision.

Recommendations

In order to more effectively and appropriately respond to IT security incidents that may impact the confidentiality of institutional data, it is important to develop a response process and policy before such an incident occurs. To this end, Cornell needs to take steps to understand what data requires a higher level of protection and where these data reside within our IT infrastructure. Further, we need to ensure timely and effective communication among all involved; develop a consistent and accurate analysis of incidents process; and establish mechanisms for collaborative involvement of the appropriate decision makers. The following set of recommendations aims to meet these goals.

1. The VP of IT should establish a Data Incident Response Team that would collaborate as required to ensure the university is appropriately and responsibly responding when security incidents occur. This Data Loss Response Team must include representatives from the Data Steward responsible for the compromised data, University Audit, CU Police, University Counsel, University Communications and Media Relations, University Risk Management, IT Policy, IT Security Office and senior staff from the unit (or units) within which the compromise occurred.
2. To ensure consistent and accurate technical analysis, the IT Security Office should participate in all investigations of IT security incidents involving resources that process institutional data. This process would follow a formal incident response methodology, such as described below:
1. Upon identification of a security incident that involves an IT resource that processes institutional data the IT Security Office is notified by the party who identified the incident.
2. As soon as possible after initial notification, the IT Security Office sends an initial incident report to the VP of IT using the incident template contained in Appendix C.
3. The VP of IT determines whether and when the Data Incident Response Team should be notified.
4. As the analysis progresses, periodic status reports are sent from the IT Security Office to the VP of IT. Upon completion of the incident analysis the IT Security Office produces a final incident report that is delivered to the VP of IT using the Security Incident Report template contained in Appendix D.
5. The VP of IT and the Data Incident Response Team work together throughout the incident response process to determine the appropriate course of action for protecting the university's interests.
3. The university should clearly articulate and define what constitutes "institutional data". This classification must be well communicated to ensure consistent security measures and appropriate response to security incidents.
4. Each unit should identify how institutional data are used, disseminated and stored within their units. This will aid in determining specific security measures and ensure appropriate response procedures are initiated.
5. CIT must support the data stewards in establishing and implementing institution-wide minimum security standards for computer systems that store institutional data.

---

Appendix A

Below are some examples of current legislation that addresses the privacy and integrity of specific data records. This is not a complete list but rather just some of the more specific and strict pieces of legislation. Further, most people expect additional legislation in the near to middle term.

1. The Family Educational Rights and Privacy Act (FERPA) requires the safeguard and protection of privacy for educational records. Individuals cannot bring a case against the institution, but the Department of Education can enforce by depriving an institution of federal funding (including financial aid to students). Historically, the Department has not been severe in its enforcement, but electronic storage of educational records exponentially increases the magnitude of a potential breach of records, and negligence in the proper safeguards could have a serious deleterious legal, financial and reputational effect.


2. The Gramm-Leach-Bliley Act (GLBA) protects banking information (for example financial aid records, but not bursar accounts). Separate security and privacy regulations call for the appointment of both security and privacy officers to monitor compliance. The security office purview includes administrative, logical and physical security, while the privacy officer is in charge of the specific fair information practices that attach to this legislation (such as initial notice of privacy policy and annual reminders). State law does not supercede the GLBA. Individuals cannot bring an action. The Federal Trade Commission enforces this legislation.


3. The Health Insurance Portability and Accountability Act (HIPAA) protects the privacy of medical records for health care providers, health maintenance organizations and health records clearinghouses. It, like the GLBA, requires "covered entities' to appoint separate security and privacy officers, who, as officers, have personal liability, which they share with whatever liability the institution may have as well. (Cornell's indemnification policy would likely cover individual employees in the case of a lawsuit.) The security regulations closely resemble those of GLBA, including the establishment of a security program and an intrusion detection and incident reporting policy for data networks. HIPAA establishes the floor of privacy protection and does not pre-empt state action. Individuals can bring an action and the Department of Health and Human Services can enforce also.


4. California's Personal Information Privacy Bill requires any entity holding personally identifiable information (name plus social security number or credit/banking information) of a California citizen that was not encrypted to notify affected individuals in the case of a breach. Both private and state enforcement are possible under this legislation. A bell-weather of proposed federal legislation, this law is responsible for the public disclosures of a number of data breaches that have occurred in California, including the California university systems.


5. New York's Breach Notification Law requires notification to any New York resident whose "private information" was, or was reasonably believed to have been acquired by a person without valid "authorization". The notification must be made in the most expedient time possible and without unreasonable delay. In addition to personal notifications notice must also be provided to the New York State Attorney General, the New York State Consumer Protection Board and the New York State Office of Cyber Security and Critical Infrastructure Coordination.

---

Appendix B

Institution Involved	Number of People Affected	Description of Incident
January 2005
George Mason University	32,000	Hackers accessed server with names, social security numbers (SSNs), campus ID numbers (#'s), and photographs of all students, faculty, and staff.
Harvard University	Unknown	Student newspaper exposes that software for surveying students can be used to view student prescription medications.
University of Kansas	1,450	Hacker accessed foreign student database that included names, SSNs, passport numbers, birth dates, and countries of origin.
University of California at San Diego	3,500	Someone accessed computers containing names and SSNs of current and former students at UCSD Extension.
University of Northern Colorado	30,000	Hard drive disappeared that contained names, addresses, SSNs, bank account numbers, dates of birth, and pay schedules for students, staff, and their beneficiaries.
February 2005
Indiana University	Unknown	Hacker accessed personal information of employees at university foundation
University of California at San Francisco	Unknown	Hacker accessed server containing data for thousands of students, faculty, and staff.
Wichita State University	7,500	Hacker accessed personal information on students and faculty in College of Education, clients of the Speech Clinic, and international students.
March 2005
Boston College	120,000	Hacker accessed names and SSNs of alumni in fundraising database.
California State University, Chico	59,000	Hackers broke into computer system containing names, addresses, and SSNs of students, alumni, faculty, and staff.
Carnegie Mellon's Tepper School of Business	2	Hacker broke into admissions software and showed applicants how to log in to see if they had been accepted.
Dartmouth College's Tuck School of Business	1	Hacker broke into admissions software and showed applicants how to log in to see if they had been admitted.
Duke University's Fuqua School of Business	1	Hacker broke into admissions software and showed applicants how to log in to see if they had been admitted.
Harvard Business School	119	Hacker broke into admissions software and showed applicants how to log in to see if they had been admitted.
MIT Sloan School of Management	32	Hacker broke into admissions software and showed applicants how to log in to see if they had been admitted.
Northwestern University	20,000	Hacker broke into server containing personal information on business school students, faculty, and alumni.
Purdue University	1,266	Hacker accessed names and SSNs of faculty, staff, students, and alumni.
Stanford Graduate School of Business	41	Hacker broke into admissions software and showed applicants how to log in to see if they had been admitted.
University of California at Berkeley	98,369	Laptop stolen that contained names, SSNs, and birth dates of alumni, graduates students, and past applicants.
University of Nevada, Las Vegas	5,000	Hackers accessed database containing current addresses and country of origin of international students.
Yale University	28	Students were directed to phony Yale website through a phishing scheme that captured their personal information.
April 2005
Carnegie Mellon University	19,000	Hacker accessed SSNs of 5,000 applicants, graduate students, and staff at business school and addresses and phone numbers of 14,000 alumni.
Georgia Southern University	Thousands	Hackers broke into a computer that contained credit card numbers and SSNs of customers at university bookstore.
Florida International University	Unknown	Hackers compromised 165 computers possibly containing SSNs and credit card numbers of faculty, staff, and students.
Michigan State University	40,000	Hacker accessed a computer for processing credit card orders at a performing arts center.
Oklahoma State University	Unknown	Laptop that included the SSN, gender, ethnicity, class, and e-mail address of students and alumni was stolen from career services office.
Tufts University	106,000	University notices "abnormal activity" on databases containing alumni names, addresses, phone numbers, SSNs, and credit card numbers.
University of California at Davis	1,100	Hacker accesses computer with names and SSNs of students, faculty, staff, and visiting speakers.
University of California at San Francisco	7,000	Hacker accessed server used by accounting and personnel departments.
University of Mississippi	300	Students' names and SSNs accidentally posted on the school's website.
University of Northern Iowa	Unknown	Security breached at a public radio station server, which contained donor names, addresses, phone numbers, pledge amounts, and credit card numbers.
May 2005
Brigham Young University	600	Program installed on four computers in lab recorded keystrokes of every student user.
Carlisle Area School District	Unknown	Students accessed to birth dates, SSNs, and addresses of district teachers and students.
Cleveland State University	44,420	Laptop stolen that contained names, addresses, and SSNs of current, former, and prospective students.
Hinsdale Central High School (IL)	2,400	Two students broke into database containing SSNs of all students and staff.
Jackson Community College (OH)	8,000	Hacker breached system containing SSNs of all students, faculty, and staff.
Middle Tennessee State University	25,000	"Limited personal information" was accessed from one of the school's servers, affecting students and staff members.
Purdue University	11,360	Hackers accessed SSNs and personal information on current and former employees.
Stanford University	9,900	Hacker accessed computers of career development center that contained SSNs, financial data, and credit card information on students and 300 recruiters.
University of Chicago	Unknown	Files containing SSNs, vaccination records, and other personal information were discovered with no security protecting them.
University of Iowa	30,000	Hacker accessed university bookstore computer containing credit card numbers and employee IDs.
Valdosta State	40,000	Breach of computer server containing SSNs and debit cards of students, faculty, and staff.
June 2005
Duke University Medical Center	14,500	User passwords, addresses, and partial SSNs were hacked from the DUMC server. Faculty, alumni, and trainees were affected.
East Carolina University	250	Hacker exported student SSNs from departmental server.
Jackson High School (OH)	Unknown	Student hackers changed grades and acquired teachers' SSNs.
Kent State University	100,000	Stolen desktop computers contained names, grades, and SSNs of faculty and students.
Michigan State University	40,000	Hacker accessed system containing credit card numbers of patrons at university performing arts center.
Ohio State University Medical Center	2,800	SSNs, names, phone numbers, addresses, and the reason for patient visit were mistakenly made available online.
Polk Community College (FL)	Unknown	Professor attempted to use names and SSNs of his students to obtain department store credit cards.
University of Connecticut	72,000	Hacker penetrated server containing names, SSNs, birth dates, and campus addresses of students, faculty, and staff.
University of Hawaii	150,000	Former library employee involved in identity theft scheme had access to SSNs of all library patrons over four-year period.

---

Appendix C

***
TO:    polley.mcclure@cornell.edu
SUBJ:  Security Incident Alert

At <time, date> we became aware of potentially significant security incident.

* Why the incident is of interest

* Brief summary of incident and current state of investigation/analysis

* When more information should be available

* Target date for formal report

* Whom to contact if further details are desired
***

---

Appendix D

IT Security Office
Security Incident Report When and Who

Date incident reported	Date of last update to this report	Cornell Department
Lead Security Engineer	Other security engineers involved	Local Support Providers involved

Description of Incident (How was it identified, what happened?)
and Analysis (Evidence found on system, in logs; to extent known: root cause, vector, when)

Systems and Data Involved
List of systems involved in compromise	Type of system (end user, web server, database, etc.)	Type of data stored on system
1. list 2.	1. Type 2.	1. Data type 2.

What is the likelihood of data being acquired? Explain.	Are there immediate steps required due to data loss? Explain.

Incident Response

List specific response mechanisms implemented        1. Hosts removed from network        2. DMZ Block        3. etc.

Formal Analysis

Type of analysis	Performed by	Tool Used	Location of Results	Date
Scan
Traffic Analysis
Image
System (log) analysis

Recommendations

List specific recommendations that could prevent this from occurring again: Edge ACLs Patch management Locking down desktops Security assessments etc.