Mcafee Mvision Unified Cloud Edge Getting Started 11-2-2021

McAfee MVISION Unified Cloud
Edge Getting Started

MVISION Unified Cloud Edge
What is MVISION Unified Cloud Edge?
• Product overview
• How it works
• Key features
• About MVISION Cloud
Getting started with MVISION Unified Cloud Edge

• Log on to MVISION Cloud for the first-time
• Activate WGCS
• Set up McAfee Client Proxy
• Set up McAfee Mobile Cloud Security
• Authenticate users using your identify provider through SAML
• Set up log data residency and log privacy settings
Securing sanctioned services

• For AWS
• For Azure
• For Box
• For Dropbox
• For Google Drive
• For Office 365
• See more sanctioned services
Discovering shadow IT
• On-demand scans
• Connected applications
• Cloud registry
Setting web policies

• Allow access to web objects globally
• Block access to web objects globally
• Block access to malware-infected web objects
• Block URLs for inappropriate websites
• Allow access to websites with coaching
• About the web policy code view
• Select your on-prem or cloud policy as default and configure exceptions
Browser isolation
• Enable browser isolation when access to a website is considered a risk
• Enable browser isolation for any website as you consider it appropriate
Protecting sensitive data

• Create custom classifications to protect sensitive data
• Create a Sanctioned DLP policy with the Policy Wizard
• Create a Shadow DLP policy with the Policy Wizard
• Policy incidents
MVISION Unified Cloud Edge Product Documents

• Release Notes
• Getting Started
• Data Protection
• MVISION Cloud
• Secure Web Gateway
2 McAfee MVISION Unified Cloud Edge Getting Started

• SD-WAN Integration
• Web Policy
Technical Content
• Supported Environments for McAfee Mobile Cloud Security (KB91790)
• Configuring global routing manager country and region prefixes (KB87631)
• Cloud Security: McAfee blogs and podcasts
• What is cloud security?
• What is a CASB?
• What is SASE?
• How to secure your data everywhere? It's easy with Unified Cloud Edge
• Think beyond the edge: Why SASE is incomplete without Endpoint DLP
• What is Browser Isolation?
• Remote Browser Isolation data sheet
McAfee MVISION Unified Cloud Edge Getting Started 3

Setting up McAfee WGCS
After logging on to MVISION Cloud and creating users and assigning web protection roles, you can complete all your setup tasks.
1. Log on to MVISION Cloud and access the web setup pages:

a. Activate McAfee WGCS
b. Create users and assign roles
2. To get started quickly, complete these steps:
a. Set up Client Proxy
b. Download the default certificate authority from here.
This step is recommended. It is also required for SAML authentication or to see error messages that occur during
authentication.
3. Configure authentication methods and add them to locations:
◦ SAML — Configure the SAML settings in MVISION Cloud
◦ IP range — Use source IP address ranges to authenticate web requests
◦ IPsec tunnels — Send web traffic to McAfee WGCS through an IPsec tunnel
◦ GRE tunnels — Send web traffic to McAfee WGCS through a GRE tunnel
4. Add log data residency information to locations:
◦ Add log data residency information to a location
◦ Configure log data residency and privacy settings
5. To set up McAfee Mobile Cloud Security in MVISION Cloud:
Secure the VPN tunnel to your mobile devices
Log on to MVISION Cloud for the first time

After you activate your MVISION Cloud account, you can log on for the first time and set up access to web setup and web policy.
After you sign up for an MVISION Cloud trial or buy or renew a subscription, McAfee sends a welcome email with the
subscription details, including the number of user licenses and the expiration date. If you are setting up an MVISION Cloud
account for the first time, McAfee sends a second welcome email with an Activate link.
If your account is already set up, you can open the MVISION Cloud UI by clicking this link: https://auth.ui.mcafee.com.
Task
1. In the welcome email, click Activate.
2. In the dialog box, specify a new password, then click Set Password.
3. Provide the email that you used when signing up, optionally select a language, then click Next.
4. Provide the password that you specified, then click Sign In.
5. Read the McAfee Cloud Services Agreement, select that you understand and agree, then click Agree.
Results
You are logged on to MVISION Cloud, where you can set up access to web setup and web policy by configuring web protection
users and roles.
Set up Client Proxy

You need to first set up the Client Proxy software on the Web Gateway Setup page.

This includes the configuration of tenant credentials, primary proxy server, proxy selection method (how a Client Proxy software
selects the active proxy server from the list) and create a Client Proxy policy with the default values. Make sure to download the
policy and deploy it to the endpoints. Once you successfully deploy Client Proxy on the endpoints, the administrators can
customize the Client Proxy policy on the Client Proxy Management page in the UI.
Task
1. On the MVISION Cloud navigation bar, click the settings icon.
2. From the drop-down list, select Infrastructure → Web Gateway Setup.
3. Click Get Started.
4. In Enter Tenant Authentication Credentials, click Configure.
a. In the New Shared Secret field, enter the new shared secret. The shared secret is the password that secures communication
between Client Proxy and McAfee WGCS.
b. In the Confirm New Shared Secret field, confirm the new shared secret.
c. Click Save.
5. In Define Proxy Server IP Addresses, click Configure.
a. From the Add Proxy drop-down list, enter proxy hostname or IP address of the proxy server, and listening port. Best practice
is to configure two proxy servers, using fully qualified domain names (FQDN) for the host names and specifying port 8080
for one proxy and 80 to the other proxy.
b. Click the + icon to configure another proxy server.
c. (Optional), From the Import CSV drop-down list, you can import the proxy server details from the .csv file.
d. (Optional), From the Export CSV drop-down list, you can download the configured proxy server list to the .csv file.
e. Click Save.
6. In Determine Proxy Selection Method, click Configure.
◦ First Available — Select this to connect to the first accessible proxy server from the list that you configure. This option is useful
when you prefer to select a specific server.
◦ Automatic Switch Over — Select this to automatically switch to the next available proxy server when the first accessible proxy
server is down. For example, if you have two proxy servers in the list and when the first server is down and second server
is reachable, Client Proxy automatically selects the second proxy server as the active proxy server to redirect the endpoint
traffic. In addition, when you select this option, Client Proxy checks for the availability of the first configured proxy server
periodically based on the interval set in the Polling Interval field. When the first configured proxy becomes available, Client
Proxy elects the first configured server as the active server to redirect the traffic. If this option is not selected, Client Proxy
does not check for the active server periodically. This option is available only when you select First Available.
◦ In Polling Interval (10 to 3600 seconds), specify the interval the Client Proxy software checks for the active server in the configured
proxy server list.
◦ Fastest Response Time — Select this to connect to the proxy server that has the fastest response time in the list that you
configure.
◦ Click Save.
7. In Name and Publish Policy, click Configure.
a. Provide a name for the policy.
b. Click Save Policy.
8. Click the yellow badge to publish the saved changes.
9. Click Download to download the Client Proxy policy file saved to an .opg file. Once Client Proxy software is installed on
endpoints, the Client Proxy clients need its first policy configuration to communicate to McAfee WGCS. Rename the .opg file to
MCPPolicy.opg and copy it to this location on the client computers.
◦ Windows-based computers — C:\ProgramData\McAfee\MCP\Policy\Temp
◦ macOS computers — /usr/local/mcafee/mcp/policy
The Client Proxy establishes trust and redirect traffic to McAfee WGCS using tenant Information and shared secret.
Note: Click the yellow badge to publish all your locally saved changes. When you complete the Client Proxy configuration, the
administrators can add proxy servers and customize the Client Proxy policy on the Client Proxy Management UI page.

MVISION Unified Cloud Edge overview
McAfee® MVISION Unified Cloud Edge is a cloud-native security platform that enables consistent threat and data protection
controls from device to cloud.
MVISION Unified Cloud Edge creates an efficient and consistent security management experience by bringing together multiple
McAfee products, components, and technologies on MVISION Cloud.
MVISION Unified Cloud Edge is available in two separate propositions.
MVISION Unified Cloud Edge Base, bring together three core technologies:
• Cloud access security broker (CASB) — The direct API and reverse proxy-based visibility and control for cloud services that
the MVISION Cloud product provides.
• Secure web gateway —
◦ The forward proxy-based visibility and control over web traffic provided by McAfee® Web Gateway Cloud Service
(McAfee® WGCS)
◦ The location awareness and traffic redirection features provided by McAfee® Client Proxy software installed on your
endpoints.
◦ The mobile device protection feature provided by McAfee® Mobile Cloud Security.
• Data protection — Unified enforcement of data protection policy across cloud and web using one console to manage
classifications, incidents, and reporting.
MVISION Unified Cloud Edge Advanced contains all features of the Base proposition, and also includes access to McAfee®
Data Loss Prevention Endpoint (McAfee DLP Endpoint) and MVISION Cloud for Sanctioned SaaS. For details of the McAfee DLP
Endpoint and MVISION Cloud SaaS capabilities, see the specific product documentation.
MVISION Unified Cloud Edge combines MVISION Cloud and McAfee WGCS technologies, working together to protect data from
device-to-cloud, and to prevent cloud-native breach attempts that are invisible to the corporate network. This creates a secure
environment for the adoption of cloud services and enablement of access to the cloud from any device.
With MVISION Unified Cloud Edge you can achieve:
• Consistent visibility and control over data from device-to-cloud.
• Unified access control and threat protection for the cloud and web.
• Cloud-native and direct to cloud architecture with enterprise scale and resilience, with service availability of 99.999%.
Secure web gateway

Use the MVISION Cloud user interface to set up how users in your organization authenticate and connect to McAfee WGCS.
McAfee WGCS protects your organization from security threats that arise when users in your organization access the web,
through in-depth content scanning an integration with other McAfee web security technologies. It:
• Scans and filters web traffic between your users and the cloud.
• Blocks traffic that is not allowed by the policies you configure.
• Protects users working inside or outside your network, for example users working in a coffee shop or hotel.
MVISION Unified Cloud Edge also brings together the management of McAfee® Client Proxy to redirect, block, or permit web
traffic according to web policy. Client Proxy helps protect users from security threats that arise when they access the web from
inside or outside your network. The client software, which is installed on endpoints running Microsoft Windows or macOS,
redirects web requests or allows them to continue to a proxy for filtering. Client Proxy allows or redirects web requests from
users based on policies that you configure.
McAfee Mobile Cloud Security redirects web traffic from mobile devices to McAfee WGCS to be filtered.
You can also configure authentication methods for multiple sites, with support for SD-WAN vendors using either dynamic IPsec
or GRE secure tunnels, and set up where web access data is stored and reported.
Web policy
Use MVISION Unified Cloud Edge to protect your organization from security threats that arise when users in your organization
access the web, by enforcing web policy, setting and applying rules to take action when certain conditions for web traffic are met.

Policy is enforced by rules, which are grouped into rule sets. These act on web traffic when a rule is applied, blocking, permitting
or skipping specific actions, such as uploads or downloads.
MVISION Unified Cloud Edge also uses the web features of McAfee WGCS to detect threats, including malware, spyware, viruses,
and ransomware.
Remote Browser Isolation protects users and secures the corporate network from potential threats by isolating browser sessions
in a remote virtual environment outside the network. Web sessions are rendered to users as images, video, or audio, and
nothing potentially malicious is returned to the end browser.
The McAfee controlled algorithm determines whether a website should be isolated, in line with your own existing policies.
MVISION Unified Cloud Edge also allows you to control how isolation works based on your own criteria, with Full Isolation
capabilities.
Remote browser isolation is controlled by web policy rules.
Use MVISION Unified Cloud Edge to protect against data loss from the cloud by classifying sensitive data and applying those
classifications to policies that trigger actions and generate incidents when sensitive data is identified, enforcing consistent
behavior.
Manage and edit these classifications in a single location, and apply them to both cloud and web data protection policies. These
classifications define sensitive data using classification criteria including keywords, file size, types or extensions, among others.
When a user tries to download, share, or upload sensitive files or data that meet one or more of these criteria, the classification
is triggered and the policy defines the appropriate action to prevent a data breach, and generates an incident. Details of these
incidents, including their severity and information about where and how they were generated, are viewed and managed in the
MVISION Cloud UI.
MVISION Unified Cloud Edge key features

MVISION Unified Cloud Edge provides a single solution that enables you to apply a single, consistent web security and threat
protection policy on devices and in the cloud.
The MVISION Unified Cloud Edge solution allows you to control access to cloud services, protect against web threats and insider
threats from them, and enforce web policies, from a single cloud-native user interface.
• Centralized policy definition — Protect against threats and data loss by creating web policy within the MVISION Cloud
console, synchronizing web policy across devices, networks, and the cloud and allowing you to enforce it consistently.
• Unified classification management — Edit and manage classifications from a single console, and apply to either cloud or
web policies.
• Control access to all cloud applications — One console to manage and deliver cloud application control, tenant restrictions
and zero-day malware protection.
• Acceptable use policy enforcement with advanced malware protection — Application Control blocks uploads to high risk
apps or personal accounts, and malware scanning for apps.
• Cloud data and permission controls — Gain visibility and control over sanctioned cloud services using either API integrations
and reverse proxy, and unsanctioned services using forward-proxy. Control access from a single console.
• Manage Client Proxy from MVISION Unified Cloud Edge — Use MVISION Unified Cloud Edge to set up and configure Client
Proxy, to redirect traffic through McAfee WGCS for filtering.
• Route web traffic securely and efficiently — SD-WAN partners secure web traffic from remote sites or branch offices using
IPsec or GRE protocols, allowing it to be routed directly to McAfee WGCS where it is filtered according to web policy.
• Threat protection — Detect and respond to threats with MVISION Cloud’s threat protection user interface, supported by
activity monitoring, user-behavior, geo-location, and privileged user analytics.
• Support for McAfee Mobile Cloud Security — Manage McAfee Mobile Cloud Security through MVISION Unified Cloud Edge to
redirect HTTP/HTTPS traffic from mobile devices to McAfee WGCS for filtering.
• Centralized incident management — View and manage incidents generated by web and cloud policies in a single location in
the UI.
• Remote Browser Isolation — Ensure safe access for users to potentially malicious content by isolating browsing on a remote
server, controlled by Web Policy rules.
Secure web gateway key features

• SAML, IP address range, IPsec and GRE authentication methods — Authenticate users requesting cloud access.

• Secure Channel — Establish a secure communication channel between Client Proxy and McAfee WGCS for all HTTP/HTTPS
requests. This is applicable only for cloud proxies.
• Reporting — Provides productivity, web activity, web policy enforcement, and web security overview reports.
• Traffic redirection — The software redirects web traffic to proxy servers for filtering according to the settings in the Client
Proxy policy.
• Location-awareness — Location-awareness settings allow one policy to cover users working inside the network, outside the
network, or connected to the network by VPN.
• Transparent authentication — Client Proxy authenticates users without prompting for credentials and passes group
membership and other information in metadata that it adds to HTTP/HTTPS requests.
• Tamper resistance — Users are not allowed to remove Client Proxy software from the endpoint or bypass the Client Proxy
policy without requesting and receiving a temporary release code from an administrator.
• Added context — Adds context such as process name, host name, operating system type, operating system version, system
name to a request, which is used for filtering traffic.
• Administrator controlled temporary bypass — Administrators can temporarily disable Client Proxy for specified duration
and it gets re-enabled automatically. Users are not allowed to independently disable or bypass Client Proxy.
• Application agnostic — Redirect, authenticate, and add context to web traffic from any application regardless of whether or
not the application is proxy aware.
Web policy key features

