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 are downloaded, followed by files that don’t have known malware signatures but instead have application code that would attempt to leverage a known exploit if those files are opened. None of these files are actually permitted to open or run, and that is key to ensuring that the test can be performed safely.
Anywhere from one thousand to eight thousand files are downloaded in “batches” over time so that the network performance is not impacted, but the entire process still only takes a few hours at most. The Agent simply attempts to download each file from a known and tightly controlled Cymulate repository in the Cloud, and if successfully downloaded the file is immediately destroyed. This process thereby allows the Cymulate Platform to determine if dangerous files can be downloaded, but doesn’t allow for the environment itself to be put in any danger.
For each file, there are three possible outcomes of the test. First, the file might be downloaded to the Agent without being altered. The Agent destroys the file and reports that the Web Gateway failed on that specific test file and continues with the rest of the files. The file might be downloaded but altered from its original form. This occurs if the web gateway systems utilize technology like Content Disarm and Reconstruction – essentially the web gateway “disinfects” the file, delivering a harmless version of it to the Agent. Once again, the Agent destroys the file; but since the Cymulate Platform can confirm that it isn’t the exact same file that was sent, the text file is considered passed, and the rest of the files continue on. Finally, the file may be blocked or otherwise stopped from being downloaded. A web gateway that scans files as they download and/or opens them in a sandbox system could have this ability, keeping a user from downloading any file discovered to be dangerous. This is also considered a passed test file, and the rest of the files continue until all the files are attempted and this phase completes.
What makes this a bit more complicated is that these files are sent via TLS – also known as SSL and/or “HTTPS” transfer. Because of this, some web gateways cannot scan the files as they are downloaded to the Agent. Specific technology – such as SSL Decryption and Inspection – must be in place for the inbound files to be properly scanned. Such technology is available in most modern corporate firewall/proxy systems, and so can be utilized to provide more complete security. If SSL Decryption is not used, then all of the files will be successfully downloaded and each would be considered a fail. This is critical to check, as most threat actors now transmit data over TLS/SSL by default – so if the web gateway cannot detect our simulation files, it also cannot detect real attack files; and therefore is putting the organization at significant risk.
Phase II: Outbound Communication Tests
Outbound testing is the second phase of a full Web Gateway Assessment (you have the ability to determine which types of testing any given Assessment will use). When Cymulate tests outbound communication, the Agent attempts to contact websites that are known to host threat activity. As with inbound testing, no actual dangerous files or data is retained, and no information that isn’t already visible to anyone on the Internet is ever sent to these threat sites. How this works is that Cymulate keeps routinely updated lists of websites, hosts, and services known to be phishing websites, malware download sites, and Command and Control websites. Command and Control websites coordinate the activity of malicious software already running on desktops, laptops, and other devices – botnet control sites, remote access service sites, Distributed Denial of Service coordination servers, etc. In each category, there are from several hundred to several thousand different example destinations for an Agent to attempt to reach; the exact numbers vary daily as new sites are discovered and old sites are taken offline. For each test entry, the Agent attempts to reach the site or server. If technologies like proxy services and DNS filters stop the connection, the test entry is considered to have passed and the test continues. Should the Agent successfully reach the test entry in question, the entry is considered to have failed, and the test continues with the next entry in the list until all entries have been attempted.
Web Content Policy Testing
Finally, web filtering testing can be performed, also commonly referred to as web content policy testing. The Web Gateway Assessment has the ability to determine if hundreds of different sites spread across anywhere from seventy to eighty different categories can be accessed (the total number of sites and categories changes over time as corporate standards change). These sites do not host any malware, scams, Command and Control Systems, or anything else dangerous; but each belongs to a category that may be blocked by the company’s web content policy. For example; common categories include sites known to offer adult material, sites that offer online gambling, and sites that deal with particularly violent or other work-inappropriate content. Several categories are designed as “controls” – such as search engines or healthcare websites. These may be blocked by company policy, but more often are not and are instead used to confirm overall connectivity during the test.
Of course, all of these individual tests are tracked as they are performed, and each becomes an entry on the Web Gateway Assessment reporting. These reports can highlight gaps in the current security protocols of the organization; such as threat databases that are out of date, or particular categories of web content that should be blocked but are not currently blocked. They may help discover if certain forms of traffic are not being correctly scanned, or if proxy or VPN systems are allowing traffic to “leak” – that is to move outside of the proxy or VPN itself. It’s important to note, though, that not all of this data is exclusively used to prove where things are not working – in fact much of it can be used to confirm that systems *are* working as well. Web gateway operations involve a lot of complex technologies all working together – often managed by different people or groups within a company. Being able to confirm that everything is working as expected across all those moving parts is information equally valuable to know which parts have weaknesses that need to be reinforced.
And there you have it – Web Gateway Assessments from Cymulate. This Assessment type is designed to look at all the ways data moves into and out of the environment, and to make sure none of it slips through the cracks as your internal network transitions to the Internet, and vice versa. Get a complete overview of Cymulate’s web gateway assessment in this solution brief.
Test Cymulate’s BAS solution today with a 14-day free trial.