|
Capital
College --- Server Security guideline: CL–SSP–01 |
|
1.0
Purpose
The purpose of this guideline is to establish standards for the base
configuration of internal server equipment that is owned and/or operated by the
Capital College, including servers operated at the departmental level.
Effective implementation of this guideline will minimize unauthorized access to
Capital College proprietary information and technology.
2.0
Scope
AD20 is the overall University policy that applies and all users are subject to
AD20. Nothing in these guidelines supercedes
user responsibilities under AD20. This guideline applies to server
equipment owned and/or operated by all agents of the Capital College, and to
servers registered under the Capital College-owned internal network
domain. This guideline is specifically for equipment on the internal
Capital College network including administrative systems as well as student and
research labs.
3.0
Ownership and Responsibilities
All internal servers deployed at the Capital College must be owned by an
academic, research or any other operational group that is responsible for
system administration. Approved server configuration guides must be established
and maintained by each group, based on business needs and approved by the
Dean’s Office. Groups should monitor configuration compliance and implement a
guideline tailored to their environment. Each operational group must establish
a process for changing the configuration guides, which includes review and
approval by the College. All internal policies must be reviewed and approved by
the Dean’s Office or the Dean’s designated representative.
4.0
General
Configuration Guidelines
· Operating
System configurations should be in accordance with approved College guidelines
to ensure at least a minimal level of security against unauthorized access.
· Services
and applications that will not be used must be disabled, where practical.
· Access
to services should be logged and protected through access-control methods such
as TCP Wrappers or other security mechanisms. There needs to be adequate
logging to identify the IP and user id responsible in the event of an incident,
regardless of the presence of other security mechanisms.
· The most
recent security patches must be installed on the system within 48 hours of release.
The only exception being when immediate application would
interfere with business requirements.
· Trust
relationships between systems are a security risk; their use should be avoided.
Do not use a trust relationship when some other method of communication will
do.
· Always
use standard security principles of least required access to perform a
function.
· Do not
use a privileged account when a non-privileged account will do.
· If a
methodology for secure channel connection is available and technically
feasible, privileged access must be performed over secure channels, (e.g.,
encrypted network connections using SSH or IPSec).
· Servers
should be physically located in an access-controlled environment. IIT
provides such an environment.
· Servers
are specifically prohibited from operating in areas accessible to persons other
than the intended system administrators.
5.0
Directory Permissions
· As per
the internal audit of 3 June, 2005, IIT is required to restrict Directory and
File permissions the Administrative server.[i]
· The
'Everyone' group will have Execute permission removed from all directories,
files and shares. This was submitted on work order 10096 on 24 May, 2005 and
was completed by 24 June, 2005.
· The
'Everyone' group will have Full Control permissions removed.
· More
restrictive permissions are currently in place for the 'Everyone' group.
6.0
Monitoring
· All
security-related events on critical or sensitive systems must be logged and
audit trails saved as follows:
·
All
security related logs will be kept online for a minimum of 3 weeks.
·
Archived logs will be retained for a minimum
of one year.
· Security-related
events will be reported immediately to SOS at security@psu.edu. The SOS office wants
to know immediately when a security event occurs. There will be no
"filtering" of this information at the College level. It is ok
to simultaneously report a security incident at the College level and in that
case it can be reported to any of the ITS security contacts, or Safety and
Police Services but SOS must know immediately and at the same time it is
reported locally. SOS has access to border router data that
can provide a much clearer picture of what's
going on, but only if they are notified quickly.
Corrective measures
will be prescribed as needed. Security-related events include, but are not limited to:
·
Dictionary
attacks
·
Unauthorized
network scanning
·
Denial
of service attacks
·
Evidence
of unauthorized access to privileged accounts
·
Anomalous
occurrences that are not related to specific applications on the host.
7.0
Compliance
8.0
Enforcement
Any employee found to have violated this guideline may be subject to
disciplinary action by their Administrative unit, the College, or the
University. Systems involved with severe security breaches may be confiscated
for forensic analysis. Individuals may be subject to all the sanctions
spelled out in AD20, to include expulsion for students or termination for employees
and that civil or criminal action
may be pursued.
9.0
Definitions
SOS - Security
Operations and Services
10.0
Revision History
3/6/2004
Last
Updated: 21 January 2005, ryb
OFFICIAL APPROVAL:
1-17-08 MSK5