Penn Computing
Computing Menu Computing A-Z
Computing Home Information Systems & Computing Penn

Administrative Computing Security Policy


The purpose of this policy is to ensure that faculty and staff:
  • Experience uninterrupted access to administrative data and systems;
  • Trust the integrity of administrative data and systems, and;
  • Trust that sensitive information is treated with care.


This policy pertains to all University administrative systems. Administrative systems are defined as any University computer systems used in planning, managing, or operating a major administrative function of the University, excluding those systems directly supporting instruction or research. This policy also pertains to any associated administrative data that resides on end-users' local desktop computers, and/or departmental servers.


Penn administrative systems are for use by authorized Penn faculty and staff, and by selected faculty and staff of the University of Pennsylvania Medical Center. Limited access is also granted, in some cases, to students to view and maintain limited personal information. When students are to be given access to administrative systems for purposes other than viewing/updating limited personal information, and when part-time, temporary or contract workers, and University of Pennsylvania vendors are to be given access to administrative systems, written authorization is required (renewed annually) from Penn faculty or staff. The faculty or staff member approving access is responsible for all use of the access granted. All use of administrative systems and data must be consistent with the requirements specified by the individual ultimately responsible for the data, the Data Steward.

User Responsibilities

University systems and data are for use only by the individual granted access. Access must not be shared, since shared use often leads to abuse. User accounts must be protected with passwords. Since short passwords or dictionary words are easy to guess using automated password crackers, any re-usable passwords must be at least seven characters long; must not be simple, dictionary words; must contain a mix of alphabetic, numeric and special characters (e.g. "*&^%$%$#"); and must change at least every sixty days. Login scripts must not include scripted passwords.

Users must be sure that critical data on their personal computers are backed up and stored remotely.

Computer viruses can waste time and can destroy data. The user must be sure that the most current anti-virus software is running on his or her computer.

The user must ensure that any restricted information stored on his/her personal computer is safeguarded, through either physical security (locked offices, or keyboards), access control software, or encryption.

When a computer is left signed on, it is easy for someone to gain unauthorized access. Users must either sign off of accounts before they leave their computer, or restrict access by some other means (locked office/keyboard, desktop access control, or a password-protected screen saver). Note, however, that many access control packages and screen savers can be easily bypassed.