• Default policy in place — Protect against full range of web threats immediately after setup with best-practice settings. These
include global block and bypass lists, HTTPS scanning, web filtering, content inspection, application control, and threat
protection.
• URL filtering — Uses allow lists, block lists, and reputation categories based on risk levels determined by McAfee® Global
Threat Intelligence™ (McAfee GTI). McAfee GTI evaluates website reputation based on past behavior and assigns websites to
categories of high, medium, low, and unverified risk. It collects, analyzes, and distributes data in real time from sensors in more
than 120 countries. Simplify policy rules by assigning similar websites, web applications and file types to groups.
◦
Web content filtering using the Web Category Filter — Assigns websites to categories based on content. This filter
allows or blocks access to specified content, such as blocking access to gambling sites.
◦ Web application filtering using Application Control — Assigns web applications to categories by type. This filter allows
or blocks access to web applications individually or by category. For example, it can block file uploads to file-sharing
applications in the cloud.
◦ Media type filtering using the Media Type Filter — Categorizes files by document type or audio or video format. This
filter allows or blocks access to specified media types, such as blocking access to streaming media.
• HTTPS scanning — Includes full decryption and content inspection.
• Web filtering — Simplifies policy rules by assigning similar websites, web applications, and file types to groups.
◦
Web content filtering using the Web Category Filter — Assigns websites to categories based on content. This filter
allows or blocks access to specified content, such as blocking access to gambling sites.
◦ Web application filtering using Application Control — Assigns web applications to categories by type. This filter allows
or blocks access to web applications individually or by category. For example, it can block file uploads to file-sharing
applications in the cloud.
◦ Media type filtering using the Media Type Filter — Categorizes files by document type or audio or video format. This
filter allows or blocks access to specified media types, such as blocking access to streaming media.
• Remote Browser Isolation —
◦ Risky Web isolation — Automatically isolate a user's browsing when a website is considered a potential risk.
◦ Full Isolation — Enable browser isolation by default for web access based on your own selected criteria. Control
exceptions, such as applying or exempting access from isolation by domains, IP addresses or URL categories,
allowing or blocking uploads and downloads, copying and pasting, and blocking cookie storage. Full Isolation is
available as part of MVISION Unified Cloud Edge with an additional license.
• Flexibility to adapt and fine-tune — Modify web policy rules to suit different environments and meet individual
requirements.
• Modular structure for ease of use — Rules for different fields of web security bundled in rule sets to ensure user-friendly
handling.
• Scope limits configurable — Enforce tailored web policies on regions, IP address ranges, and user groups.

• Extend coverage with rule set library — Import more rule sets created by web security experts from library to extend
protection and cover new threats.
• Code accessible — Permissions allow administrator to implement advanced web policy design through code access.
• Antimalware filtering — Blocks malware in-line using traditional antivirus and behavior emulation technology. The Gateway
Anti-Malware Engine filters web traffic, detecting and blocking zero-day malware in-line using emulation technology before user
devices become infected.
• Allow access to websites with coaching — Allow access to blocked websites for specific users with a business reason to visit.
• McAfee Share pre-defined classifications across web and cloud — Use the same set of pre-defined classifications across
cloud and web policies.
• Policy WIzard — Use the Wizard to create complex data protection policies quickly and easily, to prevent data leaking out.
How MVISION Unified Cloud Edge works

MVISION Unified Cloud Edge brings together MVISION Cloud and McAfee Web Gateway Cloud Service together on a single
platform to keep data and your corporate network safe.
MVISION Unified Cloud Edge uses a variety of technologies to manage and control the flow of traffic and access requests
between your locations, network and the cloud, including proxies, filtering and secure tunnels, as shown in the graphic below.
The MVISION Unified Cloud Edge platform uses McAfee WGCS to provide control and policy enforcement over web traffic and
Shadow cloud services — those not approved for corporate use by IT departments — via forward proxy. Client Proxy is installed
on endpoints. The client software is location-aware, and detects whether users are working inside or outside the network. When
users are outside the network, it directs their traffic to McAfee WGCS for filtering. To manage Client Proxy you can configure the
redirection policy, including bypass lists, in the MVISION Cloud user interface. Policy changes are stored in the Global Policy Store
in the cloud. McAfee WGCS accesses the GPS when requested by the Client Proxy, which then allows it to permit or block the
request based on the rule set in the policy. When the Client Proxy software redirects HTTP/HTTPS traffic, it adds metadata to the
requests. McAfee WGCS uses the metadata (for example, group membership) when applying web protection policies. When the
Secure Channel option is enabled in Client Proxy, the cloud proxy server certificate is validated against the device certificate
store, establishing a secure connection. Traffic can also be blocked if the validation fails.
MVISION Cloud also uses secure tunnels to secure communication between remote sites, routing traffic through McAfee WGCS,
where it is filtered according to web policy, without first going through the home network. Secure tunnels can be established
using either a dynamic IPsec or GRE protocol. McAfee WGCS uses SAML to authenticate requests received from the remote site
through the secure tunnel.
Traffic from mobile users can be directed through MVISION Unified Cloud Edge using McAfee Mobile Cloud Security. When
McAfee Mobile Cloud Security has been set up on the device, HTTP/HTTPS traffic is redirected to McAfee WGCS for filtering
through a VPN gateway. This is configured through the MVISION Cloud user interface.

McAfee WGCS also analyses the nature and intent of all content and active code entering the network via webpages to protect
against malware, hidden code, or control applications.
When Risky Web isolation is enabled, if the McAfee algorithm is not confident the session should be allowed or blocked based on
existing web policy, the session will be isolated on a remote server. When the remote browser is activated, the content is passed
through the Secure Web Gateway so traffic has consistent policies and data loss prevention across isolated and non-isolated
sessions. The content is then sent back to the isolated server and returned to the user's browser as an image, video or audio
stream. Under Full Isolation, browsing is isolated in this way by default, unless you have enabled exemptions under Web Policy.
Direct API traffic is managed by the CASB, relying on streaming activity feeds from the cloud service provider and enforcing
security by making API calls back into the service.
MVISION Unified Cloud Edge uses a reverse proxy to connect to those applications that don’t have a direct API, and routes traffic
from the cloud service to the CASB proxy to protect your organization’s sensitive information when it moves in and out of the
cloud. Reverse proxy is inserted into the traffic flow by modifying the SAML endpoint in the cloud application’s entry in the
customer’s identity provider. When traffic is directed through the reverse proxy, it can perform functions such as conditional
access control, DLP, and activity monitoring.
Classifications created in the unified classification editor can be applied to both your Sanctioned and Web/Shadow data
protection policies. You can also configure MVISION Cloud to use McAfee DLP Endpoint classifications you have created in
McAfee ePO, allowing you to select different classification rules for different cloud services. When a rule is triggered and a policy
takes action, and incident is generated and displayed in MVISION Cloud Policy Incidents.

How web components, technologies, and policy work together
Secure Web Gateway consists of the web components that connect users and the technologies that connect sites to McAfee
WGCS, where web traffic is filtered according to the policy you configure.
The web components include:
• Client Proxy installed on laptops — Connects users working on laptops to McAfee WGCS.
• McAfee Mobile Cloud Security solution configured on mobile devices — Connects users working on mobile devices to McAfee
WGCS.
These technologies connect local or remote sites to McAfee WGCS:
• IPsec tunnels
• GRE tunnels
Secure Web Gateway

All setup and configuration are done from the MVISION Cloud management platform.
1. The web administrator sets up the web components and configures the web policy in the MVISION Cloud UI.
2. The administrator manages Client Proxy policies and selects the active policy. Client Proxy redirects the users' web requests to
McAfee WGCS for filtering according to the location awareness and traffic redirection settings in the active policy.
3. After the administrator sets up the McAfee Mobile Cloud Security solution, software on the mobile devices redirects users'
web requests to McAfee WGCS for filtering.
4. The administrator configures the rules that make up the web policy. McAfee WGCS filters all web requests according to the
configured rules, blocking bad web traffic while allowing good traffic to continue to the internet.
5. The administrator configures an IPsec or GRE tunnel from an office location or remote site to McAfee WGCS. The cloud service
receives web requests through the configured tunnel and filters them according to the web policy.

Roles needed for web setup and policy management
The MVISION Cloud administrator creates users and assigns them web protection roles, so that they can access the web setup
and policy configuration areas of the UI.
For information about user roles allowing access to other areas, see About user roles and access levels.
MVISION Cloud users

MVISION Cloud supports these types of users:
• McAfee Cloud Account Administrator — This administrator can create MVISION Cloud users.
• MVISION Cloud User — These users can log on to MVISION Cloud.
Access control
The administrator assigns roles to users. The type of role assignment determines the type of access the user has in the assigned
role:
• Read Only — Users have read-only permission.
• Manage — Users have read and write permissions.
Roles for web protection users

Each role allows read-only or read and write access to different setup or configuration areas in the MVISION Cloud UI.
Role Users with manage permissions can...
Administrator → Setup & Configuration Access Web Gateway Setup as follows and complete the setup
tasks:
Settings → Infrastructure → Web Gateway Setup
Policy Management → Feature Configuration Access Feature Configuration in the Web Policy UI and configure the
features.
Policy Management → List Catalog Access the List Catalog in the Web Policy UI and configure the lists.
Policy Management → Web Policy Access and configure these areas of the Web Policy UI:
• Policy tree — Configure policy rules here.
• Block Page Templates — Customize block pages here.
Policy Management → Web Policy Code Open the Advanced view of the rules in the Web Policy UI and
configure the rules in code view.
Usage Analytics Users Access and configure the web protection dashboard and
analytics, as follows:
• Dashboards → Web Dashboard
• Analytics → Web Traffic
• Analytics → Web Malware
Applying web changes globally

To apply locally saved web setup or policy changes globally, you must publish them to the cloud, where they are saved in the
Global Policy Store.
As you set up McAfee WGCS or configure the web policy, the changes you make are saved locally to a database. While rule set
changes are saved automatically, you manually save changes you make to the setup, the lists, and the feature configuration
settings.

The yellow badge on the publish shield on the MVISION Cloud navigation bar indicates that you have locally saved changes to
publish. Clicking the shield opens these options:
• Publish — Publish locally saved changes to the cloud.
• Discard Changes — Discard locally saved changes.
• Keep working — Return to work and publish later.
Publishing is a web protection function. The publish shield is only visible from the Web Gateway Setup and Web Policy pages in the
MVISION Cloud UI.
Your customer-specific proxy and customer ID

You need your customer-specific proxy name when you configure a Client Proxy policy, web browser, or operating system to
direct web traffic to McAfee WGCS for filtering.
The customer-specific proxy is the domain name of your McAfee WGCS instance and formatted as c<customer_id>.wgcs.mcafee-
cloud.com, where:
• c — precedes the customer ID
• <customer_id> — consists of 10 digits
• wgcs.mcafee-cloud.com — is the name of the McAfee WGCS proxy service.
To configure McAfee WGCS as the proxy server, specify the customer-specific proxy name and port number 80 or 8080.
Example: c1234567890.wgcs.mcafee-cloud.com:8080
Customer ID
Your customer ID:
• Uniquely identifies you in the system.
• Allows Client Proxy, McAfee WGCS, and other web protection components to connect, synchronize, and communicate securely.
Client Proxy metadata

When the Client Proxy software redirects HTTP/HTTPS traffic, it adds metadata to the requests.
Other products, such as Web Gateway and McAfee WGCS, use the metadata (for example, group membership) when applying
web protection policies.
• Authentication tokens — Tokens containing identity information about the user making the web request
• Authentication version — Version of the metadata that Client Proxy is sharing
• Client IP address — IP address of the endpoint where the traffic originated
• Original destination IP address — Saved IP address of the server where the traffic is destined
• Customer ID — Uniquely identifies the customer's organization
• User ID — Uniquely identifies the user making the web request

• User groups — Names of any groups where the user is a member
• Process name — Name of the process that generated the traffic being redirected
• Tenant ID — Unique GUID for a customer
• System info — System information such as MAC address, host name, process uptime, operating system name, and operating
system version
Secure the communication channel between Client Proxy and

McAfee WGCS
You can enable the Secure Channel option to establish a secure communication channel between Client Proxy and McAfee WGCS
for all HTTP/HTTPS requests. When you enable this option, the software validates the cloud proxy certificate against the device
certificate store and establishes a secure connection.
Note: When you enable Secure Channel, Client Proxy uses the 8081 port to check captive portals and cloud proxy connections.
But, you continue to configure the 8080 port and proxy server hostname when adding a cloud proxy server.
Adding mobile devices to your protected endpoints

The McAfee® Mobile Cloud Security solution allows you to add mobile devices to the endpoints that are protected by McAfee
WGCS.
The mobile cloud security solution requires configuration in these interfaces:
1. MVISION Cloud UI — Upload the CA certificate used by the Mobile Device Management (MDM) server software to sign the
device certificates.
2. Administrator interface of your MDM solution — Configure an identity certificate profile for the device and a VPN profile.
Note: You must upload the CA certificate before configuring the MDM solution.
Supported operating system platforms and MDM solutions

McAfee Mobile Cloud Security supports these operating system platforms and MDM solutions. MDM software consists of client
software that is installed on the mobile devices and server software that administrators configure to manage the devices.
Supported platforms Supported MDM solutions
Android • AirWatch
• Microsoft Intune
• MobileIron
iOS • AirWatch
• Microsoft Intune
• MobileIron
Configuring the MDM software

You can use the AirWatch, Microsoft Intune, or MobileIron MDM solution to manage your users' Android or iOS devices. For
configuration details, see these McAfee Community articles:
• Configuring the AirWatch MDM solution for Android devices
• Configuring the AirWatch MDM solution for iOS devices
• Configuring the Microsoft Intune MDM solution for Android devices
• Configuring the Microsoft Intune MDM solution for iOS devices
• Configuring the MobileIron MDM solution for Android devices

• Configuring the MobileIron MDM solution for iOS devices
Components needed to protect your mobile devices

The mobile cloud security solution consists of McAfee and customer-provided components.
McAfee components
• MVISION Cloud — Provides the user interface where administrators configure the mobile cloud security solution.
• VPN Gateway — Separates the mobile cloud security infrastructure from McAfee WGCS and the internet. The VPN Gateway
runs inline with McAfee WGCS.
• McAfee WGCS — Filters HTTP/HTTPS traffic for your organization's mobile devices according to the policy you configure.
Customer-provided components
• MDM solution — The Mobile Device Management server and client software
• Mobile devices — Android or iOS endpoints with MDM client software installed
How the mobile cloud security solution protects devices

After you set up the mobile cloud security solution, software on the mobile device redirects HTTP/HTTPS traffic to McAfee WGCS
for filtering.
Open the MVISION Cloud UI.
1. In the UI, the administrator configures the mobile cloud security solution by:
a. Uploading the customer CA certificate, whose private key is used to sign the device certificates
b. Specifying the names of the fields that identify the user name and user group in the device certificates
Note: You must upload the CA certificate before configuring the MDM solution.
2. In the administrator interface of the MDM solution, the administrator:
a. Configures an identity certificate profile for the device.
b. Configures the VPN profile which references the identity certificate profile.
3. When the user logs on to the device and registers it with the MDM server, the software:
a. Signs the identity or device certificate with the CA certificate.
b. Downloads the signed certificate and VPN profile to the device.
4. After the following steps are completed, the software on the device starts redirecting HTTP/HTTPS traffic to McAfee WGCS
through the VPN gateway.
a. The device uses the signed certificate to authenticate to the VPN gateway.
b. The VPN gateway creates a secure VPN tunnel with the device.
5. McAfee WGCS filters the HTTP/HTTPS traffic, allowing or blocking web requests according to your policy.

Setting up a trust relationship between McAfee WGCS and your
endpoints
McAfee WGCS uses certificates to set up a trust relationship with your endpoints, allowing the cloud service to scan HTTPS traffic
between your endpoints and the cloud.
Certificate authorities
McAfee provides these certificate authorities:
• Default certificate authority — We recommend that you download the default CA from the Web Gateway Setup page and deploy
it to the endpoints in your organization. You need this CA to use SAML authentication or see error messages that occur before
you are authenticated.
• Customer certificate authority — When you log on for the first time, McAfee WGCS generates a custom CA for your
organization. You can download and deploy this CA to your endpoints, but for the best protection, we recommend that you
replace the custom CA with your own CA in the UI.
Managing your customer CA

You can manage your customer CA on the HTTPS Connection feature configuration page, which provides these options. Whatever
option you choose, the CA configured in the UI must also be deployed on your endpoints.
• Generate — Replaces the customer CA provided by McAfee with the self-signed CA that you generate.
• Import — Replaces the customer CA provided by McAfee with the CA that you import.
• Export — Exports the customer CA.
HTTPS Scanning rule sets

The HTTPS Scanning rule sets are processed in order. The first rule set allows configured web requests to bypass HTTPS scanning
and go directly to the internet. The second rule set specifies the rules used to verify certificates and allows some traffic to skip
certificate verification. The third rule set allows configured web requests to skip decryption and content inspection and continue
to the next rule set.
1. HTTPS Connection Options — This rule set allows web requests sent to the configured domains, hosts, WebEx servers, or
Citrix servers to bypass HTTPS scanning and go directly to the internet.
Related features: HTTPS Connection, Certificate Verification Options

2. Certificate Verification — This rule set allows you to configure which rules are applied during the certificate verification
process and which web requests can skip the rules and continue to HTTPS decryption.
Related feature: Certificate Verification
3. HTTPS Decryption — This rule set allows web requests sent to the configured domains, hosts, or URL categories to skip
HTTPS decryption and content inspection and continue to the next rule set.
Related feature: HTTPS Decryption
Benefits of SAML authentication

