Loading
Click for Philadelphia, Pennsylvania Forecast
HOME ISSUE

CALENDAR

BETWEEN ISSUES ARCHIVE DEADLINES CONTACT US
 
 
Print This Issue
Front Page
Contents
Crimes
Directory
All About Teaching
Subscribe to E-Alamanc!
Staffbox
Guidelines
 

 

OF RECORD

Note: The Policy was updated on April 6, 2010

In recent years, the spread of computer viruses and worms has taken a costly toll.  It is estimated that the worldwide cost of cleaning up from the SQL Slammer worm in spring, 2003 totaled $1.25 billion. In August, 2003 the tab for the Blaster-SoBig-Welchia worms topped an estimated $2.5 billion in just one month.

Penn's experience with worms and viruses mirrors these larger trends. When viruses and worms spread on Penn computers, campus IT staff must spend considerable time rebuilding infected systems. Faculty and staff productivity suffer when computers that are actively spreading worms or viruses must be removed from PennNet to limit further damage.

To combat this growing problem, and to protect the integrity and availability of Penn computers and networks, ISC, together with appropriate School management and School IT leadership, have built a campus consensus on the basic steps that must be taken to secure every computer connected to PennNet. Working through Penn's Network Policy Committee and IT Roundtable in recent months, a policy was drafted and circulated broadly for comment, review and consultation. The final policy, "PennNet Computer Security Policy," is below,  Of  Record, announcing to the campus community three measures that must be taken to properly secure all   campus computers:

  • Security patches must be applied promptly. Experience shows that fully patched systems are rarely, if ever, compromised by computer worms.
  • Up-to-date anti-virus software must be installed and maintained.
  • Passwords protecting remote access to campus computers must be sufficiently complex to withstand automated password guessing attacks.

These requirements will be phased in gradually beginning this fall with full compliance required by January 1, 2005. Further details are provided in the policy.

Modern operating systems like Windows XP, 2000, MacOS X and MacOS 9 make it relatively easy to achieve compliance with this new policy. Older operating systems like Windows 98, for example, can sometimes be difficult to secure adequately. To assist campus IT staff in securing these older operating systems, ISC maintains a website with pointers to helpful information at www.upenn.edu/computing/security/oldos.html.

—David Millar, University Information Security Officer

PennNet Computer Security Policy

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.

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.

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.

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.

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:

  • re-usable passwords are not sent over the network as with so-called one-time password authentication systems.
  • passwords are not sent over the network at all as, for example, with the Kerberos authentication protocol.
  • in the case of re-usable password authentication systems, when only Strong Passwords (see below) are allowed and when the password transaction is encrypted using encryption algorithms generally accepted to be strong.

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

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.

Statement of Policy

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:

  • servers, immediately, but within, at most, ten days of availability,
  • desktop and workstation computers within two business days of availability, and
  • all other PennNet-connected devices within two business days of availability. This includes, but is not limited to, routers, printers, and special purpose devices connected to PennNet. Note that security patches to devices such as printers are very rare.

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.

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.

Remote access (i.e. any access other than from the console) to privileged accounts (e.g. root, Administrator) must use Strong Authentication.

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.

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 the Critical PennNet Host Security Policy, www.isc-net.upenn.edu/policy/approved/20000530-hostsecurity.html.

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 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 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:

  • take all reasonable steps identified by Information Security to minimize the risk of the vulnerability, and
  • promptly provide Information Security with a plan to bring the device into compliance.

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.

References

 

 


  Almanac, Vol. 51, No. 1, July 13, 2004

ISSUE HIGHLIGHTS:

Tuesday,
July 13, 2004
Volume 51 Number 1
www.upenn.edu/almanac

 

Back to Contents page
HOME ISSUE CALENDAR BETWEEN ISSUES ARCHIVE DEADLINES CONTACT US