"Balancing Security and Education on the Same Net"

Christopher Cimino, MD
Albert Einstein College of Medicine
1300 Morris Park Avenue, Belfer 1303, Bronx, NY 10461
(718) 430-4211 cimino@aecom.yu.edu



PAPER

This presentation will look at the common problem of making educational software available on a network while maintaining a secure network. There will be an overview of the advantages of maintaining a secure network and examples of why educational software tends to conflict with that security. Several different methods that are used at AECOM will be examined with regard to how they work and for what situations each method is appropriate.

Computer networks offer several advantages for the distribution and management of educational software. These advantages are offset by the security risks that are inherent in a computer network. There are ways of creating a secure network. Security limitations poses specific problems for many educational programs. This paper describes two types of solutions to this conflict. One set of solutions are "work arounds" that can be used to get "off-the-shelf" software to work on a secure network. The other type of solution is that which is built into educational software as it is developed. Most of the solutions presented in this paper have been used in various situations at the Albert Einstein College of Medicine (AECOM).

Network Advantages

Among the many problems medical schools face, one of the most common is limitation of space. This can translate into computers distributed among numerous small rooms. As the number of computers grows, the task of installing each new program and each new update on each of these computers becomes monumental. Making software available at numerous affiliated hospitals becomes an additional problem. A computer network can address this problem.
A computer network is any method of sharing information between two or more computers. The computers follow a set of rules which govern how information is transferred. This set of rules is referred to as a protocol. Some protocols are machine independent and make it easy for certain functions (i.e., electronic mail or e-mail) to take place between the user's machine and any number of other machines. Examples of such protocols are Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), Gopher, and Telnet. These particular examples are all based on a common generic protocol and will be referred to as the TCP/IP protocols.

There is a special class of protocols that can be referred to as "file sharing" or "file server" protocols. These protocols are designed to make a particular computer look as if it has extra storage space even though that storage space is physically located in another computer. These protocols are very machine-dependent. The two most common for Macs and MS-DOS compatible computers respectively are Appleshare and Novell.

The Office of Computer Based Education (CBE) at AECOM supports a variety of equipment for shared use by faculty and students. CBE has 36 Macs in eight locations that share software from a single Apple AWS 95 computer. CBE also has 16 MS-DOS computers in three locations that share software from a single Everex Novell server. There are also three printers that provide service for these computers. The support for the hardware and software involved requires 1 1/2 full-time equivalents provided by medical students and employees whose primary task is network maintenance.

Network connections provide specific advantages for educational software maintenance. Technical problems are reported using e-mail. This allows the message to reach the first available staff member in the shortest possible time with little chance of the message being lost. The network allows some problems to be handled without travelling to the site of the problem. Statistics are automatically accumulated concerning which software the students find most useful. The greatest benefit of the network is that when a new piece of software needs to be installed, it is loaded on one machine (the file server) and it is available to all the other machines rather than requiring multiple installations. Some software (e.g., system software) still needs to be installed on each machine but the majority of the software is shared from a single server.

Security Risks

Connecting computers together creates security risks. The two biggest risks we face are corruption of information by computer viruses and theft of software purchased by AECOM. A virus is a computer program written specifically to make copies of itself without a user being aware that this is happening. Sometimes these programs are written with malicious intent and other times they cause problems as an unwanted side-effect. The advantage that allows a network to distribute one copy of a program to multiple computers can also spread a virus to multiple computers. Computers that are used by a large number of users, such as those in public computer rooms, are at high risk of being infected.

When an institution licenses software, in most cases it is responsible for preventing the users of that software from making illegal copies. While it is in the interest of the institution to make the program available on a large number of computers, users must be prevented from going to any one of these computers, copying a program onto a magnetic disk, and bringing the program home.

Users may maliciously or accidentally corrupt public resources. The most common form this takes is erasing necessary software on an individual machine and adding unnecessary software to an individual machine (usually game programs). This problem is not unique to networked computers. However, if the individual machine is a file server, then any problems that occur may be duplicated on all the machines relying on that file server.
There is an extremely small risk that a computer connected to the network could be used to steal information from another computer on the network. For example, students could theoretically use a public machine to look at and change grades on an administrative machine. People at a rival institution could look at research proposals being developed. In reality, if reasonable care is taken, this risk is negligible.

Forms of Protection

There are two ways to categorize network protection schemes: one is the mechanism used to implement the scheme and the other is the effect or limit they impose on the user. The mechanism can involve a "physical key", network level software, operating system software, or application software or some combination of these. For example, a physical key is a device attached to the computer that allows an application to identify a specific computer and determine what actions are allowed on that computer. TCP/IP and Novell both can identify specific computers (based on ethernet board id numbers or physical wiring connections) and to some extent provide network software that limits access based on these physical identifiers. Some applications come with a physical key that is plugged into a port on the computer. These types of keys are usually application specific. The majority of protection schemes involve a combination of network and operating system protocols that provide access in conjunction with passwords.
With no restrictions, users can view, read, write, copy, delete, or execute files (Figure 1a). Limits for each of these functions can often be set independently. In practice there are four combinations of limits that are most commonly used. For the purpose of this discussion, viewing means allowing the user to see that a file exists and reading means allowing the user to see the contents of a file.

