Privacy for OIT Campus Systems
The following policy applies to the general-access systems maintained
by the OIT campus divisions, i.e. OIT New Brunswick, OIT Newark and
OIT Camden. Specifically, it applies to eden, pegasus, clam, rci,
andromeda, and crab. This includes email and web hosting services associated
with these systems. There are separate policies for the Telecommunications Division, which cover privacy
of data related to the network and other functions of that Division.
Background
Privacy is an important part of trust: Users must be able to trust
that staff will not go snooping through their information just because
it happens to be on systems where they have privileges. The
Rutgers Acceptable
Use Policy and
Guidelines
establish an expectation of privacy on Rutgers systems, and
note that staff have an obligation to treat users' information as
confidential.
- files in user directories
- other information associated with a user, e.g. log file information
In general, staff should only look at user information in the following
situations. More details will be given below.
- When that information is public.
- When staff are handling a help request from a user, and they need to see files to answer the request.
- When staff are dealing with users who have left the University or are otherwise inaccessible.
- For investigations of cheating and other University policy violations.
- For investigations of security, abuse, and operational problems
The last three categories involve accessing data without permission of the user. Thus they are particularly sensitive. Generally such access is done only by system and service administrators. Any other staff doing such access must be explicitly authorized by the Director to do so.
Supervisors are expected to discuss privacy with all staff who are authorized to access data without permission of the user. (This includes system and service administrators and any other staff who have this authorization.) Supervisors are expected to keep track of the kinds of accesses being done by their staff, and make sure that they are appropriate.
Staff are expected to work closely with their supervisors, and to
consult them before doing any access that falls outside the types of
accesses that have been agreed on in the past. When urgent security
or performance problems do not permit advance consultation, staff
should notify their supervisor of what they did and why.
Dealing with other Organizations
Other sections of this document cover investigations carried out by OIT campus staff. Staff who are authorized to access user data may also be asked to give data to other units within the University, or to various groups outside the University.
In general University Police, Information Protection and Security, and Judicial Affairs officers are authorized to see user data in the course of an investigation. These groups have the necessary policies in place to protect the rights of users. (Staff within Information Protection and Security are themselves covered by this policy.) If there are questions about what groups are authorized access, contact the campus director, the Information Protection and Security Division, or (for student issues) the Office of Student Rights Compliance. University Police do not need court orders to see data within the University. (Indeed, as part of the University they can't get a court order. Rutgers can't ask a court to order it to give data to itself.)
Units outside the University require some sort of legal process,
such as a subpoena. OIT campus staff should generally not respond to
requests from outside the University themselves, even if presented
with legal documentation. Those requests should evaluated by University
Counsel, University Police, or the Office of Student Rights
Compliance. In some cases Information Protection and Security will
handle contacts with these units.
Prohibited Access
The following types of access are explicitly prohibited. They are
grounds for immediate termination.
- accessing files of a faculty member or RA from which the staff member is taking a course, without explicit authorization from them.
- accessing other files that violate University policies on academic dishonesty (e.g. other students' assignments, copies of exams). Staff might run into one of these accidentally in the course of normal work. However if a staff member finds that they are dealing with another student's assignment, an exam, etc., they should find someone else to help the user.
- accessing a user's mail file, without clear authorization from them, except during the course of an investigation as described below.
Other unauthorized accesses can also result in disciplinary action as appropriate.
Public Information
It is OK to look at information that anyone would normally have access to. This includes things such as web pages and files available for public FTP.
However not all files are properly protection. Some users may unintentionally have left every file visible to the public. That does not make the file public. Public means only files where there is some specific reason to believe that they are intended to be public.
However it is hard to write a precise policy covering files that a
user may have unintentionally left visible to everyone. This is a
case where staff need to exercize good judgement. Staff should not be
browsing at random through user files, even if that
information is not properly protected. If a staff member finds an unprotected
file, and there is any reason to believe that the owner would consider
information private, they should notify the owner and refrain
from looking at it. However it doesn't make sense to tell staff that they
can't use files that everyone else on the system is using.
Dealing with Requests from Users
Users often ask questions that require investigation. Where possible, staff should ask the user's permission before looking at files, even if they are dealing with a request from the user.
However when staff are dealing with email requests, asking
permission would slow things down, since it would be necessary to wait for the
user to respond to a request for permission. Thus support staff may look at the following items
in a user's directory without explicit permission, when the user is not immediately accessible, and they are relevant to responding to a request from that user:
- Configuration files, e.g. .login, .cshrc, .mailrc
- Files which are directly involved in the request. E.g. if a user asks for help with a compilation error in a program, it is permissible to look at the program. However staff would not be authorized to look at the data file which the program reads without permission. Data is more likely to contain confidential information than program source.
Take special precautions when dealing with mail files. Staff must always have at least implicit permission from the user before doing anything with a mail file that might cause them to see some of the user's messages, except in the course of an investigation as outlined below.
Where possible that permission should be explicit. That is, even if a user says "my mail file is broken, please fix it", staff should if possible say "in the process of doing this, I might accidentally see some of your mail. Is that OK?"
However in order to expedite service, managers of support areas
may authorize their staff to deal with requests of the form "please
fix my mail file" without asking further permission, when the user is
not immediately available. Staff who have this authorization
are expected to follow these guidelines:
- Use procedures that minimize the amount of mail they see.
- Avoid looking at the bodies of messages.
- Do not tell anyone else anything they may discover from seeing the messages.
Dealing with users who have left the University
When a user is leaving, they are responsible for turning over
any files to others who might need them. Unfortunately they
don't always do this. Here are examples of some situations that
have occurred in the past:
- work typed for faculty, but residing in the directory of a typist who is on vacation or no longer with the University
- joint proposals or papers prepared by RA's working with a research project, where the RA has left the University or is on vacation
These issues should be dealt with only by staff who are specifically authorized by their Directors. System and service administrators would normally be authorized to deal with such issues involving their systems.
Normally staff will only make available specific files. If necessary, a system administrator may review the user's files with an authorized requester. However it would not be appropriate to permit the requester to login as the user or to access the entire directory. Email is particularly sensitive.
Before giving anyone else access to a file, the request must be
verified as legitimate. There are several ways to do this:
- Contact the former user.
- Get authorization from someone who was supervising the former user (the sponsor, in the case of a guest).
- Get authorization from the department chair or equivalent.
If staff don't have permission directly from the user, they should normally make at least some attempt to verify the reasonableness of the request:
Normally the person requesting the access can describe the paper, and it's easy to verify by looking at the title page or abstract that it's really as said. E.g. a file in a secretary's area has a title page whose author is listed as the person requesting access.
The Director or other authorized staff may make the decision when the request appears to be "routine", e.g. access to a document on which staff were working with someone else. However if there are any signs that the matter is controversial, e.g. that the situation involves a termination or tenure process, University Counsel should be contacted.
If there is any question, refer the decision to the Director or
Associate Director.
Cheating and other University policy violations
In cheating cases, OIT's primary responsibility is to preserve evidence, and to help University hearing officers in evaluating it.
To the extent possible, cheating cases should be handled by an Associate Director or Director. However for certain systems they may authorize a staff member to handle it.
In some cases, requests may be time critical. That is, there may be reason to suspect that the accused will attempt to delete evidence. If a faculty member contacts someone other than the system administrator or other authorized person, that person should try to contact the system administrator. However if this is not practical, operations and other staff may act to preserve evidence, as long as they do not look at the files.
When preserving evidence, there are two aspects to think of:
For current data, the obvious approach is to make a copy of the user's directory (or any other area that the faculty member believes is relevant), and put it in an area to which the user does not have access (preferably on a staff system). Staff should make certain that they protect the copy so that users can't see it. Use a tool that does not change any access date.
Often investigations involve data that is no longer on the system. If this appears possible, the person handling the situation should contact operations staff and request that the relevant backup tapes not be overwritten until the system administrator has had a chance to evaluate the situation.
Evidence must only be given to people with a right to see it.
Within the University this includes hearing officers operating under
the authorization of University policies, and University Police.
Outside the University, access will normally require a court order of
some kind. Authorization for outside access should be reviewed by
University Counsel or the Student Compliance Office.
Security, Abuse, and Operational Problems
System and service administrators and other authorized staff are sometimes involved in investigating problems on their systems. These include security incidents, allegations of abuse, and operational or performance problems.
The kinds of reasons investigations might involve looking at users' files are:
- hackers often leave around programs that are obviously "hacking tools" (e.g. password crackers)
- there are often log files that will show evidence of what has been done, and what other systems have been attacked
- requests are coming in with unexpected frequency. Looking at the requests may show that some process is generating requests repeatedly.
Haste is sometimes necessary, either to preserve the evidence, or to help people at other sites doing time-sensitive investigations. Unfortunately, in these kinds of cases it's hard to limit what files a system administrator will look at, since sometimes files are intentionally given misleading names.
However there are some basic principles that such staff
must follow when accessing user information without permission:
- These issues should be dealt with only by staff who are specifically authorized by their Directors. System and service administrators would normally be authorized to deal with such issues involving their systems and services.
- Accesses should be done only when there is a specific reason to do so. The degree to which user privacy is compromised should be related to the seriousness of the problem. In particular, staff should look at mail files only when there are immediate and serious security or performance problems, and they have a reasonable belief that looking at the mail file is needed to resolve the problem.
- Accesses should be limited to files or messages for which there is reasonable cause to think that they are relevant to the investigation.
Note to users reading this policy
This policy attempts to provide guidance for staff in a variety of situations, some of which are hypothetical. It could give the impression that staff are routinely accessing user data. OIT surveyed all campus staff during the Spring of 2003, and no one was able to recall a circumstance where staff had looked at a user's mail file without their permission. Other types of access have occurred, but not frequently.
For questions or comments about this site, contact webmaster@nbcs.rutgers.edu.
© 2007 Rutgers, The State University of New Jersey. All rights reserved.
Last Updated: 5/21/2007