Tag: Microsoft

InsideCybersecurity: Cyber assessment nonprofit finds cloud-native firewalls inadequate for defending against advanced attacks

Posted on by CyberRatings.org

Cloud-native firewalls offered by major service providers performed significantly worse in vulnerability testing compared to third-party firewalls when targeted with advanced attack methods, according to the latest results from nonprofit assessment firm CyberRatings.org.

“Best-of-suite (native) solutions need significant improvement compared to best-of-breed (third party) cloud network firewalls,” CyberRatings says in an April 2 report detailing takeaways from testing conducted on 10 firewall solutions.

The latest testing results build on a November 2024 report that detailed the “first phase” of cloud-native firewall evaluation from the nonprofit and revealed shortcomings in firewall solutions native to Google, Amazon Web Services and Microsoft cloud offerings.

The new report is more extensive and goes into how some firewalls fail to protect against “evasion” techniques that hackers use to conceal their activities.

Read the full article here.

Futuriom: Cloud Firewalls Have Gaping Holes

Posted on by CyberRatings.org

In the release of remarkable firewall test results today, independent nonprofit testing firm CyberRatings.org revealed wild variability in network and cloud firewall efficacy, with special concerns about the firewall instances running in the major public clouds, which seemed not to work very well at all.

In the release of the CyberRatings Q1 2025 Comparative Test Report on Cloud Network Firewalls (CNFWs), many traditional firewalls performed quite well with efficacy ranging at almost 100%. Third-party firewalls from Check Point, Fortinet, Juniper Networks, Palo Alto Networks, and Versa Networks demonstrated the highest security effectiveness blocking exploits and evasion tactics. Results ranged from 99.61% to 100%.

But move into the public cloud, and you get a different story. Some native firewalls from Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure received a 0% Security Effectiveness score as they allowed attacks to bypass existing defenses. In addition, Cisco’s Secure Firewall Defense didn’t receive high ratings, with a 54.5% effectiveness rating and the highest costs per bit of traffic in the bunch.

Read the full article here.

CyberScoop: Independent tests show why orgs should use third-party cloud security services

Posted on by CyberRatings.org

Businesses don’t always get what they pay for in cybersecurity. Some of the most expensive cloud network firewall vendors are among the worst performers against exploits and evasions, according to the most comprehensive, independent testing CyberRatings.org has conducted to date.

Cisco, by far the most expensive cloud network firewall offering across the top 10 vendors on price per megabits per second, ranked seventh with an overall security effectiveness score of 53.5%, according to CyberRatings.org research released Wednesday.

The trio of big cloud providers — Amazon Web Services, Microsoft Azure and Google Cloud Platform — fared even worse, each landing at the bottom of the pack with a 0% security effectiveness score.

Read the full article here.

CyberRatings.org Publishes Test Results on Cloud Network Firewalls

Posted on by CyberRatings.org

Austin, TX – April 2, 2025 – CyberRatings.org (CyberRatings), the non-profit entity dedicated to providing confidence in cybersecurity product efficacy, today released its Q1 2025 Comparative Test Report on Cloud Network Firewalls (CNFW), along with separate, in-depth reports for each of the ten cloud firewall solutions tested. Security effectiveness results ranged from 0% to 100%.

Key Findings:

  • Third-party firewalls from Check Point, Fortinet, Juniper Networks, Palo Alto Networks, and Versa Networks demonstrated the highest security effectiveness blocking exploits and evasion tactics. Results ranged from 99.61% to 100%.
  • Native cloud firewalls from Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure offer a convenient alternative, but all received 0% Security Effectiveness as they allowed attacks to bypass existing defenses.
  • Google Cloud Platform’s Next Generation Firewall (NGFW) service leverages Palo Alto Networks technology. We attribute the differences in security effectiveness and performance results between the two platforms to each provider independently selecting and deploying different software versions based on their own criteria.
  • A total of six firewall solutions were Recommended and four received Caution ratings.

In the Cloud Service Provider Native Firewall test from November 2024 only 522 exploits were used in the Part 1 “Mini-Test”, but not evasions. For this round of testing, a greater number of exploits were deployed, and evasions were introduced to the test samples:

  • False Positives: 2,760 samples from various business-critical files and applications, ensuring security measures did not disrupt legitimate traffic.
  • Exploits: 2,028 attack samples from widely exploited vulnerabilities in enterprise environments.
  • Evasion Techniques: 2,500 attacks spanning 27 evasion techniques tested across multiple network layers to bypass firewall defenses.
  • Performance Metrics: 46 different stress and capacity tests under diverse workloads.
  • Stability & Reliability: Seven extended tests simulating prolonged real-world attack and operational scenarios.

