In part one and part two of this series, we introduced why best practices for improving network configuration management are important and talked about the first three.
These practices support the thesis that you can eliminate the leading cause of network downtime: simple human error. The first three practices are all about helping you identify all systems under management, standardizing the way you manage these devices, and protecting them from harmful changes. Let’s now build upon this by talking about the remaining two and why they are important.
Audit Configurations for Compliance to DISA STIG and NIST/FISMA Standards
Our objective with this practice is to ensure compliance with all applicable policy standards. There are a variety of security policies and standards that your organization may choose (or be required) to follow. These standards are designed to protect the confidentiality, integrity, and availability of systems, data, and other resources. This is important when these systems contribute to mission success.
These standards are expressed as controls that are implemented as router, switch, firewall, or other device configuration settings. Therefore, by auditing selected configuration settings you can determine your compliance with the standards you follow.
Audits are notoriously unpleasant. They are time consuming and often reveal shortcomings that can reflect poorly on managers and administrators alike. However, for many, they are a fact of life. By regularly reviewing your own “pre-audit” reporting you can discover problems before they are noted by the auditor. Therefore, when proactively finding and correcting violations, you can not only dramatically reduce risk and receive higher scores, but also improve network uptime and mission success.
Use Change Controls to Manage Updates
Our final best practice is powerful because it helps you maintain your configurations after you’ve spent time and effort implementing and perfecting them – even as your environment continues to evolve.
For this best practice, there are four suggestions we recommend you consider adding to your management regiment. These are:
The first suggestion calls for creating a configuration baseline. To “baseline” a configuration is to create an internal standard that allows you to measure other configurations and future changes. So it goes without saying that your baselines should be error-free and stable. Once you designate a configuration baseline then you can detect changes and determine whether those changes are needed and whether they followed your change control processes.
Which is a great segue into our second suggestion: creating a well-disciplined change control process. Ideally, you want to be able to review and approve all changes prior to implementing them in your network. This is useful if you have teams of admins or engineers.
Using a change control process will help coordinate activities between teams. Or you may have less experienced admins or engineers making changes. Again, a formal change control process will allow you to review all changes and detect and fix errors before the change is made.
Our third recommendation suggests using automation to deploy configuration changes, especially if the change needs to be deployed across many systems. Using automation can help ensure the change is made the exact same way and error-free. Automation is your friend.
The last recommendation deals with using change control to manage end-of-life (EOL) devices. You may be wondering why tracking EOL devices is so important. Consider the following reasons:
- Prevent excessive support costs. The primary driver for increasing support costs for EOL hardware is due to vendor end-of-sale and EOL policies. As a device approaches EOL, the support services can become both explicitly and implicitly more expensive. Failure to secure or renew a maintenance agreement before critical EOL dates expire will prevent you from receiving vendor technical support and maintenance upgrades. Therefore, you may be forced to develop or maintain more expensive in-house skills or contract externally for needed services.
- Regulatory non-compliance. Non-conformance costs will become an issue if the device is unable to achieve control objectives defined by your policies. This may be due to a lack of technical capability or because the device is no longer able to receive updates that address security vulnerabilities.
- Business disruption. This risk often produces a broad spectrum of effects caused by catastrophic device failure and can lead to business disruption and accompanying lost revenue and/or brand damage. These problems are amplified when remediating a legacy device consumes even more time because spares cannot be located or the replacement device requires extensive installation and configuration effort.
- Diminished productivity. IT is a significant business productivity driver. Therefore, when new technologies are not adopted and utilized, opportunity costs may negatively affect bottom-line financial performance. This problem is also realized when the business wants to expand service, only to discover that the underlying infrastructure won’t support the business requirements because it is no longer supported. This discovery then forces unplanned expenditures and cost overruns.
By carefully tracking EOL hardware, you can work to eliminate these problems. To implement EOL tracking, you will need tools to help you easily research and manage critical support dates.
Experience informs us that when these five best practices are followed, you can eliminate network downtime, which improves mission success and reduces costs. Achieving this success is a factor of both smart process and the right combination of tools.