Introduction
The recent uptick in high severity (and as a consequence, high-visibility) firewall vulnerabilities has brought some attention to the condition of firewalls in many organisations, with those responsible for cyber security wondering if they could be vulnerable. Vendors do an admirable job of firstly, rapidly developing updates to eliminate vulnerabilities, and secondly, of informing their customers of their exposures.
All of this activity and readily available information in a brief period of time puts a spotlight on firewalls, and we have seen an increasing number of requests for ad-hoc firewall reviews.
Problems with Periodic Reviews
While reviews of firewalls against best practices and against any standards or regulations will reveal issues, there are a number of problems with periodic reviews:
- Sometimes these reviews are done no more than annually (at best). Leading to a considerable variance in control effectiveness. There is no guarantee that security is actually effective between the reviews. Inappropriate configuration changes could be added the day after a review. To make it worse, they could be deleted prior to the next review, and no one would be the wiser.
- It requires a lot of effort in a short period of time – to both detect, report on, and remediate any issues.
- Whilst vendor notification is generally excellent, it does not mean this information makes it way to the firewall administrators or management.
An Alternative Approach
Perhaps there is alternative solution to periodic firewall reviews? One that is likely to be mandated more frequently in the future as the threat landscape evolves, and one that actually provides ongoing benefit to security: continuous monitoring and compliance.
Continuous compliance was hyped up and marketed to death a number of years ago, but the principles and benefits are sound, though seemingly hard to achieve. However, for the particular case of firewall reviews, it can be broken down into a relatively simple approach.
Define processes for making requests that incorporate the necessary discipline and hygiene for firewall rule request and configuration changes. This is rather simple. For example, make sure that changes can only be made through an approved, auditable channel, such as a ticketing system.
This ensures that rules can be traced back to their actual requirement. Each ticket must have a reason specified, and the ticket number is attached to any newly created rule as a comment.
Rules would still have to be approved, and this does require some effort upfront, but delivers significant value over time. What would need to be constructed is an algorithm for approving or denying a rule request. This can be rendered as a process, or through an automated means.
A decision algorithm would have to take into account a variety of things:
- For example, organisational cyber security policies might state that insecure protocols are forbidden. In which case, step one could be “Deny any rule requests that use an insecure protocol”.
- If the organisation was taking credit card payments, and beholden to PCI-DSS regulations, then it would likely have a PCI-DSS segment, and a non-PCI-DSS segment (let’s call it “Corporate” for argument’s sake). PCI-DSS protocols could be limited to a list of allowed protocols within the PCI-DSS segment, in which case, rule two could be “If the rule is for traffic to or from the PCI-DSS segment and the protocol is not on the PCI-DSS allowed protocols list, then deny the rule request.”
- Another factor to consider is also the capability of the firewalls themselves. They may have limited capacity or lack some functionality, and thereby constrain possible requests. In this case rule three could be “Deny any rule requests that cannot be supported by the firewall”.
- Some more generic factors could be to “Deny any overly-permissive rules”. Overly permissive would have to be qualified here to, for example deny rules that request a large range of ports or allow overly large network ranges as sources or destinations.
The construction of the algorithm could continue to be customised in this way to best fit the needs of an organisation. In our case, it is a rather simple sequence of rules that ensure requests are compliant with any necessary regulations or standards.
How Does this Solve the Problem?
The continuous compliance approach solves the issue of concentrated effort through dispersing it as small activities throughout the period. While there may still be a need to perform a review, if discipline has been maintained, and a suitable auditable system is in place, then no non-compliant rules should have been put in place. If, for some reason, any have been inadvertently (or otherwise) introduced, there should be significantly fewer of them, requiring less remediation effort.
The approach also solves the issue of security effectiveness between reviews by consistently and unavoidably qualifying rules and configuration changes against a strict set of criteria, thereby reducing the chance of the introduction of low-quality rules.
This can be achieved manually through procedures and sheer discipline, but technology solutions do exist that can do much of the heavy lifting. In many cases, a combination of the two (manual processes and technology) are the optimal solution. Get in touch with us if you want to know more about how we can help you determine the best approach for solving this, and many other industry problems.