CyberRatings evaluated firewall security by testing for evasion detection at three separate layers of the Open Systems Interconnection (OSI) model, specifically Layers 3, 4, and 7. Missing lower-layer evasions had the greatest impact on the overall score because these layers form the foundation of firewall security at the fundamental networking level, and when these lower layers are compromised, the firewall’s primary protective function is undermined. Points were deducted based on the firewall’s ability—or inability—to detect evasions:

  • A missed evasion from the Layer 3 level resulted in a 50% deduction per category, up to a potential category maximum reduction of 100%.
  • Missing a Layer 4 evasion led to a 20% deduction per category, up to a potential category maximum reduction of 60%.
  • A miss at Layer 7 incurred only a 1% deduction per category, up to a potential category maximum reduction of 10%.

Layers 3 and 4 evasions are particularly concerning since all modern applications rely on IP and TCP. Vulnerabilities at these layers can be exploited across a wide range of systems—from cloud services to enterprise applications.

“Until cloud service provider native firewalls provide better protection, customers should be looking to third parties for their cloud security needs,” said Vikram Phatak, CEO of CyberRatings.org. “Traditional third-party security vendors have demonstrated that they bring significant value to customers.”

Below is a summary of the Ratings:

The cloud firewalls were tested using Keysight’s CyPerf v5.0 software testing platform in addition to CyberRatings’ in-house developed test tools. Enterprises can easily perform similar testing with a 2-week free trial from Keysight. Further details of the CyPerf strike library can be found here: https://www.keysight.com/us/en/products/network-test/cloud-test/cyperf.html

CyberScoop: Vikram Phatak on the inherent issues in native cloud firewalls

Posted on by CyberRatings.org

In the latest episode of Safe Mode, Greg Otto talks with Vik Phatak, Chairman and CEO of CyberRatings.org. Cyber Ratings recently released a report assessing the native firewalls provided by major cloud service providers like Microsoft, Google, and AWS. These cloud-native firewalls, included with their instances, were put to the test by Cyber Ratings to evaluate their effectiveness. The findings reveal significant shortcomings in relying solely on these built-in security measures.

Listen to the full podcast here.

Exploring Cloud Service Provider Native Firewalls

Posted on by CyberRatings.org

In April 2024, we published the results of our annual Cloud Network Firewall test. In that test, the AWS Network Firewall exhibited a mere 5.39% Security Effectiveness score, the lowest result in our comparison. That extremely low Security Effectiveness score was not considered to meet any reasonably acceptable standard, and it was concerning enough that we decided to re-evaluate AWS’ offering six months later to see if any improvements might have been made.

We expanded our testing to include Microsoft Azure Firewall and Google Cloud Platform (GCP) Cloud NGFW and published those results on November 26, 2024. Combined, the “Big Three” now account for two-thirds of the growing cloud provider market. Our goal was to assess their native firewall capabilities and understand their strengths and limitations against a variety of attacks.

Part One of a Two-Part Test

This testing was conducted as part one of a two-part series examining cloud network firewalls. It was limited to a subset1 of exploits from Keysight’s CyPerf v5.0 software testing platform. In part two, we will increase the difficulty of the test by widening the scope and depth of testing. The second part of the test will also compare cloud service provider native offerings against market leading third-party cloud network firewall providers. Publication of part 2 will be in Q1 of 2025.

Retesting AWS Network Firewall

Here’s a rundown of our journey with the AWS Network Firewall, including our steps and what we discovered along the way. We decided to publish these additional details so that customers of AWS Firewalls can investigate how the firewall would work in their environments.

Setting Up and Initial Testing

First, we set up the AWS Network Firewall with its basic firewall features, such as access control rules. We wanted to ensure that the fundamental functionalities were working correctly before diving deeper. During our initial testing, these features functioned as expected, effectively controlling access according to our configurations. Then, we executed a series of attacks to test the firewall’s threat detection capabilities. Surprisingly, the AWS Network Firewall only blocked two out of all the attacks we launched. This unexpected result prompted us to question whether the firewall was correctly configured or if there was an issue with our setup.