The most effective protection is for a limit to be set on writing and reading program files but not on viewing or execution (execute-only files) (Figure 1b). This allows programs to be run but prevents theft, viruses, deletions, and unauthorized usage of storage space. Appleshare provides this type of protection. The next most effective protection is to only limit writing (read-only files) (Figure 1c). This does not protect against theft. A third form of protection only allows writing. This method is often referred to as a "drop-box" because multiple users (e.g., students) can copy their personal files (e.g., homework) to this area, none of these users can see other user's files, and all the files are visible to a user with greater access privileges to this area (e.g., a teacher) (Figure 1d). One of the weakest forms of protection is to only limit the user's view of files (hidden files) (Figure 1e). They may still be able to execute, read, or even write a file even though they can't see it. The flaw in this form of protection is that there is nothing to stop users from 'guessing' the existence of other files protected in this way.

Educational Software Conflicts

Most educational software is developed by a small group of people at a single institution. In those cases where the software is designed to make use of or allow for network security, it will be dramatically shaped by the configuration of the network at that institution. The chance of two institutions having the same network configuration is very small.

Programs often create conflicts because of "log files". A valuable piece of information when developing software is to know how people are using the program. A log file can contain information about what parts of the program are being used and how they are used. Educational programs often include an evaluation component. These evaluations would be useful to the user's teacher. A log file is a convenient place to store evaluations results. Another purpose for log files is to store information for students who will be using the same program several times. The log file will keep track of how much material they've covered and where they should start next time.

If the question of where to put the log file is raised by the developers, the most common answer seems to be in the same location as the program. If the program that writes a log file is in a read-only area of shared storage, the program will fail when it attempts to open or write to the log file. If the program is in a area where it can write, it will not be protected. A partial solution can be reached if the program allows the log file to be stored in a separate location from the program. If two users run the program at the same time and both copies of the program try to open the same log file, then problems will occur. Since most programs keep their log file open the entire time they are running, this is a very likely event if the log file is in a shared location.

Many educational programs are created in a "development shell". Examples include HyperCard, Director, and Toolbox. A development shell usually has a kernel program which provides graphic and arithmetic tools so developers can concentrate on the material they want to present instead of worrying about programming. When developers "program" the shell, they are really creating a data file which is written and read by the kernel program. Anytime permanent data is changed, the data file is altered. There are mechanisms for using temporary data for calculations but the methods for displaying temporary data are limited. If developers want the user to be able to enter dynamic data and have the program display that data in any significant way, they will have to alter the data file. This leads to problems if the network administrator wishes to protect the data file in a read-only area of storage. For example, a program might ask a student to enter their height, weight, and calorie intake and then display their basal metabolic rate, body mass index, and other information. Most shells can display the numeric result but not plot it on a graph if the data file is read-only. Even the numeric display will be limited unless developers resort to complicated programming techniques -- techniques the shell is supposed to obviate.

Two of the most frustrating conflicts in software are not unique to educational programs. They occur in programs at two extremes of design philosophy: copy-protected programs which are purposely written not to work on a network and network programs that make extensive use of network capabilities and require a specific network configuration. In the former case there is no practical (or legal) way to operate the program on a network. In the latter case, successful operation will depend on the teaching site having a network design philosophy that is similar to the program development site.

Off-the-Shelf Solutions

The simplest solution to get a program to run that conflicts with network security is to loosen the network security. In one case, we needed to run a program for a short period of time (1 week) in order to collect data from a group of students. During this week, a limited number of machines in the least active computer room were given unlimited access to one portion of the Appleshare server (Figure 2a). This configuration meant that anyone turning on those computers could write or delete files in that area. This is generally to be avoided since it would be possible for the file server to be infected with a virus which in turn could infect all the other computers connected to the file server. The risk of file deletion was limited to two files on the file server.

We implement a similar solution on a more routine basis on our Novell server. In addition to the standard operating software, all public machines connected to the Novell server also have a Saber menu system. This makes it easier for users to access software and also allows us to alter the network configuration prior to running a program, and change the configuration back again when the program is finished. We allow write-access to a portion of the file server and limit that access to the time when specific programs are running (Figure 2b). This greatly reduces the risk of virus infection and eliminates the risk of accidental deletion. There is still a risk of malicious deletion by someone with extensive computer experience but this has not been a problem. A similar method should be possible on Appleshare server using scripting languages such as AppleScript or UserLand Frontier but they do not yet include tools for dynamically changing network access.

