Real Deployments

In large-scale data centers or enterprise, hardcoded passwords are a disaster! Imagine we have ten technical staff, all who have the root level password for all the devices. The moment that password is compromised or one staff member leaves, we have an insoluble security problem.

Different organizations deal with this in different ways. My own preference is to secure devices with a unique, complex, and unwieldy password which no one can reasonably use! However, before deployment, I configured the device to back-authenticate to an infrastructure. Very few systems authenticate directly to active directory, however there are intermediate protocols like RADIUS which we implement for this functionality. Cisco have their own proprietary version, TACACS+, which in my experience can be very flaky. Also look up Cisco ACS (which is now deprecated) and ISE.

I will have a printout of the unwieldy password kept in a data safe, no one ever uses it except in the event of a complete failure of the back-authentication system. In fact, we will flag its use as a security event. When I log into a network device, I use my normal domain username and password. I am given privileges by my domain group membership. And the moment I leave the organisation, my account is suspended, and I no longer have access. This approach is scalable, manageable, and can be automated.

There are many steps in hardening devices, in addition to securing the AAA. Before a real deployment, it is necessary to study the release notes, advisories, and recommendations for all network equipment. This is a non-trivial task and any desktop research you do has a very short shelf-life. As an example, do some background on Cisco’s Smart Install Protocol and the scale of the vulnerability it created. In a masterpiece of marketing obfuscation, Cisco identified this as an abuse of a feature, rather than as a vulnerability.

As with every other system component, you need a strategy for maintenance, review of advisories, patches and vulnerabilities, changes in best practices, etc. In the past, we wrote maintenance contracts for this to be done periodically. It may be more appropriate that this work is now done proactively and with an SLA appropriate to the scale and type of the business.