The SAML 2.0 protocol supports any identity provider and authentication method, allowing you to use your own identity service
with McAfee WGCS.
The SAML specification defines these roles:
• Identity provider — Authenticates the user and provides SAML assertions affirming the user's identity. The identity provider is
any identity service that your organization specifies.
• Service provider — Decides whether to provide the service requested by the user based on the identity information received
from the identity provider. The user is requesting access to a web resource. As the service provider, McAfee WGCS forwards the
user's request to the cloud with the identity information or blocks the request.
The identity provider and service provider communicate using a request-response protocol:
• SAML request — The service provider sends a request for authentication to the identity provider.
• SAML response — The identity provider sends the service provider a response with one or more SAML assertions.
Benefits of SAML authentication

SAML authentication supports any identity provider and authentication method and eliminates passwords from the exchange of
information between the SAML parties. SAML:
• Supports any identity provider and authentication method, as long as the authentication request, response, and result are
exchanged using the SAML 2.0 protocol.
• Eliminates passwords from the exchange of information between the SAML parties. McAfee WGCS does not require a password
from the user. Instead, the identity provider shares all authentication and identity information in the form of SAML assertions.
SAML authentication alone or with location information

You can configure SAML authentication alone or add a SAML configuration to a location that has IP range, IPsec, or GRE mapping
configured. McAfee WGCS uses SAML to authenticate requests received from the IP address ranges or through the IPsec or GRE
tunnel configured for the location.
McAfee WGCS supports multiple named SAML configurations with or without the location information provided by IP range,
IPsec, or GRE mapping.
SAML alone versus SAML with location information

There are some differences between SAML authentication alone and SAML combined with IP range, IPsec, or GRE mapping.
Difference SAML alone SAML with location information
Location information No location information is provided. Location information is provided by IP

range, IPsec, or GRE mapping.
Proxy port Web requests are sent to dedicated Web requests are sent to HTTP/HTTPS
SAML port 8084. ports 80 and 443.

Difference SAML alone SAML with location information
Logon requirement Users are prompted to log on using an No logon is needed.

email address.
SAML authentication steps

SAML authentication alone and SAML with IP range, IPsec, or GRE mapping share most authentication steps. Only the initial steps
are different.
SAML alone SAML with location information
1) McAfee WGCS receives a web request on port 8084. 1) McAfee WGCS receives a web request on port 80 or 8080.
2) McAfee WGCS prompts the user for an email address and 2) McAfee WGCS identifies the customer based on the
uses the domain to identify the customer. configured IP ranges or IPsec or GRE source.
Shared SAML authentication steps
3) McAfee WGCS looks up the customer's identity provider service.
4) McAfee WGCS sends a SAML request to the identity provider.
5) The identity provider authenticates the user and sends the user name and group information in a SAML response to
McAfee WGCS.
6) McAfee WGCS applies the customer's web policy to the user's web request.
Configuring SAML parties to work together

SAML authentication requires configuration in your identity provider, on the endpoints in your organization, and in the MVISION
Cloud UI.
Configuration in your identity provider

For SAML authentication with McAfee WGCS, configure your identity provider to use this URL:
https://saml.wgcs.mcafee-cloud.com/saml
Because the cloud service consumes SAML assertions sent by the identity provider, this setting is known as the Assertion
Consumer Service (ACS) URL.
Configuration on the endpoints

Deploy the default CA provided by McAfee to the endpoints.
For SAML authentication without IP range, IPsec, or GRE mapping, configure the browsers on the endpoints to send web
requests to port 8084, as follows:
c<customer_id>.wgcs.mcafee-cloud.com:8084
Configuration in MVISION Cloud

Configuring SAML authentication for McAfee WGCS in the MVISION Cloud UI includes these overall tasks:
1. Configure the SAML authentication settings during setup.

2. (Optional) Add a SAML configuration to a location with IP range, IPsec, or GRE mapping configured.
Permissions
You need Administrator → Setup & Configuration permissions to access the Web Gateway Setup UI and configure SAML authentication.

Location feature
The location feature allows you to configure different authentication methods for different locations. A location can consist of
one or more sites in a region or multiple sites across regions.
When configuring a location, you can:
• Map a list of IP address ranges to the location
• Map an IPsec tunnel to the location
• Map a GRE tunnel to the location
• Configure more than one type of mapping for the location
• Add SAML authentication to the location
• Configure log data residency for the location
At least one IP range, IPsec, or GRE mapping is needed to save the location.
SAML authentication and location

SAML authentication is configured for a list of domains. Each configuration is named and saved. You can select and add one
SAML configuration to a location. SAML authentication is applied to the web requests received from the IP address ranges or
through the IPsec or GRE tunnels configured for the location.
Log data residency and location

You can specify a storage and reporting region for web access data collected when traffic originates from the IP address ranges
or through the IPsec or GRE tunnels configured for the location. The location-specific log data residency setting overrides the
global log data residency settings that you configure.
Permissions
You need Administrator → Setup & Configuration permissions to access the Web Gateway Setup UI and configure your locations.
How IP addresses are configured using CIDR notation

Use Classless Inter-Domain Routing (CIDR) notation when configuring IP addresses for IP range, IPsec, or GRE authentication and
for web policies.
CIDR notation specifies:
• A routing prefix to a network
• An IP address or range on the specified network
CIDR syntax consists of an IPv4 or IPv6 address followed by a forward slash and a decimal number. The decimal number specifies
the number of bits in the network prefix.
IPv4 network prefixes are allowed to range in size from 8 bits to 32 bits. A 24-bit IPv4 network prefix consists of 256 addresses.
IPv6 network prefixes are allowed to range in size from 8 bits to 128 bits. A 120-bit IPv6 network prefix consists of 256 addresses.
Protocol Network prefix (bits) CIDR notation (example) Specified IP address range
IPv4 8–32 127.0.0.0/24 From 127.0.0.0 to 127.0.0.255
IPv6 8–128 2001:db8:1234:0:0:0:0:ff00/120 From

2001:db8:1234:0:0:0:0:ff00
to 2001:db8:1234:0:0:0:0:ffff

Connecting locations or sites directly to the cloud
You can connect any location or site to McAfee WGCS by setting up a tunnel from a networking device or SD-WAN service to the
cloud service.
If you are using a Software-Defined Wide Area Network (SD-WAN) to connect your sites, you can redirect web traffic to McAfee
WGCS, where it is filtered according to your organization's web policy. SD-WAN combines traditional WAN technologies, such as
MPLS and broadband connections, by abstracting them from hardware. An SD-WAN solution enhances connectivity between
sites and provides enhanced management and monitoring of network traffic.
IPsec versus GRE tunneling protocols

Traffic is routed from your location or site to McAfee WGCS through a tunnel using one of these protocols:
• Internet Protocol Security (IPsec) — IPsec is a secure network protocol suite that authenticates and encrypts packets of data,
securing communications between computers over an Internet Protocol network. Unlike GRE, IPsec can only tunnel IP packets.
• Generic Routing Encapsulation (GRE) — GRE is a tunneling protocol that can encapsulate a wide variety of network layer
protocols inside virtual point-to-point or point-to-multipoint connections over an Internet Protocol network. GRE does not
provide the authentication and encryption security features that IPsec provides.
Configuration needed
To build an IPsec or GRE tunnel, you must configure:
• IPsec or GRE tunnel mapping in the MVISION Cloud UI
• IPsec or GRE tunnel interfaces on your networking device or in your SD-WAN service
SD-WAN solutions
You can build tunnels from any standard SD-WAN solution to McAfee WGCS. The following SD-WAN solutions have been tested
and validated with McAfee WGCS.
• Cisco
• Citrix
• Fortinet
• Silverpeak
• Versa
• VMware
Routing traffic to the best available points of presence

Find the IP addresses of the best and second best available points of presence and use them when configuring the primary and
secondary IPsec or GRE tunnels.
McAfee WGCS is delivered from the McAfee cloud services platform, which consists of globally distributed nodes called points of
presence (PoP). The Global Routing Manager (GRM) is a DNS service that is responsible for intelligent traffic routing, load sharing,
and failover. The GRM routes traffic to the best available point of presence.
To view a global map of the points of presence and see status, setup, and support information, visit https://trust.mcafee.com/
web.
Finding the best available points of presence

You can find the points of presence closest to your location by using the nslookup tool to query the Global Routing Manager
(GRM). GRM returns the IP addresses of the best available points of presence based on your location. You need these addresses
when configuring IPsec or GRE tunnel interfaces on your networking device or in your SD-WAN service.
To find the IP addresses of the best and second best available points of presence, run the nslookup command-line tool from your
network, as shown.
• IPsec example
nslookup 1.network.c<customer_id>.wgcs.mcafee-cloud.com nslookup 2.network.c<customer_id>.wgcs.mcafee-
cloud.com

• GRE example
nslookup 1.c<customer_id>.gre.mcafee-cloud.com nslookup 2.c<customer_id>.gre.mcafee-cloud.com
What to consider before configuring IPsec

Before configuring IPsec tunnels from a location or site to McAfee WGCS, review these considerations.
• Routing only HTTP and HTTPS traffic — Configure the networking device or SD-WAN service to route only HTTP and HTTPS
traffic through the IPsec tunnel. McAfee WGCS only handles IPsec traffic directed to ports 80 and 443 and drops any other
traffic that it receives through the tunnel.
• Configuring two IPsec tunnels per location — Best practice is to configure primary and secondary IPsec tunnels. The primary
tunnel is connected to the best available point of presence, while the secondary tunnel is connected to the second best point of
presence. This practice ensures continuous IPsec support in case one point of presence is not available.
• Configuring IPsec tunnels for multiple locations — If you are connecting more than one location, you can protect traffic and
improve network latency by creating IPsec tunnels from each location to McAfee WGCS.
• Adding SAML authentication — You can add a SAML configuration to a location configured with IPsec mapping. McAfee
WGCS uses SAML to authenticate requests received through the IPsec tunnel.
IPsec tunnel settings for your network device or SD-WAN service

You need these IKE and IPsec values when configuring the primary and secondary IPsec tunnels on your networking device or in
your SD-WAN service.
You enter the IP address of the best and second best available points of presence (PoPs) when you configure the primary and
secondary IPsec tunnels, respectively.
Internet Key Exchange (IKE) settings
Supported values (recommended values are shown in

IKE setting bold)
IKE version 1 or 2
Remote Gateway IP address of the best or second best available PoP
Lifetime 28800 seconds (8 hours)
Authentication • Method — Mutual pre-shared key (PSK)

• Identifier — The client ID that you configured for IPsec in
MVISION Cloud
• Peer identifier — vpn.wgcs.mcafee-cloud.com (FQDN that
identifies McAfee WGCS)
• Pre-shared key — The key that you configured for IPsec in
MVISION Cloud
Encryption • Encryption algorithm — AES-128 bits, AES-192 bits, or

AES-256 bits
• Hashing algorithm — SHA-1, SHA-256, SHA-384, or SHA-512
• Diffie-Hellman (DH) Group — Select a group:
◦ 2 (1024-bit key)
◦ 5 (1536-bit key)
◦ 14 (2048-bit key)
◦ 16 (4096-bit key)

Internet Protocol Security (IPsec) settings
Supported values (recommended values are shown in

IPsec setting bold)
Local network Your local subnet
Remote network 0.0.0.0/0 (Ports 80 and 443)
Perfect Forward Secrecy (PFS) Enabled
Lifetime 28800 seconds (8 hours)
Security association (SA) • Protocol — ESP

• Encryption algorithm — AES-128 bits, AES-192 bits, or
AES-256 bits
• Hashing algorithm — SHA-1, SHA-256, SHA-384, or SHA-512
• Diffie-Hellman (DH) PFS Group — Select a group:
◦ 2 (1024-bit key)
◦ 5 (1536-bit key)
◦ 14 (2048-bit key)
◦ 16 (4096-bit key)
How GRE tunnels are allocated

You can send web traffic from any site or location to McAfee WGCS for filtering through a GRE tunnel.
To build GRE tunnels, you must configure:
1. GRE tunnel mapping in the MVISION Cloud UI

2. GRE tunnel interfaces on your networking device or in your SD-WAN service
GRE tunnel mapping

After you provide an external IP address, McAfee allocates two GRE tunnels on your internal network and provides the IP
addresses needed to configure the GRE tunnel interfaces on your end.
McAfee allocates two GRE tunnels for redundancy:
• Primary GRE tunnel — Connects your network to the best point of presence in the cloud.
• Secondary GRE tunnel — Connects your network to the second best point of presence in the cloud when the first point of
presence isn't available.
View the allocated tunnels

After you save and publish the GRE tunnel mapping in the MVISION Cloud UI, you can view the allocated tunnels.
Note: You can edit the external source IP address. After editing it, make sure to save and publish.
Copy and save the IP addresses

You need these IP addresses to configure the GRE tunnel interfaces on your network device or in your SD-WAN service.

• GRE External Source IP — The public IP address that you provide (E1)
• McAfee PoPs — The domain names that you need to look up the public IP addresses of the primary and secondary points of
presence based on the location of your network (E2 and E3)
• Internal Source IP — The source IP addresses that McAfee allocated on your network, one for each GRE tunnel (G1 and G3)
• Internal Destination IP — The destination IP addresses on the McAfee networks, one for each GRE tunnel (G2 and G4)
Where your web access data is stored and reported

You can use the log data residency settings to meet your organization or region's data residency requirements.
Log data residency

To comply with your organization or region's data residency requirements, you can configure the geographic regions where your
web access data is stored and used for reporting. The following terms are used to describe geographic regions in a data
residency context:
• Connection region — Geographic region where your organization connects to one or more points of presence or where
McAfee WGCS filters web requests. You might have connections to points of presence in multiple geographic regions. The
connection regions are:
◦ Asia Pacific
◦ Europe
◦ North America
◦ Latin America
◦ Africa
• Storage and reporting region — Geographic region where the web access data is stored and used for reporting. You can
configure one storage region for each connection region. The storage regions are:
◦ Europe
◦ North America
The data residency settings apply to McAfee WGCS logs, but not to the following:
• Internal operational logs that McAfee maintains for security and legal compliance
• Data that Technical Support accesses for troubleshooting purposes
• Integrations that you configure with other products

Permissions
You need Administrator → Setup & Configuration permissions to access the Web Gateway Setup UI and configure the log data residency
settings.
Hiding sensitive information in logs and in the UI

By default, data is logged and displayed in plain text. You can protect sensitive information by concealing some fields. A hash
function is applied to the data in these fields. The hash value is logged and displayed in the UI.
Log data privacy

Fields whose data can be protected include:
• Block Reason — Explanation for why a web request was blocked
• Client IP (External) — Public IP address of your organization's network
• Client IP (Internal) — IP address of the endpoint
This value is provided by Client Proxy, IPsec, or GRE authentication, configured singly or together. Otherwise, the internal and
external client IP addresses have the same value.
• Last Rule — Name of the last rule applied before the information is logged
• Location — Any location name configured for the web policy
• URL Path — The part of the requested URL that follows the host name
• User Agent — Identity of the web browser passed in an HTTP user-agent header
• User Name — Name of the user making the web request or the IP address of the endpoint
• Process Name — Name of the process that generated the web request
Permissions
You need Administrator → Setup & Configuration permissions to access the Web Gateway Setup UI and configure the privacy settings.
Web Dashboard
Web Dashboard provides the summary of web malware and web traffic activities. By default, it displays the data for last 7 days.
The dashboard provides easy and quick access to top web requests and trends.
Default Web Dashboard cards

• Top Blocked Web Malware — Displays the malware name and the corresponding number of requests that were blocked in the last 7
days.
• Web Usage Trend — Displays the number of requests in the last 7 days.
• Top Web Applications — Displays the number of requests grouped by applications in the last 7 days.
• Top Web Application Categories — Displays the number of requests grouped by application categories in the last 7 days.
• Top Web Client IP with Malware Detected — Displays the number of requests by client IP addresses who have accessed the malware in
the last 7 days.
• Top Web Users with Malware Detected — Displays the number of requests by users who have accessed malware in the last 7 days.
Monitor web traffic

You can monitor and evaluate the web traffic data using the Web Traffic page. You can view the aggregated traffic data by number
of visits, website name, traffic reputation (security risks), application name, number of requests (hits), allowed or denied
requests, and number of bytes downloaded and uploaded. By default, it displays the data for the last seven days. You can use
Date Picker to change the date range.
• Log Source — The data center location. You can select a log source to fetch web traffic information.

