SECURITY BEST PRACTICES
Introduction
Perimeter Best Practices
Server Best Practices
Personal Computer Best Practices
Introduction
This document presents the highest priority and most frequently
recommended security best practices for the WSU network perimeter,
servers, and personal computers. These practices address elements of
information security; policy, procedure, people, and technology, all of
which are necessary for deployment of a successful security process.
These best practices are a means, through a threat-management-based
approach, to ensuring the survivability and security of critical
information assets.
Information security is a responsibility of everyone in the university
community. Creating, enforcing, and regularly reviewing security best
practices and guidelines are the responsibilities of CaTS. Perimeter,
Server, and Personal Computer best practices will complement each other
to ensure comprehensive management of vulnerabilities and threats.
Perimeter Best Practices
Strategy
The overall position of perimeter security will be "deny all / allow only" for incoming traffic, i.e.; everything not explicitly permitted will be prohibited.
Security Architecture and Design
A layered security architecture approach, utilizing perimeter controls
and authentication in conjunction with controls on internal devices,
will be used to provide the most effective means of protection for
university resources.
The use of fault tolerant (redundant) devices and software are
recommended, whenever possible. This will result in configurations with
lower risk and higher reliability than those with single points of
failure at any level.
Services
Perimeter controls will restrict network services based on security
considerations and the role of the server, department, or zone.
All university servers will be registered with CaTS. Devices using
wireless or modem communications will not be permitted to provide server
functions.
Authorization
System administrator access will be as required. Only authorized system
administrators will have read/write accounts on perimeter devices; i.e.,
only system administrators will be allowed to schedule tasks, move or
delete logs, maintain software, or change configurations on perimeter
devices.
End user access to data within the perimeter will be permitted or denied
by applicable server-level controls.
System and Network Maintenance
Network topology documentation will be kept current and available to
authorized personnel. Access to this documentation will be restricted.
Proposed changes in perimeter device configuration, which is related the
security of the university, will be reviewed by the Security Team before
implementation.
Thorough change management practices, including but not limited to
documentation, impact assessment, advance scheduling, and communication
of outages, will be adhered to when changes are made to the perimeter
configuration.
Operating systems and system software on devices in the perimeter will
be kept current. Maintenance addressing security and functionality
upgrades will be applied in a timely manner and any planned outages will
be communicated, in advance, to the CaTS Help Desk.
Malicious Code
Perimeter devices will be protected from malicious code (viruses, worms,
Trojan horses, etc.) by the use of virus detection software, where
appropriate. As new vulnerabilities are identified, detection software
will be updated to address them as soon as possible.
The integrity of all installed software will be checked on a regular
basis. Unused, unsupported, or unauthorized software will be removed.
Audit/Logging
Appropriate system and networking logging, monitoring, filtering and
analysis tools will be used on perimeter devices to inspect and audit
overall network traffic and significant events.
Logging from perimeter devices will be written to a central server. Logs
will be reviewed regularly. Particular attention will be paid to
noteworthy events such as failed login attempts, unusual traffic, and
changes to configurations. Events that warrant action will be addressed
according to the university incident response process. Logs will be
retained in compliance with the university record retention policy.
Backup/Recovery
Backups of both software and data will be performed on a regular basis.
Backup copies will be stored on removable media or on remote hardware.
Restoration procedures will be tested periodically.
Data Security
Data encryption and virtual private network technologies will be used to
prevent unauthorized access to critical data in transit, particularly
that which is protected by law.
All data will be erased from the disks and memories of retired or
discarded systems prior to their disposal or transfer.
Authentication
Unique username/password combinations will be used to authenticate all
authorized users to perimeter devices. Passwords used to gain perimeter
access will adhere to all university password policies. Usernames and
passwords will be transmitted via secure protocol so that no clear-text
passwords are visible on any connection. System administrator usernames
and passwords will, at minimum, comply with all of the above.
Authentication will be validated by a trusted source.
Physical Security
Access to perimeter devices will be controlled with physical controls,
where required.
Server Best Practices
Definitions
The following definitions serve to clarify terms used throughout this document:
Server - the hardware platform upon which services run
Service - a computer program that awaits and fulfills requests from other programs
Client - a computer program that requests and awaits information from a service
Strategy
It is important to define the functionality of each server in order to properly outline its security stance. Server security should be defined by the provided services, the ports required by these services, and the intended audience. The audience can be defined as a department, the university as a whole, or even the entire Internet. Once the services, ports, and audience are understood, functionality and access can be limited according to those requirements.
Services
Many operating systems install a host of network services by default.
These network services should be pared down to only the services needed
for the server’s role as mentioned in the previous section. Once only
the needed services are running, access to the server should be limited
to just the ports used by said services.
A server that provides services to internal Wright State departments
should not be visible to the Internet as a whole.
Authorization
Server access should be limited according to the audience.
Administrative access to the operating system should be as limited as
possible. Remote administrative access should be limited to restricted
network addresses. Each system administrator should have their own
unique login. Administrative passwords should, at a minimum, adhere to
all university password policies.
Accounts of users who are not currently authorized university affiliates
should be disabled in a timely manner.
System Management
Operating system patches related to security issues should be applied in
a timely manner. Whenever possible, these patches should be applied in
the defined maintenance window. In some instances, a vulnerability with
a high likelihood of exploit may need immediate patching for protection.
In the case of these emergency patches, updates may be made outside of
the maintenance window.
Malicious Code
All servers should have virus detection installed. Whenever possible,
virus definitions should be automatically updated. Virus scanners should
provide both on-access and on-demand scanning. The use of additional
utilities is recommended to help system administrators identify if a
system has been compromised and what the intruder might have changed.
Audit/Logging
All administrative and end user logins should be logged on both success
and failure. All services (for example, httpd) should be logged. Logs
should include the IP address of the remote system connecting to each
server. Logs should be reviewed on a regular basis and should be
retained according to the record retention policy.
Backup/Recovery
All servers should be backed up on a daily basis so that the maximum
data loss, in the event of disaster, is limited to one day. Recovery
procedures will be tested on a regular basis.
Data Security
Protected data, such as student information or social security numbers,
is protected by legislation (FERPA, ECPA, etc.) and should be available
only to users with a valid need-to-know. To protect data from disclosure
in the event of unauthorized server access, further security measures
that obfuscate protected data are highly recommended.
Authentication
All usernames and passwords being used to authenticate administrative
and end users to servers should be sent using a secure channel so that
no plain-text passwords are visible on any connection. Passwords used to
gain server access should adhere to all university password policies.
Physical Security
Access to servers will be controlled with physical controls, where
necessary.
Personal Computer Best Practices
Definitions |
