At a Glance
- The discovery of vulnerabilities in firewalls is not a robust indicator as to whether a brand is more secure than another.
- The vendor must provide candid information on vulnerabilities and be diligent in fixing these defects.
- The services available or enabled on a device must match what is required by the business to achieve its cybersecurity strategies and tactics.
- The selection of a device must be guided by technical requirements and economic constraints that align with IT cybersecurity strategies, tactics, operations, and monitoring.
- The organization must prepare its monitoring/detection and response plans to address vulnerabilities in all systems, including firewalls and other edge devices.
Introduction
A few days ago, we had an internal discussion regarding firewall vulnerabilities and how they should affect the purchasing process. This discussion arose from a question from one of our clients and followed the disclosure by many of the big brands of vulnerabilities affecting the remote access VPN features. These vulnerabilities enable a full device compromise of a Palo Alto firewall, a denial of service on Cisco ASA/Firepower appliances, an authentication bypass in FortiNet devices, and, more recently, Checkpoint announcement of a vulnerability in its remote access VPN feature.
Our client wondered whether this disclosure should make them rethink the purchase of firewalls and, if so, if there was a brand that we would recommend. While the question is legitimate, we think that this is not the best way to state the problem: firewall vulnerabilities are not a robust indicator of the security of the firewall itself.
To Bug or Not To Bug
Software bugs are an inevitable part of development, be it software or hardware. Some of these software bugs will result in vulnerabilities, that is, conditions that may be exploited. Over time, the major vendors have become very open and transparent regarding the presence of these vulnerabilities in their products, often publishing blog posts or bulletins. In addition, national security bodies such as CISA have catalogs of known exploited vulnerabilities and publish advisories to inform their constituents of the need to either apply a fix or monitor for unusual activities. The net result is a lot more information regarding vulnerabilities is available and, at times, may feel overwhelming. It is important to understand that this does not mean that there are more vulnerabilities nowadays but simply that we are more aware of them.
Two important things when it comes to vulnerabilities, though, are that the vendor be diligent in informing its customers and that fixes are quickly available. This also means that the organization needs a robust patch management program that covers all devices, not just computers.
Receiving timely information about vulnerabilities from the vendor or from a vulnerability management service will help with setting up heightened monitoring, be it in-house or delegated to an external party, until a fix is available, for example, to perform a manual review of network activities for the day prior or to expedite the analysis of security events. On several occasions, the vendors also offered mitigation techniques to remove or limit the impact of successful exploitation, and on some occasions, the recommendation was to disable the affected service or component.
Of course, this regimen is not tenable in the long run, which is why the speed at which fixes are issued is important. Note that this also gives weight to system support and the presence of support contracts.
Firewall With a Side of Additional Services
A long time ago, a firewall did one thing: filtering traffic based on source, destination, protocol, and, eventually, ports. Since then, firewalls have integrated features such as Layer 7 inspection (also called “deep inspection”), user authentication, and site-to-site and client-to-site VPN, to name but a few. Additionally, firewall vendors often sell services such as botnet domain lists, known C2 IP address lists, pre-populated groups of IP and domain names for common internet services such as Microsoft Office 365 or Google Workspace, or updates to rules for the embedded IPS. These services are leveraged to provide a finer filtering of the traffic, for example to let servers access Microsoft Windows Updates without opening the whole Internet or to block traffic matching attack signatures.
In most of our incidents, we have seen that additional security services, while purchased or licensed, are seldom leveraged. This raises the question of why these services were purchased in the first place and what drove the choice of the specific brand of firewall, especially given their price: said otherwise, why pay, often a consequent sum, for “things” that are not used?
Some services come as standard, such as remote access VPN, which is often a given nowadays. These should be properly configured or disabled if not in use.
A client may have a third party, usually a service provider, purchasing and managing the firewalls. In that case, the client should hold the service provider to the highest standards, ensure that what it pays for is used adequately, and clearly define its expectations in writing. This must include that the service provider informs the client of all vulnerabilities that the firewall vendor reports.
What Matters
Above, we wrote about vulnerabilities and timely fixes to them, and the adequation between the services available in the device and the services required to achieve the organization’s cybersecurity strategies and tactics. We want to add two items to that: detection plans and response plans.
As we stated, vulnerabilities are inevitable and will be found in any piece of code, given enough scrutiny. Therefore, it is important to prepare plans for increasing detection capabilities, for example, through closer monitoring and special investigative procedures.
An example of “closer monitoring” would be challenging all RDP access to the servers: the security team reviews the logs every morning for the preceding day and asks the server administrators to justify all RDP connections that occurred. Any session that cannot be accounted for is then considered a security incident and investigated as such. This is where the “special investigative procedures” come into play: the rule during these periods should be that the answers to the cybersecurity team come first and have the highest priority.
The response plans must contain the usual response to security incidents, although the response itself may be stronger or encompass a larger scope when a vulnerability has been communicated than it would normally. This, in essence, is putting additional weight to the development and rehearsal of IR plans, through IR and tabletop exercises.
When sharing information about vulnerabilities, vendors often include mitigation techniques. The response plans should include a section to expedite the analysis and potential implementation of the suggested techniques or to look for other mitigation techniques if applicable. This may include adapting the change management process to include these emergencies.
Guiding the Choice of the Firewall
After all of this, the question may be what factors need to be considered. Here is a short list of questions to ask yourself to help decide what firewall to check out.
Technical Aspects
This is the technical definition of the new firewalls, such as the required features and specifications. These technical requirements fall into three major categories:
- Security Features: What security features are needed? Deep inspection, a rich database of internet services/applications, antivirus scans, botnet and c2 deny lists, …
- Non-Security Features: What other features are needed? Virtual domains, routing protocols, …
- Performances: What bandwidth should the firewall be able to sustain? If used for IPSEC tunnels, what should be that bandwidth?
Security Features
Nowadays, firewalls provide services above the L3/L4 filtering, such as the ability to inspect DNS traffic to block the resolution of certain domains, the scanning of files transferred via HTTP to detect viruses, or the validation of SSL certificates to prevent access to sites that use self-signed certificates.
These features are important building blocks when implementing IT cybersecurity strategies and tactics. For example, it is very difficult to provide access to only Microsoft Update to servers without relying on a database of internet services, or compliance rules may require all executables entering a network to be scanned for viruses prior to reaching the endpoints.
The key here is to define the needed features based on the IT strategies and tactics, establish a list, and shop for firewalls with these features.
Non-Security Features
These features include network features such as virtual firewalls, automated failover, state synchronization, or routing protocols. Non-network features also exist, such as the possibility to generate activity reports automatically.
Features of this category will often be selected based on operational and infrastructure needs.
Performances
At the very minimum, you will want a firewall that can reach at least your internet bandwidth: there is no point in having a 1Gb/s internet access if the firewall in front of it can barely reach 200Mb/s. However, consider that other types of traffic may go across the firewall: if taking backup copies from a central location, it is likely that traffic between the backup server and the DMZ servers will cross the firewall. Note that additional features may restrict the bandwidth; for example, a firewall may be able to pass 500Mb/s with basic L3 filtering but will go down to 50Mb/s when doing virus scans.
Some firewalls also terminate IPSEC tunnels, which requires the device to encrypt and decrypt packets. The IPSEC throughput is often significantly lower than the non-IPSEC one, which may be a consideration if using these tunnels for bandwidth-sensitive applications.
Non-Technical Aspects
Some considerations are outside the realm of the technical specifications. The two points we consider the most important are the following:
- Familiarity: Is your team already familiar with specific types of firewalls or brands?
- Support: Does the vendor’s support align with your SLA objectives?
Familiarity
Of course, this applies only to cases where the firewalls are managed in-house. In those cases, the existing teams may already have knowledge of certain types and brands of firewalls. In that case, changing to a new type may require training the personnel and likely adapting procedures and operational processes.
Support
A vendor may offer different levels of support that may or may not be acceptable for the organization, for example, when there are SLAs to guarantee. This is more of an operational consideration, albeit an important one.
Log Quality
All firewalls generate logs, though some do not by default. What changes drastically from one vendor to another is the “quality of the logs,” that is, the level of information included in the logging. For example, some firewalls do not capture the session closure information and, as a result, can’t provide the volume transferred in a connection, whereas others not only capture that information but also add the detected applications. These richer logs make investigations when the logs are actually kept, much faster.