Here are seven things you can do this week to improve the security of your network at no cost. (Granted, policy and configuration changes don't come overnight, but you can at least get the ball rolling.)
Change your local passwords
Centralized authentication models, using RADIUS or TACACS+ to authenticate individual accounts against a controlled database, are an obvious best practice. However, the need to maintain administrative access to infrastructure devices in the event that the authentication service or backend database becomes unavailable generally necessitates the inclusion of one or two local accounts on each device. A typical TACACS+ configuration for IOS might look like this:
aaa new-model ! aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local ! username admin privilege 15 secret 5 $1$A8q8$lAEkzwlEvjVw66vEvF3D7/ ! tacacs-server host 10.24.74.223 key 7 021711521F020A22455E011C171E1C0C0101
Login authentication and privilege escalation ("enable") authorization is first attempted via TACACS+, and falls back to local accounts in the event the TACACS+ server returns no response. (Note that local authentication is used only when the remote server(s) fail to respond, not when permission is denied.)
These lonely local accounts tend to be neglected, especially when not deployed in great numbers. Take an hour or two to cycle these passwords (and perhaps usernames) if they haven't been changed in the last several months, and vary the credentials among devices. A strict 1:1 credential pair-to-device ratio is ideal to minimize the impact of a compromised account, but isn't always practical. Alternatively, you might also consider developing a rudimentary formula to arrive at the username and/or password for each device (for example, a common character string plus a unique identifier). If you decide to use a single common password for a group of devices, ensure it's long and truly pseudo-random (not a leetspeak phrase like "LoLz@urP4ck3tz!").
Encrypt all stored passwords
How many passwords do you have sitting in a plain spreadsheet saved on a workstation or server? If the answer is more than zero, it's a good idea to look into a more secure solution. There are commercial solutions available for secure credentials storage, but for many organizations a simple free archiver like KeePass (free and cross-platform) will do just fine.
Of course, encrypting your credentials archive raises the question of who should have the "key to the key box," and where that master key should be stored. Most encryption tools support the use of multiple keys and key files to aid in developing a flexible but secure access strategy.
Audit your configuration templates
Configuration templates are generally only developed when they are first needed, and often lie dormant for years until being cleaned up or removed. Like any physical device, configurations too should be refreshed from time to time. The word "audit" isn't often well-received, but this can actually be a quite simple process. Taking a good look at what's in (or not in) your configuration templates is a great way to not only evaluate current practices but also to help familiarize novice engineers with the technologies your organization uses and how they are being employed.
I've suggested before printing out a base configuration file and working through it line by line, marking any line for which you cannot readily explain. This approach is complemented well by using an automated utility like nipper to catch common issues or omissions.
Perform an internal port scan
An internal port scan takes only minutes and can expose potentially vulnerable services running on infrastructure devices. Scan for at least all 1024 lower ports, preferably more; advanced utilities like nmap scan thousands of well-known ports by default. It's also important to scan from various locations both within and outside of various security perimeters to ensure access restrictions (such as VTY line access groups) are defined and applied properly.
Clean up your lab
Lab equipment is generally considered benign, but is often the lowest barrier to unauthorized entry on a network. Sensitive configuration parameters may be left on unattended gear after a round of testing, or lab gear may be connected to the production network without having been properly secured first. If you haven't already, implement a simple policy dictating both the requirements for connecting lab gear to any production equipment, and measures which must be taken when tearing down a lab.
Review and tune your logs
Now is a good time to review log files for a given period of time, perhaps the last month, and account for any unexplained or unusual events or messages. In particular, address any predictable recurrences ("Oh, it does that every Friday at four. Don't worry about it."). Investigate whether each recurrence is indicative of an issue, conveys necessary information, or should be pruned from future logs. Adjust logging profiles on devices appropriately.
Secure your image repository
There has been more and more research done on IOS-based rootkits in the last few years. While no high-profile incident has yet thrust the issue into the spotlight, don't volunteer your organization to be the first to do so. Verify all software images you retrieve from vendors; this is typically accomplished by comparing a calculated MD5 or SHA-1 hash of a binary image to that asserted by a trusted source. Cisco, for example, provides guidelines for IOS image verification, but this concept applies to all vendors and system images. Free hashing applications are available for all platforms.
Of course, few engineers fetch a new software image from a vendor every time the need arises; most maintain a small local archive of the specific images and other files used by their devices. Consider moving this archive to an encrypted volume (perhaps in conjunction with your credentials catalog).