UTS Network Security Practices

Topic: UTS Network Security Practices
Audience: Students, Faculty and Staff
Creation Date: August 2007
Last Revision Date: May 2015
Author: University Technology Services - Network Communications Team

Scope:
This document describes Oakland University Internal Network Architecture Security Practices. These practices are executed in accordance with Oakland University policies #850 Network Policy, #880 Systems Administration Responsibilities & #890 Use of University Information Technology Resources. Where these practices relate to the user community a violation will result in the loss of network access and may include other sanctions as indicated in the policies.

Administration Practices:
Network configuration changes are defined as:

• A verified, approved, or common business process (e.g. changing port VLANs, activating or de-activating a network port);
• An architectural change documented, announced, and installed during a maintenance window; or
• A configuration management project item recorded in Change Management.

All changes are documented using the appropriate UTS documentation method (e.g. Footprints ticketing system, the Network Operations Manual, the UTS file share, or system log).

Documentation (e.g. Visio diagram/spreadsheet/inventory management/network management system / IP address management system, change request tickets) is kept for network and configuration data, including IP number schema, current configurations, MAC addresses, user identification, and device locations. This information is kept electronically and is backed up regularly. Collectively this documentation reflects all moves/adds/changes/deletions of equipment to the network.

Logs from any switching or routing gear are output to UTS managed logging servers for follow up on operational and security incidents. Logs are maintained in accordance with University Policy #880 Systems Administration Responsibilities.

A warranty, software/hardware support contract, or other equivalent arrangements are enforced over the life of all network equipment. The purpose of such arrangements are to address any functional issues with the device and provide resources for ongoing software updates. In the event that it becomes impossible to maintain one of these support models, the equipment will be prioritized for replacement.

Security patches are applied on a regular basis. Mechanisms for periodically updating and keeping current with security patches and software upgrades is in place.

The network infrastructure is periodically scanned and tested, scanning frequency is associated with equipment type, function and compliance requirements (e.g. quarterly, annually or after significant network configuration changes).

Physical access to areas containing network equipment is restricted to authorized personnel. Locations containing network equipment are secured (lock, card key, etc.) and/or labeled to prevent unauthorized access to the University network.

All software configurations for network equipment are backed up on a regular cycle (e.g. daily or weekly) with periodic off-site storage of a backup copy.

Physical or work copy of router or switch configurations are disposed of in accordance with OU Policies 360 Property Management and 860 Information Security.

Authenticated access paths to management functions are implemented. No default authentication credentials remain as shipped from the manufacturer; all default passwords are changed. Periodic password control procedures or other methods such as RADIUS or TACACS are implemented for password management.

Services not needed on network hardware are removed or restricted (e.g. web server, SNMP, FTP, etc.). Remaining services are set up with strong passwords. SNMP community strings are the equivalent of passwords and are changed from the vendor-provided defaults. Access control lists are used to limit access to services needed.

Access is restricted from unnecessary Internet and university network locations. Filters, access lists, or firewalls are used to limit access to the management interface and/or services available on the device. A recommended configuration is either to connect locally or through a bastion host using SSH.

All management interfaces and/or traffic access lists are documented to state what was intended by the filters.

Router and Switch configurations periodically reviewed for risk after consulting external best sources for security requirements. (e.g., SANS, CERT, equipment manufacturers).

Network systems administration is performed in compliance with Oakland University policies #830 Information Technology, #850 Network Policy, #880 Systems Administration Responsibilities & #890 Use of University Information Technology Resources.

More detailed configuration requirements and recommendations may be periodically published by UTS to help ensure security and operational continuity.

Design Practices

Network hardware is standardized in each campus location following cyclical upgrade plans.

Network hardware, including but not limited to switches, wireless access points, and hubs are not permitted to be attached to the network without prior written authorization from UTS. The network will be periodically scanned or monitored for rogue devices. Any unauthorized device will be removed from the network.

Devices meeting the criteria related to PCI-DSS can only be attached to the network using a physical wired connection (vs. wireless connection) and must be reviewed and approved by UTS for a compliant implementation with current PCI-DSS standards.

Local network servers or other devices offering DNS, DHCP, or other infrastructure services that conflict with those provided by UTS are not permitted.

Only one user computer or network device may be attached to a network jack/outlet without prior written authorization from UTS. For the purposes of connectivity UTS may consider a Voice over IP (VoIP) phone equivalent to a network jack/outlet and allow single device to be connected to the network through a VoIP phone.

Network registration or authentication systems are used to associate user IDs, hardware clients, MAC addresses, and IP addresses. Attempting to bypass or circumvent network authentication systems is prohibited