University Business - August 2007 - (Page 22)

VIEWPOINT rensic engineering team observed a pattern emerging, a pattern which determined the following: • The worm entered the system when someone using the ﬁnancial system used it to run a web browser and surf to a website that had an infected page. Accessing the page allowed the worm to download. • The worm exploited a security weakness that had not been ﬁxed with a security patch that was, in fact, readily available. • Once the worm activated within the server, it sought and found what it thought were credit card records. • The software in use by the university did, in fact, encrypt the credit card data on the main ﬁles, but it also maintained an unencrypted copy (unbeknownst to users of the system). Unfortunately, instead of being kept for a limited period of time, the copy had every credit card transaction going back for years. • Upon ﬁnding the records, the worm called out to a compromised server at an Asia-based university and downloaded additional code, known as a “payload.” In this case, the payload was a credit card parsing engine, which is software speciﬁcally designed to ﬁnd and prepare credit card data for transmission to hackers. • The worm assembled the data from a quarter of a million credit card records and was prepared to send it out to the hackers when it encountered a problem. By delving through extreme detail provided in the logs, investigators could see the worm’s attempts to connect over the internet to a series of delivery addresses. Even better, they could tell that it was unable to establish a successful connection due to internal errors and the fact that some of the delivery addresses were no longer in operation. Therefore, the credit card data never actually left the university’s server. THE NOTIFICATION OPTION While the forensic analysis was being per- formed, the university and specialists in data breach remediation began to discuss victim notiﬁcation, if the forensics found that a breach had actually occurred. A primary challenge was to navigate the diﬀerent states’ varying notiﬁcation requirements. Some have speciﬁc language parameters; others require multiple notices to designated agencies. The data breach remediation team was able to work with the university’s counsel to carve out which While issues such as unencrypted data and inappropriate site surﬁng had to be addressed, the darker cloud had lifted. requirements would have to be met, and under what time frames required by those laws. Then the logistics associated with validating cardholder information, identifying deceased cardholders, and producing and mailing hundreds of thousands of letters—as well as the related administrative issues—were used to develop a response action plan, which, fortunately, did not have to be used in this case. Another issue to be considered was how best to manage questions that would surface from the notiﬁcation. Experience from handling hundreds of data breach cases over the years indicates that people who receive notiﬁcation of a breach often want to talk with someone personally. Fielding such a range of calls and reactions is not an undertaking for unprepared staﬀ. Individuals whose data has been compromised typically need reassurance in addition to information about the incident and the solution the college or university has chosen. Callers must be treated professionally, sensitively, and uniformly. Institutional leaders must be certain that promises are not made that conﬂict with the remediation plan and that callers are not given inaccurate information. For this reason, many, if not most, organizations victimized by data breaches choose not to direct callers to their own phones. Rather, they opt for a dedicated customer care center, where trained professionals with a successful track record are ready to calm and clarify. When a care center specialist using sensitive yet targeted discussion determines a caller may actually have been victimized, the call is immediately relayed to a licensed investigator. This triage enables the team to provide eﬃcient and eﬀective service to all callers. LESSONS LEARNED Ultimately, the computer forensic team was able to advise the university team that while there were issues to be addressed— unencrypted data, absent security patches, and inappropriate site-surﬁng—the darker cloud had lifted. There was no need to notify either the 250,000 credit-card holders or anyone else, since no breach had occurred. The university dodged the bullet, although not by much. The lessons learned in all these cases lead us to make a few recommendations: • Don’t assume that it can’t happen to you. In today’s environment, the reality is that it can—and may. • Put a plan in place so that when the crisis hits you won’t be trying to ﬁgure out what to do. Part of this involves identifying the resources you will want available. • Establish a working group that will have the authority to permit necessary and required work. From a technical viewpoint, you may want to have your preselected network forensic resources spend a little time with your technology staﬀ to determine what logs should be kept, for how long, and how they should be secured if an incident is suspected. Even in the best of circumstances, a potential data breach is traumatic. But with proper planning, the incident can be rapidly analyzed, understood, and worked through in a systematic manner. 22 | August 2007 universitybusiness.com http://universitybusiness.com

Table of Contents for the Digital Edition of University Business - August 2007

Contents
College Index
Company Index
Advisory Board
Editor's Note
People Watch
Sense of Place
Viewpoint
Admissions
On the Hill
Future Shock
Independent Outlook
Facility Focus
Wanted: Foreign Students
Service With a Star
Beneficial Benefits
Addition By Subtraction
Report from EduComm 2007
Report Card
Internet Technology
What's New
Calendar of Events
Direct Connect
End Note

University Business - August 2007