Users must abide by the terms of all software licenses. (See Penn's policy on Unauthorized Copying or Use of Licensed Computer Software).

Data Steward Responsibilities

Data Stewards are responsible for defining the security and integrity requirements of their respective categories of data. All uses of data must be approved by the respective Data Steward.

Application Steward Responsibilities

Application Stewards, those sponsors of new or existing computer applications, are responsible for ensuring that their computing applications conform to the Data Steward's requirements for all categories of data used by the application.

System Administrator Responsibilities

Systems administrators are responsible for enforcing restrictions specified by Data Stewards and Application Stewards.

Since short passwords or dictionary words are easy to guess using automated password crackers, any reusable passwords must be at least seven characters long; must not be simple, dictionary words; must contain a mix of alphabetic, numeric and special characters (e.g. "*&^%$%$#"); and must change at least every sixty days. To prevent password sniffing, systems administrators are encouraged to implement one-time or encrypted password authentication.

Dormant (unused) accounts make attractive targets to intruders, since no one will likely notice the activity. Accounts must be regularly reviewed for inactivity, and any dormant accounts suspended.

Temporary access privileges granted to students, contractors/temps/ part-timers and vendors must be for a period no longer than one year or until the end of the contract term, whichever is sooner, and may only be created and renewed with written authorization from a Penn faculty or staff member.

Special care should be taken with privileged accounts (including, e.g., but not limited to "root" for UNIX and "supervisor" for Netware), commensurate with the privileges afforded the account. Systems administrators must never allow a reusable password for the most privileged accounts to travel over the network un-encrypted. Passwords for privileged accounts should be given only to people with a need for privileged access.

Vendor- or author-provided security patches must be evaluated for compatibility, and installed as soon as practical.

Wherever feasible, a login banner, stating that the system is for authorized use only, should be displayed for anyone attempting to connect to the system.

Where feasible, all operating system, version/release numbers, and vendor information provided in login/sign-on banners should be limited or disabled. Providing this information makes attacks easier by allowing intruders to pinpoint hosts with known security vulnerabilities.

Wherever feasible, login restrictions (by time of day, by system address, etc.) should be implemented.

Logs of user activity must be retained for a period of at least six months. Knowledge that logs are kept acts as a deterrent to abuse. Logs are also essential in investigating incidents after the fact. Logs should include (where feasible) the time and date of activities, the user ID, commands (and command arguments) executed, ID of either the local terminal or remote computer initiating the connection, associated system job or process number, and error conditions (failed/rejected attempts, failures in consistency checks, etc.)

Systems administrators are responsible for taking proactive steps to assure the security of the server. Examples include regularly checking for weak user passwords and checking the system for common security vulnerabilities.

Systems administrators must implement backup procedures consistent with the requirements of the Data Steward. (See Data Stewardship policy)

Systems administrators are responsible for compliance with each relevant campus operating-system-specific security standard.

Management Responsibilities

Within reason, management (School/Unit/Department management) must make available the resources that users and systems administrators need to carry out the responsibilities above.

Management must retain copies of the original software licenses for commercial software used in their department. For site-licensed software, management must retain a copy of the site license. Management must ensure compliance with the terms of all commercial software licenses.

Management must ensure the physical security of servers. It is strongly recommended that departmental and central servers be kept in a locked area. Servers must be protected from power surges, power failures, water damage, overheating, fire, and other physical threats.

Management must approve all modems installed on Penn administrative computers in their department. Unauthorized modem connections pose a security risk because if left uncontrolled, widespread, unauthenticated entry to PennNet becomes possible. Sensitive areas should consider the use of dial-back or caller-id modems. All modem access must be authenticated.

Management of departments/units providing University administrative information systems must ensure that all users have viewed a confidentiality statement at the time that access is granted, and annually thereafter (statement attached).

Management/supervisors must ensure that access to administrative systems is revoked or modified as appropriate upon employee resignation, termination, job changes, or when grants or contracts expire.


Exceptions to this policy must be approved in writing by the Vice President for Information Systems and Computing (VPISC).


Facilities, departments/units, or individuals in violation of this policy may be denied access at the discretion of the VPISC.

Violations of this policy will be handled under the University Policy on Adherence to University Policy for violations by employees and by the Office of Student Conduct or the respective School for violations by students.

Management or supervisors may be required to resolve violations by members of their staff.

Effective Date

May 1, 1997.

Confidentiality Notice

As an individual whose position requires interaction with any or all of the University's administrative information systems, you may be provided with direct access to confidential and valuable data and/or use of data/voice systems. In the interest of maintaining the integrity of these Systems and of ensuring the security and proper use of University resources, you must:

  • Maintain the confidentiality of your password for all systems to which you have access.
  • Maintain in strictest confidence the data to which you have access. Any confidential information must not be shared in any manner with others who are unauthorized to view such data.
  • Use your access to the University's systems for the sole purpose of conducting official business of the University. Understand that the use of these systems and their data for personal purposes is prohibited.
  • Understand that any abuse of access to the University's systems and their data, any illegal use or copying of software, any misuse of the University's equipment may result in disciplinary action, loss of access to the University's systems, and possible sanctions consistent with the University Policy on Adherence to University Policy.

The Administrative Computing Security Policy was originally forwarded to Almanac by the University Information Security Officer for publication "of record" (Almanac, January 21, 1997) and "for comment" (Almanac, June 18, 1996).

Appendix I - Oracle Accounts for Developers

(Effective November 20, 1997)

This addresses the use of production and test relational database management system (RDBMS, e.g. Oracle) accounts by developers working with University administrative data.

Developers need the following capabilities:

  1. Ability to create, alter and drop database objects (tables, indices, views, procedures and functions) in the test environment.
  2. Ability to request that database objects be moved into production.
  3. Ability to run "explain plan" against production databases to troubleshoot performance problems.
  4. Ability to query production data to trouble shoot users' data problems.
  5. On an emergency basis, ability to make source changes in the middle of the night without necessarily contacting Database Administration.
  6. Ability to run occasional "zap" programs to fix production data. In addition, production RDBMS accounts are needed for the following purposes:
  7. To run extracts from the data warehouse.
  8. To run views against supporting database links that are called by end-users' queries.

General Requirements

Developers generally must not have the abilities to independently move databases into production, or to alter production data because those capabilities violate the principle of segregation of duties. Except for emergency situations (see below) any changes to the production environment should require involvement of both the developer and Database Administration.

Developers must not share ID's because it violates the principle of accountability. As a preventative measure, and also to aid in investigation after the fact, it is important that individuals be accountable for their actions. If a shared account is misused, it is impossible to know who is responsible.

It may be necessary at times for developers to have direct access to production databases and source, but procedures should be established to ensure that segregation of duties and accountability are still achieved.

NOTE: Some Schools and Departments have not established formal database administration functions. In such cases, the developer's manager may serve in the same role to ensure separation of duties.

Specific Requirements

  1. Create unique (rather than shared) developer IDs for the test environment with the capability to perform developer functions (create, alter, drop tables, indices, views and synonyms; grant/revoke select access) in the test environment.

  2. Except during emergencies, only allow Database Administration to operate on the production environment or to move objects between test and development.

  3. Develop procedures for production access by developers during off-hour support and for applying "zaps." Should include provisions for manual logging of all production access and notification to Database Administration of all activity.

  4. Where developers need access to production data, provide individual accounts:

    1. Accounts have only those permissions the developer needs (e.g. read-only, explain plan, etc.).
    2. Accounts are for individual, not shared use.
    3. Accountholders read and sign the Confidentiality statement in Administrative Computing Policy.
    4. If accountholder no longer needs access/privileges (e.g. change of responsibilities), they are revoked.
    5. Accounts are canceled immediately when employee leaves the job.

  5. Establish generic accounts for production batch extracts and for views used with database links as follows:

    1. Accounts should provide the least privileges required by the application.
    2. Accounts are good for one year, must be renewed annually. [If we choose a date for annual expiration (e.g., July 1), that will simplify administration.]
    3. Passwords changed annually.
    4. Reasonable precautions are taken to protect accounts:
      • Time of day restrictions, where feasible
      • Passwords not stored in public areas
      • Passwords encrypted, where feasible
    5. Accounts are used only for the production processes identified - not for ad hoc troubleshooting by development staff.
    6. I.S. manager requests/renews the account in writing. Manager takes responsibility for above items, for use of the account, and for enforcing any safeguards specified by the Data Steward (e.g. logging user-level access to sensitive data.)

Information Systems and Computing
University of Pennsylvania
Comments & Questions

University of Pennsylvania Penn Computing University of Pennsylvania Information Systems & Computing (ISC)
Information Systems and Computing, University of Pennsylvania