Think about how much your organization spends annually on firewall hardware, software licenses, and management. Now think about watching all that money washing down the drain because a single poorly implemented rule circumvented all of the other firewall-based protections. Sounds a little alarming, but if you’re a firewall administrator, you know how real that possibility is. In a previous post we took a look at “shadow rules” and why investing in automated tools that help eliminate them can be a solid business, not to mention security investment. But eliminating redundant, outdated and ineffective rules is only part of the problem. For many firewall administrators, the bigger challenge is handling the day-to-day requests for firewall rule changes without introducing vulnerabilities or exposure points.
Firewalls aren’t static sentries that are set up once and run without change for years. Most firewalls have a fluid set of rules and are frequently updated to support new services for the business. While there’s nothing fundamentally wrong with change, how that change occurs can have significant security repercussions. When an admin is being pressured to make a change outside of the normal change management lifecycle and without proper risk analysis, problems occur.
Consider a business unit owner that is in a rush to have a couple of ports opened on the firewall so an external software development company can set up and test their application on the company servers. Chances are the business owner doesn’t know the technical reasons why these ports need to be opened or the risk associated with allowing traffic through newly opened ports, he just knows the developer said to open them. Because the owner doesn’t understand the potential risks associated with the change, he sees the firewall rules as nothing more than an annoying and unnecessary impediment to getting his application running.
This lack of understanding about how firewalls work can lead to requests for risky rule changes. For example, sometimes the application or business owner doesn’t know which ports should be opened or which services or servers the should be opened for, so they ask for overly permissive rules with ANY that allow all traffic, good and bad, through. Some permissive requests are allowed for a short time for testing purposes and are supposed to expire after the test window. Unfortunately, setting and managing rule expiration dates on multiple firewalls and routers is no easy task. So it’s not uncommon to find permissive rules that were supposed to expire weeks or months earlier, still in effect well after the testing period is complete.
If the business unit owner works in an organization with a robust change management lifecycle, he will need to submit the change request and follow certain procedures to have the change approved and implemented. A typical change management process includes writing up the business justification for the change request, a technical assessment of direct or indirect impacts from the change, and an analysis of the risk trade-offs. For example some of the questions that may be answered during this process include:
- Will the change cause the company to be in violation of a legal or industry mandate?
- Will the change put other systems in the organization at security or business continuity risk?
- Can the business requirement be met with an alternative solution?
Following a set process, like the one outlined above, gives firewall admins time to participate in the process and perform risk analysis before a change is accepted. Unfortunately this process goes awry in two very common ways: 1) The admins are not included in the risk assessment phase or 2) they are not given enough time to complete a thorough analysis. Worst case, for the sake of speed – the change is approved without any kind of formal process and the firewall admins must implement them immediately. Arguably, one of the main reasons admins and risk analysts are “left out” of the risk assessment phase is because their analysis takes too long or their recommendations are seen as too restrictive to the business.
So how can a firewall admins speed up their decision time, provide better insight into corporate risks associated with firewall configuration changes, and get back into the assessment phase?
First, security professionals need some way to model potential changes to the network environment before implementing them. This goes well beyond firewalls because a network is comprised of multiple layers of systems and services, but firewalls are the first line of defense. Any time a change is proposed, be it a new service coming online, a change to a different database platform, or a set of firewall rules to allow for communications to and from these new services risk assessment should be completed.
Having tools to help with this kind of modeling speeds up the process and may catch things a human couldn’t on their own. Tools and techniques here include network topology and mapping, penetration testing and scanning, log analysis, and the risk consoles of IT-GRC solutions. For firewalls specifically, administrators can use a tool that parses the existing rule set against one with the proposed change and identifies potential areas for exposure or if any of the new rules causes an inadvertent override of existing ones.
Bringing all of this information together into a single report, helps security and firewall professionals assess risks associated with proposed changes more quickly and accurately. To make this information even more valuable, translate the risk into business friendly terms before presenting them back to executives. While the statement “opening port 1025 is not advised because it’s not in official assigned use with IANA and has been associated with RPC vulns in the past” sounds like “dolphin” to most people, saying “if we open that port, an external attacker could take control of our servers” is pretty easy for all of us to grasp.
Another way to speed up the risk assessment process, without sacrificing security, is to learn how changes impact the system over time. The first time a request is made to open a port like 1025 a long evaluation may be in order. But if the assessment has already been completed, when the second (or third, or fourth) request to open that port comes in, the response time can be reduced but re-using relevant data from the previous assessments. By keeping a record of known and fully vetted requests for future reference, efficiency and cost-reduction are realized through re-use of existing knowledge rather than by skipping the knowledge gathering step altogether.
Don't miss out on more Tufin blogs
Subscribe to our weekly blog digest
