BAS 101: What is Web Gateway Assessment?

Continuing with our series of questions from readers and users of the Cymulate BAS Platform, let's take a look at this user question: "What happens during a Web Gateway Assessment?"

When looking at Web Gateways, there is often a lot of "moving parts." Most people think of firewalls when thinking of a web gateway, and the firewall and its technologies are a critical component of a web gateway overall, but there are several other components to take into account when assessing the security of "north-south" traffic control.

Web gateways include things like proxy services and VPNs that control who can access network resources and from where. Web content filters and DNS filters control what a user can and cannot access when using corporate network resources. Traffic inspection systems scan incoming data to ensure it doesn't contain known malicious files. All of these components make up a Web Gateway, and Cymulate's Web Gateway Assessment looks at all of its functions to make sure everyone and everything is protected.

So, how does Cymulate do that? The short answer is that we do the same kinds of things that threat actors do - but safely and in a controlled manner, of course. Web Gateway Assessments are composed of three sets of operations or "phases": Inbound communication tests, outbound communication tests, and web content policy tests. Let's take a look at each.

Phase 1: Inbound Communication Tests

Inbound texting is the most straightforward of the three operations that get performed. The Cymulate Agent sitting on a desktop, laptop, VM, etc. (just one Agent per environment) will attempt to download a series of files.

The files that get downloaded are of two types:

• First, files that have known malware signatures.
• Second, files that don't have known malware signatures but contain application code that would attempt to leverage a known exploit if opened.

Important: None of these files are actually permitted to open or run, which ensures the test can be performed safely.

Anywhere from 1,000 to 8,000 files are downloaded in "batches" over time to avoid impacting network performance. Despite this batching, the process typically takes only a few hours. The Agent downloads each file from a known and tightly controlled Cymulate cloud repository. Once downloaded, the file is immediately destroyed.

This allows the Cymulate Platform to determine whether dangerous files can be downloaded—without putting the environment at risk.

Three Possible Outcomes Per File

1. File downloaded unchanged:
   The Agent destroys the file.
   Cymulate reports the web gateway failed that specific test.
2. File downloaded but altered (e.g., Content Disarm and Reconstruction):
   The file is disinfected and harmless when delivered to the Agent.
   The Agent destroys it.
   Cymulate confirms the file is not the original and considers the test passed.
3. File is blocked or stopped before download:
   Technologies like sandboxing or real-time scanning succeed.
   The test file is considered passed.

The test proceeds until all files have been attempted.

TLS/SSL Consideration

The files are sent via TLS (aka SSL/HTTPS). Some web gateways cannot inspect files in transit unless SSL Decryption and Inspection is enabled.

Without this, all files will be successfully downloaded—resulting in all failed tests. This is a critical gap, as most modern threat actors use TLS by default.

If the web gateway can't detect Cymulate's test files, it also can't detect real attack files—leaving the organization significantly exposed.

Phase II: Outbound Communication Tests

Outbound testing is the second phase of a full Web Gateway Assessment (you can choose which phases to include in a given Assessment).

In outbound communication testing, the Agent tries to contact websites known for threat activity. No actual dangerous files or data are retained or transmitted—only publicly accessible information is used.

Cymulate maintains updated lists of known:

• Phishing sites
• Malware download sites
• Command and Control (C2) sites

C2 sites control infected devices (e.g., botnets, remote access tools, DDoS servers). The Agent tries to reach several hundred to several thousand destinations in each category. The exact number changes daily as sites are added or removed.

For each test:

• If the connection is blocked by proxies, DNS filters, or other defenses: test passed.
• If the Agent successfully connects to the test site: test failed.

The process repeats for all test entries.

Web Content Policy Testing

This final component of the Web Gateway Assessment tests web filtering policies (aka content policy testing). The system attempts to access hundreds of sites across 70–80 categories (changing over time).

These sites do not host malware or threats but are commonly restricted in workplace environments. Categories include:

• Adult content
• Online gambling
• Violent or inappropriate material

Some categories, like search engines or healthcare sites, serve as connectivity controls. These help verify that the test setup is functional, even if they are not typically blocked.

Assessment Reporting

All tests are logged and become entries in the Web Gateway Assessment report. These can reveal:

• Outdated threat databases
• Web categories that should be blocked but aren’t
• Traffic that isn’t scanned properly
• Proxy/VPN leaks (traffic bypassing intended controls)

Importantly, reports are also used to confirm that security systems are working correctly. Web gateway security involves many technologies and teams—knowing what’s working is as valuable as knowing what’s not.

Conclusion

And there you have it—Web Gateway Assessments from Cymulate. This Assessment type evaluates all the ways data flows in and out of the environment. Its goal is to ensure that nothing slips through the cracks during transitions between your internal network and the Internet.

Get a complete overview of Cymulate's web gateway assessment in this solution brief.