Double-Checking the Configuration

To rule out any misconfigurations on our part, we carefully double-checked our firewall settings against the official AWS documentation. We reviewed each configuration parameter, ensuring everything matched exactly as prescribed. Our review confirmed that the configuration was indeed correct.

Validating the Firewall Deployment

We conducted additional tests to verify that the AWS Network Firewall was deployed correctly and that all network traffic was routed through it rather than bypassing the firewall and going directly to the internet. We transmitted both normal and malicious traffic across the firewall to observe its behavior.

All traffic forwarded or blocked by the firewall rules was accurately logged in the AWS flow and alert logs via AWS CloudWatch. This validation step reassured us that the firewall was operational and actively monitoring the network traffic as intended.

Diving Deeper with Detailed Analysis

Next, we tested specific threat detection capabilities to confirm that the firewall was functioning correctly. We selected three Suricata rules from the AWS-managed ruleset and generated traffic that matched the malicious content described in those rules.

Case Study: The daddy.linkpc.net Domain

One of the domains we tested was daddy.linkpc.net. The Suricata signature associated with this domain is designed to drop any traffic attempting to access it. Here were the steps we took:

  1. Attempted to Resolve the Domain: We tried to resolve daddy.linkpc.net, mimicking a user or system attempting to access a malicious domain.
  2. Firewall Detection: The AWS Network Firewall detected this malicious activity using the predefined security signature (Signature ID 2853242).
  3. Action Taken: The firewall blocked the DNS query, effectively preventing any communication with the malicious domain.
  4. Observation: The alert triggered by this activity was visible in the AWS Alert Logs, confirming that the firewall’s detection mechanisms were working as expected for this case.

At this stage, we theorized that most of the attacks bypassed the firewall because it lacked specific rules for those particular attacks. To investigate this possibility, we decided to delve deeper into the firewall’s ruleset.

Matching CVEs from AWS Suricata Rules to CyPerf Attacks

Suricata is a high-performance, open-source network analysis and threat detection software. It’s widely used by both private and public organizations and is embedded by major vendors to protect their assets. Suricata uses a signature-based approach to detect threats, which relies on predefined rules and patterns.

CVE stands for Common Vulnerabilities and Exposures. It is a glossary that classifies vulnerabilities. Its purpose is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.

To test our theory, we needed to determine whether the AWS Network Firewall had rules corresponding to the attacks Cyperf was using. Here’s how we approached it:

  1. Extracted CVEs from Suricata Rules: We extracted all the CVEs listed in the Suricata rules used by the AWS Network Firewall.
  2. Matched CVEs with CyPerf Attacks: We compared these CVEs with the attacks available in CyPerf to identify those that matched.
  3. Executed Matched Attacks: We then executed only the attacks with corresponding CVEs in the firewall’s ruleset.

The Result: We found very few rules matched CVEs. This is because many Suricata rules did not contain CVE details, and out of those that did, the AWS Firewall only blocked two attacks. Further, most of the signatures were not relevant for cloud environments.

Observations and Concerns

Through our analysis, we observed the following about AWS Network Firewall’s capabilities:

  • Reliance on Basic Regular Expressions: Many signatures in the firewall’s ruleset rely on simple regular expressions. While effective for straightforward patterns, this approach can be insufficient against more sophisticated or obfuscated attacks.
  • Design Focus: Many signatures appear to be designed for home or small office environments rather than for cloud or server workloads. This could limit the firewall’s effectiveness in enterprise or cloud-native scenarios.
  • Total Signatures and Limitations: As of October 2024, the signatures contained over 21,500 preconfigured rules. These signatures are organized into groups, each containing thousands of signatures. Therefore, to enable one, you must enable all in the group. The AWS Firewall also limits the number of signatures you can enable. The maximum number of signatures is 30,000 for stateful and stateless firewall
  • Distribution of Rules:
    • Approximately 10% of the rules protect web browsers.
    • Around 17,500 rules monitor outbound connections (post-infection activities).
    • Only about 4,000 rules focus on inbound traffic.
    • Lack of CVE Information: Most signatures do not contain CVE details, making it challenging to assess the firewall’s coverage against known vulnerabilities.

Assessing the Severity of Limitations

