Administrative Computing Security Policy
PurposeThe purpose of this policy is to ensure that faculty and staff:
ScopeThis 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.
PolicyPenn 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 ResponsibilitiesUniversity 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 ResponsibilitiesData 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 ResponsibilitiesApplication 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 ResponsibilitiesSystems 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 ResponsibilitiesWithin 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.
ExceptionsExceptions to this policy must be approved in writing by the Vice President for Information Systems and Computing (VPISC).
EnforcementFacilities, 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 DateMay 1, 1997.
Confidentiality NoticeAs 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:
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:
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.
Information Systems and Computing
University of Pennsylvania
Comments & Questions