Cost benefits of the security and systems management of electronic publishing Internet Web server subscription services and e-commerce.
This study deals with a perceived cost benefit theory of the security and systems management of electronic publishing Internet Web servers and subscription services. Our focus includes security threats, vulnerabilities and proposed remedies.
Before the catastrophe of the World Trade Center twin Towers on 9/11/2001, Americans felt pretty secure in the US. All of that changed overnight; it took only one event to alter the perceived cost of insecurity in the United States. The security vulnerability facts of the US did not change as a result of the 9/11 event, but the perceptions changed dramatically. All of a sudden Americans felt very insecure, and felt the full cost of this insecurity in terms of loss of life, property, stock market values, loss of opportunities, economic decline, and constant fear of terror.
Our theory is that the same perception applies to computer security and e-commerce in particular. The perceived cost of security vulnerabilities dictates their perceived benefits, and therefore the spending on security measures and controls. It is similar to the theory of "What Makes Users Happy (Rushinek & Rushinek, 1986)," except that it is more about "what makes users unhappy." The main hypothesis, which we have tested numerous times, is that users will pay for whatever makes them happy. Likewise, they will pay to avoid what makes them unhappy. For a more detailed analysis, we will apply our theory to the security and systems management of automated electronic publishing Internet Web server and e-commerce.
An electronic publishing Internet Web server hosts an accounting spreadsheet Internet case study that provides students an opportunity to practice what they have learned and prepare for the final exam. During the semester, students download the case from an electronic publishing Internet site for a small fee (http://www.cybertext.com). Students subscribe to these services using a credit card and can use the services for the duration of the semester. The subscription allows the students to upload their work an unlimited number of times. The case assignment is graded each time the students upload their work to the server, keeping their latest score as the final score. This case is a take-home exam of sorts; students take it on their own time during the semester, and their last score contributes to 10 percent of their final grade in the class. Once we establish that the performance of the case assignment and the final exam in the course are statistically significant, we can use this correlation, or lack of it, as a red flag detector for the possibility of cheating. Such a detection system design is the focus of the current study.
Recent political and military events, coupled with the accelerating frequency of cyber attacks on network and Information Technology (IT) systems and technical revelations of management protocol insecurities, underscore the substantial risks associated with network, systems and applications management. In our case of the Security and Systems Management of an Electronic Publishing Internet Web Server, students and possibly even some faculty members may attack the network system or the Web server. This system involves an author who develops this case study and gets royalties from the revenues that the Web server collects from each student who subscribes to the services for the duration of the semester. Students may be motivated to crash the system so that the instructor will relieve them from the burden of doing the assignments. Likewise, professors that have to include student's performance in the final grade may also not be extremely motivated to administer this case, but this is another problem. The focus of this study is how to control the students and the insecurities that they may present themselves.
Through management systems, rogue students can perpetrate targeted as well as system-wide fraud, theft of services, and disruption of capabilities and management data. One activity that the students may be able to do, is continuously gang up on the Web server. They can upload excessive payloads on to the server continuously and relentlessly, crashing it multiple times. Then they can run back to the administration claiming the server is down and they should be relieved from the homework.
Worse yet, due to the extended, pervasive reach of management systems, such rogues can obtain the credit card numbers of other students and attempt to either use or sell them on the Internet. Likewise, such students may also try to cheat by not taking their own take-home case exam, and instead hiring other students to do the work for them. In return, these students will pay other students to do the work for them, and upload the work as if they have done it. Other rogue students and non-students may see this as an opportunity to make a little money and participate in this scheme. Likewise, students can try to upload huge video files, viruses embedded in the case-study files and put a stranglehold on the IT and networking resources of an enterprise, the university in this case, and/or the Web server, which is a third-party independent publishing company.
Consequently, interest in the security aspects of the Security and Systems Management of Electronic Publishing Internet Web Servers and Services has been on the increase. Security is now an essential feature, not an after-thought, of an information enterprise. The commercial sector is pursuing double-digit growth rates for IT and network security spending. Publishing companies are embracing e-business strategies that involve integration of systems and resources with business partners. The publishing professors and authors want assurances that their internal resources will not be compromised by vulnerable management systems, internal or external. Such companies and universities remain at risk for cyber attack on the integrity of their systems. This is making security R&D a high priority. International standardization activities are emerging to address security in managed networking domains for global communities.
Threats, Vulnerabilities and Requirements for Security Management and Management System Security
1. Web Server Side Threats, vulnerabilities and requirements for security management and management system security.
We can divide threats, vulnerabilities, and requirements for security management and management system security to two main categories, the Web server, and the Web client. We can further sub-divide the Web server category into its users. One type of user is the publisher, another type of user is the author or the software developer (which many times are the same person, but can be different people and many times different companies). The clients are students, who subscribe to the services for the duration of the semester and their respective instructor, who instructs them and grades their performances. Each category and sub-category has its own unique threats, vulnerabilities, and requirements for security management and management system security. In contrast, all users have also some common threats, vulnerabilities and requirements for security management and management system security.
One common Web server side type of vulnerability is the stability, scalability and availability of the server. All the users need to access the server, and some even have an interest in bringing it down. For example, if the students can bring the server down at the last week of the semester, the due date, they may relieve themselves of the extra work. Such threats, vulnerabilities, and requirements for security management and management system security may include but are not limited to virus attacks, overloading the storage, and bandwidth with huge irrelevant files, such a DVD files, etc.
Server Back Up & Recovery Procedures
What can the publisher and administrator of the server do to back up the server and recover (Rushinek & Rushinek, 1985) from a server crash, in which all the work of all the students for the entire semester may be lost? Does the publisher have server back up and recovery procedures and are they effective?
What about the loss of the credit card numbers that were collected yet not charged? Is there anyway to recover them and proceed with charging them and collecting the revenue due to the author/developer?
Web Server Side and Author/Developer Category Insecurity Concerns
Other vulnerabilities and requirements for security management and management system security are unique to the author and software developers. Their concern may be as to how easy is it for the publisher or another author/developer team to reverse engineer their creation, duplicate it, and compete with them. Specifically, they may be concerned about the publisher. How easy will it be for the publisher to reverse engineer popular subscription-based case studies, recreate them, and cut the original author/developer team out of business?
Web Server Side and Publisher Category Insecurity Concerns
On the other hand, the publisher may have the opposite concern. Once the author/developer team figures out how profitable it is to run this subscription service, what will prevent them from duplicating the server on their own and cut out the publisher, by placing their own server on the World Wide Web? This way, instead of making only a commission of 10 percent from the sale, the author/developer team is in for the entire 100 percent of the profit. The authors do not even need to set up their own server; they can simply rent these services from any Internet service provider for a flat fee of $20 a month and $60 for a semester, keeping the profit for themselves. If only 300 students subscribe at $20 a pop, the author will earn $540 for one course. Scale it to a large state school, like the University of Texas at Austin, and you get 10 times as much for one course, about $5000, and for two courses $10,000. One can scale it further to several dozen large schools to get approximately $10,000 per school and $100,000 per semester. This can be more than the average professor earns for an entire academic year.
2. Client Side Threats, vulnerabilities and requirements for security management and management system security.
Theft of Client Credit Cards
One client-type vulnerability is the stealing and selling of students' credit card numbers. As of now, the students enter their credit card numbers into a regular field, where it is visible to any other student, who may be watching over their shoulders. A remedy for this problem would be to mask the credit card field with dark dots so that it is not visible to the eyes of a bystander. Is it cost effective? Is it necessary? How many students are likely to steal, conceal and sell other students credit numbers? These are empirical questions. So far we have not documented even one such case. Is it impossible? No. It is very easy to do. However, what are the chances of this to occur? Do we want to wait until it happens? The answer may depend on the development cost versus the potential risk of loss and damages.
If the loss of revenues and profits are enormous, yet the development cost is insignificant, we will do it soon. On the other hand, if the margins are such that we barely break even, we are not going to sink a lot more cash and resources into the security of the system.
Let us say that we have further developed the security and the system masks the first two digits of the credit card any time a student enters a credit card. A bystander would no longer be able to simply copy the credit card number and expiration date from the screen. Is this security method foolproof? The answer is no! A sophisticated student can run a keyboard entry trapping (trapper) routine on all the computers in the lab prior to the arrival of the class. Such a trapper routing will trap the entries directly from the keyboard interrupt ignoring the video display and storing the entries on a file, to be used later. Should the developer go to the next step to detect and or prevent such trapper routines? We do not think that it will be cost effective in this case, but it may be in other cases.
Hiring a Proxy to Perform the Work for Which Students Claim Credit
How about cheating? Can we verify that a student does not hire another student to upload the take-home case-study exam with certainty? No, not if we let them do the work anywhere any time they want. Do we want to force the students to do the work in the university lab under the supervision of a proctor and view of the security cameras? This may not be feasible because the labs are not large enough to accommodate so many students for so many hours. The whole point of this method of teaching is the flexibility to do it anywhere, at anytime, as many times as the student wants. So what can we do to discourage cheating?
This is the focus of our current study: A system that discourages cheaters by automating the detection of red flags, and allows one to review the flags for further investigation. This threat alone may be sufficient to deter students from cheating, and yet is extremely inexpensive.
The Security and Systems Management of an Electronic Publishing Internet Web Server
How does the security and systems management of an electronic publishing Internet Web server system work? Simply, it tracks the students at the extremes of the performance distribution. It finds the students with the highest case study grades and the lowest in-class test grades, and flags them. Such students will be invited to speak to the instructor to explain the wide grade discrepancy between their take-home case study and their in-class exams that cover the same material. The instructors may well accept their explanations. The instructors may choose to re-administer the case study under supervision. If they ace it again or come close to it, it's ok; but if they fail it miserably, then may be they have cheated the first time when they aced it, and got 100 percent in one upload. In this case, investigations may be warranted and further security measures need to be implemented in the future.
Another initial security threat to this system was that the correct solutions were included in a hidden Excel spreadsheet. The security weakness was such that some students figured out how to get into the hidden sheets. Instead of solving the problems by themselves, they copied the correct solution from the hidden sheet, and submitted it as if they have solved the problem. The current security system has controlled for such vulnerabilities.
Client Back Up & Recovery Procedures
The instructor teaches the students to work on the hard drive since it is faster and more secure, and then upload their work to a "digital drop box," which is an education Web server that stores their work. This digital drop box stores the student's work to two different directories. One is the student's private directory and the other is the instructor's directory. This way the student has four different concurrent copies of their work. Furthermore, the instructor requires students to maintain three generations of floppy copies, Monday, Wednesday and Friday, alternating their use every day. This way when the Friday floppy is wiped out, the student client can recover from the Wednesday floppy losing only one day of work, assuming their work is no longer on the hard drive and the "digital drop boxes.
Testing and Evaluating Security Management and Management System Security Solutions
For those students that the system generated "red flags", re-testing will be done. The continuous re-testing of some students constitutes part of a testing & evaluating security management system for these e-business systems. As long as it appears to be working, we will avoid any drastic changes. In contrast, if we discover a large number of problems, we will add additional security measures.
One of the security solutions that we used to ensure that the system would not crash during normal overload was to invite an entire class of students to the PC Lab at the beginning of the semester. We had the students upload files to the server simultaneously. After the Web server passed several of these tests, we authorized the use of this system on our classes. We do this load testing at the beginning of each semester, to ensure that the Web server is stable enough and that it can handle normal overload.
Integration of Security and Management with Business Goals and Strategies
We integrated the security and management of this system with its business goals and strategies of a take-home exam and a case study system. We want to avoid overloading the instructor with excessive grading duties by automatically grading the students every time they upload their answers to the server. This makes it possible for students to cheat every time they upload their work. We could limit the number of uploads, but this will deprive diligent students from learning from their mistakes during successive uploads.
This case study so far has been an experience of secure management and security management systems that is sufficient and cost effective. Some weaknesses still remain but it is not clear that securing these weaknesses any further will be cost effective. In other words, if we implement additional security measures their costs may exceed their benefits. For this reason, we want to investigate the red flags to decide whether these issues need additional security controls. For example, if we find that some students ace the take-home exam and fail the final, but there is no evidence that they have cheated, then there would be no reason to add more costly controls.
Capturing Sudents' User Names, Passwords, Credit Card Numbers, & Expiration Dates
There are several internal and external hardware and software keystroke loggers, recorders and trappers. These products can compile a record of what a user types and then make it available over email, Web site or recorded on a hardware device. Prices range from $100 to $500 for hardware-based keystroke loggers and can capture millions of keystrokes and support several foreign languages. Some of these devices are wireless and can communicate in real time. Logging software programs are available for less than $99 and record keystrokes and screen images (Coursey, 2002).
Due to the fact that many university labs set their computers to prohibit users from installing or downloading software, many of the keystroke logger software packages may not work. However, that still does not prevent the hardware logger from working. Thus a person, who knows when a class is coming to the lab, can install a few of these external hardware loggers prior to the arrival of the class, capture the data entries, and then after the departure of the class harvest the confidential information.
Is this possible? Yes. Is it simple? Yes. Could we prevent it? Yes, by simply enclosing the PC in a sealed cabinet while exposing only the part of the keyboard, video, and disk drive that users need to access. However, this is too costly for most education organizations and therefore, most of them remain vulnerable.
Laws and Policies on Management Systems, Operations, Administration and Maintenance
Laws and policies on management systems, operations, administration, and maintenance can be used to promote certain security issues. For example, one such issue is the prevention of cheating during a take-home case-study test. One of the policies on management systems, operations, administration and maintenance of this system is the implementation of a static random number generator for problems and solutions. This differs from a dynamic random number generator. Since the student does not need to finish the case in one sitting, the system generates a set of numbers for the case study and these numbers remain static for the student for each upload. However, to prevent cheating, each student is assigned a different random number generated set. Another policy enforced is a six-digit (to the right side of the decimal point) precision requirement for the solutions to the answers.
The static random number generated problems and solutions ensure that each student gets a unique set of numbers in the problem and its solution. This makes it more difficult for a student to copy and paste the answers of another student, and claim credit for another student's work. However, the system is still vulnerable to copying and pasting of the formulas, which will ensure that no matter what the numbers are, as long as the formula is correct the students will be able to get away with cheating.
What can we do to further reduce the probability of cheating? We could implement a random number generation of the formulas, making it very difficult and time-consuming to copy and paste formulas from one student to the other. However, this will not be cost effective for now, because the return on investment (ROI) does not justify additional investments on the current return.
The six-digit (to the right side of the decimal point) precision requirement for the solutions to the answers makes it more difficult for students to simply copy manually the answers from another source, such as a calculator or another student. The idea is to motivate the student to use a spreadsheet to calculate the results, rather than a traditional calculator. Again, this is not perfectly effective; some students have such bias against using a spreadsheet that they get a calculator with high precision and type in the answers manually. So, should we raise the precision? We do not think so, due to the diminishing cost benefit relationships.
In summary, we have reviewed the security and systems management of electronic publishing Internet Web servers, highlighting some of the red flag security threats and applying a cost benefit approach. We have listed numerous issues and advanced the theory that it may all be a function of a cost benefit analysis. More specifically, it is a matter of the perceived cost of insecurity. Based on the perceived cost of insecurity, we estimate the value of the benefits of eliminating that cost and finally arriving at the value of the solutions.
We conclude that typically our experience and not objective facts determine the perceived cost of insecurity. Therefore, only catastrophic experiences of the kind that we have described will lead to a sufficiently high value of the perceived cost of insecurity. For example, if 4,000 credit card numbers were to be stolen from student labs at a large university, leading to an average of $1,000 of unauthorized Internet purchases, and total of a total of $4 million of losses and damages; this may be sufficient to draw the attention of the relevant authorities, raising the perceived cost of insecurity. That rise in the perceived cost of insecurity will lead to a different cost benefit analysis and the tightening of some of the security holes that we have listed.
Without a significant rise in the perceived cost of insecurity, the cost of security measures is obvious. It is clear every time we have to remember which user name and password applies to which system. Every time we misspell our user name or password, and every time we have to re-enter them, is another experience of burden and the cost of security systems. Every time we use a user name like "username" and a password like "password," we remember the burden of security. So, we will continue to be very cautious before we will implement more security measures.
The implication of this study is that more resources should be devoted to evaluating the effect of such a training method in order to further improve its academic effectiveness as well as the cost effectiveness. As software becomes more Internet-compliant, such applications will be much more robust and much easier to develop and use. Therefore, we expect them to grow exponentially with the growth of the Internet.
Coursey, D. "Keystroke Loggers" http://www.zdnet.com, January 4, 2002.
Rushinek, S. and Rushinek, A. "Accounting Information System Development in EDP Auditing," The Management Accountant, March 1983, 96-100.
Rushinek, A. and Rushinek, S. "Security: Vital Controls in an Accounting Information System," Accountancy, March 1983, Vol. 94, No. 1075, 65-68.
Rushinek, A. and Rushinek, S. "Performance Monitoring Tools for Computer Systems: Hardware, Software, Firmware and Hybrid Controls," Computers & Industrial Engineering, 1984, Vol. 9, No. 4, 419-524.
Rushinek, A. and Rushinek, S. "Auditing Accounting Information Systems Around, Through and With the Computer," The Ohio CPA Journal, 1984, Vol. 43, No. 2, 73-78.
Rushinek, A. and Rushinek, S. "Data Capture, Preparation and Entry Controls in an Accounting Information System," Data Management, July 1984.
Rushinek, S. and Rushinek, A. "Threats to Computer Security," Business, October 1984, Vol. 34, No. 4, 45-48.
Rushinek, A. and Rushinek, S. "Auditing the Computerized Accounting Information System: Conceptual Foundation, Structure and Development," Modelling Simulation and Control, 1985, Vol. 4, No. 2, 1-19.
Rushinek, A. and Rushinek, S. "Generalized Audit Software: It's Usage in Accounting Information Systems," Cybernetica: International Association for Cybernetics, 1985, Vol. 28, No. 3, 247-258.
Rushinek, S. and Rushinek, A. "Backup and Recovery in Accounting Information Systems," Data Processing, April 1985, Vol. 27, No. 3, 42-46.
Rushinek, A. and Rushinek, S. "What Makes Users Happy," Communications of the ACM, July 1986, Vol. 29, No. 7, 594-598.
Rushinek, A. and Rushinek, S. "Physical Locking/Antitheft Devices (LD) Case Study: A Product Evaluation and Selection System," Cybernetics, 1988, Vol.31, No.4.
Rushinek, A. and Rushinek, S. "Evaluating Asset Safeguarding and Data Integrity in the EDP Audit", Managerial Auditing Journal, 1989, Vol. 4, No. 2, 3-6.
Rushinek, A. and Rushinek, S. "Data Encryption Features for Computer Hardware and Software Profitability: I/O ports, Expansion Slots, Algorithms, Cyphers and Security", Computers & Security, 1991, No. 10, 345-357.
Rushinek, A. and Rushinek, S. "Selecting Password/File Access Software", Corporate Controller, 1992, Vol. 4, No. 6, 33-38.
Rushinek, A. and Rushinek, S. "Data Encryption (DE) Case Study: Feature Selection System (FSS) for Microcomputer Users and Manufacturers", Economic Computation and Economic Cybernetics Studies and Research, 1993, Vol. 26, No. 1, 93-115.
Rushinek, A. and Rushinek, S. "Accounting Software Evaluation: Hardware, Audit Trails, Backup, Error Recovery and Security", Managerial Auditing Journal, 1995, Vol. 10, No. 9, 29-37.
Rushinek, A. and Rushinek, S. "Internet Fraud Auditing: A Simulated Health Care Industry Case Study", Journal of Forensic Accounting, 2000, Vol. 1, No. 1, 125-234.
About the Authors
The authors are professors at the University of Miami. They will provide additional appendices, tables, charts and program code listings upon written request. Avi Rushinek's (email@example.com) research interests include e-commerce security and controls, Web marketing ROI, e-learning, and Internet domain copyright, trademarks and patents ROI. Sara Rushinek's research interests include computer applications for decision-making, electronic stock trading; and Internet and e-commerce security of enterprise resource management.