To illustrate the potential impact of these limitations, let’s consider an example involving domain-based signatures:

Example: Circumventing Domain-Based Signatures

  • Signature Limitation: Suppose there’s a signature designed to block traffic to cnn.com.
  • Potential Circumvention: An attacker could easily bypass this signature by slightly altering the domain name to cnn.com, using a subdomain like news.cnn.com, or adding a character before or after cnn.com.
  • Issue: If the signature only matches the exact domain cnn.com or tries to match a precise number of characters, it fails to detect these variations, allowing malicious traffic to pass undetected.
  • Implication: This example demonstrates how attackers can exploit simple signatures by making minor changes, highlighting the need for more robust and comprehensive detection mechanisms.

Our Journey with Other Cloud Service Provider Firewalls

Azure

Unfortunately, we came into this test blind; Azure seems to use a propriety, closed-source security stack. It provides little visibility into how it works or how to change anything. You pay for it, turn it on, and it does “stuff.” This limitation is frustrating, given the results, as it removes the user’s ability to adjust protection based on their unique deployment.

The lack of visibility into rules and/or related CVE information limits the user’s ability to understand how well the protection aligns with their environment, applications, and workloads.

Google Cloud Firewall (GCP)

Like Azure, this is also closed-source security software. However, we discovered that GCP’s firewall is running software from Palo Alto Networks. We have worked with Palo Alto Networks for many years and expected much better results than we saw reflected in the scores. GCP directs you to the Palo Alto Networks website for information on the deployed protection.
Recommendations:

  • Third-Party Firewall: Until Cloud Service Provider’s Native Firewalls offer adequate protection, we recommend using a third-party cloud firewall (offered through the respective CSP’s marketplace).
  • Custom Rule Creation: Consider creating custom rules tailored to your specific environment and attack surface.
  • Supplementary Security Measures: Consider using additional security technologies to complement the Cloud Network
  • Update & Test: Update your firewall regularly and test each update. Attackers are continuously innovating; defenses that work today may not work tomorrow. It is important that your defenses are current and that you verify they work as expected.
  • Supplementary Security Measures: Consider using additional security technologies to complement the Cloud Network Firewalls based on test results.

Our journey highlighted the importance of not solely relying on default configurations and the need for a proactive approach to network security. By understanding the capabilities and limitations of tools like Cloud Service Provider Firewalls, organizations can better protect their assets and respond to evolving threats.

For further information on how to best configure these products, please reference Best Practices for Cloud Network Firewall Deployment in 2024: Cloud Service Providers (CSP).

[1] We limited the scope of exploits to those that: 1) targeted servers, 2) were applicable to applications or workloads that could be run on a cloud virtual machine or bare metal platform, 3) were for known exploits over the last 10 years with a CVSS score of medium to high.

 

Best Practices for Cloud Network Firewall Deployment in 2024: Cloud Service Providers (CSP)

Posted on by CyberRatings.org

This guide supports the Cloud Network Firewall (CNFW) mini-test, which compares the security effectiveness of native firewall solutions from Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

This guide should supplement what vendors already provide to their customers. Please see the links below for the best practices and guides for each product we tested. We have also included information for Keysight’s CyPerf v5.0 software testing platform, enabling enterprises to easily replicate our results.

Cloud Network Firewall Test Topology

AWS Network Firewall

Product, best practices, and documentation:

Following AWS’s documentation, the CyberRatings team deployed the AWS Network Firewall instance in routing mode to inspect both inbound and outbound traffic. We set up and configured our threat testing harness using CyPerf, which was installed using the AWS Marketplace.

Deployment Steps:

  1. Route Tables: The route tables must be configured to properly route traffic across the AWS Firewall (AWS FW). Three necessary routing tables are required, and they are described below.
  2. Control Subnet: routes traffic from and to the Control Subnet, the subnet on which the AWS FW endpoint has been deployed.
  3. Customer Subnet: routes traffic from and to the Customer Subnet, which is the subnet on which the trusted clients and servers are deployed, i.e., the LAN side of the Firewall.
  4. Public Internet Gateway: routes traffic from and to the Customer Subnet, which is the subnet on which the trusted clients and servers are deployed, i.e., the WAN side of the Firewall.
  5. Firewall Policies: create rule groups for various traffic types, including allowed and blocked IPs and protocols.
  6. Firewall Subnet: configure in each VPC to direct traffic through the firewall.
  7. Logging & Monitoring: Lastly, we enabled logging to store data in CloudWatch for auditing and monitoring purposes (S3 can also be utilized).