• Filters — You can use filters to control the amount and the kind of data displayed on the Web Traffic page.
• Views — You can save a view and reuse it to search data at any time. You can also create your own dashboard using this saved
view.
• Export — You can export the displayed data to a CSV, XLS, and PDF file.
• Search — You can use the Search bar to look for a specific website traffic data. You can search for Site, Application Name,
Reputation, Application category, Malware Name, and Protection Area.
• Edit Table Columns — You can customize tables by resizing columns, sorting the data, and selecting certain columns for display.
• Schedule — You can schedule the current view of a website traffic report to run itself daily, weekly, or monthly, every three
months, or yearly. You can either download these scheduled reports from the Reports section or provide an email address to
automatically send reports to the recipients.
The Web Traffic page displays the web traffic information in either chart or table format. You can view the following information for
the last seven days:
• Site — Name of the website visited.
• URL category — The category to which the site belongs. For example, the category of YouTube is Media sharing and Media
streaming and the category of Snapchat is Chat and Social Networking.
• Reputation — The reputation of a site. Displays whether visiting a site has minimal, medium, or high risk.
• Application Name — The category of the application.
• Requests — The total number of hits. You can click on the value to view the complete list of events for the selected site.
• Allowed/Denied Requests — The number of allowed and denied requests.
• Total Bytes — The total number of bytes uploaded or downloaded from a site.
• Downloaded Bytes — The number of bytes downloaded from a site.
• Uploaded Bytes — The number of bytes uploaded to a site.
Monitor web malware

Using the Web Malware page, you can view the list of sites affected by malware. This page displays malware name, user name, IP
address, site, URL category, protection area, number of requests (hits), allowed or denied requests, number of bytes downloaded
and uploaded. By default, it displays the data for the last seven days. You can use Date Picker to change the date range.
• Log Source — The data center location. You can select a log source to fetch malware information.
• Filters — You can use filters to control the amount and the kind of data displayed on the Web Malware page.
view.
• Search — You can use the Search bar to look for a specific malware data. You can search for Malware Name, User Name, IP
address, site, application name, application category, and protection area.
Allowed | Denied Requests
• Schedule — You can the current view of a malware report to run itself daily, weekly, or monthly, every three months, or yearly.
You can either download these scheduled reports from the Reports section or provide an email address to automatically send
reports to the recipients.
The Web Malware page displays the malware information in either chart or table format. You can view the following information for
• Malware Name — The name of the malware.
• User Name — The user name who accessed the website.
• IP Address — The IP address of the website.
• Site — Name of the affected website.
• URL category — The category to which the site belongs. For example, the category of YouTube is Media sharing and Media
streaming and the category of Snapchat is Chat and Social Networking.
• Application category — The category of the application category. You can click on the value to view all application categories. For
example, Facebook, Google, Twitter.
• Protection Area — The reason for blocking the malware.
• Application Name — The application category of the website.

• Allowed/Denied Requests — Displays the number of allowed and denied requests.
Monitor web users

You can monitor number of users who visited a website using the Web Users page. You can view the aggregated user data by
number of visits, website name, website reputation (security risks), application name, number of requests (hits), allowed or
denied requests, and number of bytes downloaded and uploaded. By default, it displays the data for the last seven days. You can
use Date Picker to change the date range.
• Log Source — The data center location. You can select a log source to fetch web site visitor information.
• Filters — You can use filters to control the amount and the kind of data displayed on the Web Users page.
view.
• Search — You can use the Search bar to look for a specific website traffic data. You can search for Site, Application Name,
Reputation, Application category, Malware Name, Protection Area and Isolation Type.
• Schedule — You can schedule the current view of a web users report to run itself daily, weekly, or monthly, every three months,
or yearly. You can either download these scheduled reports from the Reports section or provide an email address to
automatically send reports to the recipients.
The Web Users page displays the web user information in either chart or table format. You can view the following information for
• User Name — Name of the user.
• Site — Name of the website visited. You can click on the site count to view the web traffic details.
• Application Name — The name of the application.
• Allowed/Denied Requests — The number of allowed and denied requests.
• Isolated Requests — The number of request isolated by Remote Browser Isolation (RBI).

Workflow for data protection with MVISION Unified Cloud Edge
MVISION Unified Cloud Edge features and policy components make up a data protection process that fits into this overall
workflow.
Protect against data loss by applying classifications to data protection policies that trigger actions and generates incidents when
sensitive data is identified.
1. Start by defining and classifying sensitive data that needs to be protected with the Classifications editor.
2. Protect sensitive data by applying CASB or Web Data Protection rules.
3. Review incidents in the Policy Incidents page in MVISION Cloud to see potential policy violations and to fine-tune existing policies.
Identifying sensitive data with classifications

To protect sensitive data, you start by identifying the sensitive data that needs to be protected and categorizing the data using
classifications. Data protection rules apply the classification criteria and other definitions to protect the sensitive data from
leaving your organization.
A range of built-in classifications for common requirements is provided, and can be used for complying with various regulations.
Classifications can also be customized to suit the organization needs. Both built-in and customized classifications are consistent
and can be used across your data protection policies. Classifications are created and managed with a unified Classifications editor.
The Classifications editor displays the list of built-in classifications and user-defined custom classifications. Classifications are
categorized into logical groups, for example, the Healthcare category includes classifications for detecting possible HIPAA
violations, and more. Built-in classifications include, among others, classifications for detecting personal identifiable information
(PII), with classifications specific to different countries. You can use built-in classifications as is in data protection policies, or you
can customize new classifications.
Note: For users with McAfee DLP Endpoint, consistent classifications for McAfee DLP Endpoint and cloud policies can be
enforced. For more details about McAfee DLP Endpoint, see the specific product documentation.
Classifying your data

Sensitive data can be identified with sensitive text patterns using regular expressions, dictionaries, and keywords. They can also
specify file conditions such as the true file type, file extension, file size, or location in the file.

Methods to define classification criteria include:
• Advanced patterns — Regular expressions or phrases, used to match patterns such as security numbers or credit card numbers.
Advanced patterns are ranked according to a score, meaning, the number of times the sensitive expressions need to appear in
the content for the rule to be triggered. The Classifications editor includes several built-in advanced patterns for ensuring
compliance with government regulations and simplifying detection of personal information. You can also create your own
advanced patterns.
• Dictionaries — Collections of related keywords and phrases, such as, profanity or medical terminology. Sensitive data is compared
to the dictionary entries and ranked according to a score, meaning the number of times the sensitive keywords need to appear
in the content for the rule to be triggered. The Classifications editor includes several built-in dictionaries with terms commonly
used in health, banking, finance, and other industries. You can also create your own dictionaries or export built-in dictionaries
to edit them to suit your organization's needs.
• Keywords - A string value that defines sensitive data. You can add multiple keywords for content classifications. Keywords are not
consistent across classifications. If you need to use consistent keywords across classifications, use a dictionary.
• File size - The size of the file to detect the sensitive data. You can also define a file size range.
• True file types — The true file type to determine which files to identify the sensitive data. True file type helps detect attachment
violations when file extensions are renamed and sent as attachments. For example, a .cpp file saved as a .txt file can be
detected using the true file type classification criteria.
• File extension - The file types to detect the sensitive data, such as MP3 and PDF.
• Location in file - The section of the file to look for the sensitive content; Header, Footer, Body or within the first characters.
◦ Microsoft Word documents - Header, body and footer can be identified.
◦ PowerPoint documents - WordArt is considered Header, everything else is identified as Body.
◦ Other documents - Only Body is applicable.
How sensitive data is prevented from leaking out

You can prevent sensitive data stored and maintained in the cloud that you do not want to expose to unauthorized access or use
from leaking out.
To prevent this leakage, you can implement a cloud security solution under MVISION Unified Cloud Edge that includes
completing two main steps:
• Classify sensitive data — Identify the data that is sensitive and use classifications to categorize it, for example, Confidential.
• Set up policies to protect classified data — Create policies with rules that prevent leakage of documents and other objects
containing sensitive data classified in one or the other way.
These rules rely on security functions that detect attempted leakage and respond to it by triggering suitable actions. This way it
is ensured that your data is secure.
For example, a rule blocks a request sent by a user who works in the cloud to send a document with classified data to a
destination outside your organization.
A policy that prevents data from leaking out is referred to as Data Loss Prevention (DLP) policy. The terms leak or leakage are also
used here occasionally instead of loss.
MVISION Unified Cloud Edge provides options to complete both main steps on its user interface.
Types of DLP policies

You can create two types of DLP policies on MVISION Unified Cloud Edge.
• Sanctioned Policy — This type includes rules that prevent classified data from leaking out using the functions of a Cloud
Access Security Broker (CASB) that are provided under MVISION Unified Cloud Edge.
If you want to prevent cloud data from leaking out, you must have a complete view of them. This visibility is achieved by
connecting to the cloud services through Application Programming Interfaces (APIs).
• Shadow/Web Policy — This type includes rules that prevent classified data from leaking out using the filtering functions of a
web proxy that you set up under MVISION Unified Cloud Edge.
Traffic originating from web usage of users working in the cloud is redirected to this proxy and filtered according to the rules of
your DLP policies. Any content is then scanned to detect classified data and prevent it from leaking out.

For example, a user within your company works on a document with data classified as Confidential using Microsoft Office 365 as
a cloud service. Eventually, the user attempts to transfer the document from this cloud environment to a location within your
competitor's network.
A DLP policy rule then blocks the request to transfer the document and carries out further actions, for example, it notifies your
DLP administrator.
The rule might also log an incident that describes the attempt and the actions that were executed in response to it.
Different responses can be configured depending on the policy type.
How a DLP policy is set up

You can set up a DLP policy in different ways on MVISION Unified Cloud Edge depending on its type.
• Using a wizard to set up a Sanctioned Policy — A wizard assists you when you set up a DLP policy as a Sanctioned Policy.
This wizard is known as the Policy Wizard. It is invoked on the user interface.
When you are done with creating a Sanctioned Policy, this policy is displayed in a list on the initial wizard page.
• Using a wizard to set up a Shadow/Web Policy — When you set up a DLP policy as aShadow/Web Policy, you can also use the
Policy Wizard, invoking it on the user interface.
When you are done with creating a Shadow/Web Policy, it is displayed in a list on the initial wizard page.
• Setting up a DLP policy manually — You can set up a DLP policy manually as a Shadow/Web Policy, working with the rule sets
on the web policy rule set tree, which is accessible on the user interface.
This rule set tree includes default rule sets with rules for policies of this type. You can modify the rules in the already existing
rule sets and add new rule sets with modified rules.
The rule set tree also includes rule sets with rules for other web security functions, for example, rules for malware and URL
filtering.
When working with these rules, you can access a code view and complete configuration activities in this view. You must obtain
a separate license to be able to work with the code view.
What a DLP policy can include when it is created using the Policy
Wizard
A Data Loss Prevention (DLP) policy consists of rules for preventing classified data from leaking out, which you can create using
the Policy Wizard with the complexity that is required to ensure your data is secure.
A DLP rule that you create with the Policy Wizard basically includes two parts:
• Condition — Specifies what must be given to let the rule apply.
This involves the type of classified data that has been detected by the DLP functions of MVISION Unified Cloud Edge, for
example, in a document.
On the user interface, you see the condition displayed, for example, as:
IF Classification is Confidential
For a simple rule, nothing else has to be specified as a condition.

• Response — Specifies what measures are taken if the condition matches and the rule applies.
When working with the Policy Wizard, measures include setting a security level and triggering one or more actions.
On the user interface, you see the response displayed, for example, as:
THEN Severity is High AND Block
For a simple rule, nothing else has to be specified as a response.

When you are creating a sanctioned policy, the rule also logs an incident by default.
The incident description includes the attempted leakage that made the condition match as well as the measures that were
taken in response.
You can make a policy and its rule more complex by specifying, for example, who or where this policy should be enforced on, as
well as a number of other parameters. Different parameters can be configured depending on the policy type
You can also create a complex policy by combining two rules or more within it.

Parameters for a complex DLP policy
A DLP policy can be made complex to ensure your data is safe with regard to:
• Scope — You can set the scope of a policy to let it apply to all traffic or restrict it according to location, services, and other
parameters.
• Response — You can configure a complex response that a rule triggers by combining multiple measures to be taken if its
condition matches.
• Rules — You can make a policy complex by combining multiple rules within it.
Scope restriction
When you are working with the Policy Wizard to create a DLP policy, it applies by default to all traffic originating from cloud user
activities relating to your data. You can restrict this scope according to the following parameters:
• Client IP address
• Connection IP address
• Location
• Service
• Service Group
• User name
• User group
• Web (URL) category
For example, you can set the scope of a policy to let it apply only to traffic originating from cloud activities of users in Santa Clara
and San Jose.
Furthermore, you can let it apply only when these users work with the Dropbox cloud service. And you can let it apply to all of
them except for one individual user whose name is Bob Miller.
On the user interface, you would see this scope displayed as:
ZF Location is one of Santa Clara | San Jose AND Service is Dropbox AND User name is not bmiller@mycompany.com
Complex response
You can make the response of a rule in a DLP policy complex by configuring multiple measures for it. The following parameters
are involved here:
• Severity level — Setting it is required in a response.
On the user interface, you see this displayed, for example, as:
THEN Severity is High
• Rule action — Setting at least one is required for a sanctioned policy. More actions can be added.
For a Shadow/Web Policy, a Block action can be set optionally.
On the user interface, you see would see, for example, the following displayed when email with classified data is detected and
a response is triggered under a sanctioned policy:
THEN Quarantine AND Send Email Notification to dlpadmin@mycompany.com
• Incident — Is set by default for a sanctioned policy.

The incident description includes the attempted leakage and the measures taken in response to it.
Multiple rules
You can make a DLP policy complex by including multiple rules in it.
On the user interface, you see this displayed, for example, as:
Rule Group 1 IF Classification is Top Secret THEN Severity is Critical AND Block or Rule Group 2 IF
Classification is Confidential THEN Severity is Major AND Block

Web policy
To protect your network against threats arising from the web, you can enforce a web policy. This policy usually consists of rules,
which are grouped in rule sets.
Like Web Gateway, the McAfee WGCS policy consists of rules, lists, and settings. Rules filter web traffic, allowing or blocking
access to web content, applications, and other objects. You configure the rules you want applied to web traffic and the related
lists and settings.
Rules
Rules are grouped in rule sets under the following headings in the Web Policy UI. The headings are branches in the policy tree. The
rule engine processes rule sets, proceeding from the top to the bottom of the policy tree until all rule sets are processed or
processing is stopped by a rule action. For example, when a rule blocks a web request, processing is stopped. The order of the
branches, rule sets, and rules can't be changed.
Policy tree branches
1 Global Bypass
2 HTTPS Scanning
3 Global Block
4 Common Rules
5 Web Filtering
6 Content Inspection
7 Application Control
8 Media Type
9 Data Protection (DLP)
10 Threat Protection
Rule sets are processed in cycles, each cycle corresponding to a web request or a web response. Web requests are sent from the
user to the web, while web responses are sent from the web to the user. A web response is always sent in response to a web
request.
Each rule set applies to web requests or web responses or sometimes, to both requests and responses. The rule engine only
processes the rule sets that apply to the current request or response, skipping any rule sets that do not apply. For example, the
Global Block rule set only applies to web requests. The rule engine processes the Global Block rule set during request cycles, but
skips the rule set during response cycles.
Lists
Many rules use lists that you configure. For example, the Skip Content Decryption for these Categories rule compares the category
of the URL requested by the user to the list of URL categories configured for the rule. If there is a match, the web request is
allowed to skip HTTPS decryption and processing continues with the next rule set. If there is no match, the web request is not
allowed to skip HTTPS decryption.

Rule name List Result Rule action
Skip Content Decryption for List of URL categories • Matches in list • Matches in list = Skip HTTPS
these Categories • Does not match in list decryption
• Does not match in list =
Continue with HTTPS
decryption
You configure the list with the URL categories that you consider safe. Web requests sent to the URL categories in the list do not
require decryption and content inspection.
You can configure the lists with the rule sets, or you can configure them separately in the Policy → Web Policy → List Catalog UI.
Feature Configuration settings

