Advertorial Supplement Upgrade your firewall—and downgrade risk
“Far too many companies today are using end-of-life firewall systems with limited patch-management capabilities.”
Firewalls are your organization’s primary network defense, so it is vital to take extra precautions when making any changes to your network firewall. However, modifying, updating, or up- grading your firewall in response to changes in your IT environ- ment or business demands often introduces considerable risk. How can you update your firewall solution while minimizing risk? Test major firewall changes before they are implemented in production, and use the latest firewalls with robust patch- management capabilities.
Far too many companies today are using end-of-life firewall systems with limited patch-management capabilities. A patch management system can prevent unwanted changes to the current configuration of the network, limiting the chance that a change will impair functionality.
Here are three recommended best practices to follow in managing your firewall:
Use a test environment
Failure to adequately test changes can lead to business disruptions ranging from network latency issues to complete network outages.
Editing firewall rules on the production device guarding your systems is risky, so thoroughly test firewall changes on a test environment that mirrors production systems for implementing those changes in production.
One solution is to test changes a lab environment using a “virtual sandbox” mirroring your systems. These sandboxed virtual machines should be physically separate from your live systems, connected only through an incomplete network interface configuration. If maintaining a separate testing environment is impractical, consider implementing policy changes on a central management console. Policy updates to the firewall allows for easier reversion than a physical swap, which should also thoroughly tested before going live.
Create a change-testing plan
Rule of thumb: The more damage a serious disruption might create, the greater the value of testing a configuration before going live with the changes.
First, create a firewall change-testing plan, and confirm that the firewall is allowing and blocking data according to the established policies and rule sets. Review security policies of all systems on the network for consistency, including failover and recovery plans. Ensure the firewall has adequate access security, and perform an inbound and outbound data test using an appropriate packet-sniffer.
During change-testing, complete a performance test to determine how a new configuration enhances or degrades network activity, particularly for VPNs. Check the compatibility and interoperability of the firewall with other applications and equipment on the network (particularly from heterogeneous vendors and sources), and create an audit trail for trend and root-cause analysis. Allow ample time to execute change testing, and avoid rushing into significant change changes to firewall configurations.
© 2011 Dell Inc. All rights reserved. Make a configuration snapshot
Protect yourself by taking a “configuration snapshot” before making changes to your firewall.
The worst problems with a configuration change tend to happen while other problems emerge—turning a challenge into a catastrophe. Protect yourself by taking a “configuration snapshot” before making changes to your firewall. Imagine a customer-facing, revenue-generating website under a distrib- uted denial of service (DDoS) attack, requiring significant firewall configuration changes to thwart. Under these circumstances, there is often no time to test, so it is vital to have a change- reversion system in place with failover and recovery plans.
Configuration snapshots are a vital part of a change-reversion system, and many platforms can take snapshots. Check Point Software's SecurePlatform configuration can be saved and reverted with its snapshot utility and revert command. Juniper, IBM, and other providers also have systems with snapshot capabilities. Taking a configuration snapshot and testing major firewall changes are crucial to making a safe transition to a new configuration, and help avoid self-inflicted problems and business disruption in your efforts to protect your organization.
Case Study:
"I was a new-hire network engineer at a small manufac- turing firm and was asked to upgrade our firewalls to a fairly new version of software. I had previously had numer- ous problems with upgrading to this version, so bad that it took hours to recover, due to a number of bugs and poor implementation on the vendor's part. Knowing this, I warned the senior manager that upgrading to that version should not be done unless it was absolutely necessary, and that it would not be a quick process.
We found out that the current version of software our fire- walls used would support the functions we were looking to implement. This had not been formally documented in the release notes for the version of software we were running; however, the vendor did provide written documentation stating it would work. Despite this, our managers still insisted on proceeding with the upgrade.
The next morning we began upgrading the firewalls. Upon rebooting the first one to the new version of software, we immediately ran into problems. The upgrade scripts the vendor had implemented did not work, we encountered numerous bugs, and the firewall was stuck in a constant loop that allowed for no commands to be executed on it.
We had to reboot the firewall numerous times and go into a special mode to recover the device and bring it back to the previous working version of software. The entire process took out the network for several hours and could have been easily avoided with sufficient testing."
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28