OF RECORD

Critical PennNet Host Security Policy

Effective: January 1, 2001

Authority and Responsibility

Information Systems and Computing's Information Security organization is responsible for establishing information security policies, guidelines and standards and therefore has the authority and responsibility to specify security requirements for critical hosts or any workstation that can potentially affect other users connected to PennNet.

Executive Summary

This policy describes the requirements and constraints for attaching and securing a critical 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 ensure that all systems installed on PennNet are maintained at appropriate levels of security while at the same time not impeding the ability of users and support staff to perform their work. The University does not maintain a firewall environment for all of PennNet, so each and every computer connected to PennNet is directly connected to the Internet and is accessible by anyone anywhere in the world for any purpose. Therefore, individual computers, servers or desktops, connected to PennNet must be secure.

Risk of Non-compliance

The use of automated scanners and break-in scripts makes it easy for someone to quickly scan entire networks for vulnerable systems. Systems which are not properly secured are likely to be discovered and broken into.

Break-ins in the past have resulted in Penn systems being:

  1. disconnected from PennNet and unavailable for days while they are re-secured,
  2. used to attack other sites,
  3. used for denial of service attacks which degrade valuable PennNet services such as Internet connectivity and network availability in one or more buildings.

Break-ins can also result in the destruction, alteration or disclosure of sensitive data.

Scope

This policy applies to all critical hosts on PennNet. Information Security shall, after consultation with the Network Policy Committee, publish interpretations defining what machines shall be considered critical.

Defining Critical PennNet Hosts

A critical host is one which, if compromised, could significantly harm the University. Schools and centers may optionally designate any hosts as critical if its compromise could significantly harm the local unit. Examples of significant harm could include legal liability, reputational damage, interruption of critical business functions, and disclosure of confidential information.

Examples of critical hosts include those which:

  • Contain sensitive or confidential data including, but not limited to, personally identifiable medical records, payroll information, student grades and transcripts, or social security numbers, or
  • Are used in planning, managing, or operating major academic, research, or administrative functions of the University, or
  • Have 100 Mb/s PennNet connections.

Specifically, the following service is defined as critical:

  • Any e-mail server supporting more than twenty-five users.

Statement of Policy

  1. One or more individuals supporting the system must be identified, and accurate contact information for the support person must be maintained in ISC's Assignments database.
  2. The support person is responsible for identifying critical systems to Information Security and for ensuring that the requirements of this policy are met.
  3. The support person must ensure that the security of the system is maintained by installing needed security patches on a timely basis.
  4. The support person must have attended Penn security training (if offered) for the relevant operating system within the past three years.
  5. Critical systems must be scanned for security vulnerabilities twice annually. Any serious vulnerabilities--those which allow a remote or local user to gain full privileges on the system--must be corrected.
  6. Remote access (i.e. any access other than from the console) to privileged accounts (e.g. root, Administrator) must use strong authentication such that cleartext, re-usable passwords are not sent over the network.
  7. All user access to critical hosts must be authenticated. All accounts must have a password. Users must not be allowed access from 'trusted hosts' without the use of a password.
  8. All user access to critical hosts must be authenticated with a form of strong authentication such that cleartext, re-usable passwords are not sent over the network by September 1, 2001 (assuming thorough supporting infrastructure in place by January 1, 2001).
  9. For operating systems that Penn owns site-licensed anti-virus software, there must be a regular program of maintaining current virus signatures and scanning for viruses.

Recommendations and Best Practices

Most computer systems as shipped by the vendor are very insecure. Steps must be taken by the system administrator at the time of installation and connection to ensure that certain known vulnerabilities are eliminated.

The following related practices are strongly recommended by Information Security.

  1. Remove un-needed services. Running un-needed services increases the risk of break-in.
  2. Limit access to needed services and log all successful and unsuccessful access.
  3. Locate critical hosts behind a firewall. A firewall can limit the risk of break-ins by controlling how services are made available outside of the firewall. A firewall is not a substitute for any of the requirements outlined above; a firewall only supplements good host security by adding a layer of security.
  4. Encrypt stored and transmitted sensitive data where possible. If security is compromised, the damage due to data disclosed or altered can be limited if sensitive data are encrypted.
  5. Use integrity checking tools. When run against a freshly-installed operating system, integrity checkers will produce a snapshot of the system for use later following a break-in to help identify tools left behind by intruders. Integrity checking tools can greatly reduce the amount of time needed to recover from a system break-in.
  6. Configure systems carefully to enhance security. Security standards and configuration guidelines are available at www.upenn.edu/computing/home/menu/security.html.
  7. Some desktop operating systems such as MacOS, Windows 95 and 98 are very difficult to adequately secure. On such operating systems, it is best to either encrypt especially sensitive data, or to not store such data permanently on the desktop, but rather on a more secure file server. Be sure to follow recommended guidelines for disabling and/or limiting file sharing: www.upenn.edu/computing/security-privacy/standards/FileSharing/.
  8. Avoid using the same password on critical hosts and less secure computers. Otherwise, a security compromise on a less secure computer could lead to a compromise on the critical host. For further details, see the Penn Information Security Awareness Brochure at www.upenn.edu/computing/security/pubs/brochure_2003.pdf.

A. Verification: Information Security will actively use security scanners annually to scan all critical systems.

B. Notification: 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 severity of the operational impact on PennNet. In some cases, systems that are compromised and connected at 100mb or higher speeds, may be backed down to 10mb service until the security problem is rectified. Thus 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 department or unit owning the critical hosts shall bear the costs of ensuring compliance with this policy. Adequate funding is needed to present ongoing operating system security training. The Strategic Site License Fund may be available to subsidize some of the software-related costs.

E. Responsibility: Responsibility for remedy lies with the system administrator and system owner.

F. Time Frame: Non-compliant devices must either be remedied within thirty days of notification of the support person, or must be removed from PennNet.

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

H. Appeals: Please see the Appeals section of the Policy on Computer Disconnection from PennNet at www.upenn.edu/computing/policy/disconnect.html. Disputes about whether or not systems are considered critical shall be decided by the University Information Security Officer. Appeals to such decisions are decided by the Vice Provost for Information Systems.

References

For encryption recommendations, or scanners currently in use, contact security@isc.upenn.edu.

Almanac, Vol. 47, No. 4, September 19, 2000

| FRONT PAGE | CONTENTS | JOB-OPS | CRIMESTATS | COUNCIL BYLAWS, 2000 | POLICIES OF RECORD: PennNet Host Security, Opereration of DHCP & BOOTP Servers, Affirmative Action, Sexual Harassment and Privacy in the Electronic Environment | TAT: "Facing Reality" (L. Hunter) | TALK ABOUT TEACHING ARCHIVE | BETWEEN ISSUES | SEPTEMBER at PENN |