A. Name: Critical PennNet Host
B. Number: 20000530-hostsecurity
C. Author(s): D.Millar (Information Security), M.Wehrle (ISC
D. Status: [ ] proposed [ ] under review [ ] approved [ ] rejected [X] 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
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'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.
III. 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.
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
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.
VI. 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:
- disconnected from PennNet and unavailable for days while they
- used to attack other sites,
- 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
VIII. 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
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
3. The support person must ensure that the security of the system
is maintained by installing needed security patches on a timely
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
6. Remote access (i.e. any access other than from the console) to
privileged accounts (e.g. root, Administrator) must use Strong
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
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.
IX. 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
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
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
6. Configure systems carefully to enhance security. Security
standards and configuration guidelines are available at
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:
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
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.
Security will actively use security scanners annually to scan all
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
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
H. Appeals: Please see the Appeals section of the Policy
on Computer Disconnection From PennNet at
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
- Penn Operating System security standards at
For encryption recommendations, or
scanners currently in use, contact firstname.lastname@example.org.
ATTACHMENT 1 - Defining
Critical PennNet Hosts
A critical host is a Server
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.
Compliance with this policy on Desktops
and Workstations is strongly encouraged though not currently
mandatory. It is expected that Desktops and Workstations will
be covered by this policy when the University selects a supported
remote desktop management product.
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
- Are used in planning, managing, or operating major academic,
research, or administrative functions of the University.
ATTACHMENT 2 - Optional and Mandatory
|POP, IMAP, SMTP