
Default Blocking
Malicious, phishing and botnet/C2 categories are blocked out of the box, for baseline protection from day one.
Customer problem
Many attacks start in a browser: a phishing link, a lookalike login page or a site that calls back to an attacker's server.
When everyone sat in one office, a gateway could filter this traffic. Today much of it starts on a laptop at home or on a public network and never touches the office gateway.
Backhauling it to a central proxy adds delay and cost.
THE COSGRID SOLUTION
SecureWebAccess enforces web policy on the device through the COSGrid endpoint agent. Policy is set centrally and pushed to each device, which makes allow and block decisions locally. Malicious, phishing and botnet/C2 categories are blocked by default.
With SecureWebAccess, organisations can
Define policy by user or group using categories, applications, domains, IPs and custom lists, with allow, block or bypass and a default action.
Policy is pushed to each device through the COSGrid endpoint agent, which makes allow and block decisions locally.
While connected to the COSGrid secure access service, DNS lookups for blocked domains are not resolved. On the device, requests are matched on host name.
Blocked requests show a block page explaining why. Web activity logs export to Splunk, Elasticsearch and CEF.

Malicious, phishing and botnet/C2 categories are blocked out of the box, for baseline protection from day one.

Known bad domains are not resolved while the device is connected to the COSGrid secure access service.

The same policy applies at home, in the branch and on the road, without backhauling web traffic.

Build rules from categories, exact and wildcard domains, IPs, subnets, custom lists and web applications.

The agent keeps the last policy it received and continues to enforce it until it can fetch an update.

Logs show user, device, host, action, category or app, and process, and export to your SIEM.
Use cases

A user at home clicks a phishing link. The domain is in a blocked category, so the request is stopped and a block page explains why.

Staff on shared devices are limited to the sites and applications they need, without a filtering appliance at every site.

A laptop on hotel Wi-Fi keeps its web policy, and keeps enforcing the last policy if the policy server is unreachable.

A separate group gets a tighter policy, with only the categories and applications their role needs.
Need SaaS discovery and control? See "See and control the SaaS apps your staff actually use" →
Have a question about secure web access and SecureWebAccess?
Necessary Cookies
Performance Cookies
Targetting Cookies
Functional Cookies