For AWS Network Firewall, multiple steps are required:

  1. Enable logging (both flow and alert logs)
  2. Forward logging output to one or more AWS services (CloudWatch, S3 Storage, etc.)
  3. Then, we analyzed the logs (in JSON format). They can also be exported to multiple formats to be viewed locally.

CyPerf: We used AWS Marketplace and installation was straightforward.

Google Cloud NGFW Enterprise Firewall

Product, best practices, and documentation:

We followed their best practices and documentation and deployed the instance in routing mode to inspect both inbound and outbound traffic. We set up and configured our threat testing harness using CyPerf. Using the provided instructions and documentation, it was easy to deploy.

Cloud NGFW’s threat detection and prevention capabilities are powered by Palo Alto Networks threat prevention technologies[1]. To help protect your network, Cloud NGFW supports a default set of threat signatures with predefined severity levels. Users can view all the threat signatures configured in Cloud NGFW in the threat vault.

Firewall Endpoints:

Firewall Policy:

CyPerf: The CyPerf agents were deployed on GCP using Terraform. The procedure for deploying using Terraform is shown below.

Installation of Google Cloud Software Development Kit (SDK):

  1. Reference: Install the gcloud CLI  |  Google Cloud CLI Documentation
  2. Next step: https://github.com/Keysight/cyperf/tree/main/deployment/gcp/terraform
  3. Once the GCP SDK has been installed successfully, install the agents using Terraform. (These were obtained from Cyperf): https://github.com/Keysight/cyperf/tree/main/deployment/gcp/terraform

Microsoft Azure Firewall Premium

Product, best practices, and documentation:

We followed their best practices and documentation for Microsoft Azure Premium Firewall and deployed the instance in routing mode to inspect both inbound and outbound traffic. We set up and configured our threat testing harness using CyPerf.

Microsoft Azure Firewall Premium uses Microsoft’s closed-source signatures. As of October 2024, its ruleset contained over 67,000 rules in over 50 categories.

Deployment Steps:

  1. First, we installed Terraform: https://learn.hashicorp.com/tutorials/terraform/install-cli
  2. Then we installed Azure CLI: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli
  3. Firewall Policy:
  4. Firewall IDPS Policy:
  5. Firewall Threat Intelligence Policy:
  6. Lastly, we set up logging and forwarded logs to NetWatcher, another service in Azure. The logs could then be analyzed in multiple formats.

CyPerf: https://github.com/Keysight/cyperf/tree/main/deployment/azure/terraform/controller_and_agent_pair

[1] https://cloud.google.com/firewall/docs/about-threats

Inside Cybersecurity: Cyber assessment nonprofit identifies firewall vulnerabilities in ‘Big Three’ cloud service provider offerings

Posted on by CyberRatings.org

Firewalls provided by Amazon, Google and Microsoft as part of their cloud service offerings are vulnerable to a significant number of known exploit tactics, according to the latest test results from nonprofit cyber assessment firm CyberRatings.org.

“Until cloud native firewalls demonstrate they have a higher level of security effectiveness to protect against cyber threats, we strongly recommend that customers consider third-party providers with a proven track record,” CyberRatings CEO Vikram Phatak said in a Tuesday release.

The nonprofit’s latest report dives into the cyber defense capabilities of firewalls built into the infrastructure of the “Big Three” cloud service providers.

Read the full article here.

CyberRatings.org Announces Test Results for Cloud Service Provider Native Firewalls

Posted on by CyberRatings.org

Austin, TX – November 26, 2024 – cyberratings.org/ (CyberRatings), the non-profit entity dedicated to providing confidence in cybersecurity products and services through its research and testing programs, has completed an independent “Mini-Test” of Cloud Service Provider (CSP) Native Firewalls from Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Security effectiveness protection ranged from 0.38% to 50.57%.

In today’s cloud-centric environment, businesses often face a critical choice regarding the security of their cloud infrastructure. They can rely on firewalls offered directly by Cloud Service Providers (CSPs) or use independent security vendor firewall offerings typically available through the respective CSP’s marketplace. Security effectiveness is a crucial factor in selecting the right firewall solution, as it directly impacts the organization’s ability to protect against cyber threats.

