A. Name: Critical PennNet Host Security Policy

B. Number: 20000530-hostsecurity

C. Author(s): D.Millar (Information Security), M.Wehrle (ISC Networking)

D. Status: [ ] proposed [ ] under review [X] approved [ ] rejected [ ] obsolete

E. Date proposed: 1999-09-27

F. Date approved: 2000-05-30

G. Date revised: 2002-04-08, 2005-02-14

H. Current revision effective date: 2002-05-01, 2005-03-15

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 computer that can potentially affect other users connected to PennNet.

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.

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.

Desktop - A computer primarily used to provide direct access (via a locally attached keyboard, mouse and monitor) to applications such as web browsers, email clients, office productivity and data analysis tools for use usually by one individual.

Server - A computer used primarily to provide network-based services (e.g. web, file, or email), for use typically by multiple users.

Strong Authentication - Authentication is strong when re-usable passwords are not sent over the network in cleartext or weakly encrypted.

Workstation -  See Desktop.

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.

This policy applies to all critical hosts on PennNet, regardless of whether they are connected via a firewall. Information Security shall, after consultation with the Network Policy Committee, publish interpretations defining what machines shall be considered critical. See Attachment I for current definitions. When questions arise about whether or not a machine is considered critical Information Security will make the determination.

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.  Instructions for registering Critical Hosts are at http://www.upenn.edu/computing/security/crithost/register.html
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) or equivalent  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.
7. All user access to critical hosts must be authenticated. Minimally, all accounts must have a password. Users must not be allowed access from 'trusted hosts' without the use of Strong Authentication.
8.Authentication must either be provided as an option or must be mandatory on critical hosts by the dates in Attachment 2.   In consultation with Network Policy Committee and subject to review by IT Roundtable, Information Security shall update this list every six months as Strong Authentication options for network services become readily available and within a reasonable period after Penn supported client software for the respective network service becomes available.  
9. 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 for viruses native to that operating system.
10. All critical hosts providing email services must have a documented plan to limit the spread of computer viruses through email.

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 http://www.upenn.edu/computing/security/standards/
7.  Some Desktop operating systems such as MacOS versions 9 and lower, 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: http://www.upenn.edu/computing/security/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 http://www.upenn.edu/computing/security/brochure_2002.html
9. Avoid storing cleartext passwords and private keys wherever possible. Some applications permit the user to script their ID and password. Web browsers and other clients sometimes intercept logins and offer to auto-complete the login by filling in the username and password based on what was typed previously. Such features should be avoided since they expose passwords to theft.  Similarly, when used with public key authentication, secure shell permits users to store private keys without encrypting passphrases.  This should be avoided whenever possible. When a system administrator cannot be present to enter a passphrase for scripted batch processes, special care should be taken to ensure that access to stored private keys is limited to the users and process(es) that need access.

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 http://www.upenn.edu/computing/policy/disconnect.html.

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 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. Appeals granted for the inability to meet one compliance requirement do not exempt the system owner from meeting all other requirements.
 

• Policy on Computer Disconnection from PennNet at http://www.upenn.edu/computing/policy/disconnect.html
• Penn Operating System security standards at http://www.upenn.edu/computing/security/

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

---

---