Router & Switch Security Standard
This standard describes a required minimal security configuration for all routers and switches connecting to a production network or used in a production capacity at or on behalf of Loyola University Chicago.
All routers and switches connected to Loyola University Chicago production networks are affected. This document is broken in to two sections: Baseline routers and switches, and Perimeter routers and switches. All routers and switches will be configured to the baseline standard, perimeter devices have additional required controls.
- No local user accounts are configured on the router. Routers must use RADIUS for all user authentication.
- The enable password on the router must be kept in a secure encrypted form. The router must have the enable password set to the current production router password from the router's support organization.
- Disallow the following:
- IP directed broadcasts
- TCP small services
- UDP small services
- All web services running on router
- Switch interfaces set with “dynamic” port negotiation
- Use SNMPv3 and MD5 hashing.
- All routing updates shall be done using secure routing updates.
- Access control lists are to be added and modified as business needs arise.
- A primary and backup point of contact must be provided for each router and switch on the University’s networks.
- Each router must have the following statement posted in clear view:
- "This computer and network are provided for use by authorized members of the Loyola community. Use of this computer and network are subject to all applicable Loyola policies, including Information Technology Services policies, and any applicable Loyola Handbooks. Any use of this computer or network constitutes acknowledgment that the user is subject to all applicable policies. Any other use is prohibited.
- Users of any networked system, including this computer, should be aware that due to the nature of electronic communications, any information conveyed via a computer or a network may not be private. Sensitive communications should be encrypted or communicated via an alternative method."
- Telnet may never be used across any network to manage a router, unless there is a secure tunnel protecting the entire communication path. SSH is the preferred management protocol.
- Synchronize all clocks through the use of NTP.
- An audit and logging strategy, based on the ITS Log Management Standard,must be utilized.
- Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.)
- Disallow the following:
- Incoming packets at the router sourced with invalid addresses, such as RFC1918 addresses or the Loyola public IP space
- Block IP packets that have the same source and destination
- Outgoing packets at the router sourced with invalid addresses, such as RFC1918 addresses
- All source routing
- CDP on Internet connected interfaces
- IP directed-broadcast
- Implement black hole routing, or null routing
- Disable network auto-loading via TFTP
Exceptions to this policy will be handled in accordance with the ITS Security Policy.
This policy will be maintained in accordance with the ITS Security Policy.
In emergency cases, actions may be taken by the Incident Response Team in accordance with the procedures in the ITS Incident Response Handbook. These actions may include rendering systems inaccessible.
- Documents Referenced:
- ITS Security Policy
- ITS Incident Response Handbook
- ITS Log Management Standard
- CIS_Cisco_IOS _Benchmark_v2.2.pdf
- September 12, 2011: Initial Policy
- October 6, 2011: Revised
- October 29, 2012: Annual review for PCI Compliance
- July 17, 2013: Annual review for PCI Compliance
- July 5, 2014: Annual Review for PCI Compliance
- August 7, 2014: Added section to comply with PCI-DSS v3.0 Req. 2.1
- May 13, 2015: Annual Review for PCI Compliance