Rule set processing involves related McAfee WGCS features. For example, processing the Anti-Malware rule set involves the Anti-
Malware for GAM feature. The following features have settings that you can configure.
Feature Related rule set
Anti-Malware for GAM feature Anti-Malware
Certificate Verification feature Certificate Verification
Certificate Verification Options feature HTTPS Connection Options
Composite Opener feature Archive and Transfer
DLP Classification feature DLP Classification
DLP Dictionaries feature DLP Dictionary
Data Trickling feature Download Progress
ICAP Server feature DLP ICAP Server
HTTPS Connection feature HTTPS Connection Options
HTTPS Decryption feature HTTPS Decryption
Next Hop Proxy feature Next Hop Proxy
Web Filtering feature Reputation and Category
You can configure the settings with the rule sets, or you can configure them separately in the Policy → Web Policy → Feature
Configuration UI.
Permissions
With Web Policy permissions, you can manage the web policy, which includes configuring the rules, lists, and features that make it
up. To view and directly edit the policy code underlying the rule sets, you need Web Policy Code permissions. The Code View feature is
intended for advanced users.
How rules act on web traffic

Rules act on web traffic to enforce your web policy. They block access to web objects, for example, if they threaten the security of
your network, and allow access to useful objects.

The rule actions are:
• Block — The traffic is blocked, and rule processing stops.
• Bypass — The traffic is allowed, and rule processing stops. Web requests that are allowed go directly to the internet.
• Skip — Rule processing skips the remaining rules in the rule set and continues with the next rule set.
The following table includes an example of each rule action.
Rule name Condition Result Rule action
Domains block list The requested domain is in • Matches in list • Matches in list = The traffic
the list configured for this • Does not match in list is blocked, and rule
rule. processing stops.
• Does not match in list = Rule
processing continues with
the next rule.
Domains bypass The requested domain is in • Matches in list • Matches in list = The traffic
the list configured for this • Does not match in list is allowed, and rule
rule. processing stops.
the next rule.
Skip Content Decryption for The requested URL category is • Matches in list • Matches in list = Rule
these Categories in the list configured for this • Does not match in list processing skips the
rule. remaining rules in the rule
set and continues with the
next rule set.
the next rule.
Types of lists for web policy rules in the List Catalog

The List Catalog lets you view the types of lists that are used to support the rules of your web policy.
List types include strings, regular expressions, and IP addresses. For example, you can configure a rule that allows all traffic sent
from a list of client IP addresses. Lists simplify policy configuration.
You can view and configure lists in the List Catalog, which consists of these list categories.
List category Description
Certificate Authority Lists of trusted root CAs — These lists are used by many
policy rules and features.
Host and Certificate Lists of host name and certificate pairs — These lists are used
to allow certificates that are otherwise invalid. For example,
they might be recently expired.
IP Lists of individual IPv4 or IPv6 addresses — These lists are

used by many policy rules and features.

List category Description
IP range Lists of IPv4 or IPv6 address ranges — These lists are used by
many policy rules and features.
Specify IP address ranges using:
• A starting IP address and ending IP address separated by a
hyphen
• CIDR notation
Media type Lists of items selected from a McAfee-maintained catalog of

media type categories — You can create custom media type
lists by selecting and deselecting categories and items in the
catalog.
Number Lists of numbers — These lists are used by many policy rules
and features.
Regular expression Lists of regular expressions — These lists are used for string
matching.
Format: Perl regular expression syntax
Smart Match Lists of mixed URLs, host names, IP addresses, and domains
— These lists are used by policy rules and features that
support smart match.
String Lists of strings — These lists are used by many policy rules
and features.
URL category Lists of items selected from a McAfee-maintained catalog of

URL categories — You can create custom URL category lists by
selecting and deselecting categories and items in the catalog.
Maintaining your own lists and using lists maintained by McAfee

The lists in the List Catalog are provided as McAfee-maintained lists, where entries are filled in by McAfee, and as user-defined lists,
where you fill the entries.
User-defined lists
Initially, user-defined lists are empty. To populate a user-defined list with list items, you can add them individually or import them
from a .csv file. McAfee WGCS validates all list items and flags invalid items with error messages.
McAfee-maintained lists
McAfee maintains lists for you to use in policies and keeps them up-to-date.
• Subscribed lists — These lists are updated dynamically when new information is available.
• System lists — These lists only occasionally need updating.
McAfee-maintained lists are populated with list items and can't be changed or deleted. To identify lists that are maintained by
McAfee, select the name in the List Catalog, then view the URL in the browser address field.
• Names of subscribed lists — Begin with "McAfee_" in the URL.
Example URL string for a subscribed list:

• Names of system lists — Begin with "MWG_" in the URL.
Example URL string for a system list:
Working with URL category and media type lists

URL category and media type lists consist of list items that are selected from catalogs maintained by McAfee. When you create
these lists, you select the list items from the related catalog:
• URL Category Catalog
• Media Type Catalog
When adding items from a catalog to a list, you can select from multiple categories in the catalog. For example, you can create a
list named Custom Media Type List and add items from the Archives, Executables, and Text categories to the list.
How URL fragments can be used in SmartMatch lists to support

rules for blocking URLs
You can configure smart match lists for policy rules and features that support the smart match feature. The smart match feature
compares URLs in web requests to lists of smart match URLs and returns a true value if there is a match. .
Smart match URLs include URL fragments that you can configure to yield the matches you want. For example, if you want to
match every web request sent to Google, you can add google.com to your smart match list.
Smart match URLs and URL fragments have this format:
[<protocol>://][<domain>][:<port>][<path>]
How smart match URLs are formatted and matches are made
URL part Smart match URL (format) URL in the web request (match)
protocol optional The URL in the web request must

include the protocol, if present, for a
match to occur.
domain The domain is required if there is no URLs that match the domain result in a
path. true value. If the smart match URL
includes a subdomain in addition to a
domain, URLs that match must have one
of these formats:
• subdomain.domain.tld
• domain.tld
port optional The URL in the web request must

include the port number, if present, for a
match to occur.
path The path is required if there is no URLs that match the path result in a true
domain. value. If the smart match URL includes a
path and subpath, URLs that match
must have one of these formats:
• /path/subpath
• /path

URL part Smart match URL (format) URL in the web request (match)
Note: The URL in the web request must
include the forward slash at the end of
the path if present or omit it if absent for
a match to occur.
domain/path This format is allowed. URLs that match the domain, the path,
or both URL components result in a true
value.
Smart match examples
Web request URL Smart match list entry Match
http://www.myorg.com:8080/path https://www.myorg.com:8080 no
http://www.myorg.com:8080 yes
http://www.myorg.com yes
www.myorg.com:8080 yes
http://www.library.university.edu/ www.library.university.edu yes

research/alumni
library.university.edu yes
university.edu yes
/research/alumni yes
/research yes
How rules relate to features

Rules are often supported by features that are associated with them.
Features that come with default settings

Some features come with default settings that can't be edited or deleted. You can use the default settings as is or clone and edit
them.
• Anti-Malware for GAM → Default Gateway Anti-Malware settings
• Certificate Verification → Default TLS Certificate Chain Setting settings
• Certificate Verification Options → Default Certificate Verification settings
• Composite Opener → Default Composite Opener settings
• Data Trickling → Default Data Trickling Settings settings
• HTTPS Decryption → Default Enable Content Inspection settings
• Web Filtering → Default GTI Setting settings
Features that require configuration

Some features require configuration with values that are specific to your organization. These features come with settings that
you can edit without cloning first.
• DLP Classification → DLP Classifications settings
• DLP Dictionaries → DLP Dictionary settings
• ICAP Server → ICAP DLP Setting settings
• HTTPS Connection → Customer CA settings

• Next Hop Proxy → Next Hop Proxy settings
Features can be configured in the Feature Config UI or with the related rule sets in the Web Policy UI.
Feature Config UI
When configuring feature settings in the Feature Config UI, you can:
• Create a new configuration — Select a feature, then click New Configuration.
• Clone and edit a configuration — Select a default or user-defined configuration, then select Clone and edit from the Actions drop-
down list. You can edit the configuration after cloning it.
• Delete a configuration — Select a user-defined configuration, then select Delete from the Actions drop-down list.
What scopes rule sets can have

By default, the rules in the rule sets apply to all web traffic. You can limit the scope of each rule set by configuring the following
criteria.
• Location — Any location name configured in the UI for web policy
• Client IP — IP address of the endpoint
• Connection IP — IP address of the firewall or other device between your organization's network and the cloud (your public IP
address)
• User Group — Names of one or more groups where the user making the web request is a member
• User Name — Name of the user making the web request
For example, you can select a location named Europe and specify that a rule set only applies to web traffic inside that region.
Configuration needed for some rule sets to take effect

Some rule sets need configuration before they take effect. You can get started with the web policy as is, or you can configure and
add these rule sets to it.
To get started with the web policy as is, use the default rule sets and settings that are installed with the cloud service and visible
in the policy tree. Most default rule sets have rules already selected and the rule set status set to on. These rule sets are ready to
use. A few rule sets require more configuration before they can be used.
Default rule sets with no rules selected

The following rule sets are installed with no rules selected. You can use the web policy without these features. Or you can select
and configure the rules that you want to use. After you publish your changes to the cloud, the rules take effect.
• Common Rules → Add Additional Header
• Application Control → Application Blocking
• Application Control → Tenant Restriction
• Application Control → Activity Control
Default rule set with status set to off

The following default rule set is installed with rules selected. But you must set the rule set status to on for the rules to take effect:
Global Bypass → Office 365 Bypass.
Default rule sets that require more configuration

These rule sets are installed with the cloud service and visible in the policy tree, but they require more configuration before they
can be used effectively. To use them, you can complete the extra configuration, set the rule set status to on, and publish your
changes to the cloud.
• DLP ICAP Server rule set — Configure the ICAP Server feature.
• Next Hop Proxy rule set — Configure the Next Hop Proxy feature.

Default rule sets that you can add to the web policy
Some rule sets are not installed with the cloud service, but listed on the Web Policy | Getting Started page. These rule sets require
more configuration before they can be used effectively.
• Advanced Threat Defense rule set — Configure the Anti-Malware for ATD feature.
• YouTube Control rule set — Provide your YouTube API key.
You can use the web policy without these features. Or you can add the rule sets to the policy by following these general steps:
1. Add the rule set from the rule set group menu in the policy tree or from the list on the Getting Started page.
2. Select and configure the rules.
3. Complete the additional required configuration.
4. Set the rule set status to on.
5. Publish your changes to the cloud for the rules to take effect.
Steps required before configuring some rule sets

Some rule sets have prerequisites that must be met before they can be fully configured and ready for use in your web policy.
Rule set Prerequisites
Activity Control This rule set gives you fine-grained control over the cloud
services in the Service Catalog, allowing you to select which
activities you want blocked instead of blocking entire services.
For example, you can select Box from the Service Catalog,
then select download and upload activities for blocking, while
allowing edit and post activities. Before you can configure these
rules, you must add cloud services from the Service Catalog.
Prerequisites:
• Add a cloud service from the Service Catalog
Advanced Threat Defense This rule set sends web objects to Gateway ATD for in-depth
static and dynamic analysis according to the rules that you
configure. For example, you can allow some media types to
skip ATD processing, while requiring other media types to be
processed by ATD.
Prerequisites:
1. Install and run the Advanced Threat Defense software.

2. Verify that McAfee WGCS can connect to your Advanced
Threat Defense instance.
Required settings:
◦ User name and password that McAfee WGCS uses to
authenticate and connect to Gateway ATD
◦ Host name or IP address and port number of the server
hosting Gateway ATD
3. Add a CA certificate.
Application Blocking This rule set blocks access to configured groups of cloud
services called Service Groups. Before you can add Service
Groups to this rule set, you must create them.
Prerequisites:

1. From the MVISION Cloud navigation bar, select Governance |
Service Groups.
2. Create one or more Service Groups.
Certificate Verification This rule set verifies certificates according to certificate

verification rules that you customize for your organization.
For example, you can configure the certificate verification
process to be more or less restrictive. For the certificate
verification rules to take effect, you must first provide at least
one CA certificate.
Prerequisites:
• Add a CA certificate
DLP Dictionary This rule set blocks the transfer of sensitive information
outside your organization according to the DLP dictionary
rules that you configure. For this rule set to work for your
organization, you must customize the default DLP Dictionary.
Prerequisites:
• Customize the default DLP Dictionary
DLP ICAP Server This rule set sends files to DLP ICAP servers according to the
rules that you configure. For example, you can send all files or
send only the file types that you specify. For the DLP ICAP
server rules to take effect, you must configure at least one
DLP ICAP server.
Prerequisites:
1. Install the DLP ICAP server.

2. Verify that McAfee WGCS can connect to the server
instance.
Required settings:
◦ Host name or IP address
◦ Port number 1344
Next Hop Proxy This rule set forwards web traffic to proxy servers according
to the next hop proxy rules that you configure. For example,
you can forward all traffic or forward only risky traffic. For the
next hop proxy rules to take effect, you must configure at
least one proxy server. Adding more than one proxy server
enables round robin load balancing.
Prerequisites:
• Add a proxy server
Required settings: host name or IP address, port number
Tenant Restriction This rule set blocks users from accessing sanctioned cloud
services through their personal accounts, while allowing
access to these services through the accounts that you
configure. To configure each tenant restriction rule, you need
these application-specific details.
Prerequisites:
• Amazon Web Services (AWS) — Allowed AWS Account IDs

• Box — Allowed Box subdomains and allowed user email
address domains
Examples:
◦ Box subdomain: If your Box domain name is
forestry.box.com, your subdomain is forestry.
◦ Email domain: mcafee.com
• Dropbox — Allowed Dropbox Team IDs
• Google — Allowed user email address domains
• Microsoft Office 365 — Directory ID of your Azure Active
Directory instance and allowed user email address domains
• Slack — Allowed Slack Team IDs
YouTube Control This rule set filters YouTube traffic according to the rules you
configure. For example, you can block traffic by title or
category and allow or block traffic by channel. McAfee WGCS
filters traffic by checking the metadata sent with a video
stream over the YouTube API. Before you can configure the
YouTube rules, you must provide your YouTube API key.
Prerequisites:
• Get a YouTube API key through Google APIs
Where new and updated rule sets are listed in the UI

New web policy features and enhancements are introduced in rule sets, which you can view on the Web Policy → Getting Started page
in the MVISION Cloud UI. Look for updates when there is a software release.
You can update your web policy with new features and enhancements at times that work for you. To do so, add the rule sets to
the policy tree from one of these locations:
• The Getting Started page
• The rule set group menus (...) in the policy tree
Deleted rule sets

When all instances of a rule set are deleted from the policy tree, the rule set is added to the list of new and updated rule sets.
You can add these unused rule sets back to the policy tree the same way that you add new and updated rule sets.
The list of new, updated, and unused rule sets allows you to:
• Add a new feature to your web policy.
• Update your web policy with an enhanced feature
• Start over with a rule set's default settings
Default rule sets

All new, updated, and unused rule sets are added to the policy tree with their default settings. Rule sets in the policy tree whose
settings retain their initial default values are default rule sets. You can use these rule sets as templates for new rule sets by
cloning, editing, and renaming them.
Rule set installation

Rule sets are installed when they are added to the policy tree. Some rule sets are installed initially. Other rule sets are installed
when they are added to the policy tree later.
When you add a rule set to a rule set group in the policy tree, you see the following message if the group already contains one
rule set of each type. In the following example, the HTTPS Connection Options group already contains one rule set of each type:
HTTP Connection Options, Certificate Verification, and HTTPS Decryption.

How coaching allows users to override blocking
Instead of either blocking or allowing access to websites, you can also allow restricted access. Users of your organization can
override blocking and access a website if they have a business reason. Allowing users access in this way is also known as
coaching.
For example, users can be allowed coached access to websites that have URLs falling under particular categories. Or coached
access can be allowed to particular domains. Coaching can also be applied to services.
Coaching rules
Coaching is implemented like blocking through rules. The rules are supported by lists that you fill with entries. You can, for
example, enter the URL categories or domain names of the websites you want to apply coaching to. Or you can enter groups of
services you want to allow coached access to.
Coaching page
When coaching is enabled, for example, for a website, users who attempt to access it will not see a block page, but a coaching
page.
This page informs the users that access to the requested website is blocked, but can be accessed with a business reason. Users
confirm by clicking a suitable button on the page that they have a business reason..
How in-depth protection against web threats is reached

