期刊名称：Journal of Information Technology Education: Discussion Cases
印刷版ISSN：2166-1316
电子版ISSN：2166-1324
出版年度：2017
卷号：6
DOI：10.28945/3926
语种：English
出版社：Informing Science Institute
摘要：A professor in information systems discovers that his personal website has been hacked. Even worse, his ISP has suspended his site because the defacement included a PayPal phishing scheme. This is not the first time this has happened. How should he recover? Dr. T. Grandon Gill, a Professor in the Information Systems and Decision Sciences Department at the University of South Florida, was traveling with his family in England when he received a strange phone message. Not being able to respond, he ignored it until—a couple of days later—he was notified that access to his personal website had been suspended (see Exhibit 1). Grandon.com had, once again, been hacked–for the 7th time. Getting his website hacked was not a new experience for Grandon Gill. In the past, however, getting the site back up and running had been a quick fix involving replacing the corrupted files. This time it was different. Based on the email and his service provider’s response, his site now contained links to PayPal phishing sites. Without significant changes, he could become complicit in fraud if the situation was not remedied. This was a problem that could no longer be ignored. After Gill had re-read the email, he pondered the various options available to him. Given the amount of trouble it was causing him, he wondered if he needed the website at all. To maintain the domain name grandon.com, which he had held for more than 20 years, all he needed to do was to put up a simple landing page with a message: “Hi, I am Grandon—go to my school account to find out more.” At the other extreme, he could completely re-engineer the site to make it much less vulnerable—a process that could take days, if not weeks. Between the two extremes, there were many other possibilities. These included changing hosts, simplifying the site so that it contained only the most critical information, dropping its WordPress component, or even going to a pure WordPress model. He had a suspicion, based on previous experience, that vulnerabilities in WordPress may have been the source of the hack. But were these vulnerabilities intrinsic to the application, or were they simply the result of his inattentive management? Whatever he decided, he needed to take action soon. It was very embarrassing, and perhaps professionally damaging, to have his site showing an unavailable message. He thought back to a popular ironic quote that said: “Good decisions come from experience, and experience comes from bad decisions.” What should he do now?
