This is the 3rd part of this loose series on considerations of (operating) DMZs in 2016 (part 1 on the role of a DMZ is can be found here, part 2 on reverse proxies here).
Again, I dare to deviate a bit from the plan & order I initially had in mind – today I will cover one process whose maturity may significantly influence the overall security posture of a DMZ environment: firewall rule management.
Let’s first look at the objectives usually pursued (but not always clear to the parties involved) in the context of the process. These are:
- Security: evidently the arrangement of firewall rules contributes to the security of the environment (for the better or the worse).
- Documentation and transparency: in order to be able to understand why a firewall change is desired and maybe even more importantly to be able to do so in hindsight. This allows to judge at a certain (later) point of time if a rule is still needed. The effectiveness of the rule management process with regard to this objective often depends on supporting tools and the workflow.
- Governance: the way how organizational entities are involved in the firewall change/rule management processes allows to implement (security) governance functions. It serves as an interface between the security objectives laid out by security policies (still using such stuff anyone? ;-)) or the CISO office and the technical real-life implementation.
- Supporting business needs: obviously (but still to be remembered) a firewall rule change is usually triggered from the business side of things/from application owners striving to enable functionality reflecting business needs and hence contributing to the organizations core objectives.
While the above listing may sound quite mundane it has to be kept in mind that often there is a lack of understanding which of those objectives the respective processes of an organization are actually serving. As so often you can’t have it all and it’s about finding the proper balance. Striving to serve them all at the same time often leads to overly complicated processes which in turn induce delays considered unacceptable from the business. Problems often arise from the knowledge mismatch between the parties requesting a rule and the parties deciding on its approval or being responsible for the implementation (see also this post).
Now, what can be done to improve the process and to reach a higher achievement of objectives? Approaches to reduce the resources (like time & effort) needed for firewall rule management include:
- allow deployment of new systems without the need to touch/change firewall rules at all, on the basis of zones/segments with fixed (and usually heavily simplified) firewall rules. In a future post I will discuss the concept of a rapid deployment zone which, amongst others, employs exactly this.
- allow deployment of new systems without the need to touch/change firewall rules by using (for example server) groups with standards rules, so new systems can just be added to such a group.
- reducing the need for technical knowledge on the requestors’ side by using abstraction by tools like Tufin SecureApp. [It should be noted that we do not endorse specific tools from specific vendors, as we don’t sell any solutions. feel free to propose similar stuff together with your personal experience via comments.]
- in general using supporting tools like those of Tufin, FireMon or AlgoSec can greatly help to achieve the documentation/transparency and governance objectives, but of course this comes at the price of potentially bringing in (yet) another tool. Regular readers of our blog know we’re not the biggest fans of a “bring in tools to solve organizational or process-level deficiencies”…
- carefully reconsider the roles & responsibilities involved in checking a firewall rule request. We’ve seen organizations where –e.g. for historical reasons – persons have been involved in approval processes which (nowadays) did not have the necessary knowledge/understanding to take well-informed decisions in this space and hence approved pretty much all requests. When this happens (and usually it’s not too difficult to find out; just look at the ratio of requested vs. approved rules for the individual elements of the decision chain) it might quite simply be easier to remove one element from the chain/workflow of rule request evaluation.
- improve the tool set supporting the decision chain. Obviously a ticket-based workflow might have some advantages over one that involves several steps performed by different tools and via different communication channels (just recently I did some consulting work in a 120K user organization and learned that, for specific reasons, one major subsidiary still requests firewall changes by … fax.). Just modifying the type of information asked for in a rule request form can significantly accelerate the process of filling out the form on the business side or the evaluation procedure on the approvers’ side.
- Escalation procedures (in case a rule request is denied). Let me ask a (kind-of) funny question about this one: how many times have you seen this in your environment? 😉
- Quick availability of information (like the ability to identify an application owner based on system’s FQDN or to identify a network zone based on FQDN) can also be helpful.
- Re-thinking the handling of rule expiry. Some organizations work on the basis of time-limited rules which the respective business owners have to re-approve before expiry of that period. Guess what they do in pretty much all cases – they approve the rules. Question just is: for what reasons does this happen? Well-informed reflection or, just maybe, ignorance?
These are some ideas you might reflect on when trying to strengthen a DMZ environment in 2016. Stay tuned for the next parts of the series.
Everybody have a great day