Working together, these McAfee technologies protect your organization from web-based threats through an in-depth process
that detects malware, spyware, viruses, ransomware, phishing URLs, targeted attacks, and blended threats.
1. Anti-Malware module — Using signature-based antivirus technology with URL category and reputation data from McAfee®
Global Threat Intelligence™ (McAfee GTI), the Anti-Malware module filters known threats from web traffic, while allowing
known good traffic to pass. This step of the process detects most web-based threats.
McAfee GTI evaluates website reputation based on past behavior and assigns websites to categories of high, medium, low, or
unverified risk. It collects, analyzes, and distributes data in real time from millions of sensors worldwide.
2. Gateway Anti-Malware engine — The Gateway Anti-Malware engine then inspects the suspicious unknown traffic. Using
emulation technology, it observes dynamic web content and active code in a controlled environment. This step of the process
detects most remaining web-based threats. Known as zero-day malware, these threats are new or changed malware files that
do not have signatures yet.
3. Advanced Threat Defense — McAfee® Advanced Threat Defense uses static analysis of unknown files combined with
dynamic analysis in a sandbox environment and machine learning to increase detection of zero-day malware and
ransomware, detecting nearly all remaining web-based threats.
Note: McAfee WGCS supports integration with Advanced Threat Defense software that you install and run, as long as McAfee
WGCS can connect to your Advanced Threat Defense instance.

How to bypass HTTPS scanning when certificate pinning is in use
McAfee WGCS provides a subscribed list and global bypass rule that allow web traffic from mobile devices to bypass HTTPS
scanning when certificate pinning is in use.
Cloud service providers that own both the server-side and the client-side code sometimes configure their clients to accept only
the server's public key, a process known as certificate pinning. Certificate pinning ensures the integrity of the HTTPS connection
between client and server. But it prevents a proxy service, such as McAfee WGCS, from decrypting the traffic without destroying
the ability of the client to connect to the original destination.
When the McAfee Mobile Cloud Security solution is configured, make sure that the certificate pinning bypass rule is enabled:
• Enable mobile access to sites using certificate pinning — This global bypass lists rule allows web traffic from mobile devices
to bypass HTTPS scanning when the host or domain name is on the Sites Using Pinned Certificates subscribed list.
• Sites Using Pinned Certificates — This subscribed list is maintained by McAfee and contains the names of hosts and domains
that use certificate pinning.
How browser isolation is used for secure web access

You can use browser isolation, which is also known as Remote Browser Isolation (RBI), to ensure web access is secure for users of
your organization.
When a user sends a request to access a website with browser isolation enabled, the original content of that website is not sent
in response to the user's browser, but to a browser on a remote server.
From there, a real-time, interactive image of this content is transferred to the user's browser. This ensures the user's browser
and system are protected against threats arising from the original content, for example, against infections by viruses and other
malware inhering in this content.
Using browser isolation, you can allow users access to websites that would otherwise be blocked under your web policy because
accessing them was considered an unacceptable risk.
The user is notified when browser isolation is applied. For this purpose, the representation of the original web content is marked
by a green border around any page that is displayed in the user's browser.
The browser isolation process is controlled by the rules of your web policy. These rules filter web traffic relying for their execution
on the web proxy functions that are implemented under MVISION Unified Cloud Edge.
There are two rule sets offering different modes of browser isolation:
• Risky Web — Browser isolation is used when a access to a website is considered a risk.
Whether access to a website is considered a risk, is determined by the web security functions that are implemented under
MVISION Unified Cloud Edge.
You can specify exceptions and other settings.
• Full Isolation — Browser isolation is used for access to a website according to criteria that you select.
Note: You must obtain an additional license from McAfee to use the Full Isolation mode of browser isolation.
Modifying browser isolation for risky websites

Under the Risky Web mode of browser isolation, the web security functions of MVISION Unified Cloud Edge determine whether
access to a website is a risk. You can modify its use as follows:
• Exempting websites — While using this mode, you can exempt websites from having it applied if you think your users can
access them without risk.
You can exempt websites based on domains, IP addresses, and URL categories.
• Blocking and allowing activities — While using this mode, you can block or allow:
◦ File uploads and downloads
◦ Copying and pasting data
◦ Storing cookies
• Behavior when browser isolation cannot be enabled — If access to a website is considered a risk, but this mode cannot be
enabled for some reason, you can block access to this website.

This ensures that while using this mode, risky websites are either accessed by your users under it or not at all.
Modifying full browser isolation

Under the Full Isolation mode of browser isolation, you determine when to apply it. You can modify its use as follows:
• Exempting websites — While using this mode, you can exempt websites from having it applied if you think your users can
access them without risk.
You can exempt websites based on domains, IP addresses, and URL categories.
• Restricting browser isolation to websites — While using this mode, which applies to all websites by default, you can select
websites and restrict use of this mode to them.
You can base your selection on domain, IP addresses, and URL categories.
• Blocking and allowing activities — While using this mode, you can block or allow:
◦ File uploads and downloads
◦
Copying and pasting clipboard data
You can also set a limit to the amount of cliipboard data that is copied or pasted.
◦ Storing cookies
• Behavior when the licensing limit for browser isolation is reached — You need to obtain an additional license from McAfee
to apply this mode of browser isolation. This license allows a limited number of users to access websites from their browsers
with this mode enabled.
When this number is exceeded, you cannot apply this mode to other users anymore. Then you can still block access to all
websites where you would otherwise have applied it.
This ensures that while using this mode, websites are either accessed by your users under it or not at all.
How licenses for applying Full Isolation to browser sessions are

controlled
When the Full Isolation mode of browser isolation is applied, the number of licenses that enable users to apply this mode to their
browser sessions is limited and controlled under MVISION Unified Cloud Edge.
The licenses that are available to users for applying the Full Isolation mode are referred to as seats. When a user requests a Full
Isolation browser session, the web protection functions that are implemented under MVISION Unified Cloud Edge verify if a seat
is available for this user.
Availability of seats is tracked and controlled globally by these functions using GPS and other facilities. Information about seats is
distributed to the local datacenters known as Points of Presence (POPs), where instances of MVISION Unified Cloud Edge are
hosted and can be accessed by users.
When a user is no longer active on a session, the occupied seat is freed up to ensure an ever changing group of users can be
supported. Some over-usage is tolerated regarding seat usage, which means that it can actually go up to 115% of the normal
scope.
User buckets
Seats allotted to users are entered in three buckets to record seat usage over particular periods in time. Usage occurring during
the last twelve hours is recorded in the first bucket. For the twelve hours preceding the last twelve, it is recorded in the second
bucket, and in the third for another twelve hours back.
When a user requests a Full Isolation browser session, former seat usage is checked for this user, beginning with the first bucket.
If a user has been using a seat during the last twelve hours, the check is positive, and further usage is allowed.
Otherwise checking continues with the second and third buckets. A user who was active on a seat during one of the twelve-hour
intervals recorded in these buckets is moved up to the first bucket.
A user who cannot be found in any of the three buckets is entered in the first bucket if the overall seat limit has not been reached
yet. Otherwise, no free seat is available, which means the user's request to start another Full Isolation browser session is
rejected.

When a bucket rollover happens, the third bucket expires. Users who were only recorded as using a seat in this bucket have their
entries dropped. A new bucket is then created to serve as the first, while the other two buckets each go down by one position.
This approach ensures that a user who is active on a seat at least once a day has this seat permanently available.
Because a rollover happens only every twelve hours, it can take up to twelve hours until a seat is actually freed up after a user
has ceased to be active on it.
VIP users
A user can be awarded VIP user status and entered in a VIP list. VIP users have seats reserved for their requests to apply Full
lsolation to their browser sessions.
Seats cannot be reserved for all VIP users on the list if their number is higher than the total number of available seats or if a user
is added to the VIP list while all available seats are occupied by VIP and other users.
Using a VIP list can impact other users who might not be able to apply Full Isolation to their browser sessions even if free seats
are available, but reserved for VIP users.
Access for support

To retrieve information and run support workflows, the license control system can be accessed using internal support tools.

About the web policy code view
The user interface for MVISION Unified Cloud Edge provides a code view option. Using this option, you can view the code for the
web policy functions and modify it.
Caution: Improperly modifying this code can severely damage the web policy functions. Be sure to understand the code before
you change it or add anything to it.
The code view allows you to adapt the web policy functions, for example, anti-malware filtering or the full isolation mode of
browser isolation, to your requirements in a way that other options of the user interface do not offer.
This documentation:
• Tells you how to access the code view
To be able to access this view, an administrator must have enabled access for you.
• Explains important concepts that you need to understand about the code
• Provides examples of how to modify the code
A glossary of important code terms is also provided.
Understanding the web policy code

The web policy code underlies the functions MVISION Unified Cloud Edge provides to enable a policy that ensures protection
against web threats.
Web threats can arise when users access the web. A web policy specifies rules for taking measures against web threats if they
arise.
How the code enables a web policy

A general rule for a policy against web threats could read as follows.
• If a threat arising from web usage is recognized, then do something against it.
A rule that addresses a particular threat, for example, a malware-infected file, would read:
• If a file sent from a website in response to a user's request is found to be malware-infected, then block the response with this file.
In the web policy code, this rule is expressed by a statement that basically looks like this:
IF MWG.Body.Infected THEN MWG.Block
When this piece of code is processed, a file that a user requests access to is blocked if it is found to be infected. It is also referred
to as IF-THEN statement or simply as rule.
The following two code items are mainly involved here:
• Function: MWG.Body.Infected
• Procedure: MWG.Block
Referring to these items, you could also paraphrase the statement as follows:
• If a particular function returns a value (that shows there is a web threat), then a suitable procedure is executed.
Or, more shortly:
IF <Function returns (critical) value> THEN <Execute procedure>
The web policy code for MVISION Unified Cloud Edge includes all kinds of IF-THEN statements or rules that address all kinds of
web threats. Together they make up your web policy.
When a website sends a file in response to a user's request, it is usually sent as the body of the response. This is why the name of
the function in the example includes a Body part. The response body is scanned following a rule of your web policy. If it is found
to be infected, it is not forwarded to the user.

Note: These code items and others were developed for MVISION Unified Cloud Edge based on similar items of the McAfee Web
Gateway on-prem web security product. Many of them are, therefore, prefixed by MWG.
Routines
Code statements or rules that address the same kind of web threat are included, together with other code items, in a routine.
There is a routine with rules for anti-malware filtering, URL filtering, media type filtering, and so on.
Other routines include rules for applying a particular method of protection against web threats. For example, there are routines
for different modes of isolating a user's browser or for coaching a user's access to the web.
The name of a routine appears, together with the term ROUTINE, at the beginning of the code portion that makes up this routine,
for example:
ROUTINE Anti_Malware_Rules
On the normal user interface, the Web Policy pages also offer suitable options for dealing with all kinds of web threats and
unwanted web usage.
Usually each page addresses a particular kind of web threat as well. The code view option on each page allows you to access the
underlying routine.
Pages and routines correspond to each other, for example, as follows:
• Page: Anti-Malware — Routine: Anti_Malware_Rules
• Page: Category, Reputation & Geo — Routine: URL_Filtering_Rules
• Page: Full Isolation — Routine: Full_Isolation
Main parts of a routine

A routine within the web policy that is implemented under MVISION Unified Cloud Edge usually has three main parts. These are
not formal sections of the code, but are distinguished here to allow for a better understanding of the code structure.
• Initial part — Begins with ROUTINE. Includes the routine name, the processing cycle or cycles where the routine is run, and
information about whether the routine is enabled.
Example:
ROUTINE Anti_Malware_Rules ON (Web.Request,Web.Response,EmbeddedObject) [enabled="true"]
• Variable setting — Variables are set here to particular values for further use in the routine.
While most variables are usually set in one place within a routine, this can also be done later on. In addition to variables, other
code items can also be set here.
Example:
NUMBER transferSizeLimit = 209715200
• IF-THEN statements — Several statements with an IF-THEN structure, which are also known as rules.
Example:
// Block If Virus Was Found IF MWG.BodyInfected (gam) THEN { MWG.Block (McAfee_Malware_found, "Block If Virus
Was Found", "Gateway Anti-Malware") }
Understanding the initial part of a routine

The initial part of a routine provides basic information about it, including its name, when it is run, and whether it is enabled.
The code portion that makes up a routine begins with the ROUTINE term. It continues with the routine name and some other
items.
These items are explained here in more detail:
• Routine name — Name of the routine preceded by ROUTINE
Example:
• Processing cycles — Cycles of the filtering process preceded by ON

Example:
ON (Web.Request, Web.Response, EmbeddedObject)

