There are quite a few things that you don’t realize how great they are until you don’t have them anymore. For me, one of those things was standard guidelines for device configurations. At my last job, documented standards were extremely important – we had them for everything. While some devices might ultimately be configured in a slightly different manner to accommodate their specific purpose, the underlying basics were all configured exactly the same. Fast forward to where I am at now, and when I started there was no such thing. One device might be configured for management access only over the out of band interface, while a few others might allow management traffic over every interface. Some devices had SNMP configured, some didn’t, and yet others had default credentials still enabled.
The problem here stemmed from the fact that there were no documented standards in place. An engineer was given a device to configure, and it was configured depending on who did it and what they felt needed configuring. In a few cases, this actually led to unnecessary security risks being introduced into the environment because something was left enabled. In one instance, this included open root SSH logins via the Internet to a production firewall. Scary, huh?
So how do we go about changing this? Here is a quick little guide I threw together on my method for tackling the situation:
1. Define a standard – Begin creating a baseline document, whether it be a spreadsheet, word doc, or a wiki page. Start small and choose a single system, like your external firewalls for example.
2. Research best practices – Check out the vendor’s website to see what they recommend. There are also some amazing free resources out there like the Center for Internet Security’s configuration benchmarks, Do your research – there is plenty available to help you.
3. Figure out what’s best for your network – Not all of the best practices or security hardening guides will be a perfect fit for your environment. So it will take a little manual review to see what actually fits. For example, many of these guides recommend disabling local authentication in exchange for something centralized like TACACS+ or RADIUS. But if you don’t have that available, then you’re going to stick with local authentication. This can still be a great time to find room for future improvement projects though.
4. Test! – If you have a development or test environment available, then run a device or two through your checklist and make sure there are no big issues. If you don’t have a dedicated test area, then try and choose a low-impact device – where not much will be impacted if the changes go wrong.
5. Roll out the changes – Make sure you have a list of every device that needs to be touched, so that you have a way to validate. Then make the configuration changes to get each device into compliance with your new standards. Have a validation/testing checklist ready, so that you can quickly ensure that no production traffic was impacted.
6. Train your peers – Configuration standards only work well as long as everyone follows them. It only takes one person to ignore the checklist and potentially expose a vulnerability. So take an afternoon, schedule a training session with your team. Help them understand the importance of maintaining these standards, and train them on how to apply the changes (if necessary).
7. Automate – This part is optional, but highly recommended. If nothing else, spend the time to automate verification of the standards – which will make it easy to locate a device that falls out of compliance. If you or your team have the skill set, then automate the entire process from initial deployment to continuous validation. Why is this the last step, instead of being included with the roll out? I am a firm believer that you should completely understand how your device functions and reacts to changes before automating those changes.
So that’s more or less how I worked to implement a standardized configuration at my current job. I began with a completely new device platform that we were integrating into our environment, then began to go back to older device platforms. It might be a lot of upfront work, but it certainly helps me sleep better at night not having to wonder if there might be one device out there that’s misconfigured (and will cause an issue later, due to that misconfiguration).
So let me know in the comments below – have you ever implemented something like this? If so, what did you do differently? If not, then let me know if you give this a try!