Neither of the above solutions will work for programs that create log files. Here the solution is to temporarily copy the program from the file server to the local machine each time it is run (Figure 2c). The copying can be done automatically for our DOS machines using our Saber menu system. It is possible to implement this method on an Appleshare server using AppleScript, Frontier, or HyperCard XCMDs that allow program-controlled copying and deletion. We currently depend on Mac users to do the copying themselves. This methods works well except it means information in the log files is routinely lost. It is also not practical for large files.

Out of over 50 software titles used at AECOM, 4 programs have failed to conform to these solutions. One copy-protected program is made available by allowing students to sign out the disk at the reserve desk in the library. Another program we use was designed to use the network to log information about multiple users in a single database. Unfortunately, the configuration of this program was at odds with our network. We could have used the copy method described above to make this effectively a single user program but the size of the program prohibited this. Our solution was to find another computer to act as a dedicated machine for running this software. The third example is a Mac program that needed to be run on the local machine but because of its large size and the high frequency of use, it was impractical to require students to copy it each time they needed it. This application also required a hardware key which was an added complication. The solution was to configure the program so that only a small part was needed and this was then installed permanently on the local machines along with hardware keys. The last example is also a Mac program that requires specific files in the system folder. These latter two programs are the only ones besides system software that have files permanently installed on individual computers.

Development Solutions

Developers who wish to make their applications run in a network environment should try to follow these four rules: 1) make the application work in a read-only environment and 2) separate the portions of the application and its data files into those that require writing data and those that don't, 3) make the write portions as small as possible, and 4) allow the user to choose where the write portions are stored.

The last rule can be the most challenging. The read-only portion of the application must have some mechanism for locating the write portions. One method is for this information to be stored with the read-only portion when the application is installed by the network administrator. Another method is for this information to be stored in a computer system variable available to the program when it is run (DOS or Windows environment variables). There is usually no alternative on Macs but to write this type of information in a specific location (i.e., "Preferences Folder" inside the "System Folder").

One method that has been used at AECOM and other sites it to make each user responsible for locating written user data files (Figure 3a). This is particularly applicable if the purpose of this user data is for the user to review the results of previous sessions. We have developed a patient record program called CaseLog which is available on the network as well as off the network at several affiliated hospitals. Each student is given a magnetic disk which they can use with the program at any location. All written data is stored on the disk. Periodically, student data is collected at a single location to allow faculty to view the data. The only real risk would be accidental erasure of a single student's data.

Another method we are looking at for collecting evaluation and tracking data is to make use of the TCP/IP protocols (Figure 3b). This would be particularly useful for log files where the user has no need to review previous data. For example, a program could collect user information but instead of writing the information into a log file, it would be sent to an e-mail address or written to a shared database on a Unix system. This method avoids all the major security risks discussed above because the TCP/IP connection can limit transfers to text files. While similar database tools can be implemented on DOS and Mac servers, they usually require a dedicated machine for each database system.

Conclusion

Compared to supporting isolated machines, using a secure network to manage educational software greatly reduces man-power requirements. Most educational software can run on a secure network. The most common compromise for off-the-shelf software is that "log file" data is routinely lost. As network technology becomes more prevalent, we can expect educational software to make better use of the power of a network while maintaining network security.

Figure Captions
Click here for Picture

Figure 1: Types of Network Restrictions. Each arrow represents movement of data from one resource to another. Double-headed arrows represent movement in both directions. a) A network with No Restrictions allows viewing of file names, transfer of file contents to a computer for execution, and copying of the file from a server to a local hard disk or floppy disk. Files on the server can also be altered. b) Execute-Only access allows viewing of files and transfer of their contents to a computer for execution. Files can not be copied and no data flows to the file server. c) Read-Only access allows viewing, execution, and copying. No data flows to the file server. d) A Drop-Box allows users to write files to a protected area of the file server. They can't view files or their contents once they have been copied to this area. e) Hidden-Files can not be viewed but if the user knows of their existence, they can usually manipulate them in any way possible, including looking at their contents.

Click here for Picture

Figure 2: Compromises Between Network Security and Off-The-Shelf Software. Each arrow represents movement of data from one resource to another. Double-headed arrows represent movement in both directions. a) Restricted Location access is controlled through the use of door locks or other standard security measures. Once a user gains access to one of these locations, they have unrestricted access to the network. b) Restricted Time access allows complete network access at limited times. These times are under software control and limited to the shortest time possible that allows a program to run. The gray arrows represent the access that is time limited. c) Software Copying allows a temporary copy of a program to be transferred from a server to a local computer. When the user is done with the program, the local copy is erased. The connection to the server is Read-Only at all times.

Click here for Picture

Figure 3: Development Strategies For Network Security And Log Files. Each arrow represents movement of data from one resource to another. a) User Data Logs should be stored in a location that individual user
controls. Usually it is most convenient if each user has their own floppy disk containing personal data. b) Evaluation And Tracking Logs can use a file server protocol alternative that allows data to be constrained to text only and one way transmission of data. The network communications server can receive data from multiple clients and multiple types of programs and reroute it to a database or other users.