A routine is run when the filtering process on MVISION Unified Cloud Edge is in one of the cycles that are specified for it. These
cycles can be specified:
◦
Web Request — Cycle where user requests for web access are filtered
◦
Web Response — Cycle where responses to user requests received from the requested websites are filtered
◦
Embedded Object — Cycle where objects embedded in requests or responses are filtered
Only one of these cycles is going on at a given moment. Any combination of them can be specified for a routine, depending on
its purpose.
For example, only the request cycle is usually specified for a URL filtering routine because it serves the purpose of evaluating
and filtering URLs that are submitted in user requests.
All three cycles are usually specified for an anti-malware filtering routine because malware can inhere, for example, in a file that
is uploaded to the web, as requested by a user. It can intrude into your network through a file that is received as a response
from the web, or in an object that is embedded in a request or response.
Later in the routine, a particular processing cycle can be the condition of an IF-THEN statement. The cycle is checked using the
term Trigger:
IF Trigger == "Web.Request" THEN {
• Enabling — Information about whether the routine is enabled

Example:
[enabled="true"]
Understanding variable setting in a routine

After the initial part of a routine, variables are usually set for further use in this routine.
Example:
This variable is set in a routine for anti-malware filtering to limit the size of the web objects that are filtered. If a web object
exceeds this limit, it is allowed to skip the filtering to save time and resources.
The variable is used later on in an IF-THEN statement:
// Bypass Based on Size (default 200 MB) IF skipBigSize AND MWG.CycleName == "Response" AND MWG.BodySize >
transferSizeLimit THEN { END }
A comparison between the value of this variable and the size of a web object shows whether the limit is exceeded. The object
size is the return value of the MWG.BodySize function. The result of this comparison is one of three conditions in the IF clause.
If all three are met, a web object is allowed to skip anti-malware filtering. It means that no procedure is executed. So, THEN is
immediately followed by END.
Understanding IF-THEN statements in a routine

IF-THEN statements are used in a routine to specify measures that are taken, such as blocking a web object or forwarding it to a
user, and the conditions that must be met for taking these measures.
These statements are known as IF-THEN statements due to their structure and also as rules because of their function as elements
in a policy against web threats.
An IF-THEN statement can include another IF-THEN statement or more of them as embedded elements. A statement can also be
made more complex by using ELSE clauses. You will see this when you review individual routines.
What is explained in the following applies to statements that are not complex, but only include one IF and one THEN clause. Most
of it applies, however, in a similar way to complex statements as well.

The IF clause of an IF-THEN statement specifies a condition for taking a measure that is specified in the THEN clause. To find out
whether a condition is met, a function can be run to return a value that determines whether the condition is met. For a complex
condition, more functions and other code items can be used.
A function is run, for example, to scan a file for malware infections. If it returns the value TRUE, which means the file is infected,
the condition is met and a block procedure is executed.
Functions and procedures can have parameters, which are added to these code items in parentheses. This is explained here in
more detail:
• IF clause — Part of an IF-THEN statement specifying the condition that must be met for the measure in the THEN clause to be
taken
Example:
IF MWG.Body.Infected (gam)
An IF clause can include a function, which can have one or more parameters.
The condition that is specified in an IF clause can be complex and include, for example, more than one function. Functions are
connected by operators such as AND or OR.
• Function — Code item in an IF clause that is run to return a value to find out whether the condition specified by this clause is
met.
Example:
MWG.Body.Infected (gam)
If the return value for a condition to be met is TRUE, it is usually left out in the code. So ...
IF MWG.Body.Infected (gam)
can be read as:

IF MWG.Body.Infected (gam) = TRUE
• Function parameters — Modify the behavior of a function, for example, by specifying the settings of a component that
supports the function
Example:
(gam)
A component that is available on MVISION Unified Cloud Edge for supporting a function is referred to as a feature.
For example, when the MWG.Body.Infected function is run, it is supported by the Anti-Malware feature. This feature has settings that
can involve a particular scanning engine, for example, the Gateway Anti-Malware (GAM) engine, in the filtering process.
The GAM engine scans a file when it is received as the body of a response sent from a website. The result might be that this file
is infected.
Then the Anti-Malware feature provides the MWG.Body.Infected function with this result. The function returns TRUE, so the
condition is met and a block procedure is executed.
The settings for a feature are specified as a function parameter. In the example, the settings name is gam.
• THEN clause — Code item in an IF-THEN statement specifying what is to happen if the condition in the IF clause is met.
Example:
THEN { MWG.Block (McAfee_Malware_found, "Block If Virus Was Found", "Gateway Anti-Malware") }
• Procedure — Code item in a THEN clause that is executed if the condition in the IF clause is met.
A procedure can have one or more parameters.
Example:
MWG.Block (McAfee_Malware_found, "Block If Virus Was Found", "Gateway Anti-Malware")
• Procedure parameters — Modify the behavior of a procedure

Example:
(McAfee_Malware_found, "Block If Virus Was Found", "Gateway Anti-Malware")
The parameters in this example have the following meanings:

◦
Block reason: McAfee_Malware_found
This reason is usually shown in the block message.
◦

Name of the blocking rule: "Block If Virus Was Found"
This name is usually shown in the block message.
◦
Setting name: "Gateway Anti-Malware"
What functions do in a routine

Functions return values that are needed, for example, to find out whether a condition is met that requires a procedure to be
executed.
For example, to find out whether the condition is met for executing a procedure that blocks an infected file, a function is run. It
lets the file be scanned and returns TRUE or FALSE, depending on whether the file is found to be infected or not.
This function is explained here in more detail as an example.
MWG.BodyInfected(<Setting>)
Returns value of type: Boolean
This function lets a web object, for example, a file, be scanned and returns TRUE if the result of the scanning is that the file is
infected by a virus or other malware. Otherwise it returns FALSE.
The file might have been received, for example, as the body of a response that a website sent to respond to a user's download
request.
The file can be scanned using different methods involving different scanning devices, for example, the Gateway Anti-Malware
(GAM) scanning engine. The setting parameter specifies a setting for the function that determines which method and engine or
engines are involved in the scanning.
The setting for involving the GAM scanning engine is the MWG.AntimalwareSetting:
MWG.BodyInfected(MWG.AntimalwareSetting)
This setting name can be replaced with gam in a routine, for example, in the variable setting part.
MWG.AntimalwareSetting gam = McAfee_Gateway_AntiMalware
The name that the setting has when it is configured for a web policy feature is specified here as McAfee_Gateway_AntiMalware.
When the function is used in an IF clause to find out whether the condition of being infected is met for a file, the parameter name
is gam.
IF MWG.BodyInfected (gam)
What procedures do in a routine

Procedures are executed as measures against web threats if particular conditions are met.
For example, a block procedure is executed if the condition is met that a file that was received from a website is infected.
This procedure is explained here in more detail as an example.
MWG.Block (<Block reason and other parameters>)

This procedure blocks requests and responses.
It is used, for example, in the Anti_Malware_Rules routine to block a response from a website with an infected file as its body.
This file is not forwarded to the user who requested access to it. A block message is sent to the user instead providing the block
reason and other information.
You can edit the layout and structure of a block message using the options provided under End User Notification Pages on the user
interface.
• Procedure with sample parameters:
MWG.Block (McAfee_Malware_found, "Block If Virus Was Found", "Gateway Anti-Malware")
These parameters specify:

◦ Block reason: McAfee_Malware_found
◦ Name of the blocking rule: Block If Virus Was Found
◦ Setting name: Gateway Anti-Malware
• Procedure in a sample statement:
IF MWG.BodyInfected (gam) THEN { MWG.Block (McAfee_Malware_found, "Block If Virus Was Found", "Gateway Anti-
Malware", "Gateway Anti-Malware") }
This statement is included in the Anti_Malware_Rules routine where it blocks malware-infected web objects.
Working with web policy items in the code view and on the user
interface
You can complete many web policy activities both in the code view and on the normal user interface, for example, setting a
variable or enabling a rule.
So, to understand the code view, it helps if you have a good understanding of the options on the normal user interface.
For example, if you know you can enable a rule on the user interface that lets web objects skip anti-malware filtering, you can
look for items that correspond to this rule when reviewing the code. Understanding what this rule does from working with it on
the user interface helps you recognize corresponding items in the code view.
There are also web policy items that you can only work with in the code view, but not on the user interface. On the other hand,
you can complete some activities only using options of the user interface.
In the following, examples are given for all three kinds of web policy items and the way you can work with them.
For a code item, the routine that it belongs to is added. For an option on the user interface, the web policy page where it appears
is added.
transferSizeLimit variable
This variable is an example of a web policy item that you can work with both in the code view and on the user interface.
The value that this variable is set to is a limit that is observed in the anti-malware filtering process. If a file exceeds this limit, it
can be exempted from anti-malware filtering to save time and resources.
Here's how this variable appears in the code and on the user interface.
• In the code view:
◦
Routine: Anti_Malware_Rules
◦
Code item:
• On the user interface:

◦
Page: Web Policy — Anti-Malware
◦
Option: Transfer Size Limit
This option is available on a side panel that appears when the following rule is clicked: Skip GAM processing if transfer size is
greater than specified limit.
When you change the value for this size limit in the code view, the change appears on the user interface. If you change it on the
user interface, it appears in the code view.
The variable is used in the Bypass Based on Size rule.
Block If Virus Was Found rule

This rule is an example of a code item that has no corresponding option or options on the normal user interface. You cannot
modify or enable and disable it there, but only in the code view.

The rule is for blocking web objects that are infected by viruses and other malware.
Here's how this rule appears in the code view:
• Routine: Anti_Malware_Rules
• Code item:
Lists
A list of your web policy is an item that you can only work with in the code view to some extent.
In the code view, you can specify a list as a parameter of a function in a rule. For example, in a rule that lets URLs skip URL
filtering a list named skipURLs can be a parameter of the MWG.Url.Smart.Match function.
// Bypass URL Filtering for URL Filtering Bypass URLs IF skipByURL AND MWG.Url.SmartMatch (skipURLs) THEN
{ END }
But you cannot fill list entries in the code view. To do this, you need to work with the pages of the List Catalog on the user interface.
Sample routine: Anti_Malware_Rules

The Anti_Malware_Rules routine is for blocking files and other web objects that are malware-infected.
It includes a block rule, but also rules for exempting web objects from anti-malware filtering based on several criteria.
Reviewing this routine in the code view and reading what is explained here about it, should improve your understanding of how
an individual routine works.
You can access the code view for this routine from the Web Policy — Anti-Malware page, which belongs to the Threat Protection branch of
the policy tree.
Initial part
This part of the routine includes the usual ROUTINE term, routine name, processing cycles during which the routine is run, and
enabling information.
ROUTINE Anti_Malware_Rules ON (Web.Request, Web.Response, EmbeddedObject) [enabled="true"]
Variable setting
There are seven variables set in this part for use later in the routine.
• Three of them serve the purpose of enabling or disabling a particular rule of the routine.
Example:
BOOLEAN skipGAMByUrls = TRUE
This variable is evaluated when the rule that allows web objects to skip anti-malware filtering is processed. Processing only
continues for the rule if the value of this variable is TRUE.
• The remaining four variables serve other purposes.
Example:
This variable is evaluated when the rule that allows web objects to skip anti-malware filtering depending on their size is
processed.
These variables can also be set using options on the normal user interface.
IF-THEN statements
This part includes six IF-THEN statements (rules).
• There is a rule for blocking infected web objects. It is only visible and accessible in the code view.
• Three rules are for allowing web objects to skip anti-malware filtering based on various criteria, for example, user agents or
domains. These rules have corresponding options on the normal user interface.
For example, the rule that allows web objects to skip anti-malware filtering based on URLs can also be enabled or disabled
using a checkbox on the user interface. It relies on a list of web objects, which you enter in the list on the normal user interface.
• Two rules serve other purposes. Like the block rule, they are only visible and accessible in the code view.

The order in which these rules follow each other in the code is important.
The block rule is in last position. If anti-malware filtering is skipped for a web object because any of the rules that go before this
rule requires this, the filtering process stops. This means the block rule is not processed anymore.
In the following, some of these rules are explained in more detail. The rules are referred to by rule names, which are taken from
the comment lines in the code.
• Block If Virus Was Found — This rule is the key rule in this routine. It blocks files and other web objects if they are found to be
infected by viruses and other malware.
It is also one of the most important rules in the web policy that is implemented under MVISION Unified Cloud Edge, as
protection against malware is one of the most important reasons for installing this solution.
Regardless of its importance, the structure of this rule is rather simple.
Code items are used here as follows.

◦
There is one condition.
IF MWG.BodyInfected (gam)
Is a web object that was received as the body of a request or response infected by malware? If it is, then this
condition is met, and the procedure in the THEN clause is executed.
The MWG.BodyInfected function is run to find out whether a web object is infected. It is supported by the Anti-Malware
for GAM feature, which runs with a setting that involves the Gateway Anti-Malware (GAM) scanning engine in the
filtering process. It is this engine that performs the scanning of the web object.
In the code, the feature setting appears in parentheses next to the function.
MWG.BodyInfected (gam)
The setting is specified shortly here as gam. In the variable setting part of the routine, gam is set as the name of the
current setting for the Anti-Malware for GAM feature and identified as the McAfee_Gateway_AntiMalware setting. This
setting or configuration is also accessible over the normal user interface.
MWG.AntimalwareSetting gam = McAfee_Gateway_AntiMalware
On the Web Policy — Anti-Malware page of the user interface, which is also the page that provides access to this routine, it
is indicated when the Anti-Malware for GAM feature is in use and what its current configuration is.
◦
If the condition matches, the MWG.Block procedure is executed to block the infected web object. Depending on the
setting of the procedure, a block message is also sent to the user who requested access to this web object.
THEN { MWG.Block (McAfee_Malware_found, "Block If Virus Was Found", "Gateway Anti-Malware" }
The procedure has parameters, which specify the following:

◦ Block reason: McAfee_Malware_found
◦ Name of the blocking rule: "Block If Virus Was Found"
◦ Setting name: "Gateway Anti-Malware"
• Bypass Gateway Anti-Malware for Gateway Anti-Malware Bypass URLs — This rule allows web objects with URLs that are
on a bypass list to skip anti-malware filtering.
// Bypass Gateway Anti-Malware for Gateway Anti-Malware Bypass URL IF skipGAMByUrls AND MWG.Url.SmartMatch
(bypassGAMURLs) THEN { END }
Code elements are used here as follows.

◦
There are two conditions.
IF skipGAMByUrls AND MWG.Url.SmartMatch (bypassGAMURLs)
The first of them is met if the value of skipGAMByUrls is TRUE. It means this rule, which lets web objects skip anti-
malware filtering, is enabled. The variable is set in the variable setting part of the routine. It can also be set using an
option of the user interface.
The second condition matches if the MWG.Url.SmartMatch (bypassGAMURLs) function returns that the URL of the web
object matches with an entry in the bypassGAMURLs list.
◦

If both conditions match, the THEN clause applies. Because this is a bypass rule that lets web objects skip anti-
malware filtering, nothing is done here. No procedure is executed, so THEN is followed by END.
• Bypass Based on Size — This rule allows web objects with a size that exceeds a given limit to skip anti-malware filtering. This is
done to save time and resources.
// Bypass Based on Size (default 200 MB) IF skipBigSize AND MWG.CycleName == "Response" AND MWG.BodySize >
transferSizeLimit THEN { END }
Code elements are used here as follows.

◦
There are three conditionse.
IF skipBigSize AND MWG.CycleName == "Response" AND MWG.BodySize >transferSizeLimit
The first of them is met if the value of skipBigSize is TRUE. It means this rule, which lets web objects skip anti-
malware filtering if they are too big, is enabled. The variable is set in the variable setting part of the routine. It can
also be set using an option of the user interface.
The second condition is met if the MWG.Cycle.Name function returns "Response", which means the routine is currently
running in the response cycle of the filtering process.
Large files and other large web objects can be received from web sites in response to requests from users. This is
why the routine is run in the response cycle.
The third condition is the key condition of this bypass rule. It is about what the bypassing is based on. It is met if the
size of a web object, which the MWG.Body.Size function delivers as its return value, is higher than the value of the
transferSizeLimit variable. This variable is set in the variable setting part of the routine or using an option on the
user interface.
◦
If all three conditions are met, the THEN clause applies. Because the purpose of this rule is to let web objects skip
anti-malware filtering, nothing is done here. No procedure is executed, so THEN is followed by END.
Sample routine: Category_And_Domain_Coaching

The Category_And_Domain_Coaching routine is for allowing a user's request to access a website that would otherwise be blocked
if the user confirms there is a business reason for accessing it.
Handling a user's request in this way is also known as coaching. Two complex rules for coaching are included in this routine. They
perform coaching based on URLs for particular domains and on URL categories.
You can access the code view for this routine from the Web Policy — Category & Domain Coaching page, which belongs to the Web Filtering
branch of the policy tree.
Initial part
This part of the routine includes the usual ROUTINE term, routine name, processing cycle in which the routine is run, and enabling
information.
ROUTINE Category_And_Domain_Coaching ON (Web.Request) [enabled="true"]
Only Web.Request is specified here as the processing cycle because this is a routine for filtering requests for access sent by users
to websites.
Variable setting
There are four variables set in this part for use later in the routine.
• Two of them are used to determine if there is a time limit for a coaching session and, if so, what this limit is.
BOOLEAN sessionTTL = TRUE NUMBER coachSessionMinutes = 60
• Another variable is used to determine if the coaching that this routine enables is to be performed based on URLs for particular
domains or not. The list of URLs that the rule for enabling URL-based coaching relies on is specified as well.

It is also specified how this list relatest o the list of URLs for coaching that is provided using the list catalog in MVISION Unified
Cloud Edge.
BOOLEAN coachByURL = TRUE MWG.SmartMatchList coachURLs = Web_Filtering_Coach_URLs
A similar variable is set for coaching based on URL categories. The relevant lists are also specified.
BOOLEAN coachByCategory = TRUE VECTOR<MWG.UrlCategory> coachCategories = Coach_URL_Categories
IF-THEN statements
In this part, there are two complex IF-THEN statements (rules) for performing coaching based on different criteria.
• A rule for coaching based on URLs for particular domains
• A rule for coaching based on URL categories
These rules are explained here in more detail:
• Coaching based on URLs for particular domains — This coaching rule relies on a list with URLs for domains. When a user
requests access to a domain with a URL that is in this list, it is granted with coaching.
To perform the coaching itself, the rule calls another routine, which is not explained here.
CALL "CoachingAction"
The complete code for this rule looks like this.

IF coachByURL AND MWG.Url.SmartMatch (coachURLs) THEN { callParameter = callParameter.Set
("coaching_session_minutes", coachSessionMinutes) callParameter = callParameter.Set ("coaching_session_id",
"coachURL") CALL ("CoachingAction") END }
Code items are used here as follows.

◦
There are two conditions.
IF coachByURL AND MWG.Url.SmartMatch (coachURLs)
The first of them is met if the value coachByURL variable is TRUE. This means that coaching based on URLs for
particular domains is performed. The variable can be set in the variable setting part of the routine.
The second condition is met if the MWG.Url.SmartMatch function returns that the URL of a particular domain is in the
coachURLs list.
◦
If both conditions are met, the THEN clause applies.
THEN { callParameter = callParameter.Set ("coaching_session_minutes", coachSessionMinutes)
callParameter = callParameter.Set ("coaching_session_id", "coachURL") CALL ("CoachingAction") }
Coaching is not performed by a procedure here. The "CoachingAction" routine is called instead to handle the
coaching.
Before this routine is called, two sets of call parameters, including the session length, the session ID, and the list with
the URLs for coaching, are handed over.
• Coaching based on URL categories — This coaching rule relies on a list with URL categories. When a user requests access to a
domain with a URL that falls under a category in this list, it is granted with coaching.
To perform the coaching itself, the rule calls another routine, which is not explained here.
CALL ("CoachingAction")
The complete code for this rule looks like this.

// Coaching action for URLs Whose Category is Listed in Coached URL Categories IF coachByCategory AND
coachCategories.Overlaps (MWG.UrlCategories (MWG.LAST_USED_config)) THEN { callParameter = callParameter.Set
("coaching_session_minutes", coachSessionMinutes) callParameter = callParameter.Set ("coaching_session_id",
"coachCategories") CALL ("CoachingAction") END }
This rule has the same structure and uses mostly the same code items as the rule for coaching based on URLs for particular
domains. The following is different:
◦
A different variable is evaluated to find out whether the condition is met that the rule is enabled. Its name is
coachByCategory, not coachByURL.
IF coachByCategory

A list with URL categories is used to find out when coaching is to happen. Its name is coachCategories. If a website
that a user requests access to has a URL that falls under a category in this list, access is not blocked, but allowed with
coaching.
◦
A different method is used to find out whether a particular URL category is in this list.
coachCategories.Overlaps (MWG.UrlCategories (MWG.LAST_USED_config)
This method checks whether there is an overlap between the list of URL categories for coaching and the URL
category that the URL for the requested website falls under, or rather whether this URL category is in the list.
Because a URL can fall under more than one category, the overlap can involve several categories.
The MWG.UrlCategories function, which is specified here as a parameter, retrieves the category or categories that the
URL for the requested website falls under.
MWG.UrlCategories (MWG.LAST_USED_config)
The setting that this function uses while retrieving categories is provided by another function. The name of this
function is MWG.LAST_USED_config. It is specified here as a parameter of the MWG.UrlCategories. function, which is
itself a parameter of the method that finds out about the overlap.
Sample routine: Full_Isolation

The Full_Isolation routine is for isolating a user's browser during web usage. When a browser is isolated, only images of web
content are forwarded to it, not the original content, in order to ensure it is protected against web threats.
Isolating a browser in this way is also known as Remote Browser Isolation (RBI). This routine includes a complex rule for applying
the full mode of browser isolation. Other rules are provided for determining when full isolation is not to be applied and what is
allowed while it is applied, for example, file upload or download.
You can access the code view for this routine from the Web Policy — Full Isolation page, which belongs to the Browser Isolation branch of
the policy tree.
Initial part
This part of the routine includes the usual ROUTINE term, routine name, processing cycles during which the routine is run, and
enabling information.
ROUTINE Full_Isolation ON (Web.Request, Web.Response) [enabled="false"]
This routine is not enabled by default.
Variable setting
About 40 variables and other items are set in this part for use later in the routine. Most of them are set for one of the following
purposes:
• Specifying the criteria on which full isolation should be applied
It could be applied, for example, only when a user requests access to a domain that is in a list.
BOOLEAN isolateByDomain = TRUE
When isolation is performed in this way, it is specified which list is used here. It is also specified how this list relates to the list
for isolating by domain that is in the list catalog of MVISION Unified Cloud Edge.
MWG.SmartMatchList alwaysIsolatedDomains = Domainstoalwaysisolate3
• Specifying where full isolation should not be applied

It might not be applied, for example, when a user requests access to a website with a URL that is in a list. The list with the URLs
and the corresponding list in the catalog are also specified.
BOOLEAN bypassByURL = TRUE MWG.SmartMatchList urlBypassList = FullIsolationDomainsexemptfromisolation3
• Specifying what should be allowed while full browser isolation is applied

For example, uploading files to domains, might be allowed, except for those that are in a list. The relevant list and the
corresponding catalog list are also specified.

BOOLEAN permitUploadByDomain = TRUE UCE.FileTransferControlList permitUploadExceptions =
Uploadspermittedexceptforthese3
IF-THEN statements
This part includes two rather complex and six less complex IF-THEN statements (rules).
• There is a complex rule for applying the full isolation mode of browser isolation.
• Another complex rule handles permissions to use the clipboard when full isolation is applied.
• Five rules are about not applying full isolation depending on criteria such as URLs, URL categories, and IP addresses.
• One rule is for finding out whether a different type of browser isolation is already being applied when a user requests web
access. Full isolation is then not applied.
The rule that applies full isolation is explained here in more detail:
• Applying full isolation — This rule is the key rule in this routine. It is rather complex and includes also code for handling file
uploads and downloads during the isolation, along with code for handling license expiration.
To perform the isolation itself, the rule calls another routine, which is not explained here.
CALL "RBI_Isolation"
The complete code for this rule looks like this:

IF startIsolation THEN { RBI.ApplyFullIsolationSettings (blockOnLicenseExceeded, cookiesOnLocalMachine,
copyLocalMachine, pasteLocalMachine, maxClipboardPasteSize, maxClipboardCopySize) // Isolated File Upload
Control IF permitUploadByDomain THEN { RBI.SetUploadFileControlPermit (permitUploadExceptions) } ELSE
{ RBI.SetUploadFileControlBlock (denyUploadExceptions) } // Isolated File Download Control IF
permitDownloadByDomain THEN { RBI.SetDownloadFileControlPermit (permitDownloadExceptions) } ELSE
{ RBI.SetDownloadFileControlBlock (denyDownloadExceptions) } CALL "RBI_Isolation" IF blockOnLicenseExceeded
AND RBI.MustBeIsolated THEN { MWG.Block (McAfee_RBI_No_Session, "Full Browser Isolation cannot be used", "Full
Browser Isolation") } }
Code elements are used as follows here.

◦
If you omit the two embedded IF-THEN statements that handle file upload and download during the isolation, as well
as the embedded statement about license expiration, a basic statement for handling the isolation proper is left over.
It reads like this:
IF startIsolation THEN { RBI.ApplyFullIsolationSettings (blockOnLicenseExceeded,
cookiesOnLocalMachine, copyLocalMachine, pasteLocalMachine, maxClipboardPasteSize,
maxClipboardCopySize) CALL "RBI_Isolation" }
◦ In the IF clause of this basic statement, the startIsolation variable is evaluated, which is set before the overall
statement for applying full isolation is processed.
BOOLEAN startIsolation = isolateAll OR (isolateByDomain AND MWG.Url.SmartMatch
(alwaysIsolatedDomains)) OR (isolateByRegex AND alwaysIsolatedRegexList.Matches (MWG.Url.Host)) OR
(isolateByIPRange AND Net.IsInRangeList (MWG.DestinationIP, alwaysIsolatedIPRanges)) OR
(isolateByCategory AND MWG.UrlCategories (MWG.LAST_USED_config).Overlaps (alwaysIsolatedCategories))
OR (isolateUncategorized AND MWG.UrlCategories (MWG.LAST_USED_config).Size == 0)
The value of startIsolation varies according to how the range for applying full isolation has been set.
For example, this range might have been set to isolating the user's browser for all that the user wants to access in
the web, which can be done by setting the isolateAll variable in the variable setting part of this routine accordingly.
isolateALL = TRUE
If this range is not set to everything in the web, but limited to particular domains or destinations with particular IP
addresses or depending on other criteria, startIsolation is set to the respective value.
A function is also used then to find out if the domain or IP address, or whatever it is, is in a list.
For example, for applying full isolation to particular domains, the value for startIsolation is:
isolateByDomain AND MWG.Url.SmartMatch (alwaysIsolatedDomains)
◦
If a range for applying full isolation can be determined by evaluating startIsolation, the condition for actually
starting it is met. What is included in the THEN clause of the basic statement is executed, which means the routine for
applying full isolation itself is called.
Before this routine is called, a procedure hands over settings for this isolation, for example, regarding what should be
allowed while it is applied.
RBI.ApplyFullIsolationSettings (blockOnLicenseExceeded, cookiesOnLocalMachine, copyLocalMachine,
pasteLocalMachine, maxClipboardPasteSize,

And then ...
CALL "RBI_Isolation"
◦
The embedded statement for handling file uploads includes a Boolean variable in the IF clause. If its value is TRUE,
the condition for executing what is included in the THEN clause is met.
Otherwise, what is in the ELSE clause is executed. This way file uploads are either allowed or denied under full
isolation.
// Isolated File Upload Control IF permitUploadByDomain THEN { RBI.SetUploadFileControlPermit
(permitUploadExceptions) } ELSE { RBI.SetUploadFileControlBlock (denyUploadExceptions) }
File downloads under full isolation are handled in the same way.
◦
The embedded statement on license expiration blocks access to all websites that isolation would otherwise have
been applied to. The condition for this is that the license for the isolation feature has expired.
IF blockOnLicenseExceeded AND RBI.MustBeIsolated THEN { MWG.Block (McAfee_RBI_No_Session, "Full
Browser Isolation cannot be used", "Full Browser Isolation") }
Glossary of important web policy code terms

This glossary lists and explains important terms in the code for the web policy that is implemented under MVISION Unified Cloud
Edge.
Term Description
Function A piece of code that performs a particular task, for example,

finding out whether a URL falls under a category that is in a
block list
A function returns a value and can have parameters, for
example, the setting for a feature that supports the function.
Example:
MWG.UrlCategories (gtiSetting)
The MWG.UrlCategories function returns the category or

categories that a particular URL falls under.
The function is supported by the Web Filtering feature, which is
configured with the (gtiSetting) setting.
This setting involves the Global Threat Intelligence (GTI)
database, where information about URLs and their categories
is stored, in the URL filtering process.
IF-THEN statement A statement in a routine that specifies a condition and what is

to happen if the condition is met
A simple IF-THEN statement includes an IF and a THEN clause.
Example:
IF MWG.BodyInfected (gam) THEN { MWG.Block
(McAfee_Malware_found, "Block If Virus Was
Found", "Gateway Anti-Malware") }
A more complex IF-THEN statement can have more than one

condition, ELSE clauses, and embedded IF-THEN statements.
An IF-THEN statement is also referred to as rule.
Procedure A piece of code that performs a particular task, for example,

blocking a file that was received from a website in response to
a user's request

Term Description
A procedure does not return a value. It can have parameters.
Example:
MWG.Block (McAfee_Malware_found,"Block If Virus
Was Found", "Gateway Anti-Malware")
The MWG.Block procedure blocks a file. The parameters

specify the block reason, the name of the blocking rule, and
the name of the setting for the procedure.
The setting lets the procedure send a block message to the
user who requested access to the file that was blocked.
Routine A usually larger portion of code that enables a particular web

policy function, for example, anti-malware filtering or
applying full browser isolation, and determines its behavior
A routine includes other code items such as functions and
procedures.
In the code, a routine begins with the ROUTINE term and the
routine name.
Example:

Integrating Zero Trust Network Access (ZTNA) Partners
MVISION Unified Cloud Edge integrates your ZTNA partners to leverage visibility of ZTNA partners site within the solution.
• When you have a ZTNA Partner — Only the ZTNA partners you have subscribed to are displayed. You can download the list of
IP addresses that are bypassed in the ZTNA application in a CSV format. You can configure the downloaded IP address list in
the Client Proxy policy to bypass the traffic in McAfee® Web Gateway.
• When you do not have a ZTNA Partner — The McAfee MVISION Marketplace link is displayed, where you can create a new
subscription.

Zero Trust Network Access
Zero Trust Network Access (ZTNA) provides secure access to applications and services both for users in the corporate network
and remote users. ZTNA framework treats every access attempt originates from an untrusted network. Access to any resource is
denied by default and grants explicit access only after authenticating and authorizing. This approach enables tighter network
security and micro-segmentation that can limit lateral movement if a breach occurs. It ensures that security and access decisions
are dynamically enforced based on identity, device, and user context.
Need for ZTNA

Corporate resources are moving out of enterprise boundaries (public clouds and private data centers), user-owned devices, and
remote workers have challenged organizations to protect their network and sensitive data. The network-centric approach to
security and access is no longer sufficient to protect the company's assets. Traditional Virtual Private Network (VPN) fails to
secure the workforce connecting remotely to cloud-based deployments. So organizations now need a new security model to
adapt to the complexity of the dynamic business environments. McAfee offers MVISION Private Access (MPA) to meet these
challenging needs and provides seamless and secure connectivity to private applications and resources.
How MVISION Private Access works

MPA does not trust any endpoints unless they are explicitly granted access to a given resource. It acts as a trust broker between
an authenticated user and an application. Based on the enforced private access control policies, it grants or denies access to the
applications. MPA makes outbound-only connections to hide both network and application infrastructure from unauthorized
users. Furthermore, it provisions access to the application through a secure and encrypted tunnel. Every user session connection
is authorized and authenticated before granting access.
Functional overview:
1. Authenticates users before granting access to an application. McAfee Client Proxy intercepts the traffic, validates the
application type (Private or Public), and directs the traffic to the nearest McAfee PoP.
2. The administrators create Private Access policies that sync with all McAfee PoPs. The McAfee PoPs apply the private access
policies, and the traffic diverges depending on the application type.
a. Directs traffic to the internet if the request is for accessing a public application.
b. Directs traffic to the McAfee POP that is nearest to the customer network (application server) if the request is for accessing
a private application
3. The McAfee PoP directs traffic through the tunnel to a connector, and the connector forwards the traffic to the requested
private application.

Key components
You must complete certain configurations to get started with MPA.
• McAfee PoP — McAfee PoPs direct traffic through the secure tunnel to the nearest connector, and connector forwards it to the
requested private application.
• Authentication — MPA authenticates every connection and session that the user makes. It supports single sign-on (SSO)
through SAML. For information, see SAML authentication.
• Connectors — MPA introduces a new component called Connectors, which is a lightweight virtual machine deployed in your
datacenter or in the private cloud. The connector establishes a secure connection with the nearest McAfee PoPs that are
deployed around the world. For information, see Deploy Connectors.
• McAfee Client Proxy (MCP) — When users access a private application from their device, the McAfee Client Proxy running on
the user device optimizes the traffic handling capabilities. It validates the application type (Private or Public), and directs the
traffic to the nearest McAfee PoP. For information about downloading and configuring MCP (Windows and macOS), see Install
McAfee Client Proxy.
• Device profile — You can ensure that only devices that comply with your predefined security policies can access the resources.
You can allow access from the device that are complying with one or more of the following policies: OS name, version, presence
of specific antivirus software on the device, if fixed disk of the device is unencrypted, whether the device holds the appropriate
certificate. For information, see Configure device profile.
• Private Access policy — You can create private access policies that are shared with all McAfee PoPs. The McAfee PoPs apply
these policies, and the traffic diverges depending on the application type. MPA grants access based on the enforced private
access policy. For information about private access policies, see Configure private access policy.

COPYRIGHT
Copyright © 2021 Musarubra US LLC.
McAfee and the McAfee logo are trademarks or registered trademarks of McAfee, LLC or its subsidiaries in the US and other countries.
Other marks and brands may be claimed as the property of others.

Mcafee Mvision Unified Cloud Edge Getting Started 11-2-2021

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mcafee Mvision Unified Cloud Edge Getting Started 11-2-2021

Uploaded by

Copyright:

Available Formats

McAfee MVISION Unified Cloud

Edge Getting Started

Getting started with MVISION Unified Cloud Edge

Securing sanctioned services

Setting web policies

Protecting sensitive data

MVISION Unified Cloud Edge Product Documents

2 McAfee MVISION Unified Cloud Edge Getting Started

McAfee MVISION Unified Cloud Edge Getting Started 3

1. Log on to MVISION Cloud and access the web setup pages:

Log on to MVISION Cloud for the first time

Set up Client Proxy

4 McAfee MVISION Unified Cloud Edge Getting Started

McAfee MVISION Unified Cloud Edge Getting Started 5

Secure web gateway

6 McAfee MVISION Unified Cloud Edge Getting Started

MVISION Unified Cloud Edge key features

Secure web gateway key features

McAfee MVISION Unified Cloud Edge Getting Started 7

Web policy key features

8 McAfee MVISION Unified Cloud Edge Getting Started

How MVISION Unified Cloud Edge works

McAfee MVISION Unified Cloud Edge Getting Started 9

10 McAfee MVISION Unified Cloud Edge Getting Started

Secure Web Gateway

McAfee MVISION Unified Cloud Edge Getting Started 11

MVISION Cloud users

Roles for web protection users

Role Users with manage permissions can...

Applying web changes globally

12 McAfee MVISION Unified Cloud Edge Getting Started

Your customer-specific proxy and customer ID

Client Proxy metadata

McAfee MVISION Unified Cloud Edge Getting Started 13

Secure the communication channel between Client Proxy and

Adding mobile devices to your protected endpoints

Supported operating system platforms and MDM solutions

Supported platforms Supported MDM solutions

Configuring the MDM software

14 McAfee MVISION Unified Cloud Edge Getting Started

Components needed to protect your mobile devices

How the mobile cloud security solution protects devices

McAfee MVISION Unified Cloud Edge Getting Started 15

Managing your customer CA

HTTPS Scanning rule sets

16 McAfee MVISION Unified Cloud Edge Getting Started

Benefits of SAML authentication

Benefits of SAML authentication

SAML authentication alone or with location information

SAML alone versus SAML with location information

Difference SAML alone SAML with location information

Location information No location information is provided. Location information is provided by IP

McAfee MVISION Unified Cloud Edge Getting Started 17

Logon requirement Users are prompted to log on using an No logon is needed.

SAML authentication steps

SAML alone SAML with location information

Shared SAML authentication steps

3) McAfee WGCS looks up the customer's identity provider service.

4) McAfee WGCS sends a SAML request to the identity provider.

Configuring SAML parties to work together

Configuration in your identity provider

Configuration on the endpoints