The CSP firewalls were tested against 522 exploits using Keysight’s CyPerf v5.0 software testing platform, offering an evidence-based look at how well these native solutions withstand real-world security threats. Only known Common Vulnerabilities and Exposures (CVEs) from the last ten years with a severity of medium or higher were used to assess security effectiveness, usability, and protection. The exploit (CVE) types targeted servers and are typically relevant to cloud workload deployments.

Mini-Test Results:

“This was designed to be an entry level test,” said Vikram Phatak, CEO of cyberratings.org/. “The exploits were straightforward; we didn’t apply any evasions which is normally how attackers bypass security products. The number of missed exploits is concerning. Until cloud native firewalls demonstrate they have a higher level of security effectiveness to protect against cyber threats, we strongly recommend that customers consider third-party providers with a proven track record.”

This test is part one of a two-part test. Part two will include a higher number of exploits, along with evasions. The second part of the test will also compare cloud service provider native solutions against market leading third-party cloud network firewall providers.

The native firewalls were tested using Keysight’s CyPerf v5.0 software testing platform. Enterprises can easily replicate the results with a 2-week free trial from Keysight. Further details of the strike library can be found here: https://www.keysight.com/us/en/products/network-test/cloud-test/cyperf.html

CyberRatings.org Announces Test Results for Cloud Network Firewall

Posted on by CyberRatings.org

Austin, TX – April 3, 2024 – cyberratings.org/ (CyberRatings), the non-profit entity dedicated to providing confidence in cybersecurity products and services through its research and testing programs, has completed an independent test of eleven market leading Cloud Network Firewall vendors. Six products were Recommended, one product received a Neutral rating, and four received a Caution rating.

Cloud network firewalls are considered to be the first line of defense when deployed in public cloud providers such as Amazon Web Services, Google Cloud Platform and Microsoft Azure. But implementing security in the cloud can be complex, with multiple factors influencing effectiveness.

CyberRatings tested the cloud firewall products to determine how they handled TLS/SSL (authentication) 1.2 and 1.3 cipher suites (algorithms), how they defended against 984 exploits (attacks that take advantage of a software flaw or install malware), and whether any of 1,645 evasions could bypass protection. At all times the devices needed to remain stable under adverse conditions. To provide a more realistic rating based on modern network traffic, both clear text (HTTP) and encrypted traffic (HTTPS) were measured. Amazon Web Services (AWS) was the public cloud service chosen to run the test.

The combination of Security Effectiveness and Value dictated where products landed on the Security Value Map™ (SVM). Six out of the eleven products were Recommended for their Security Effectiveness with scores ranging from 99.70% to 100%. Recommended ratings are based on threat prevention (how many exploits and evasions were blocked?), TLS/SSL functionality, routing and policy enforcement, and stability and reliability to achieve a final Security Effectiveness score. These same products also demonstrated competitive pricing in the Total Cost per Protected Mbps (Value). The product rated Neutral received a 48.44% Security Effectiveness score. Four products rated Caution had Security Effectiveness scores ranging from 5.39% to 48.37%.

“We have been testing firewalls for years, and more recently cloud network firewalls,” said Vikram Phatak, CEO of cyberratings.org/. “All of the products chosen were market leaders and the range of scores clearly shows that building a product for the cloud is different than building a product on an appliance where you control the environment,” said Phatak. “We recommend that enterprises check with their service providers or IT teams to see which cloud firewall products are currently deployed in their networks.”

As part of the cloud firewall test, CyberRatings also checked to see if products were secure by default. It was discovered that some firewall evasion defenses are not on by default, potentially leaving customers at significant risk. In response, CyberRatings is providing a policy and configuration guide to help enterprises ensure that their firewalls are configured properly.

Encryption matters: roughly 80% of web traffic is encrypted. The top four cipher suites account for over 95% of HTTPS traffic. In some products, decryption was not on by default. Firewalls will not see attacks delivered via HTTPS unless configured to do so. Performance is significantly different when TLS/SSL is turned on. With the exception of one vendor that failed to handle TLS 1.3 despite claiming support, all other vendors supported encryption.

Enterprises should monitor security and performance capabilities, and update firewalls regularly. With the everchanging cloud platform and agile development, something can go wrong even when the security vendor does not make a change.

The following products were evaluated:

Additional Resources: