SECURITY BEST PRACTICES
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 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.
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
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.
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.
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
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.
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.
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.
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 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.
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.
Access to perimeter devices will be controlled with physical controls, where required.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Access to servers will be controlled with physical controls, where necessary.