I. Title

A. Name:  PennNet Computer Security Policy

B. Number:

C. Author(s): Dave Millar (ISC Information Security), Caroline Couture (College House Computing), Tony Olejnik (ISC Technical Support Services)

D. Status:

[ ] proposed [ ] under review [ ] approved [ ] rejected [X] obsolete

E. Date proposed: 2003-12-17

F. Date revised:

G. Date approved: 2004-05-24

H. Effective date: 2004-09-01


Policy Obsolete - March 2010

This policy is obsolete. It has been superceded by the following policy, which should be consulded instead:

Computer Security Policy, located at http://www.net.isc.upenn.edu/policy/approved/20100308-computersecurity.html

Links below this point have been disabled.


II. Authority and Responsibility

Information Systems and Computing is responsible for the operation of Penn's data networks (PennNet) as well as the establishment of information security policies, guidelines, and standards. It therefore has the authority and responsibility to specify security requirements for machines connected to PennNet.

III. Executive Summary

This policy describes the requirements and constraints for attaching and securing a computer to PennNet. It also provides "best practice" recommendations to guide systems administrators in further steps to protect PennNet-connected systems.

IV. Purpose

The purpose of this policy is to avoid expensive and disruptive security incidents by ensuring that all systems installed on PennNet are protected from the most common computer security threats.

V. Risk of Non-compliance

Computers that lack the most basic levels of security protection are vulnerable to attacks that can result in disclosure of data and widespread disruption to PennNet and PennNet-connected computers.

VI. Definitions

Critical Vulnerability    Penn Information Security will determine whether or not security vulnerabilities are considered Critical, basing the determination on the degree to which the vulnerability poses a significant risk of widespread disruption to PennNet, the Internet, and/or PennNet connected devices.

Strong Authentication - Authentication is strong when:

Strong Password - Passwords that are resistant to dictionary attacks, meeting the requirements set forth in http://www.upenn.edu/computing/email/pswd_guide.html

VII. Scope

This policy applies to all devices connected to PennNet, whether they are connected directly to PennNet, or indirectly through a firewall, router performing NAT, or similar device.

VIII. Statement of policy

  1. Devices connected to PennNet must have all relevant security patches applied, or the associated vulnerabilities must be otherwise effectively eliminated on a timely basis.  Patches for Critical Vulnerabilities must be applied to, or the associated vulnerabilities must be otherwise effectively eliminated from:
  1. When software vendors package fixes for Critical Vulnerabilities together with numerous other fixes to repair non-critical problems (such as Microsoft Service Packs), the risk of the combined fix introducing new problems is considerably higher. Consequently, systems administrators are not required to apply such "roll-up" software fixes in the timeframes outlined above, but rather are strongly encouraged to first consult with other technical staff at Penn and elsewhere to determine whether sufficient testing has been done. Penn Information Security will work with software vendors to try to ensure that fixes for critical vulnerabilities are distributed as discrete fixes, independent of large, roll-up software fixes.
  2. Remote access (i.e. any access other than from the console) to privileged accounts (e.g. root, Administrator) must use Strong Authentication.
  3. For operating systems for which Penn owns site-licensed anti-virus software, there must be a regular program of maintaining current virus signatures and real-time scanning, consistent with software vendor recommendations.

IX. Recommendations and Best Practices

The use of automated patch management tools and antivirus update software is strongly encouraged.  Generally, security patches for operating systems in wide use on campus (e.g. Windows, MacOS) have been well-tested by the vendor for desktop and workstation platforms.  It is a low risk to configure such machines to automatically download security patches from the operating system vendor. 

Untested security patches for servers pose a moderate risk, however.  Systems administrators on campus occasionally have problems with vendor security patches interfering with critical server functions.  For this reason, systems administrators are encouraged to test security patches, or check that others have done so before applying patches.

Additional best practices are listed in policy http://www.net.isc.upenn.edu/policy/approved/20000530-hostsecurity.html, the Critical PennNet Host Security Policy.

X. Compliance

A. Verification:    Information Security will periodically scan campus computers for security vulnerabilities.

B. Notification:  After taking reasonable care to remove false positive reports of vulnerabilities, information Security will report violations of this policy to the primary contact in ISC's Assignments database and to the senior Information Systems manager in the department or unit owning the machine.

C. Remedy:   Remedy may be an immediate removal of the system from the network, depending on the potential for widespread disruption and harm to PennNet and PennNet-connected devices.  The problem should be resolved as quickly as possible. Information Security will offer assistance to the LSP for the area in correcting security problems, after which the device may be re-connected to the network, and/or normal service restored.

D. Financial Implications:   The owner of the system shall bear the costs of ensuring compliance with this policy.

E. Responsibility: Responsibility for complying with this policy lies with the system administrator and system owner.

F. Time Frame:Non-compliant devices are subject to immediate removal from PennNet if, in the judgment of Information Security, they pose a significant risk of widespread disruption to PennNet and/or PennNet connected devices.

G. Enforcement: Please see the Policy on Computer Disconnection from PennNet at http://www.upenn.edu/computing/policy/disconnect.html.

Until 1/1/05, Information Security will only disconnect systems not complying with this policy from PennNet for non-compliance with this policy if an actual exploit is publicized or circulating that exploits a Critical Vulnerability. After January 1, 2005, any machine not in compliance with this policy may be subject to being disconnected.

H. Appeals:Please see the Appeals section of the Policy on Computer Disconnection From PennNet at http://www.upenn.edu/computing/policy/disconnect.html. Disputes shall be decided by the University Information Security Officer. Appeals are decided by the Vice President for Information Systems. Appeals granted for the inability to meet one compliance requirement do not exempt the system owner from meeting all other requirements.

For devices that are vulnerable, but cannot be patched, Information Security will recommend workarounds wherever possible.  Devices that cannot be patched due to technological obsolescence (e.g. operating systems for which the vendor no longer provides security patches) are exempt from this policy.  In the interim, owners of such machines must:

System owners and operators who believe that they are unable to comply with this policy for operational reasons may request in writing a waiver from Information Security, explaining their operational constraints, and describing alternative plans to ensure that systems are properly secured. Information Security will respond to all such requests in writing within ten business days.

Notwithstanding, ISC reserves the right immediately upon the availability of security patches to remove from PennNet any such vulnerable, unpatched or compromised machines if, in the judgment of Information Security, the risk of widespread disruption to PennNet and/or PennNet connected devices outweighs the benefit of remaining connected to PennNet.

XI. References