Security Policies
In Depth
Secure Web Gateway
Release 10.2
M86 SECURITY POLICIES IN DEPTH
© 2012 M86 Security
All rights reserved.
828 W. Taft Ave., Orange, CA 92865, USA
Version 10.2, published June 2011 for Secure Web Gateway
software release 10.2.
This document may not, in whole or in part, be copied,
photocopied, reproduced, translated, or reduced to any
electronic medium or machine readable form without prior
written consent from M86 Security.
Every effort has been made to ensure the accuracy of this
document. However, M86 Security makes no warranties with
respect to this documentation and disclaims any implied
warranties of merchantability and fitness for a particular
purpose. M86 Security shall not be liable for any error or for
incidental or consequential damages in connection with the
furnishing, performance, or use of this manual or the
examples herein. Due to future enhancements and
modifications of this product, the information described in this
documentation is subject to change without notice.
Trademarks
Other product names mentioned in this manual may be
trademarks or registered trademarks of their respective
companies and are the sole property of their respective
manufacturers.
M86 SECURITY
SECURITY POLICIES IN DEPTH
2
TABLE OF CONTENTS
Table of Contents
ABOUT THIS MANUAL ................................................... 6
Where To Go From Here. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
CHAPTER 1: SECURITY POLICY CONCEPTS.................... 7
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Types of Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Master Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
X-Ray Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Emergency Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
HTTPS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Full Bypass Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Cloud User Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Security Policy Components . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Rules and Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Rule Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Available Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
CHAPTER 2: DETAILED RULE DESCRIPTIONS ............... 37
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Allow Access to White Listed Sites . . . . . . . . . . . . . . . . . . . . . . . . . 37
Allow All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Allow and Scan Customer-Defined File Extensions. . . . . . . . . . . . . 43
Allow and Scan Customer-Defined True Content Type . . . . . . . . . . 44
Allow Known Legitimate Content . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Allow Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Allow Trusted Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Allow Whitelisted ActiveX, Java Applets and Executables . . . . . . . 48
Block Access to Adware Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Block Access to Blacklisted Sites . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Block Access to High-Risk Site Categories . . . . . . . . . . . . . . . . . . 58
Block Access to Spyware Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Block ActiveX, Java Applets and Executables by ACL . . . . . . . . . . 65
Block Binary Exploits in Textual Files . . . . . . . . . . . . . . . . . . . . . . . 68
M86 SECURITY
SECURITY POLICIES IN DEPTH
3
TABLE OF CONTENTS
Block Binary Objects With Invalid Digital Certificate . . . . . . . . . . . . 69
Block Binary Objects Without a Digital Certificate . . . . . . . . . . . . . . 71
Block Binary VAD Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Block Blacklisted File Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Block Customer-Defined File Extensions. . . . . . . . . . . . . . . . . . . . . 79
Block Customer-Defined True Content Type . . . . . . . . . . . . . . . . . . 80
Block Everything Except White Lists . . . . . . . . . . . . . . . . . . . . . . . . 81
Block Files with COM Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Block Files with Suspicious Multiple Extensions . . . . . . . . . . . . . . . 83
Block Illegitimate Archives (Including
Password-Protected Archives). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Block IM Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Block Known Malicious Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Block Known Spyware (ACL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Block Known Viruses (McAfee / Sophos / Kaspersky). . . . . . . . . . . 93
Block Malicious ActiveX, Java Applets and Executables. . . . . . . . . 96
Block Malicious Content (Malware Entrapment Engine) . . . . . . . . 102
Block Microsoft Office Documents
containing Macros and/or Embedded Files . . . . . . . . . . . . . . . . . . 103
Block Outgoing Microsoft Office Documents . . . . . . . . . . . . . . . . . 106
Block Potentially Malicious Archives . . . . . . . . . . . . . . . . . . . . . . . 109
Block Potentially Malicious Packed Executables . . . . . . . . . . . . . . 111
Block Revoked Cloud Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Block Spoofed Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Block Suspicious File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Block Unscannable (McAfee / Sophos / Kaspersky) . . . . . . . . . . . 117
Block Unscannable ActiveX, Java Applets and Executables. . . . . 117
Block Unscannable Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Customer-Defined URL Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Data Leakage Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Detect Known Trojan Network Activity. . . . . . . . . . . . . . . . . . . . . . 122
Temporarily Block Cloud Users . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Block Social Media Post Control . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Social Media Post Control Allowed Requests . . . . . . . . . . . . . . . . 124
Bypass Whitelisted URLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Block All HTTPS URLS Except White Lists . . . . . . . . . . . . . . . . . . 127
M86 SECURITY
SECURITY POLICIES IN DEPTH
4
TABLE OF CONTENTS
CHAPTER 3: IMPLEMENTING SECURITY POLICY .......... 128
Pre-supplied Policies Containing Rules . . . . . . . . . . . . . . . . 128
Establishing Site Security Policy — Key Points . . . . . . . . . 129
List of Available Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Rules Available for Security Policies . . . . . . . . . . . . . . . . . . . . . . . 131
Rule Available for HTTPS Policies. . . . . . . . . . . . . . . . . . . . . . . . . 133
Rules Available for Emergency HTTPS Policy . . . . . . . . . . . . . . . 133
Defining Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Creating a Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Creating / Editing a Rule in a User-Defined Policy . . . . . . . . . . . . 135
Adding / Editing Conditions in a Rule. . . . . . . . . . . . . . . . . . . . . . . 137
Example - Creating a New Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Setting Which Policies are Implemented . . . . . . . . . . . . . . . 146
Setting Policy Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Setting a Master Policy for an Administrator . . . . . . . . . . . . . . . . . 149
Assigning Policies to User Groups and Users . . . . . . . . . . . . . . . . 149
Defining User Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Fields and Options in the Security Definition Screens . . . . 153
Options Available in the Policy Tree . . . . . . . . . . . . . . . . . . . . . . . 153
Policy Details Screen - Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Rule Details Screen - Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Condition Details Screen - Fields . . . . . . . . . . . . . . . . . . . . . . . . . 158
APPENDIX A .............................................................. 159
M86 SECURITY
SECURITY POLICIES IN DEPTH
5
WHERE TO GO FROM HERE
About This Manual
This manual supplements the security policy information described
in the SWG Management Console Reference Guide and the
SWG User Guide, and it assumes that you are familiar with the
information in those guides.
Although some of the information contained in this manual also
appears in the SWG Management Console Reference Guide and
the SWG User Guide, this guide expands on SWG security
functionality in more depth and describes advanced SWG security
configuration.
Where To Go From Here
The chapters in this guide are sequenced in user-recommended
order.
• Before customizing security policy, you should be familiar with
the information in Chapter 1: Security Policy Concepts.
• For descriptions of the rules, rule definitions, and relevant
conditions, see Chapter 2: Detailed Rule Descriptions.
• For instructions and related information on how to customize
security policy, see Chapter 3: Implementing Security Policy.
• For sample diagrams of the Master Policy and the Security
Policy enforcement process, see Appendix A.
M86 SECURITY
SECURITY POLICIES IN DEPTH
6
CHAPTER 1: SECURITY POLICY CONCEPTS
Chapter 1: Security Policy Concepts
This chapter contains the following main sections:
• Introduction
• Types of Policies
y Master Security Policy
y X-Ray Policy
y Emergency Policies
y HTTPS Policies
y Full Bypass Policy
y Cloud User Policies
• Security Policy Components
y Rules and Conditions
y Rule Logic
y Available Conditions
• User Management
M86 SECURITY
SECURITY POLICIES IN DEPTH
7
INTRODUCTION
Introduction
Secure Web Gateway security is policy-based with advanced
configuration availability. Policies are built on rules that define the
actions to be taken when specific conditions are met.
SWG provides pre-supplied security policies, which are secured
against editing. To match an organization’s specific security
requirements, SWG enables new policy creation. To assist in
increasing policy configuration availability, the pre-supplied
secured policies can be copied and then edited as required.
The basic policy building block is a condition, which is satisfied
when an event is triggered. The condition is associated with a rule,
which, based on the triggered event, performs an action (and in
many cases also displays end-user messages). The rules action in
turn is associated with the organization’s security policy.
Security policies, their rules and conditions are defined in the
Management Console. The Management Console also enables
identification of which policies to use in which situations.
In addition to setting up security policies, the policies must be
associated with users or user groups. Users groups can be
defined, and then policies assigned specifically to individual
groups.
As the basis for maintaining user groups, SWG uses the
Lightweight Directory Access Protocol (LDAP) application protocol
for accessing and maintaining distributed directory information
services.
SWG enables users to be assigned to either LDAP groups or
non-LDAP groups. SWG does not require users to be assigned to
a group.
M86 SECURITY
SECURITY POLICIES IN DEPTH
8
CHAPTER 1: SECURITY POLICY CONCEPTS
Types of Policies
Secure Web Gateway provides the following pre-supplied security
policies.
Policy
For information, see:
•
•
•
•
Master Security Policy.
M86 X-Ray Policy (and X-Ray
Mode)
X-Ray Policy
•
•
Emergency Policies
M86 Emergency Policy
M86 HTTPS Emergency
Policy
M86 HTTPS Policy
HTTPS Policies
•
Cloud User Policies
•
M86 SECURITY
M86 Master Policy
M86 Basic Security Policy
M86 Medium Security Policy
M86 Strict Security Policy
M86 Blocked Cloud Users
Policy
M86 Revoked Cloud Users
Policy
Full Bypass Policy
Full Bypass Policy
•
•
•
•
For details, see the
Management Console
Reference Guide.
Caching Policy
Logging Policies
Identification Policies
Device Logging Policies
SECURITY POLICIES IN DEPTH
9
TYPES OF POLICIES
Master Security Policy
Master security policies are compulsory global policies for all
groups in an organization, and are in addition to Basic, Medium
and Strict policies implemented by lower level general
Administrators.
Master policies are created by Super Administrators and are
assigned to general Administrators for different user groups.
General Administrators can change policies or rules belonging to
their specific group only.
NOTES: A Master Policy can comprise any security policies within
the system. The Super Administrator can assign different Master
Policies to different Administrators or assign the same Master
Policies to all Administrators.
Figure 1-1 illustrates the relationships between Super
Administrators, general Administrators, and Security policies.
Figure 1-1: Master Policy Dependencies
M86 SECURITY
SECURITY POLICIES IN DEPTH
10
CHAPTER 1: SECURITY POLICY CONCEPTS
Master Security Policies
M86 provides three Security Policy levels to match an individual
organization's unique security requirements. Each provides a
progression in the security level.
• M86 Basic Security Policy: Provides a baseline policy when
connecting two relatively secure environments to each other.
Only the basic engines for client web security are activated.
• M86 Medium Security Policy: Provides better security when
connecting to the internet by building on top of the basic security
policy and adding more proactive, behavioral, real-time
elements. The policy uses all the security engines, and enforces
the standard measures or code analysis. This is the default
policy in the Management Console.
• M86 Strict Security Policy: Provides additional security
against the system being compromised in higher-sensitivity
environments. It utilizes all the rules and standards for secure
web behavior, while keeping HTML Repair enabled to provide a
usable browsing experience without blocking complete pages
that may have violated some security standards. HTML Repair
is part of the SWG Malware Entrapment Scanning Engine which
automatically repairs pages after removing suspicious code.
Security Policies – Setup
Security policies are configured using rule and condition
components. These components are described in greater detail in
Security Policy Components.
Policy configuration is intended for more experienced system
administrators. Existing pre-supplied advanced policies cannot be
modified, but can be copied and then edited, effectively creating
new policies with rules and conditions that can be fine-tuned.
M86 SECURITY
SECURITY POLICIES IN DEPTH
11
TYPES OF POLICIES
X-Ray Policy
An X-Ray Policy evaluates the effects of a planned security policy
on the system before implementation.
In an X-Ray policy, if a transaction meets the required conditions,
the rule is logged but not acted upon, and the transaction continues
being evaluated with the next rule, and so on for all rules in the
policy.
In this way, X-Ray Policy ensures that transactions are evaluated
against rules, but there is no blocking action or content change.
The results of the X-Ray Policy, and rules within, can be assessed
in the Logs View (under Logs and Reports in the Management
Console).
NOTES: Rules within the X-Ray Policy are not marked as X-Ray
mode.
X-Ray Mode
Even in non-X-Ray policies, individual rules can be placed in
X-Ray Mode (the Rule Definition screen displays an X-Ray Mode
check box for each rule). Rules in X-Ray Mode are logged but the
actions are not performed.
If both X-Ray and non-X-Ray Mode rules are activated in a
non-X-Ray policy, only the last triggered rule is reported.
Emergency Policies
The M86 Emergency Policy and M86 Hypertext Transfer Protocol
Secure (HTTPS) Emergency Policy are designed for cases where,
for example, Internet access in the organization has encountered
an infectious attack or where the organization has been infected by
malicious code.
Emergency Policies prevent and minimize damage by blocking
most network traffic while still enabling access to some pre-defined
web sites (for example, Windows Update).
M86 SECURITY
SECURITY POLICIES IN DEPTH
12
CHAPTER 1: SECURITY POLICY CONCEPTS
HTTPS Policies
M86 Hypertext Transfer Protocol Secure (HTTPS) Policies contain
rules dealing with HTTPS site access. HTTPS Policies define
which HTTPS sites are fully allowed, which HTTPS sites are
inspected, which HTTPS sites request user approval to continue,
and which HTTPS sites are blocked. The blocking mechanism is
based on White Lists, URL categorization, certificate error
checking, and certificate validation.
HTTPS Policies are displayed only for customers with the required
license.
Full Bypass Policy
This policy contains one rule (Allow All) ensuring no items are
scanned by the M86 engines. This rule can be set by
administrators and is intended for end-users who are permitted to
surf through the M86 SWG Appliance without any scanning.
Cloud User Policies
Cloud User policies determine user access:
• Blocked Cloud Users Policy: Defines policies for users who
are temporarily blocked from using the cloud.
• Revoked Cloud Users Policy: Defines policies for users who
are permanently revoked from using the cloud.
M86 SECURITY
SECURITY POLICIES IN DEPTH
13
SECURITY POLICY COMPONENTS
Security Policy Components
Rules and Conditions
The main Security Policies components are:
• Rules: Define the actions to be performed.
• Conditions: Determine if a rule is triggered.
Figure 1-2 illustrates the tree pane displayed for Policies in the
Management Console.
Figure 1-2: Security Policy Tree Pane
It is important to note the following about rule actions:
• The most common rule actions are as follows:
y Allow: The web content is allowed, usually with a specified
action requirement.
y Block: The web content is blocked.
M86 SECURITY
SECURITY POLICIES IN DEPTH
14
CHAPTER 1: SECURITY POLICY CONCEPTS
y Coach: The web content is temporarily blocked with the
end-user receiving a warning message, usually with a
specified action requirement.
• Depending on the defined action, the rule also contains one of
the following:
y Advanced Actions: Used for Allow actions.
y End-user Message: Used for Block and Coach actions.
Examples
The M86 Basic Security Policy comes with several rules including
the following (values are explained later in this document):
Rule: Allow Streaming
• Action: Allow
• Advanced Action: Bypass Scanning
• Condition name: True Content Type
Rule: Block Access to Blacklisted Sites
• Action: Block
• End-user Message: Blacklisted URL
• Condition Name: URL List
Rule: Data Leakage Prevention
• Action: Block
• End-user Message: Data Leakage Prevention
• Condition Name (there are two conditions):
y Data Leakage Prevention (Applies to Confidential
information)
y Direction (Applies to Incoming/Outgoing)
M86 SECURITY
SECURITY POLICIES IN DEPTH
15
SECURITY POLICY COMPONENTS
Rule Logic
A rule can include multiple conditions. For the rule to be enforced,
all its conditions must be matched. For example, a rule that
includes conditions regarding file extensions, time frames and
parent archive types, is enforced only if all of the conditions are
met.
Rules are enforced in the order determined by the rule priority list.
Rule priority determination is as follows:
• A rule’s priority is determined by its relative position in the rule
list, with the highest priority rule at the top, and the lowest at the
bottom. Rules can be moved up and down in the list to change
their priority level.
• Any action taken is according to the rule of highest priority
matching a given transaction.
• After a rule is enforced, lower priority rules are no longer
relevant and are not evaluated. Keep this in mind as you
consider the placement of rules in the policy. For example:
y In Blocking rules, consider which blocking reason is likely to
provide the most important information in the logs, reports
and notifications. For example, if access can be blocked in
case of a virus or a suspicious file type, the virus name is
probably more important than the file type. Therefore, to
ensure that the virus name is provided, place the Anti-Virus
rule before the Suspicious File Type rule.
y In Allow rules, if the conditions of a higher priority rule are
matched, the rules after that are not be checked against
content. In other words, a matched Allow rule effectively
creates a virtual trust level, and any content received after the
matched Allow rule is not scanned by any blocking rules.
M86 SECURITY
SECURITY POLICIES IN DEPTH
16
CHAPTER 1: SECURITY POLICY CONCEPTS
• If a rule is not specific to any of the listed values for a condition,
instead of selecting all possible values, do not use the condition,
and leave it blank.
• All rules can be used in X-Ray mode, where rule activities are
logged but no action is taken. The rule activity is displayed in the
logs, enabling production environment fine tuning, or rule review
and its related policy.
Rule Processing Flow
The security rule processing flow is divided into two phases:
• Request Phase
y If a Block action is triggered by a rule in the Request phase,
the request is not sent to the destination server, and an
appropriate message is displayed to the user.
y If a Coach action is triggered by a rule in the Request phase,
an appropriate message is displayed to the user. If the user
then approves the message, the request is sent to the
destination server. The Coach action applies only to the
Request phase.
• Response Phase
y Any content received in the response phase is evaluated
regardless of the action taken in the Request phase.
y If an Allow action is triggered, the content is passed to the
user. In addition, if no action is taken, the default action is an
implicit Allow.
y If a Block action is triggered, the content is not passed to the
user, and an appropriate error message is displayed to the
user.
M86 SECURITY
SECURITY POLICIES IN DEPTH
17
SECURITY POLICY COMPONENTS
The following diagram illustrates the basic six steps in the rules
transaction process:
Figure 1-3: Rules Transaction Process
For additional Request and Response phase diagrams for Master
Policy and Security Policies interaction, see Appendix A.
The diagram illustrates when a Master Policy is being used (that
is, users go through both a Master and a Security Policy) and the
rule process occurs as follows:
1. Client sends a request.
2. All request rules in the Master Policy are processed and the
request is forwarded to the Security Policy.
M86 SECURITY
SECURITY POLICIES IN DEPTH
18
CHAPTER 1: SECURITY POLICY CONCEPTS
3. All request rules in the Security Policy are processed and the
request is sent to the Internet.
4. A response is returned from the Web server.
5. All response rules in the Master Policy are processed, and the
response content is forwarded to Security Policy.
6. All response rules in the Security Policy are processed and the
content is delivered to the Client.
NOTES: These rules are processed as long as a rule is not yet
triggered.
M86 SECURITY
SECURITY POLICIES IN DEPTH
19
SECURITY POLICY COMPONENTS
Output Messages
As the flow indicates, many rules, including those performing Block
actions, display output messages to the end-user. The following
are examples of output messages.
Page Blocked Message
When an Internet site is blocked, a page block message (if
configured) is sent to the end-user stating that a site was blocked
due to the reason specified in the message. This message also
contains a transaction ID, which the administrator can use to trace
the transaction in the Log View and find out why this specific site/
page was blocked.
An example of a page Block message is as follows:
Figure 1-4: Example of a Page Block Message
M86 SECURITY
SECURITY POLICIES IN DEPTH
20
CHAPTER 1: SECURITY POLICY CONCEPTS
Coaching Message (Warning)
An administrator can create a new Security Policy and within this
policy, create Coach (Warning) rules. These can be used as
warnings for potential security situations or work performance loss
for end-users. An example of a Coach message is as follows:
Figure 1-5: Example of a Coach Page Message
Partial Block Message
If part of the HTML page contains malicious code, SWG can
remove that specific part of the HTML page and allow the rest of it
to be displayed to the end-user.
M86 SECURITY
SECURITY POLICIES IN DEPTH
21
SECURITY POLICY COMPONENTS
Available Conditions
Each rule can include multiple conditions, all of which must be met
for the rule to be triggered.
Conditions Available for Security Policy Rules
The following conditions are used in configuring Security Policy
rules.
• Authentication Cluster: Applies to the clusters as used in the
parameters for the Authentication or Get User Credentials
actions when configuring an Identification policy rule.
The Authentication Cluster condition is available for rules in
Policy type Device Logging.
• Authentication Methods: Uses the configured authentication
methods defined in the Action field when configuring an
Identification policy rule.
y Authenticate M86 SWG: Communicates with the client to get
USERID information and uses an external Authentication Site
to validate this information.
y Get user credentials: M86 SWG gets user identification via
NTLM or another such method.
y Identify by headers: Identifies the end-user according to the
Header (HTTP).
y Identify by source IP: Identifies the end-user by source IP.
This condition can be used to include or exclude the
authentication methods for logging purposes.
The Authentication Methods condition is available for rules in
Policy type Device Logging.
• Authentication Protocols: Logs the protocols used for
authentication (Basic, NTLM or both).
The Authentication Protocols condition is available for rules in
Policy type Device Logging.
M86 SECURITY
SECURITY POLICIES IN DEPTH
22
CHAPTER 1: SECURITY POLICY CONCEPTS
• Authentication Status: Logs the failed status of authentication
attempts.
The Authentication Status condition is available for rules in
Policy type Device Logging.
• Active Content List: Contains active content objects such as
ActiveX Controls and Java Applets which have already been
scanned by SWG and kept in the SWG Server Database. Each
newly scanned Applet, Control or Executable is automatically
added to the Auto-Generated list, which is the only list that
cannot be used in a rule. To create exception rules, items from
the Auto-Generated list can be moved to other lists.
The condition is applied to objects matching entries in these
lists. SWG includes the following default list which can be used
as part of this condition:
y Allowed: Allows trusted objects, which are blocked by the
Default Security Policy.
y Blocked: Blocks forbidden objects, which are allowed by the
Default Security Policy.
To configure the Active Content List, click Policies Æ
Condition Settings Æ Active Content List. For more
information, see the Management Console Reference Guide.
The condition is applied to objects matching the Active Content
List and are available for rules in Policy types Security and
Logging.
• Anti-Virus (McAfee/Sophos/Kaspersky): Anti-virus third party
scanning engine which scans for known viruses. The anti-virus
lists are automatically updated with SWG maintenance updates.
The Anti-virus condition is available for rules in Policy types
Security and Logging.
M86 SECURITY
SECURITY POLICIES IN DEPTH
23
SECURITY POLICY COMPONENTS
• Approved Content: VuSafe is an M86 Security web portal
used for streaming media content categorization, and
permissions management within the education market. The
Approved Content condition enables SWG to integrate VUSafe
(http://www.m86vusafe.com) and perform the necessary actions
required to filter out content unsuitable for a particular audience.
Administrators add a URL Encryption Key (UEK) to the VuSafe
portal. When an end-user (primarily students) tries to view an
authorized video, the URL request will have an additional UEK
hash key. This same UEK is entered into the SWG where it is
then verified.
To configure Approved Content, click Policies Æ Condition
Settings Æ Approved Content (incl. VuSafe). For more
information, see the Management Console Reference Guide.
The condition is applied to objects matching entries in the UEK
lists and are available for rules in Policy types Security and
Logging.
• Archive Errors (Archives): This applies if an archive is not
scanned by SWG due to predefined conditions such as
password protection, nesting depth, expanded file exceeding
limit, file could not be extracted, etc.
The archive file size for the condition verifying size limitation
compliance must be set. The specified number of files bundled
together includes the number of archives within archives, and
the size of the extracted file. Archives include: Zip Archive, GZip
Archive, RAR Archive, CAB Archive, BZ2 Archive and TAR
Archive. To configure the archive file size, click Policies Æ
Condition Settings Æ Archives. For more information, see
the Management Console Reference Guide.
The Archive Errors condition is available for rules in Policy types
Security and Logging.
• Archives: Specifies the number of files bundled together; the
number of archives within archives and the size of the extracted
file. Archives include: Zip Archive, GZip Archive, RAR Archive,
CAB Archive, BZ2 Archive and TAR Archive.
M86 SECURITY
SECURITY POLICIES IN DEPTH
24
CHAPTER 1: SECURITY POLICY CONCEPTS
• Behavior Profile (Binary Behavior): The M86 binary behavior
engine is based on checking security behaviors and profiles,
which are examined through the inspection of the binary’s
exposed mechanisms defined as required interfaces to the
system. The Binary Behavior Profile enables active content
identification that could be considered malicious or suspicious
when exhibited by ActiveX Controls, Java Applets, executable
files and any other relevant files. This condition can also match
objects to the following non-editable profiles:
y Suspected Malware: Contains behavior profile patterns
specific to Spyware objects. This option is displayed only if
the Anti-Spyware engine is purchased.
y Unscannable Active Content: This profile is assigned
whenever the appliance could not scan an object.
To configure Behavior Profile, click Policies Æ Condition
Settings Æ Binary Behavior. For more information, see the
Management Console Reference Guide.
Binary Behavior conditions are available for rules in Policy types
Security and Logging, and include the following:
y Automatic Execution and Termination: Conditions for
automatic file execution options considered unsafe when
performed by ActiveX, Executables and by Java Applets.
y File Access: Conditions for file access options considered
unsafe when performed by ActiveX, Executables and by Java
Applets.
y Registry Access: Conditions for registry access options
considered unsafe when performed by ActiveX, Executables
and by Java Applets.
y Network Access: Conditions for network access options
considered unsafe when performed by ActiveX, Executables
and by Java Applets.
y Minor Risk Operations: Conditions for minor risk operations
options considered unsafe when performed by ActiveX,
Executables and by Java Applets.
M86 SECURITY
SECURITY POLICIES IN DEPTH
25
SECURITY POLICY COMPONENTS
y Disclosure of Information: Conditions for Disclosure of
Information options considered unsafe when performed by
Java Applets.
y Java Runtime: Conditions for Java runtime options
considered unsafe when performed by Java Applets, which
can eliminate security restrictions.
y Change Settings: Conditions for Change Settings options
considered unsafe when performed by ActiveX and
Executables.
y System Settings: Conditions for system settings options
considered unsafe when performed by Java Applets.
y General: Conditions for general options considered unsafe
when performed by ActiveX and Executables.
y Other Running Applications: Conditions for other running
application options considered unsafe when performed by
ActiveX and Executables.
• Binary VAD: The Binary Vulnerability Antidote (VAD) condition
scans binary files, looking for patterns of exploits. Binary VAD is
divided into five security levels: None, Basic, Medium, High
and Strict.
The Binary VAD condition is available for rules in Policy types
Security and Logging.
• Content Size: Refers to the content size (in KB) being scanned,
which can limit very large files from entering or leaving the
network. The predefined content sizes cannot be modified.
However, new Content Size lists can be created.
To configure Content Size, click Policies Æ Condition
Settings Æ Content Size. For more information, see the
Management Console Reference Guide.
The conditions are set against the configured content sizes and
are available for rules in Policy types Security, Logging, and
ICAP Forward.
M86 SECURITY
SECURITY POLICIES IN DEPTH
26
CHAPTER 1: SECURITY POLICY CONCEPTS
• Data Leakage Prevention: Data Leakage Prevention (DLP) is
a content processor through which SWG scans information—
such as customer records, financial information, and intellectual
property—stored within varying document types, and prevents it
from leaving the network should it violate specific organization
compliance.
This condition is pre-set to identify potentially harmful data
incorporating a multi-language built condition used in a DLP
rule, in X-ray mode, within a default policy. It cannot be edited.
However, using the DLP Rule Builder, additional filter conditions
can be created, defined and edited.
To configure Data Leakage Prevention, click Policies Æ
Condition Settings Æ Data Leakage Prevention. For more
information, see the Management Console Reference Guide.
The conditions are set against the configured DLP and are
available for rules in Policy types Security and Logging.
• Digital Signatures: Specifies if the content has an invalid or
missing digital signature.
The Digital Signatures condition is available for rules in Policy
types Security and Logging.
• Direction: Specifies the transaction direction (Incoming/
Outgoing) for which the rule may be triggered. For example, in
HTTP, Outgoing means the protocol Request phase, and
Incoming means the protocol Response phase. If no direction
is specifically applied, then the rule is checked on both the
request and response phases.
The Direction condition is available for rules in Policy types
Security and Logging.
M86 SECURITY
SECURITY POLICIES IN DEPTH
27
SECURITY POLICY COMPONENTS
• File Extensions: Each node in the File Extension tree identifies
a predefined list of file extensions, organized by topic. Also
included in the tree is the Multiple File Extensions list. This
refers to files that have more than one extension, and the last
extension allows the Operating System to run the file, for
example, file.txt.exe.
With the exception of the editable Multiple File Extensions list,
extensions from the existing File Extensions provided by
Trustwave SpiderLabs cannot be added or deleted. New File
Extension lists can be created.
To configure File Extensions, click Policies Æ Condition
Settings Æ File Extensions. For more information, see the
Management Console Reference Guide.
The conditions are set against the File Extension lists and are
available for rules in Policy types Security and Logging.
• HTTP Method: This condition is used in conjunction with the
Social Media Posts rule. The HTTP Method is a content
processor providing the ability to select, through the security
policy condition, possible values such as GET, POST, LOCK,
etc. This feature supports HTTP, ICAP, and HTTPS/SSL
requests.
The list of supported HTTP Method types is predefined and
non-editable.
The HTTP Method condition is available for rules in Policy types
Security, Logging, and ICAP Forward.
• Destination Port Range: Specifies port ranges used in
Identification Policy rules. The rules apply to client applications
whose target destination ports are in the range.
To configure Destination Port Range, click Policies Æ
Condition Settings Æ Destination Port Range. For more
information, see the Management Console Reference Guide.
The conditions are set against the destination port ranges and
are available for rules in Policy type Device Logging.
M86 SECURITY
SECURITY POLICIES IN DEPTH
28
CHAPTER 1: SECURITY POLICY CONCEPTS
• Header Fields: Headers are metadata enabling rule
customization based on these header fields. For example, you
can create a rule that blocks requests from specific user-agents.
The headers can be either request or response headers.
The Header Fields tree comes with a number of predefined
Header Fields provided by Trustwave SpiderLabs. With the
exception of Exclude By Headers, which can be edited, you
cannot add or delete any of them. However, new Header Fields
can be defined.
To configure Header Fields, click Policies Æ Condition
Settings Æ Header Fields. For more information, see the
Management Console Reference Guide.
The conditions are set against the configured Header Fields and
are available for rules in Policy types Security, Device
Logging, Logging, ICAP Forward, and Identification.
• ICAP Service Groups (Status): Internet Content Adaptation
Protocol (ICAP) is a high-level protocol for requesting services
from an Internet-based server. It provides a common format for
requesting services using standard HTTP messaging and
allows ICAP clients to invoke services on ICAP servers for a
variety of services.
To enable SWG to act as an ICAP Client, the receivable ICAP
Services must be configured in the condition by being clustered
into ICAP Service Groups.
To configure ICAP Service Groups, click Policies Æ
Condition Settings Æ ICAP Service Groups. For more
information, see the Management Console Reference Guide.
The ICAP Service Groups condition is available for rules in
Policy type Device Logging.
M86 SECURITY
SECURITY POLICIES IN DEPTH
29
SECURITY POLICY COMPONENTS
• IP Range: Defines one or more IP ranges for use in
Identification Policy rules applying to end-users whose IPs are
in the range. The range is used to distinguish the client machine
connecting to the Secure Web Gateway device by its source IP.
SWG provides pre-supplied IP Range definitions named
Exclude by IP and Branch Offices IPs. To enable
administrators to add/modify the IP ranges as required, M86
provides the default list Exclude by IP.
To configure IP Range, click Policies Æ Condition Settings
Æ IP Range. For more information, see the Management
Console Reference Guide.
The conditions are set against the configured IP ranges and are
available for rules in Policy types Device Logging, Upstream
Proxy and ICAP Forward.
• IM: Applies to transactions using Instant Messaging protocols
with HTTP tunnelling.
The IM condition is available for rules in Policy types Security
and Logging.
• Certification Validation Errors: Includes certificate integrity
checks, expiration checks, revocation and matching to ensure
corporate certificate policies are enforced, by automatically
validating each certificate and making sure that the chain goes
back to the trusted authority. Policies regarding certificates are
enforced by checking individual certificate names, date, trusted
authority chain and revocation lists.
A list of trusted certificate authorities is supplied with the system
and used for digital signature analysis and for HTTPS certificate
validation. Digital certificate lists are updated via the M86
security updates. These lists include the required trusted
certificate authorities as well as the Certificate Revocation Lists.
M86 SECURITY
SECURITY POLICIES IN DEPTH
30
CHAPTER 1: SECURITY POLICY CONCEPTS
Conditions can be set for the following certificate validation
failures:
y Invalid Certificate Structure
y Certificate Cannot be Trusted
y Certificate is Not Currently Valid
y Certificate Revoked
y Host Cannot be Trusted
y Bad Certificate Usage
To configure HTTPS Certificate Validation, click Policies Æ
Condition Settings Æ HTTPS Certificate Validation. For
more information, see the Management Console Reference
Guide.
Conditions are set against the configured certification validation
errors and are available for rules in Policy type HTTPS.
• Location: Used to distinguish a client application based on the
scanning server location. The condition options are one of the
following:
y Cloud: The scanning server is located in the internet cloud.
y Local: The scanning server is located in the enterprise.
The Location condition is available for rules in Policy types
Security, HTTPS, Caching, Logging, Identification, Device
Logging, and Upstream Proxy.
• Pre Authentication Headers: Includes header data previously
authenticated by a downstream proxy agent. These are
available for inclusion in the Identification Policy Rules. Defined
Pre Authenticated Headers can be added or deleted.
To configure Pre Authentication Headers, click Policies Æ
Condition Settings Æ Pre Authentication Headers. For more
information, see the Management Console Reference Guide.
The conditions are set against the configured pre authentication
headers and are available for rules in Policy type Device
Logging.
M86 SECURITY
SECURITY POLICIES IN DEPTH
31
SECURITY POLICY COMPONENTS
• Malware Entrapment Profile: M86 Security’s Malware
Entrapment Scanning Engine monitors and identifies malicious
content.
The engine uses language tokens, Active Code semantic
patterns, forbidden combinations of operations, parameters,
and programming techniques to identify malicious active
content fed into the engine.
Malware Entrapment Profiles are divided into five different
security levels: None, Basic, Medium, High and Strict.
The security levels are directly related to the profile enforcement
effectiveness.
Each profile level consists of a list of actions that could be
considered malicious or suspicious when executed by Web
pages, VB Script files, Java Script files or other relevant files.
By default, the SWG system is pre-configured at the Medium
security level. Administrators can set an appropriate security
level on a per policy basis.
The Malware Entrapment Profile condition is available for rules
in Policy types Security and Logging.
• Parent Archive Type: Enables the administrator to assign
specific rules for items within archives such as ZIP, CAB, etc.
This condition does not match files outside the archives or the
archive files themselves.
The Parent Archive Type condition is available for rules in Policy
type Logging.
• Protocol: Used for the different browsing or downloading
protocols.
The Protocol condition is available for rules in Policy types
Security, Logging, and ICAP Forward.
M86 SECURITY
SECURITY POLICIES IN DEPTH
32
CHAPTER 1: SECURITY POLICY CONCEPTS
• Rule Action: Enables the option to log transactions when a
specific end-user action is performed. The rule actions include
Block, Allow, Block HTTPS, Bypass, Coach, Inspect or User
Approval.
Rule Action conditions are available for rules in Policy type
Logging.
• Spoofed Content: This condition applies to malicious files
disguised as harmless files.
The Spoofed Content condition is available for rules in Policy
types Security and Logging.
• Static Content List: This condition applies if a content's
signature is found in a list of predefined malicious content
signatures. This list is invisible to the administrator, and is
constantly updated by Trustwave SpiderLabs.
The Static Content List condition is available for rules in Policy
types Security and Logging.
• Time Frame: Enables the administrator to modify
organizational demands and requirements according to varying
week times. The predefined time frames provided with the
system can be modified to suit local times and customs. New
Time Frames can also be added.
Time Frame conditions are available for rules in Policy types
Security, Logging, and ICAP Forward.
• True Content Type: Unlike the declared content type, the True
Type detection engine limits the rule action to predefined
content types. The engine uses real content inspection to
identify the content type.
The True Content Type condition is available for rules in Policy
types Security, Logging, and ICAP Forward.
M86 SECURITY
SECURITY POLICIES IN DEPTH
33
SECURITY POLICY COMPONENTS
• URL Filtering: Blocks or allows content based on content
analysis instead of content source. A proprietary M86 List
Categorization engine is deployed as the primary URL
Categories Filter in the SWG, and provides increased
effectiveness by identifying embedded URLs.
The filter enables setting logical category groups, enabling
actions to be set by category group and not by every individual
category.
The URL Filtering condition is available for rules in Policy types
Security, HTTPS, Logging and ICAP Forward.
• URL Filtering (IBM/Websense): Specifies to which URL
category (or categories) the rule should apply. These categories
are maintained by the respective 3rd party.
The URL Filtering (IBM/Websense) condition is available for
rules in Policy types Security, HTTPS, Logging and ICAP
Forward.
• URL Lists: This condition refers to predefined URL white lists
(allowed), black lists (blocked), or bypass lists. Almost all URL
Lists are editable (the only pre-supplied list that is not editable is
M86 Security Recommended White List), and the administrator
can also create an organization-specific list.
This condition can also match the non-editable Spyware URL
List, which contains a list of known Spyware sites.
To configure URL Lists, click Policies Æ Condition Settings
Æ URL Lists. For more information, see the Management
Console Reference Guide.
The conditions are set against the URL lists.
The URL Lists condition is available for rules in Policy types
Security, HTTPS, Caching, Logging, Identification, Device
Logging, Upstream Proxy and ICAP Forward.
M86 SECURITY
SECURITY POLICIES IN DEPTH
34
CHAPTER 1: SECURITY POLICY CONCEPTS
• Upstream Proxy: Configures connections to upstream proxies.
Scanned traffic is sent either to a router, based on routing table
information, or to an upstream proxy, where the request is sent
in proxy format. Upstream proxy connection configuration is
through one of the following options:
y Client IP Header and User Name Header: How user
credentials are forwarded to the upstream proxy.
y Protocol: Protocol used to forward to the upstream proxy.
To configure Upstream Proxy, click Policies Æ Condition
Settings Æ Upstream Proxy. For more information, see the
Management Console Reference Guide.
The conditions are set against the configured upstream proxy
and are available for rules in Policy type Device Logging.
• Upstream Proxy Status: Checks if the connection to an
Upstream Proxy was successful.
The Upstream Proxy Status condition is available for rules in
Policy type Device Logging.
M86 SECURITY
SECURITY POLICIES IN DEPTH
35
USER MANAGEMENT
User Management
The basis for managing users in most environments is within
groups. Groups enable a more efficient method for assigning
policies for many users who require the same security profile.
Once a member of a group, policy management at the group level
automatically affects all the users assigned to the group.
Policies can have groups applied to them, or policies can have
groups excluded. For more information, see Assigning Policies to
User Groups and Users and the Management Console Reference
Guide.
IMPORTANT: It is important for administrators to maintain
configuration records to avoid anomalies where users are both in
groups applied to policies, and in groups excluded from policies.
In addition, defined User Lists enable administrators to specify to
which users a Security, HTTPS, or Logging policy rule will be
applied and which users should be excluded. For more information,
see Defining User Lists and the Management Console Reference
Guide.
M86 SECURITY
SECURITY POLICIES IN DEPTH
36
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Chapter 2: Detailed Rule Descriptions
This chapter provides detailed rule descriptions.
Rules are used to set policies described in Chapter 3: Implementing
Security Policy. and are based on conditions described in Chapter 1:
Security Policy Concepts.
SWG provides pre-set rules encompassing all areas of security.
SWG also enables the creation of new rules as required by the
organization’s security demands.
For more information, see Creating / Editing a Rule in a User-Defined
Policy and Adding / Editing Conditions in a Rule.
For an example of rule creation, see Example - Creating a New Rule.
The example describes a Data Leakage Prevention policy, rule and
condition creation, and test.
Rules
Allow Access to White Listed Sites
This rule enables access to sites included on the safe lists.
However, SWG still scans any files within container files—such as
zip files—residing on a White Listed site.
White lists can be used to prevent over-blocking caused by
detecting dangerous operations in active content required for
organization productivity - for example, Microsoft Windows update
sites containing a powerful ActiveX control. Effectively, White lists
are a type of performance accelerator when browsing trusted sites.
M86 SECURITY
SECURITY POLICIES IN DEPTH
37
RULES
The following table describes the M86-provided rule definitions:
Allow Access to White Listed Sites
General Tab
Action
Allow
Advanced Action
Allow content and scan containers
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects the following conditions:
• Customer Defined White List: Editable as an element by
clicking Policies Æ Condition Settings Æ URL Lists, and
then clicking Customer Defined White List.
• M86 Recommended White List: Provided by Trustwave
SpiderLabs and updated through maintenance updates.
• URL White List (Strict): Editable by clicking Policies Æ
Condition Settings Æ URL Lists, and then clicking URL
White List (Strict).
M86 SECURITY
SECURITY POLICIES IN DEPTH
38
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Testing the Rule
 To test the Allow Access to White Listed Sites rule:
1. Copy and paste the following blocked URL site into your
browser:
http://www.m86security.com/EVG/passwordprotected.zip and
press Enter. The Login page opens.
2. Type the username: getevg and password: HurNoc45, and
then click OK.
The URL is blocked because the URL contains a password
protected archive. The following error message opens:
Figure 2-1: Page Blocked – Password Protected
To avoid blocking this page, add it to either the Customer Defined
White List, or the URL White List (Strict).
 To add a URL address to the Customer Defined White List:
1. Click Policies Æ Condition Settings Æ URL Lists, and then
click Customer Defined White List. In the right pane the
Customer Defined White List workspace opens.
M86 SECURITY
SECURITY POLICIES IN DEPTH
39
RULES
2. At the bottom right of the screen, click Edit.
Figure 2-2: Edit URL to Customer Defined White List
3. To add a row (URL), click
. A blank row opens in the table.
Figure 2-3: Add URL to Customer Defined White List
4. In the highlighted URL box, type the new URL:
http://www.m86security.com/EVG/passwordprotected.zip
5. Click Save, and then click
M86 SECURITY
.
SECURITY POLICIES IN DEPTH
40
CHAPTER 2: DETAILED RULE DESCRIPTIONS
6. Copy and paste the following blocked URL site into your
browser:
http://www.m86security.com/EVG/passwordprotected.zip and
press Enter. The Login page opens. To connect to the site, type
the username: getevg and password: HurNoc45, and click OK.
The following dialog box opens.
Figure 2-4: Web Site from White List
7. To save the file select Save File, and to view the file select
Open with and select the application to open the file.
8. Click OK.
 To remove a URL address from the Customer Defined White
List:
1. Click Policies Æ Condition Settings Æ URL Lists, and then
click Customer Defined White List. In the right pane the
Customer Defined White List workspace opens.
2. At the bottom right of the screen, click Edit.
M86 SECURITY
SECURITY POLICIES IN DEPTH
41
RULES
3. Click
next to the www.m86security.com/EVG/
passwordprotected.zip entry, and then click Delete URL. The
URL is deleted from the from the Customer Defined White List.
4. Click Save, and then on the tool bar, click
.
Allow All
NOTES: This rule appears only in the Full Bypass Policy, and is
the only rule in that policy.
This rule enables all scanning to be bypassed, effectively
suspending the M86 engine scanners. The rule setting is provided
by M86 and is intended for end-users permitted to surf through the
M86 SWG Appliance without any scanning.
The following table describes the M86-provided rule definitions:
Allow All
General Tab
Action
Allow
Advanced Action
Bypass Scanning
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
M86 SECURITY
SECURITY POLICIES IN DEPTH
42
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Allow and Scan Customer-Defined File Extensions
This rule enables files with specific extensions to avoid scanning,
and at the same time enables container file scanning, for example
zipped files.
The following table describes the M86-provided rule definitions:
Allow and Scan Customer-Defined File Extensions
General Tab
Action
Allow
Advanced Action
Allow content and scan containers
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
Conditions
For this rule, SWG selects only the condition File Extensions
White List. Editable as an element by clicking Policies Æ
Condition Settings Æ File Extensions, and then—depending on
the rule—clicking File Extensions White List (Basic), or File
Extensions White List (Medium), or File Extensions White List
(Strict).
The list of supported file types is predefined and non-editable.
All file extension categories are predefined by Trustwave
SpiderLabs and modified by SWG software updates. The condition
definition is based on selecting these file extension categories.
M86 SECURITY
SECURITY POLICIES IN DEPTH
43
RULES
Allow and Scan Customer-Defined True Content
Type
This rule enables certain true type files, as defined by system
administrators, not to be scanned. The true type files are still
scanned if they are within archive containers. For this rule, SWG
provides no conditions.
The following table describes the M86-provided rule definitions:
Allow and Scan Customer-Defined True Content Type
General Tab
Action
Allow
Advanced Action
Allow content and scan containers
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
Conditions
For this rule, SWG provides no conditions. A copied and modified
rule can enable any defined condition. The conditions are grouped
file types, so before setting the conditions on a new rule, set the
files types to the conditions.
M86 SECURITY
SECURITY POLICIES IN DEPTH
44
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Allow Known Legitimate Content
This rule enables the scanning of files that have been approved as
known legitimate content by M86 to be bypassed.
The following table describes the M86-provided rule definitions:
Allow Known Legitimate Content
General Tab
Action
Allow
Advanced Action
Allow content and do not scan containers
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
Conditions
For this rule, SWG selects only the condition Known Legitimate
Content List. The list is generated by Trustwave SpiderLabs and
is not accessible by the administrator. The list is updated during
SWG software updates.
M86 SECURITY
SECURITY POLICIES IN DEPTH
45
RULES
Allow Streaming
This rule enables media streaming such as audio and video to
pass through the system.
The following table describes the M86-provided rule definitions:
Allow Streaming
General Tab
Action
Allow
Advanced Action
Bypass scanning
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects only the condition Streaming.
A copied and modified rule can enable any of the other conditions.
The conditions are grouped file types, so before setting the
conditions on a new rule, set the files types to the conditions.
M86 SECURITY
SECURITY POLICIES IN DEPTH
46
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Allow Trusted Sites
This rule refers to security scanning being disabled completely on
highly trusted sites (as long as they are not blacklisted or part of a
Spyware/Adware list).
NOTES: Generally this rule is run prior to other security rules
(apart from blacklisted or spyware/adware sites). None of the sites
in the Trusted Sites and URL Bypass List will be scanned for any
security breach. Therefore, M86 recommends using this only for
selected sites and using the regular Customer Defined White List
for the majority of trusted sites.
The following table describes the M86-provided rule definitions:
Allow Trusted Sites
General Tab
Action
Allow
Advanced Action
Bypass scanning
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
M86 SECURITY
SECURITY POLICIES IN DEPTH
47
RULES
Conditions
For this rule, SWG selects the following conditions:
• Allow Large Download Sites: Editable as an element by
clicking Policies Æ Condition Settings Æ URL Lists, and
then clicking Allowed Large Download Sites.
• Trusted Sites: Editable as an element by clicking Policies Æ
Condition Settings Æ URL Lists, and then clicking Trusted
Sites.
• URL Bypass List (Basic): Editable as an element by clicking
Policies Æ Condition Settings Æ URL Lists, and then
clicking URL Bypass List (Basic).
Allow Whitelisted ActiveX, Java Applets and
Executables
This rule enables items in the “Allowed” Active Content List to enter
without scanning.
The following table describes the M86-provided rule definitions:
Allow Whitelisted ActiveX, Java Applets and Executables
General Tab
Action
Allow
Advanced Action
Allow content and do not scan containers
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
M86 SECURITY
None provided by M86.
SECURITY POLICIES IN DEPTH
48
CHAPTER 2: DETAILED RULE DESCRIPTIONS
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Note the following:
• SWG creates signatures for active content (Java Applets,
ActiveX and Executable files) that passes through the SWG.
These signatures are available in the Active Content List. To
see the list, click Policies Æ Condition Settings Æ Active
Content List Æ Auto-generated. Auto-generated active
content signature entries can be moved to a destination group;
Allowed list or Blocked list. For the Default M86 Security Policy,
content based on signature only, is passed without scanning for
entries moved to the Allowed list. This enables the administrator
to specifically allow binary active content.
• If the Allow Whitelisted ActiveX, Java Applets and
Executables rule conditions are met, the rule is enforced at the
response phase.
Conditions
For this rule, SWG selects only the condition Allowed. This
condition refers to content with signatures listed in the Active
Content List. There are three lists, Allowed, Auto-generated and
Blocked. To edit these lists, click Policies Æ Condition Settings
Æ Active Content List. Then click the list to edit, and edit the lists
as required.
M86 SECURITY
SECURITY POLICIES IN DEPTH
49
RULES
Block Access to Adware Sites
This rule blocks predefined Adware URLs. The rule is enforced,
when its conditions are met, at the Request phase.
The following table describes the M86-provided rule definitions:
Block Access to Adware Sites
General Tab
Action
Block
End-user Message
Blocked adware URL
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects only the condition Adware URL List.
The list is generated by Trustwave SpiderLabs and is not
accessible by the administrator. The list is updated during SWG
software updates.
M86 SECURITY
SECURITY POLICIES IN DEPTH
50
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Testing the Rule
 To test the Block Access to Adware Sites rule:
1. Copy and paste the following URL into your browser (known
adware):
www.infinityads.com
The following message opens when trying to access this site.
Figure 2-5: Page Blocked Message – Adware Sites
2. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
3. At the bottom right of the screen, click Manage Profiles, and
then in the left pane, click admin Blocked Transactions. The
blocked transactions are listed in the right pane.
4. In the same row as the blocked transaction, click
and click
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
51
RULES
5. To view additional information on the transaction’s Request
phase, in the Transaction Details tree, click Request. Only the
Request component exists for this transaction because it was
blocked at the Request phase.
Figure 2-6: Request: Adware Sites
M86 SECURITY
SECURITY POLICIES IN DEPTH
52
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Access to Blacklisted Sites
This rule blocks URLs on a predefined list specifying blacklisted
sites. The rule is enforced, when its conditions are met, at the
Request phase.
The following table describes the M86-provided rule definitions:
Block Access to Blacklisted Sites
General Tab
Action
Block
End-user Message
Blacklisted URL
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects the following conditions:
• Customer Defined Black List: Editable as an element by
clicking Policies Æ Condition Settings Æ URL Lists, and
then clicking Customer Defined Black List. Entries can be
added or deleted, which determines what is blocked by SWG.
• M86 Recommended Black List: Cannot be edited or viewed
by the administrator.
• URL Black List (Basic): Editable as an element by clicking
Policies Æ Condition Settings Æ URL Lists, and then
clicking URL Black List (Basic).
M86 SECURITY
SECURITY POLICIES IN DEPTH
53
RULES
Testing the Rule
 To test the Block Access to Blacklisted Sites rule:
1. Click Policies Æ Condition Settings Æ URL Lists, and then
click Customer Defined Black List. In the right pane the
Customer Defined Black List workspace opens.
2. At the bottom right of the screen, click Edit.
Figure 2-7: Edit URL to Customer Defined Black List
M86 SECURITY
SECURITY POLICIES IN DEPTH
54
CHAPTER 2: DETAILED RULE DESCRIPTIONS
3. To add a row (URL), click
. A blank row opens in the table.
Figure 2-8: Add URL to Customer Defined Black List
4. In the highlighted URL box, type the new URL:
www.cnn.com/* (‘*’ is the wild card, meaning that all URLs
contained within www.cnn.com will be blocked).
5. Click Save, and then click
.
 To test that this website was blocked:
1. Copy and paste the following URL into your browser:
www.cnn.com
The following message opens when trying to access this site.
Figure 2-9: Page Blocked Message – Blacklisted Sites
NOTES: The transaction ID refers to the unique interaction
between the end-user and the SWG system.
M86 SECURITY
SECURITY POLICIES IN DEPTH
55
RULES
2. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
mp
Figure 2-10: Web Logs
3. In the same row as the blocked cnn.com transaction, click
and then click Details. The Transaction Detail tabs include
Transaction, User, Policy Enforcement, Content and Scanning
Server details.
4. In the Transaction Details tree, click Request to obtain further
information on the Request phase of this transaction. Only the
Request component exists for this transaction since it was
blocked at the Request phase.
M86 SECURITY
SECURITY POLICIES IN DEPTH
56
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Figure 2-11: Request: Blacklisted Site
 To remove this website from the Customer Defined Black List:
1. Click Policies Æ Condition Settings Æ URL Lists, and then
click Customer Defined Black List. In the right pane the
Customer Defined Black List workspace opens.
2. To open the screen for editing, click Edit.
3. In the same row as the blacklisted URL www.cnn.com
transaction, click
, and then click Delete.
4. Click Save, and then click
M86 SECURITY
.
SECURITY POLICIES IN DEPTH
57
RULES
Block Access to High-Risk Site Categories
NOTES: If the rule name is followed by a (Websense) or (IBM)
qualifier, the rule applies to filtering by the respective engine. If the
rule name is not followed by a qualifier, the rule applies to all M86
filtering.
This rule blocks a list of predefined URL categories. A different
URL list is provided for the Websense, IBM Proventia, and M86
Web Filter, depending on your license. The rule is enforced, when
its conditions are met, at the Request phase.
NOTE: Websense and IBM Proventia Web Security filter engines
require a license.
The following table describes the M86-provided rule definitions:
Block Access to High-Risk Site Categories
General Tab
Action
Block
End-user Message
Blocked URL Category
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
M86 SECURITY
SECURITY POLICIES IN DEPTH
58
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Conditions
For the following rules, SWG selects the following conditions:
• URL Filtering: Includes the following condition elements and
sub-condition elements:
y Security: Includes the security sub-condition elements Bad
Reputation Domains, BotNet, Hacking, Malicious Code/Virus
Phishing, Spyware, Web-based, and Proxies/Anonymizers.
These elements can be selected or deactivated according to
organizational policies. To maximize security, the provided
M86 rule has all elements selected.
• URL Filtering (Websense): Includes the following condition
elements:
y Adult/Sexually Explicit
y Hacking
y Proxies and Translators
y Spyware
• URL Filtering (IBM): Includes the following condition elements:
y Anonymous Proxies
y Computer Crime/Hacking
y Erotic/Sex
y Malware
y Phishing URLs
y Pornography
y Spam URLs
y Warez/Software Piracy
M86 SECURITY
SECURITY POLICIES IN DEPTH
59
RULES
Testing the Rule
 To test the Block Access to High-Risk Site Categories rule:
1. Copy and paste the following URL into your browser:
http://www.hackingexposed.com/
The following message opens when trying to access this site.
Figure 2-12: Page Blocked Message - Hacking
NOTES: The transaction ID refers to the unique interaction
between the end-user and the SWG system.
2. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
3. In the same row as the blocked transaction, click
and then
click Details. The Transaction Detail tabs include Transaction,
User, Policy Enforcement, Content and Scanning Server
details.
4. In the Transaction Details tree, click Request to obtain further
information on the Request phase of this transaction. Only the
Request component exists for this transaction since it was
blocked at the Request phase.
M86 SECURITY
SECURITY POLICIES IN DEPTH
60
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Figure 2-13: Request: High-Risk Site Categories - Hacking
Block Access to Spyware Sites
This rule blocks predefined Spyware Sites. The rule is enforced,
when its conditions are met, at the Request phase.
The following table describes the M86-provided rule definitions:
Block Access to Spyware Sites
General Tab
Action
Block
End-user Message
Blocked Spyware URL
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
M86 SECURITY
None provided by M86.
SECURITY POLICIES IN DEPTH
61
RULES
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects only the condition Spyware URL List.
The list is generated by Trustwave SpiderLabs and is not
accessible by the administrator. The list is updated during SWG
software updates.
Testing the Rule
 To test the Block Access to Spyware Sites rule:
1. Copy and paste the following URLs (known spyware sites) into
your browser:
y www.dplog.com
y www.cashsearch.biz
The following message opens when trying to access the sites.
Figure 2-14: Page Blocked Message – Spyware Sites
2. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
M86 SECURITY
SECURITY POLICIES IN DEPTH
62
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Figure 2-15: View Web Logs
3. In the same row as the blocked transaction, click
and then
click Details. The Transaction Detail tabs include Transaction,
User, Policy Enforcement, Content and Scanning Server
details.
Figure 2-16: Transaction Details - Spyware Site
M86 SECURITY
SECURITY POLICIES IN DEPTH
63
RULES
4. In the Transaction Details tree, click Request to obtain further
information on the Request phase of this transaction. Only the
Request component exists for this transaction since it was
blocked at the Request phase.
Figure 2-17: Request: Spyware Sites
M86 SECURITY
SECURITY POLICIES IN DEPTH
64
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block ActiveX, Java Applets and Executables by
ACL
The rule causes the SWG Appliance to block items moved to the
“Blocked” Active Content List. The rule is enforced, when its
conditions are met, at the Response phase, unless it is uploaded.
The following table describes the M86-provided rule definitions:
Block ActiveX, Java Applets and Executables by ACL
General Tab
Action
Block
End-user Message
Active Content List
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Note the following:
• SWG creates signatures for active content (Java Applets,
ActiveX and Executable files) that passes through the SWG.
These signatures are available in the Active Content List. To
see the list, click Policies Æ Condition Settings Æ Active
Content List Æ Auto-generated. Auto-generated active
content signature entries can be moved to a destination group;
Allowed list or Blocked list.
M86 SECURITY
SECURITY POLICIES IN DEPTH
65
RULES
Once an entry is moved to the Blocked list, the next time an
end-user requests a blacklisted entry, the content is blocked
automatically—without scanning— based on signature only.
Figure 2-18: Auto-generated Screen
Conditions
For this rule, SWG selects only the condition Blocked. This
condition refers to content with signatures listed in the Active
Content List. There are three lists; Allowed, Auto-generated and
Blocked. To edit these lists, click Policies Æ Condition Settings
Æ Active Content List. Then click the list to edit, and edit the lists
as required.
M86 SECURITY
SECURITY POLICIES IN DEPTH
66
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Testing the Rule
 To test the Block ActiveX, Java Applets and Executables by
ACL rule:
1. Go to a site that uses Java Applets such as:
http://java.sun.com/applets/jdk/1.3/
2. On the left side, click one example, for example: Dither Test.
3. To open the Auto-generated screen displaying active content,
click Policies Æ Condition Settings Æ Active Content List
Æ Auto-generated.
p
Figure 2-19: Auto-generated Screen: Example
4. In the Find All field, type the word Java, and then click Go.
5. Select all the found entries. In the To field, select the Blocked
List.
6. Click Save, and then click
.
7. Re-access the Java Applets using the site, in our example:
http://java.sun.com/applets/jdk/1.3/
This will result in an access denied message.
M86 SECURITY
SECURITY POLICIES IN DEPTH
67
RULES
Block Binary Exploits in Textual Files
This rule blocks potential exploitations of vulnerable applications
by detecting and blocking textual files with binary data.
The following table describes the M86-provided rule definitions:
Block Binary Exploits in Textual Files
General Tab
Action
Block
End-user Message
Blocked Binary Exploit in Textual File
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects the following conditions:
• Content Size: Content size refers to the size (in KB) of the
content being scanned. These content size values limit very
large files from entering or leaving your organization.
• File extensions: Only the Potentially Exploitable Textual
Files element is selected, which cannot be edited by the
administrator. However, it can be viewed at Policies Æ
Condition Settings Æ File extensions.
• True Content Type: Only Other is selected, referring to binary
content in a textual file.
M86 SECURITY
SECURITY POLICIES IN DEPTH
68
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Binary Objects With Invalid Digital Certificate
This rule blocks binary objects which, for various reasons, have an
incorrect digital certificate attached.
The following table describes the M86-provided rule definitions:
Block Binary Objects With Invalid Digital Certificate
General Tab
Action
Block
End-user Message
Digital Signature Violation
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects only the condition Digital Signatures,
which specifies if the content has an invalid digital signature.
M86 SECURITY
SECURITY POLICIES IN DEPTH
69
RULES
Testing the Rule
 To test the Block Binary Objects with Invalid Digital Certificate
rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/invalid%20signature.exe
2. To connect to the site, type the username: getevg and
password: HurNoc45, and then click OK.
The following message opens when trying to access the site.
Figure 2-20: Page Blocked - Invalid Signature
3. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
4. In the same row as the blocked transaction, click
and then
click Details. The Transaction Detail tabs include Transaction,
User, Policy Enforcement, Content and Scanning Server
details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
70
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response phase
of this transaction.
Figure 2-21: Response: Invalid Digital Signature
Block Binary Objects Without a Digital Certificate
This rule blocks binary objects that do not have a digital certificate
verifying their integrity. The digital certificate identifies to whom the
certificate was issued and the certifying authority that issued the
certificate. ActiveX, executables and other binary objects which are
not signed by a Certification Authority are potentially malicious
objects. The digital certificate contains information about who the
certificate was issued to, as well as the certifying authority that
issued the certificate.
M86 SECURITY
SECURITY POLICIES IN DEPTH
71
RULES
The following table describes the M86-provided rule definitions:
Block Binary Objects Without a Digital Certificate
General Tab
Action
Block
End-user Message
Digital Signature Violation
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects the following conditions:
• Digital Signatures: Specifies if the content has a missing
digital signature.
• Parent Archive Type: Enables the administrator to assign
specific rules for items within archives such as ZIP, CAB, etc.
For this rule, M86 has selected Everything except for the
items selected below, and with nothing selected, effectively
selects all the archive types listed in the SWG.
M86 SECURITY
SECURITY POLICIES IN DEPTH
72
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Testing the Rule
 To test the Block Binary Objects without a Digital Certificate
rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/no_digital_signature.exe
2. To connect to the site, type the username: getevg and
password: HurNoc45, and then click OK.
The following message opens when trying to access the site.
Figure 2-22: Page Blocked - Missing Digital Signature
3. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
4. In the same row as the blocked transaction, click
and then
click Details. The Transaction Detail tabs include Transaction,
User, Policy Enforcement, Content and Scanning Server
details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
73
RULES
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response phase
of this transaction.
Figure 2-23: Response: Missing Digital Signature
M86 SECURITY
SECURITY POLICIES IN DEPTH
74
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Binary VAD Vulnerabilities
This rule blocks binary application level vulnerabilities based on
Trustwave SpiderLabs detection rules.
The following table describes the M86-provided rule definitions:
Block Binary VAD Vulnerabilities
General Tab
Action
Block
End-user Message
Binary VAD Violation
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
The condition is actually a Suspected Malware list which is
updated by Trustwave SpiderLabs, and cannot be accessed by the
administrator.
M86 SECURITY
SECURITY POLICIES IN DEPTH
75
RULES
Block Blacklisted File Extensions
This rule blocks file types which may be a security hazard and are
not normally used by legitimate sites/applications.
The following table describes the M86-provided rule definitions:
Block Blacklisted File Extensions
General Tab
Action
Block
End-user Message
File Extension
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects only the condition File Extensions
Black List. Editable as an element by clicking Policies Æ
Condition Settings Æ File Extensions, and then—depending on
the rule—clicking File Extensions Black List (Medium), or File
Extensions Black List (Strict).
The list of supported file types is predefined and non-editable.
All file extension categories are predefined by Trustwave
SpiderLabs and modified by SWG software updates. The condition
definition is based on selecting these file extension categories.
M86 SECURITY
SECURITY POLICIES IN DEPTH
76
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Testing the Rule
 To test the Block Blacklisted File Extensions rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/dir.cmd
2. To connect to the site, type the username: getevg and
password: HurNoc45, and then click OK.
The following message opens when trying to access the site.
:
Figure 2-24: Page Blocked - Forbidden File Extensions
3. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
M86 SECURITY
SECURITY POLICIES IN DEPTH
77
RULES
4. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response phase
of this transaction.
Figure 2-25: Request - Forbidden File Extensions
M86 SECURITY
SECURITY POLICIES IN DEPTH
78
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Customer-Defined File Extensions
This rule blocks files with a specific extension, defined and
selected by the administrator.
The rule is enabled only in the M86 Basic Security Policy.
The following table describes the M86-provided rule definitions:
Block Customer-Defined File Extensions
General Tab
Action
Block
End-user Message
File Extension
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
The list of supported file types is predefined and non-editable.
All file extension categories are predefined by Trustwave
SpiderLabs and modified by SWG software updates. The condition
definition is based on selecting these file extension categories.
M86 SECURITY
SECURITY POLICIES IN DEPTH
79
RULES
Block Customer-Defined True Content Type
This rule blocks specific content type files, selected by the
administrator.
The rule is enabled only in the M86 Basic Security Policy.
The following table describes the M86-provided rule definitions:
Block Customer-Defined True Content Type
General Tab
Action
Block
End-user Message
Type Detector
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
The condition type is True Content Type, but for this rule by default
SWG does not select any file extensions.
The list of supported file types is predefined and non-editable.
All file extension categories are predefined by Trustwave
SpiderLabs and modified by SWG software updates. The condition
definition is based on selecting these file extension categories.
M86 SECURITY
SECURITY POLICIES IN DEPTH
80
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Everything Except White Lists
NOTES: This rule appears only in M86 Emergency Policy, and is
the first rule listed in that policy. (The other rules in that policy also
appear in other policies.)
Blocks all URLs, except the ones which appear on the Emergency
White List or on the M86 Recommended White List.
The following table describes the M86-provided rule definitions:
Block Everything Except White Lists
General Tab
Action
Block
End-user Message
Emergency Policy Active
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects all the URL List conditions except the
following two conditions:
• Emergency White List: A user-defined list of allowed sites.
Editable as an element by clicking Policies Æ Condition
Settings Æ URL Lists Æ Emergency White List.
M86 SECURITY
SECURITY POLICIES IN DEPTH
81
RULES
• M86 Recommended White List: The list is generated by
Trustwave SpiderLabs and is not accessible by the
administrator. The list is updated during SWG software updates.
Block Files with COM Extension
This rule blocks files with COM extensions (separately from the
Block Blacklisted File Extensions rule) which are a known
security risk.
The following table describes the M86-provided rule definitions:
Block Files with COM Extension
General Tab
Action
Block
End-user Message
File Extension
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects the following conditions:
• Direction: Specifies the transaction direction (Incoming/
Outgoing) which triggers the rule. For example, in HTTP,
Outgoing means the protocol Request phase, and Incoming
means the protocol Response phase. SWG selects Incoming.
M86 SECURITY
SECURITY POLICIES IN DEPTH
82
CHAPTER 2: DETAILED RULE DESCRIPTIONS
• File Extensions: Only the COM element is selected, which
cannot be edited by the administrator. However, it can be
viewed at Policies Æ Condition Settings Æ File extensions.
• True Content Type: The following elements are selected:
y DOS Executable File: Refers to executable file developed
and run through DOS.
y Other: Refers to binary content in a textual file.
Block Files with Suspicious Multiple Extensions
This rule blocks files with suspicious multiple extensions. This is
based on a comparison of the last file extension to a list of
suspicious extensions (as well as comparing the extension before
last to a list of benign extensions). This rule protects users from
mistakenly downloading a potentially dangerous file.
The following table describes the M86-provided rule definitions:
Block Files with Suspicious Multiple Extensions
General Tab
Action
Block
End-user Message
Multiple Extension
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
M86 SECURITY
SECURITY POLICIES IN DEPTH
83
RULES
Conditions
For this rule, SWG selects only the File Extension condition
component Multiple Extensions. To edit the multiple extension
list, click Policies Æ Condition Settings Æ File extensions, and
then click Multiple Extensions.
Testing the Rule
 To test the Block Files with Suspicious Multiple Extensions
rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/Capitalsettime.TXT.JS
2. To connect to the site, type the username: getevg and
password: HurNoc45, and then click OK.
The following message opens when trying to access the site.
Figure 2-26: Page Blocked - Multiple Extensions
3. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
4. In the same row as the blocked transaction, click
and then
click Details. The Transaction Detail tabs include Transaction,
User, Policy Enforcement, Content and Scanning Server
details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
84
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request to obtain further
information on the Request phase of this transaction. Only the
Request component exists for this transaction since it was
blocked at the Request phase.
Figure 2-27: Request: Multiple Extensions
M86 SECURITY
SECURITY POLICIES IN DEPTH
85
RULES
Block Illegitimate Archives (Including PasswordProtected Archives)
This rule blocks attacks that try to use malformed archives. It also
blocks password protected archives because they cannot be
scanned.
The following table describes the M86-provided rule definitions:
Block Illegitimate Archives (Including Password-Protected
Archives)
General Tab
Action
Block
End-user Message
Container Violation
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
M86 SECURITY
SECURITY POLICIES IN DEPTH
86
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Conditions
For this rule, SWG selects the following Archive Errors condition
elements:
• File could not be extracted: Specifies containered files which
cannot be extracted, for example a compressed file. If a file
cannot be opened, it cannot be scanned.
• Invalid format: Specifies files with a format not recognized by
the system, and subsequently cannot be scanned.
• Password protected: Specified password protected files which
are closed to the system, and subsequently closed against
scanning.
Testing the Rule
 To test the Block Illegitimate Archives (Including Password
Protected Archives) rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/demo.zip
This link will try to exploit ZIP file vulnerability causing a denial
of service.
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
M86 SECURITY
SECURITY POLICIES IN DEPTH
87
RULES
A download status page appears.
After this page, the following error message is displayed:
Figure 2-28: Page Blocked - Illegitimate Archives
3. Return to the Management Console and click Logs and
Reports Æ View Web Logs.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
88
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
Figure 2-29: Response: Illegitimate Archives
M86 SECURITY
SECURITY POLICIES IN DEPTH
89
RULES
Block IM Tunneling
This rule blocks IM tunneling by default since these are known
crimeware distribution vehicles.
The following table describes the M86-provided rule definitions:
Block IM Tunneling
General Tab
Action
Block
End-user Message
Instant Messenger Detected
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects the following IM condition elements:
• AOL and ICQ
• Windows Live Messenger
• Yahoo Messenger
M86 SECURITY
SECURITY POLICIES IN DEPTH
90
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Known Malicious Content
The rule statically blocks a list of predefined malicious objects
identified by Trustwave SpiderLabs.
The following table describes the M86-provided rule definitions:
Block Known Malicious Content
General Tab
Action
Block
End-user Message
Hash Scanner
Apply to Tab
User options
All Users
Exceptions Tab
Open workspace
None provided by M86.
This rule definition cannot be edited, but can be copied and
modified, and the condition elements can be edited. A copied and
modified rule can enable any defined condition.
Conditions
For this rule, SWG selects only the Static Content List condition
element Malicious Objects List. The Malicious Objects List
cannot be manipulated or viewed by the administrator.
M86 SECURITY
SECURITY POLICIES IN DEPTH
91
RULES
Block Known Spyware (ACL)
This rule blocks a list of predefined malicious content. This list is
generated by Trustwave SpiderLabs and is not accessible by the
administrator.
The following table describes the Rule Editor definitions:
Block Known Spyware (ACL)
Action
Block
End-User Message
Spyware Object Detected
Conditions
True Content Type
Active binary content
Active Content List
Spyware Objects
Note that the Block Known Spyware (ACL) rule will be enforced,
if its conditions were met, at the Response phase.
M86 SECURITY
SECURITY POLICIES IN DEPTH
92
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Known Viruses (McAfee / Sophos /
Kaspersky)
The Block Known Viruses rules (McAfee/Sophos/Kaspersky)
block known viruses using the Anti-Virus engine that you have a
license for and provide a specific virus name in the Web Logs
where possible. There are three Anti-Virus engines – McAfee,
Sophos and Kaspersky – that work with the SWG Appliance. Using
an Anti-Virus engine helps to optimize user experience.
The following table describes the Rule definitions:
Block Known Viruses
Action
Block
End-User Message
Virus detected
Conditions
Anti-Virus (McAfee/
Sophos/Kaspersky)
M86 SECURITY
Virus detected
SECURITY POLICIES IN DEPTH
93
RULES
Testing the Rule
 To test the Block Known Viruses (McAfee/Sophos/Kaspersky)
rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/eicar.com.txt
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
The following error message is displayed:
Figure 2-30: Page Blocked: Virus
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
94
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
Figure 2-31: Response - Virus Detected
M86 SECURITY
SECURITY POLICIES IN DEPTH
95
RULES
Block Malicious ActiveX, Java Applets and
Executables
The Block Malicious ActiveX, Java Applets and Executables
rule uses the M86 Proprietary Behavior Profile (Binary) engine.
This is a unique security engine, designed to identify and block
malicious content by identifying combinations of operations,
parameters, script manipulations and other exploitation techniques
for a given piece of content.
The following table describes the definitions:
Block Malicious ActiveX, Java Applets and Executables
Action
Block
End-User Message
Malicious Behavior Detected
Conditions
Behavior Profile
M86 SECURITY
Default Profile - Binary Behavior (Strict)
Suspected Malware (Strict)
Medium Sensitivity Binary Behavior Profile
(Medium)
SECURITY POLICIES IN DEPTH
96
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Note the following:
• If Default Profile - Binary Behavior is selected then this rule
prevents end-users from downloading most executables such
as setup.exe files and is therefore included only in the Strict
Security Policy. This is the only difference between the
Medium and Strict Security Policies.
• The Binary Behavior information can be found via Policies Æ
Condition Settings Æ Binary Behavior Æ Default Profile –
Binary Behavior.
Figure 2-32: Behavior Profile (Binary)
The Behavior Profile consists of selected behavior groups of the
Behavior Profile engine. Those groups are divided into 2 areas:
• ActiveX and Executables
• Java Applets
M86 SECURITY
SECURITY POLICIES IN DEPTH
97
RULES
Testing the Rule
Java Applets
 To test the Block Malicious ActiveX, Java Applets and
Executables rule with selection of the Behavior Blocking: Java
Applets:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/readFile.class
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
The following error message is displayed:
Figure 2-33: Error Messages: Malicious Behavior
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
98
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
Figure 2-34: Response: Malicious Behavior
ActiveX and Executables Violation:
 To test the Block Malicious ActiveX, Java Applets and
Executables rule with selection of the Behavior Blocking:
ActiveX and Executables Violation:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/FinjanEmptyDemo.zip
M86 SECURITY
SECURITY POLICIES IN DEPTH
99
RULES
This URL contains an exe file which violates the following
restricted behaviors:
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
File Read
File Write
Terminate Process
Potentially Dangerous Process: Debugging
Functions
Potentially Dangerous Memory Management
Functions
Dynamic Link Library Invocation Functions
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
The following error message is displayed:
Figure 2-35: Page Blocked - Malicious Behavior
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
100
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
Figure 2-36: Response: Malicious Behavior
M86 SECURITY
SECURITY POLICIES IN DEPTH
101
RULES
Block Malicious Content (Malware Entrapment
Engine)
The Block Malicious Content (Malware Entrapment Engine)
rule uses the M86 proprietary Malware Entrapment Scanning
engine to monitor, identify, and block malicious content. The
engine uses language tokens, semantic patterns of Active Code,
forbidden combinations of operations, parameters and
programming techniques, to identify malicious active content fed
into the engine.
This rule has a single condition: Malware Entrapment Profile.
Malware Entrapment Profiles are divided into five different security
levels: None, Basic, Medium, High and Strict. The security levels
pertain to the efficacy with which the profile is enforced. Each
profile level consists of a list of actions that could be considered
malicious or suspicious when executed by Web pages, VB Script
files, Java Script files or other relevant files.
The SWG system is pre-configured, by default, at the Medium
security level. Administrators can set an appropriate security level
on a per policy basis.
The following table describes the Rule Editor definitions:
Block Malicious Content (Malware Entrapment Engine)
Action
Block
End-User Message
Malicious Behavior Detected
Conditions
Malware
Entrapment Profile
M86 SECURITY
Active malicious content
SECURITY POLICIES IN DEPTH
102
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Microsoft Office Documents containing
Macros and/or Embedded Files
The Block Microsoft Office Documents containing Macros
and/or Embedded files rule blocks Microsoft Office Documents
which contain macros or embedded files. This is because macros
and embedded files might contain malicious code.
The following table describes the definitions:
Block Microsoft Office Documents containing Macros and/or
Embedded file
Action
Block
End-User Message
Suspicious File Type Detected
Conditions
True Content Type
M86 SECURITY
Microsoft Office Document with Embedded Files,
Microsoft Office Document with Macros
SECURITY POLICIES IN DEPTH
103
RULES
Testing the Rule
 To test the Block Microsoft Office Documents containing
Macros and/or Embedded files rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/macro.doc
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
The following message appears:
Figure 2-37: Page Blocked - Microsoft Office document containing macro
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
104
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
Figure 2-38: Response: Microsoft Office document with Macros
M86 SECURITY
SECURITY POLICIES IN DEPTH
105
RULES
Block Outgoing Microsoft Office Documents
The Block Outgoing Microsoft Office Documents logs the
number of transmissions of Microsoft Office documents to the
Internet. In the M86 Policy it is defined as X-Ray.
The following table describes the Rule definitions:
Block Outgoing Microsoft Office Documents
Action
Block (X-Ray)
End-User Message
Outgoing Microsoft Office File Detection (N/A)
Conditions
Direction
Outgoing
File Extensions
Microsoft Office
True Content Type
Microsoft Office Document, Microsoft Office
Document with Embedded Files, Microsoft Office
Document with Macros, Microsoft Office Scrap
Object, Microsoft Outlook MSG Document,
Microsoft Word document, Microsoft Excel Macro
File, Microsoft Access Database
Note the following:
• The Block Outgoing Microsoft Office Documents rule has
been added as an X-ray rule in the predefined M86 Security
Policies.This means that no documents will actually be blocked;
but the results will be displayed in the Logs view.
• If the Block Outgoing Microsoft Office Documents rule was
Active, then it would be enforced, if its conditions were met, at
the Request phase.
M86 SECURITY
SECURITY POLICIES IN DEPTH
106
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Testing the Rule
 To test the Block Outgoing Microsoft Office Documents rule:
1. Duplicate the M86 Medium Security Policy.
2. Edit the Block Outgoing Microsoft Office Document rule by
disabling the X-Ray check box.
3. Make sure your User Group has the Duplicate Policy assigned
to it.
4. Copy and paste the following URL into your browser:
http://encodable.com/uploaddemo/
5. In the File 1 of 1 field, select Browse and select any Microsoft
Office document for uploading.
6. Click Begin Uploading. The following error message is
displayed:
Figure 2-39: Page Blocked - Block Outgoing Microsoft Office Documents
7. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
8. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
107
RULES
9. In the Transaction Details tree, click on Request (4) screen to
obtain further information on the Request phase of this
transaction. Only the Request component exists for this
transaction since it was blocked at the Request phase.
Figure 2-40: Request: Block Outgoing Microsoft Office Documents
10.Reassign the required Security Policy to your User Group.
M86 SECURITY
SECURITY POLICIES IN DEPTH
108
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Potentially Malicious Archives
The Block Potentially Malicious Archives rule was designed to
block attacks that try to cause Denial of Service using archives.
The following table describes the Rule Editor definitions:
Block Potentially Malicious Archives
Action
Block
End-User Message
Container Violation
Conditions
Archive Errors
Maximum Extracted Container Size - exceeded,
Archive Depth - exceeded, Maximum Entries in
Container - exceeded
Testing the Rule
 To test the Block Potentially Malicious Archives rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/
Potentially_Malicious_Archives_Demo.zip
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
M86 SECURITY
SECURITY POLICIES IN DEPTH
109
RULES
After the downloading box, the following error message is
displayed:
Figure 2-41: Page Blocked: Potentially Malicious Archives
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
M86 SECURITY
SECURITY POLICIES IN DEPTH
110
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Figure 2-42: Response: Block Potentially Malicious Archives
Block Potentially Malicious Packed Executables
The Block Potentially Malicious Packed Executables rule
blocks known problematic packed executables which may be used
to hide malicious content.
The following table describes the definitions:
Block Potentially Malicious Packed Executable
Action
Block
End-User Message
Type Detector
Conditions
True Content Type
M86 SECURITY
Potentially Malicious Packers
SECURITY POLICIES IN DEPTH
111
RULES
Note the following:
• You must enable one of the Anti-Virus engines (Sophos/
McAfee/Kaspersky) in order to use this Block Potentially
Malicious Packed Executables rule.
Testing the Rule
 To test the Block Potentially Malicious Packed Executables
rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/packer.exe
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
The following message appears:
Figure 2-43: Page Blocked - Packed Executables
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
M86 SECURITY
SECURITY POLICIES IN DEPTH
112
CHAPTER 2: DETAILED RULE DESCRIPTIONS
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
Figure 2-44: Response: Packed Executables
Block Revoked Cloud Users
NOTES: This rule appears only in the M86 Revoked Cloud Users
Policy, and is the only rule to appear in that policy.
The Block Revoked Cloud Users rule is used to block users from
browsing through the Secure Web Gateway if their certificates are
known to have been compromised and are therefore deemed no
longer valid. The current user certificate is revoked and a new
certificate must be issued.
M86 SECURITY
SECURITY POLICIES IN DEPTH
113
RULES
The following table describes the Rule Editor definitions:
Block Revoked Cloud Users
Action
Block
End-User Message
Revoked Cloud User
Conditions — (None)
Block Spoofed Content
The Block Spoofed Content rule was designed to neutralize
attacks in which a virus or malicious code masquerades as a
harmless file in order to elude the anti-virus engine. This rule also
covers situations where executable files are spoofed as other
extension files.
The following table describes the definitions:
Block Spoofed Content
Action
Block
End-User Message
Spoofed Content
Conditions
Spoofed Content
Spoofed Content
Testing the Rule
 To test the Block Spoofed Content rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/archive.zip
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
M86 SECURITY
SECURITY POLICIES IN DEPTH
114
CHAPTER 2: DETAILED RULE DESCRIPTIONS
The following message appears:
Figure 2-45: Page Blocked: Spoofed Content
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction.
M86 SECURITY
SECURITY POLICIES IN DEPTH
115
RULES
Figure 2-46: Response: Block Spoofed Content
Block Suspicious File Types
The Block Suspicious File Types rule complements the Forbid
Blacklisted File Extensions rule by checking the true type of the
downloaded content and preventing extension spoofing which
might have bypassed the Forbid Blacklisted File Extensions rule.
The following table describes the Rule definitions:
Block Suspicious File Types
Action
Block
End-User Message
Suspicious File Type Detected
Conditions
True Content Type
M86 SECURITY
DOS Executable file, Link File, MSI Installation
Package, Microsoft Outlook MSG Document,
PIF-Windows Program Information, UPX
compressed Win32 Executable, URL File,
Windows Metafile, Windows registry files
SECURITY POLICIES IN DEPTH
116
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Unscannable (McAfee / Sophos / Kaspersky)
The Block Unscannable rules (McAfee/Sophos/Kaspersky)
block unscannable content. Content which is not scannable by the
traditional Anti-Virus engine is always blocked since there is no risk
estimation for it, and since formatting content in such a way is
suspicious behavior. You need a license for one of these Anti-Virus
engines.
The following table describes the definitions:
Block Unscannable (McAfee/Sophos/Kaspersky)
Action
Block
End-User Message
Blocked since AV could not scan
Conditions
Anti-Virus (McAfee/
Sophos/ Kaspersky)
The Anti-Virus engine could not scan this
file
Block Unscannable ActiveX, Java Applets and
Executables
The Block Unscannable ActiveX, Java Applets and
Executables rule blocks unscannable active content.
The following table describes the definitions:
Block Unscannable ActiveX, Java Applets and Executables
Action
Block
End-User Message
Unscannable Content Detected
Conditions
M86 SECURITY
True Content Type
Active Binary Content
Behavior Profile (Binary)
Unscannable Active Content
SECURITY POLICIES IN DEPTH
117
RULES
Block Unscannable Archives
The Block Unscannable Archives rule blocks archives which
cannot be opened by M86's engine. Such archives are blocked
since there is no risk estimation regarding their content.
NOTES: This rule is activated before Anti-Virus scanning to
protect the Anti-Virus from potential archive viruses
contained in such archives.
The following table describes the definitions:
Block Unscannable Archives
Action
Block
End-User Message
Type Detector
Conditions
True Content Type
Unscannable Archives
Note that this rule is evaluated at the Response phase.
Testing the Rule
 To test the Block Unscannable Archives rule:
1. Copy and paste the following URL into your browser:
http://www.m86security.com/EVG/unaceVulnerability.zip
This URL contains a Zip file with ACE files designed to test
ACE’s vulnerabilities.
2. To connect to the site, type the username: getevg and
password: HurNoc45, and click OK.
3. Return to the Management Console and select the Logs and
Reports Æ View Web Logs menu in the Main Navigation bar.
M86 SECURITY
SECURITY POLICIES IN DEPTH
118
CHAPTER 2: DETAILED RULE DESCRIPTIONS
4. In the same row as the blocked transaction, click
and select
Details. The Transaction Detail tabs include Transaction, User,
Policy Enforcement, Content and Scanning Server details.
5. In the Transaction Details tree, click Request/Response to
obtain further information on the Request and Response
phases of this transaction. The first part of the Response
component is a zip file.
Figure 2-47: Response 1: Unscannable Archives
M86 SECURITY
SECURITY POLICIES IN DEPTH
119
RULES
6. Click to reveal the second page of the response. You will see
that the zip file contains an ACE file and was therefore blocked.
Figure 2-48: Response 2: Unscannable Archives
Customer-Defined URL Filtering
NOTES: If the rule name is followed by a (Websense) or (IBM)
qualifier, the rule applies to filtering by the respective engine. If the
rule name is not followed by a qualifier, the rule applies to M86
filtering.
The Customer-Defined URL Filtering rules (including those for
Websense and IBM) refer to blocking a list of URL categories. A
different URL list is provided for the Websense, IBM Proventia, and
M86 Web Filter, depending on your license. This rule is only
relevant if you have selected categories through the Simplified
Policies interface.
M86 SECURITY
SECURITY POLICIES IN DEPTH
120
CHAPTER 2: DETAILED RULE DESCRIPTIONS
The following table describes the definitions:
Customer-Defined URL Filtering
Action
Block
End-User Message
Blocked URL Category
Conditions
Customer-Defined
URL Filtering
(Websense/IBM)
The categories that you choose in the Simplified
Setup URL Categorization block will be displayed
here.
Data Leakage Prevention
The Data Leakage Prevention (X-Ray default) rule scans web
content to prevent vital information from being leaked out of the
organization network.
The Data Leakage Prevention rule refers to the Data Leakage
Prevention profile.
To configure the Data Leakage Prevention rule, click Policies Æ
Condition Settings Æ Data Leakage Prevention.
M86 SECURITY
SECURITY POLICIES IN DEPTH
121
RULES
The following table describes the Data Leakage Prevention
condition and rule definitions.
Data Leakage Prevention
Action
Block, Allow, or Coach
End-User Message
Data Leakage Prevention
Conditions
Direction
This condition enables the administrator to
trigger a rule specifically on the transaction
request (Outgoing) or response (Incoming)
phase.
Data Leakage Prevention
This condition enables the administrator to
monitor and prevent data leakage.
Detect Known Trojan Network Activity
The Detect Known Trojan Network Activity rule detects network
activity usually associated with Trojans sending and receiving data
from the Internet. This rule is provided in X-Ray format with the
predefined Security Policies. To change this rule to block Trojan
activity, duplicate the Policy and remove the check in the X-Ray
check box.
The following table describes the definitions:
Detect Known Trojan Network Activity
Action
Block
End-User Message
Suspected Trojan traffic detected (appears in Logs
on X-Ray action)
Condition
M86 SECURITY
Header Fields
Trojans
Direction
Outgoing
SECURITY POLICIES IN DEPTH
122
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Temporarily Block Cloud Users
NOTES: This rule appears only in the M86 Blocked Cloud Users
Policy, and is the only rule to appear in that policy.
The Temporarily Block Cloud Users rule is used to block users
from browsing through the Secure Web Gateway if their certificates
are suspected of being compromised and are therefore deemed no
longer valid. The current user certificate must be verified.
The following table describes the Rule Editor definitions:
Temporarily Block Cloud Users
Action
Block
End-User Message
Temporarily Blocked Cloud User
Conditions — (None)
Block Social Media Post Control
The Block Social Media Post Control rule blocks posts (entries)
to Social Media sites such as Facebook. (Allowed exceptions are
specified in the Social Media Post Control Allowed Requests
rule.) This rule does not affect read-only activity in social media
sites.
M86 SECURITY
SECURITY POLICIES IN DEPTH
123
RULES
The following table describes the rule definitions:
Block Social Media Post Control
Action
Block
End-User Message
Social Media Sites
Conditions
HTTP Method
Post
Protocol
HTTP and HTTPS
URL Lists
*.facebook.com
Social Media Post Control Allowed Requests
The Social Media Post Control Allowed Requests rule identifies
the nature of the posts (entries) that can be made to Social Media
sites — for example, login to Facebook.
The following table describes the rule definitions:
Social Media Post Control Allowed Requests
Action
Allow: Allow content and scan containers
Conditions
M86 SECURITY
HTTP Method
Post
Protocol
HTTP and HTTPS
URL Lists
*.facebook.com
SECURITY POLICIES IN DEPTH
124
CHAPTER 2: DETAILED RULE DESCRIPTIONS
Block Certificate Validation Errors
NOTES: This rule is available only in the M86 HTTPS Policy and is
the only rule in that policy.
The Block Certificate Validation Errors rule blocks sites
containing invalid or missing digital certificates.
The following table describes the Rule definitions:
Block Certificate Validation Errors
Action
Block HTTPS
End-User Message
Certificate Validation Mismatch
Conditions
Certificate
Validation Errors
Default Certificate Validation Profile
IMPORTANT: It is important in any customer-defined HTTPS
Policy to always have the first rule allowing content.
Additional HTTPS Policy Rule Details
The Rule Details screen defines the Action and End User
Message for the corresponding rule, and includes Apply to and
Exception tabs.
• Action: Each rule has a corresponding Action:
y Bypass: Certificate validation will not be performed by the
system. No security inspection will take place.
y Inspect Content (default): HTTPS rules and Security rules
scanning is carried out.
M86 SECURITY
SECURITY POLICIES IN DEPTH
125
RULES
y User approval: Sends an approval page to the end-user for
each new HTTPS site that is accessed. This is sent for
situations where the certificate is valid but user approval is
required to decrypt traffic for this site or where there were
certificate mismatches and the end-user is given the choice to
continue or not. If the end-user chooses not to approve the
transaction, the connection is closed. This is similar to the
Coach action for Security Rules.
y Block HTTPS: Sites that have certificate errors are blocked.
• End-User Message: Each rule that has the Inspect Content or
User Approval or Block HTTPS action can have a reason
which is selected from a drop-down list. This reason is displayed
in a message to the end-user which can be configured via
End-User Messages Æ Block/Warn Messages. This reason
can be selected from a list of pre-defined reasons or created by
the administrator.
Alternatively, you can select Do not display End-User
Message if you do not want to display a message to the
end-user.
• Apply to and Exception tabs: If one or more user lists have
been predefined, you can specify lists of users to which the rule
will be applied and which users should be excluded from the
rule.
Bypass Whitelisted URLs
NOTES: This rule appears only in the M86 Emergency HTTPS
Policy, and is the first rule (of two) to appear in that policy. (The
other rule in that policy is Block all HTTPS URLs except White
Lists.)
The Bypass Whitelisted URLs rule allows access to trusted
Internet sites which are listed on the Emergency white list and the
M86 recommended white list.
M86 SECURITY
SECURITY POLICIES IN DEPTH
126
CHAPTER 2: DETAILED RULE DESCRIPTIONS
The following table describes the Rule definitions:
Bypass Whitelisted URLs
Action
Bypass
Conditions
Certificate Validation Mismatch
URL Lists
M86 Recommended White List, Emergency
White List
Bypass Whitelisted URLs
Block All HTTPS URLS Except White Lists
NOTES: This rule appears only in M86 Emergency HTTPS Policy,
and is the second rule (of two) to appear in that policy. (The first
rule in that policy is Bypass Whitelisted URLs.)
The Block all HTTPS URLs except White Lists rule blocks
access to all URLs that do not appear in the listed white lists.
The following table describes the Rule definitions:
Block all HTTPS URLS except White Lists
Action
Block HTTPS
End-User Message
Emergency Policy Active
Conditions
No conditions apply to this rule
M86 SECURITY
SECURITY POLICIES IN DEPTH
127
PRE-SUPPLIED POLICIES CONTAINING RULES
Chapter 3: Implementing Security Policy
This chapter contains the following main sections:
y Pre-supplied Policies Containing Rules
y Establishing Site Security Policy — Key Points
y List of Available Rules
y Defining Security Policies
y Setting Which Policies are Implemented
y Fields and Options in the Security Definition Screens
Pre-supplied Policies Containing Rules
SWG-provided rules cannot be changed. However, these rules can
be copied and the newly generated rules can then be changed to
match the organization’s security requirements.
The rules are logically grouped into pre-defined policies. To access
the rules, click Policies Æ Condition SettingsÆ Advanced.
The pre-supplied policies with set rules are as follows:
• Full Bypass Policy
• M86 Basic Security Policy
• M86 Blocked Cloud Users Policy
• M86 Emergency Policy
• M86 Medium Security Policy
• M86 Revoked Cloud Users Policy
• M86 Strict Security Policy
• M86 X-Ray Policy
M86 SECURITY
SECURITY POLICIES IN DEPTH
128
CHAPTER 3: IMPLEMENTING SECURITY POLICY
Establishing Site Security Policy — Key Points
To implement security policy, you perform the following tasks:
1. Define any needed new security policies (optional). This
includes defining their rules and adding their conditions.
2. Set which policies will be implemented. This includes setting
which policies will be the site defaults, and then setting any
needed exceptions to those defaults (for administrators, user
groups, users, etc.).
This chapter describes how to perform all these tasks.
As noted in Chapter 1: Security Policy Concepts, the Secure Web
Gateway application comes with a number of predefined security
policies, but you can define other policies.
The application requires a default for each of the following policy
types, and assigns predefined policies as the defaults.
y Master Policy
y Security Policy
y HTTPS Policy
y Logging Policy
y Emergency Policy
y HTTPS Emergency Policy
You can change the default policy assignments.
For each of the above policy types (except Emergency), you can
also assign a different policy for each user and group. If a different
one is not assigned to the user or group, the default is used. (The
policy defined as the default Emergency policy applies to all user
groups and users.)
M86 SECURITY
SECURITY POLICIES IN DEPTH
129
LIST OF AVAILABLE RULES
Note the following:
y You can set any policy as a Master Policy default, and for
different administrators, you can set any other policy as that
administrator’s Master Policy.
y Only one policy can be set as the default Security Policy. A
different policy can set for each User Group/User as the
Security policy in place of the default. The assigned Security
Policy must be one of the following:
Recommended for the default
•
•
•
•
M86 Basic Security Policy
M86 Medium Security Policy
M86 Strict Security Policy
(site-defined policy)
Not recommended for the
default; intended for specific
Users/Groups
•
•
•
•
•
Full Bypass Policy
M86 X-Ray Policy
M86 Blocked Cloud Users Policy
M86 Revoked Cloud Users Policy
(site-defined policy)
Not recommended for the
default or for Users/Groups
M86 Emergency Policy
y Instructions for setting the defaults are provided in Setting
Policy Defaults.
y Instructions for assigning a policy to a user group are
provided in Assigning Policies to User Groups and Users.
List of Available Rules
This section contains the following topics:
y Rules Available for Security Policies
y Rule Available for HTTPS Policies
y Rules Available for Emergency HTTPS Policy
M86 SECURITY
SECURITY POLICIES IN DEPTH
130
CHAPTER 3: IMPLEMENTING SECURITY POLICY
Rules Available for Security Policies
The following table lists predefined rules, and indicates—with an X
in the relevant columns—the rules enabled in each policy.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Revoked Cloud Users
X-Ray
X
Emergency
Strict
X
Full Bypass
Medium
Allow Access to White Listed Sites
Allow All
Allow and Scan Customer-Defined File Extensions
Allow and Scan Customer-Defined True Content Type
Allow Known Legitimate Content
Allow Streaming
Allow Trusted Sites
Allow Whitelisted ActiveX, Java Applets and
Executables
Block Access to Adware Sites
Block Access to Blacklisted Sites
Block Access to High-Risk Site Categories (including
Basic
Rule
Blocked Cloud Users
Rules link to detailed descriptions in Chapter 2: Detailed Rule
Descriptions.
X
M86, Websense and IBM)
Block Access to Spyware Sites
Block ActiveX, Java Applets and Executables by ACL
Block Binary Exploits in Textual Files
Block Binary Objects With Invalid Digital Certificate
Block Binary Objects Without a Digital Certificate
Block Binary VAD Vulnerabilities
Block Blacklisted File Extensions
Block Customer-Defined File Extensions
Block Customer-Defined True Content Type
Block Everything Except White Lists
M86 SECURITY
X
X
X
X
SECURITY POLICIES IN DEPTH
X
X
131
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Revoked Cloud Users
X-Ray
X
X
X
Emergency
Strict
X
X
X
X
Full Bypass
Medium
Block Files with COM Extension
Block Files with Suspicious Multiple Extensions
Block Illegitimate Archives (Including PasswordProtected Archives)
Block IM Tunneling
Block Known Malicious Content
Block Known Spyware (ACL)
Block Known Viruses (McAfee / Sophos / Kaspersky)
Block Malicious ActiveX, Java Applets and
Executables
Block Malicious Content (Malware Entrapment
Engine)
Block Microsoft Office Documents containing Macros
and/or Embedded Files
Block Outgoing Microsoft Office Documents
Block Potentially Malicious Archives
Block Potentially Malicious Packed Executables
Block Revoked Cloud Users
Block Social Media Post Control
Block Spoofed Content
Block Suspicious File Types
Block Unscannable (McAfee / Sophos / Kaspersky)
Block Unscannable ActiveX, Java Applets and
Executables
Block Unscannable Archives
Customer-Defined URL Filtering (including M86,
Basic
Rule
Blocked Cloud Users
LIST OF AVAILABLE RULES
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Websense and IBM)
Data Leakage Prevention
Detect Known Trojan Network Activity
M86 SECURITY
SECURITY POLICIES IN DEPTH
X
132
Social Media Post Control Allowed Requests
Temporarily Block Cloud Users
Revoked Cloud Users
Emergency
Full Bypass
X-Ray
Strict
Medium
Basic
Rule
Blocked Cloud Users
CHAPTER 3: IMPLEMENTING SECURITY POLICY
X
X
IMPORTANT:
• The difference between Medium and Strict Security
Policies is displayed in the Block Unscannable ActiveX,
Java Applets and Executables rule where the Default
Profile - Binary Behavior is not blocked in the Medium
Security Policy.
• Where possible, Trustwave SpiderLabs provides Rule
Tests for the above rules. Before beginning Rule Tests,
ensure that your browser is configured with the SWG NG
Appliance IP as an HTTP proxy.
Rule Available for HTTPS Policies
HTTPS policy contains a single rule:
y Block Certificate Validation Errors
Rules Available for Emergency HTTPS Policy
Emergency HTTPS policy contains the following rules:
y Bypass Whitelisted URLs
y Block All HTTPS URLS Except White Lists
M86 SECURITY
SECURITY POLICIES IN DEPTH
133
DEFINING SECURITY POLICIES
Defining Security Policies
This section contains the following procedures:
y Creating a Security Policy
y Creating / Editing a Rule in a User-Defined Policy
y Adding / Editing Conditions in a Rule
y Example - Creating a New Rule
Creating a Security Policy
NOTE: This procedure applies to the following policies:
• Full Bypass Policy
• M86 Basic Security Policy
• M86 Medium Security Policy
• M86 Strict Security Policy
• M86 X-Ray Policy
• M86 Emergency Policy
• M86 HTTPS Policy
• M86 HTTPS Emergency Policy
You can assign any security policy as the default Master Policy.
For instructions, see Setting Policy Defaults.
 To create a security policy:
1. Right-click the policy that you want to duplicate, and choose
Duplicate Policy. (Alternatively, you can create a new policy
from scratch by right-clicking the root Policies node in the tree
and choosing Add Policy.)
M86 SECURITY
SECURITY POLICIES IN DEPTH
134
CHAPTER 3: IMPLEMENTING SECURITY POLICY
The following table identifies how to access each type of policy
that can be duplicated, in the Management Console.
Policy
Access
• M86 Basic Security Policy
• M86 Medium Security Policy
• M86 Strict Security Policy
Policies Æ Security Æ
Advanced.
•
•
•
•
•
Policies Æ Security Æ
Advanced.
Full Bypass Policy
M86 Emergency Policy
M86 X-Ray Policy
M86 Blocked Cloud Users Policy
M86 Revoked Cloud Users Policy
• M86 HTTPS Policy
• M86 HTTPS Emergency Policy
Policies Æ HTTPS
2. In the Duplicate Policy window, do the following:
a. Type a name for the policy.
b. If the policy should be an X-Ray policy, select the X-Ray
check box. (An X-ray policy is generally used for
evaluation purposes. It evaluates and logs transactions
against its rules, but does not activate the rules.)
c. Provide a description of the policy (optional).
d. When done, click Save.
3. Create and add the rules that constitute the policy. For
instructions, see Creating / Editing a Rule in a User-Defined Policy.
Creating / Editing a Rule in a User-Defined Policy
 To create or edit a rule in a user-defined policy:
1. Do any of the following:
y To edit an existing rule, click the rule in the tree, and then in
the main pane, click Edit.
M86 SECURITY
SECURITY POLICIES IN DEPTH
135
DEFINING SECURITY POLICIES
y If you are defining the first rule in the policy, right-click the
policy and choose Add Rule.
y To add a rule directly above an existing rule, right-click the
existing rule, and select Insert Rule.
(Note: To move a defined rule above or below another
defined rule, right-click either of the two rules and choose
Move this Rule; then right-click the other rule, and choose
Above this Rule or Below this Rule, as appropriate. This is
especially useful if you want to create a new rule under the
lowest rule, but the Insert Rule command inserts the new rule
above that rule.)
2. In the Rule definition screen:
a. Type (or edit) a name for the rule.
b. If the rule should be an X-ray rule, select the X-Ray check
c.
d.
e.
f.
M86 SECURITY
box. An X-ray rule is a rule that is evaluated and logged,
but not activated.
Provide a description of the rule (optional).
Select the Action for the rule (Allow, Block, or Coach.) For
more information, see Rules and Conditions and Rule
Processing Flow.
Depending on whether or not the rule should be enabled,
ensure that the Enabled check box is appropriately
checked or unchecked (default: Enabled).
Do either of the following:
ƒIf you chose Allow as the action, select the appropriate
Advanced Action.
ƒIf you chose Block or Coach as the action, select the
desired End-User Message. If the End User
Message should not be displayed, select the Do Not
Display End User Message check box. For
information on defining End User Messages, see
Rules and Conditions and Rule Processing Flow.
SECURITY POLICIES IN DEPTH
136
CHAPTER 3: IMPLEMENTING SECURITY POLICY
g. For Security, Logging, and HTTPS policies, if one or more
user lists have been predefined:
ƒ Click the Apply to tab and select the check box to
specify to which predefined user lists the rule will be
applied.
ƒ Click the Exception tab and select the check box to
specify which user lists should be excluded from the
rule.
For more information, see Defining User Lists.
h. Click Save.
3. Add the Conditions that determine if the rule will be triggered.
For instructions, see Adding / Editing Conditions in a Rule.
Adding / Editing Conditions in a Rule
 To add each condition to the rule in a user-defined policy:
1. Do either of the following:
y To edit an existing condition, click the condition under the rule
in the tree, and then in the main pane, click Edit.
y To add a new condition, right-click the rule and choose Add
Condition.
2. In the Condition definition screen, do the following.
a. Select a condition. Depending on the condition that you
choose, an appropriate check box list is displayed at the
bottom of the Condition window.
b. In the Applies To area, select whether you want to apply
the condition to any of the values you will be selecting in
the check list, or to apply the conditions to the values you
will NOT be selecting in the check list.
c. Depending on the Applies To radio button you selected,
check the appropriate check boxes. (If useful, you can
use the Select/Deselect All check box).
d. If the condition has any other special fields or
requirements to fill in, fill them in appropriately.
M86 SECURITY
SECURITY POLICIES IN DEPTH
137
DEFINING SECURITY POLICIES
e. Click Save.
3. (To delete a condition, right-click the condition and choose
Delete Condition).
Example - Creating a New Rule
This example describes a Data Leakage Prevention policy, rule
and condition creation, and test.
Use the following steps to create and test a Data Leakage
Prevention rule:
1. To create a new Data Leakage Condition:
2. To create a new Data Leakage Prevention Profile and Rule:
3. To test the New Rule:
 To create a new Data Leakage Condition:
This Condition Component example ensures that Diner’s Club
credit card numbers do not leave the organization. An entry such
as Diners Club 3005 458696 5454 is recognized and blocked, all
Diners Club credit card information numbers beginning with 300
and a total of 14 digits is recognized. However, an entry such as
Diners Club 4005 458696 5454 is not blocked, as it does not meet
the condition requirements (such as the number 300) and is
therefore known not to be a valid Diners Club credit card number.
1. To create a new Security policy, click Policies Æ Condition
SettingsÆ Data leakage Prevention.
2. In the left pane, right-click Data Leakage Condition and click
Add Filter Condition, or click
M86 SECURITY
.
SECURITY POLICIES IN DEPTH
138
CHAPTER 3: IMPLEMENTING SECURITY POLICY
A new component is added to the list of Condition Components.
Figure 3-1: Create Condition Component
3. In the Data Leakage Prevention Name box, type an appropriate
Condition name, for example, Block Documents with Diners CC.
4. Build the condition using the appropriate values, placeholders,
and operators. For this example, build the following condition:
(Diners Club OR Carte Blanche) AND (300$$$$$$$$$$$ OR
305$$$$$$$$$$$ OR 36$$$$$$$$$$$$).
SWG provides three different condition building methods:
y Edit the condition directly into the workspace.
y Use the provided Condition Builder:
Click Condition Builder.
The Condition Builder dialog box opens.
Figure 3-2: Condition Builder Dialog Box
M86 SECURITY
SECURITY POLICIES IN DEPTH
139
DEFINING SECURITY POLICIES
y Use the on-screen editing buttons.
Figure 3-3: On-screen Condition Editing Buttons
NOTES: Be sure to use the placeholder buttons for the right
and left parentheses, the “OR” and “AND” logical operators,
and the $ numeric wild card.
While typing the condition, SWG automatically checks syntax
accuracy, and when completing the condition, SWG indicates
the correctness by changing the
icon to
.
Figure 3-4: New Condition Component
5. Click Save.
M86 SECURITY
SECURITY POLICIES IN DEPTH
140
CHAPTER 3: IMPLEMENTING SECURITY POLICY
The new Component is added to the Condition.
Figure 3-5: New Added Component
 To create a new Data Leakage Prevention Profile and Rule:
1. To create a new Security policy, click Policies Æ Security.
2. In the left pane, right-click Policies and click Add Policy, or if
displayed, click
.
A new policy is added to the list of policies.
Figure 3-6: Create New Policy
M86 SECURITY
SECURITY POLICIES IN DEPTH
141
DEFINING SECURITY POLICIES
3. In the Policy Name box, type DLP Test Policy, and then click
Save.
4. Right-click the DLP Test Policy policy, and then click Add
Rule, or click
.
A new rule is opened in the right pane.
5. In the Rule Name box, type Data Leakage Prevention and in
the End-User Message drop-down list select Data Leakage
Prevention.
Figure 3-7: Create New DLP Rule
6. If one or more user lists have been predefined:
y Click the Apply to tab and select the check box to specify to
which predefined user lists the rule will be applied.
y Click the Exception tab and select the check box to specify
which user lists should be excluded from the rule.
For more information, see Defining User Lists.
M86 SECURITY
SECURITY POLICIES IN DEPTH
142
CHAPTER 3: IMPLEMENTING SECURITY POLICY
7. Click Save.
The new rule is displayed under the policy.
Figure 3-8: New DLP Rule Added
8. Right-click the Data Leakage Prevention rule, and then click
Add Condition, or click
.
A new Condition is opened in the right pane.
9. In the Condition Name drop-down list, select Data Leakage
Prevention, and then from the displayed Components select
Block Documents with Diners CC.
M86 SECURITY
SECURITY POLICIES IN DEPTH
143
DEFINING SECURITY POLICIES
Figure 3-9: Add Condition to Rule
10.Click Save.
The new Condition is displayed under the Rule.
Figure 3-10: New Condition Added to Rule
M86 SECURITY
SECURITY POLICIES IN DEPTH
144
CHAPTER 3: IMPLEMENTING SECURITY POLICY
11.To ensure that the new policy is in use, click Policies Æ
Default Policy Settings.
12.Click Edit, then in the Default Policy Values workspace, from
the Security Policy drop-down select DLP Test Policy.
Figure 3-11: Setting Default Security Policy
13.Click Save.
 To test the New Rule:
1. Copy the following URL into your browser:
http://www.m86security.com/EVG/diners.doc
2. Connect to the site, and type the username: getevg and
password: HurNoc45, and then click OK.
3. Copy the following URL into your browser:
http://www.m86security.com/EVG/data_leakage_test.asp
4. Click Browse, then navigate to the folder containing the
downloaded “diners.doc”, and select the file.
M86 SECURITY
SECURITY POLICIES IN DEPTH
145
SETTING WHICH POLICIES ARE IMPLEMENTED
5. Click Upload.
6. For a correctly configured rule, SWG displays a blocking
message, similar to the following:
Figure 3-12: Data Leakage Prevention Page Block Message
Setting Which Policies are Implemented
You can override the defaults for specific user groups and users. In
the case of Master Policy, you can assign policies other than the
default Master Policy to different administrators. You can also
define user lists to identify the users to which specific rules should
or should not apply.
This section contains the following topics:
y Setting Policy Defaults
y Setting a Master Policy for an Administrator
y Assigning Policies to User Groups and Users
y Defining User Lists
M86 SECURITY
SECURITY POLICIES IN DEPTH
146
CHAPTER 3: IMPLEMENTING SECURITY POLICY
Setting Policy Defaults
You set policy defaults in the Default Policy Settings screen of
the Management Console.
 To set policy defaults:
1. Select Policies Æ Default Policies Settings.
The Default Policies Settings screen (Figure 3-13) lists a number
of policy types, and provides a drop-down list of all defined
policies for each type.
Figure 3-13: Default Policy Settings Screen
M86 SECURITY
SECURITY POLICIES IN DEPTH
147
SETTING WHICH POLICIES ARE IMPLEMENTED
2. Click Edit.
3. To set Emergency Policies here, check the Enable Emergency
Policy check box and select the policies. Note: Setting
Emergency Policies here assigns them to all Users and
overrides any other Security Policies individually set per User or
per User Group.
4. In the Default Policy Values area, select the desired policy for
each policy type. For an explanation of the different types of
policies, see Types of Policies.
Note the following:
y In the Master Policy drop down list, the empty option is the
default value provided by the system. Select one of the
policies to be used as the default Master Policy.
y The default Security, Logging and HTTPS policies set here
will automatically be assigned to users in the system if no
other Policies have been assigned to them in the Users tab.
They will also be assigned automatically to unknown users.
The following are the default values provided by the system:
ƒ
ƒ
ƒ
Security Policy: M86 Security Strict Security Policy
Logging Policy: Log All Protective Actions Policy
HTTPS Policy: M86 HTTPS Policy
NOTE: The policies you define here will be the values referred to in
User Groups and LDAP Groups.
5. When done, click Save.
M86 SECURITY
SECURITY POLICIES IN DEPTH
148
CHAPTER 3: IMPLEMENTING SECURITY POLICY
Setting a Master Policy for an Administrator
NOTE: Before setting a security policy as the Master Policy for an
administrator, you must ensure that the security policy is defined.
For instructions on creating a security policy, see Creating a
Security Policy.
 To set a master policy:
1. In the Management Console, select Administration Æ
Administrators, and then, in the tree pane under Super
Administrators, select Admin.
2. In the main pane:
a. Click Edit.
b. In the Master Policy drop-down list, select the policy that
should be used as the Master Policy.
c. Click Save.
Assigning Policies to User Groups and Users
Unless you instruct otherwise, all users groups and users will use
the default policies, as set in Setting Policy Defaults.
NOTE: The application comes with predefined user groups called
Blocked Cloud Users and Revoked Cloud Users. It is
recommended that you assign Cloud User policies to the
like-named user group, and then add or remove users from the
groups as needed.
 To assign policies to a User Group:
NOTE: This procedure assumes that the User Group is already
created. For instructions on creating other User Groups, see the
Management Console Reference Guide.
1. Select Users Æ Users/User Groups.
2. In the User Group tree, select the User Group.
M86 SECURITY
SECURITY POLICIES IN DEPTH
149
SETTING WHICH POLICIES ARE IMPLEMENTED
3. In the main detail screen (Figure 3-14), do the following:
Figure 3-14: User Group Policy Definition
a. Click Edit.
b. For each policy type whose assignment you want to
change, select the desired policy in the drop down list.
c. When done, click Save.
M86 SECURITY
SECURITY POLICIES IN DEPTH
150
CHAPTER 3: IMPLEMENTING SECURITY POLICY
 To assign policies to individual users:
NOTE: This procedure assumes that the user, including IP
addresses, is already defined. For instructions on defining users,
see the Management Console Reference Guide.
1. Select Users Æ Users/User Groups.
2. In the Independent Users tree, select the user.
3. In the main detail screen for the user:
a. Click Edit.
b. For each policy type whose assignment you want to
change, select the desired policy in the drop down list.
c. When done, click Save.
Defining User Lists
User Lists enable you to define lists of LDAP Groups and Users,
and M86 User Groups and users. The lists can then be used to
identify the users to which specific rules should or should not apply
when defining Security, HTTPS, and Logging Policy rules.
You define User Lists in the User Lists screen, accessed via
Users Æ User Lists.
• To create a new user list, right-click the User Lists main node in
the tree and select Add List.
• To edit an existing user list, select the list under the User Lists
main node. Then, in the User List window, click Edit.
For detailed instructions, see the Management Console User
Guide.
M86 SECURITY
SECURITY POLICIES IN DEPTH
151
SETTING WHICH POLICIES ARE IMPLEMENTED
The User List definition window is displayed in the main pane and
comprises five tabs:
• The Selected Members tab displays a summary of the details
selected in the other lists.
• The other tabs, LDAP Groups, LDAP Users, M86 User
Groups, and M86 Users, enable you to select existing values
from those respective categories.
Note that selected items are cumulative. For example, an LDAP
user who was not selected in the LDAP User tab, but who belongs
to an LDAP Group that was selected in the LDAP Group tab, will be
included in the list.
After a new or edited user list is saved and committed, the list is
included in the lists that appear in the Applies To tab and Except
tab of Security, HTTPS and Logging policy rules.
To see which policy rules a list is used in, right-click the User List
and select Used In.
For more information, see the Management Console Reference
Guide.
M86 SECURITY
SECURITY POLICIES IN DEPTH
152
CHAPTER 3: IMPLEMENTING SECURITY POLICY
Fields and Options in the Security Definition
Screens
This section contains the following topics:
y Options Available in the Policy Tree
y Policy Details Screen - Fields
y Rule Details Screen - Fields
y Condition Details Screen - Fields
Options Available in the Policy Tree
The following table describes the options available when you
right-click a tree entry at a particular level:
Action
Description
Root Level
Add Policy
Available from top level folder only. Allows
you to create a new Policy.
Policy Level
M86 SECURITY
Add Rule
Available from Policy folder. Allows you to
create a new Rule.
Delete Policy
Available from specific Policy. Allows you to
remove a Policy. Note that deleting a Policy
will delete all the Rules and Conditions
belonging to it.
Set As Default
Available from specific Policy. Allows you to
set the Policy as the default Security Policy.
Duplicate Policy
Available from specific Policy. Allows you to
clone a predefined Policy and customize it for
your own needs.
SECURITY POLICIES IN DEPTH
153
FIELDS AND OPTIONS IN THE SECURITY DEFINITION SCREENS
Action
Description
Export to HTML
Available from specific Policy. Allows you to
export to HTML format - which you can then
save or print as required.
Export to XML
Available from specific Policy. Allows you to
export to XML format - which you can then
save or print as required.
Rule Level
Add Condition
Available from Rule. Allows you to create a
new Condition.
Insert New Rule
Available from any rule. Allows you to insert a
new rule into your Policy above the rule you
are currently standing on.
Delete Rule
Available from specific Rule. Allows you to
remove a Rule from the Policy.
Move Rule To
Before this Rule
After this Rule
Available from specific Rule. Select Move
Rule To and then move cursor to desired
place. Select Before this Rule/After this
Rule to move the rule to the required
location.
Condition Level
Delete Condition
M86 SECURITY
Available from specific Condition. Allows you
to remove a Condition from a Rule.
SECURITY POLICIES IN DEPTH
154
CHAPTER 3: IMPLEMENTING SECURITY POLICY
Policy Details Screen - Fields
The Policies Details screen displays the following information:
M86 SECURITY
Field
Description
Policy Name
Name of the specific policy
X-Ray
Defines whether the Policy is X-Ray or not. (X-Ray
means the policy is logged but no action is taken)
Description
Contains a description of the policy.
User Groups/Users
using this policy
Security Policies can be assigned to different user
groups and users. This section displays which user
groups/users have this particular Policy assigned to
them. For more information on assigning policies to
user groups and users, see Assigning Policies to
User Groups and Users.
SECURITY POLICIES IN DEPTH
155
FIELDS AND OPTIONS IN THE SECURITY DEFINITION SCREENS
Rule Details Screen - Fields
If a rule is not specific to any of the listed values for a condition,
instead of selecting all possible values, do not use the condition,
and leave it blank.
The Rules Details screen displays the following information:
M86 SECURITY
Field
Description
Rule Name
Defines the name of the Security rule.
X-Ray
If the X-Ray check box is ticked, the rule is evaluated in the
Logs only. In other words, an x-ray rule is activated and
logged, but no block, warn or explicit allow action is taken.
Description
This provides a place for you to write a description of the rule.
Enable
Rule
When checked, the rule is enabled. When unchecked, the
rule is disabled.
Action
Block, Coach or Allow action, on positive evaluation of the
rule, as described below.
Block
The web content is blocked.
Coach
The web content is temporarily blocked and the
end-user receives a warning message that this
site is not recommended and that his/her activities
will be logged. The end-user can then decide
whether to proceed or not.
Allow
The web content is allowed and the selected
Advanced Action is taken as described below.
SECURITY POLICIES IN DEPTH
156
CHAPTER 3: IMPLEMENTING SECURITY POLICY
Field
Description
Advanced
Action
When Allow is selected you can choose one of the following
Advanced Action options:
• Allow transactions and scan containers: The content
is allowed, but container files are opened and the
contents are scanned. (This is the default option)
•
Allow content and do not scan containers: Allows
content through including container files, such as zip or
rar files, without scanning inside them. Content is allowed
through on request stage but may be stopped on
response stage.
•
Bypass Scanning: Allows content through without any
scanning at all on the request or response stage. This
allows full streaming and is useful, for example, for sites
which contain stock ticker streaming.
Do not
display
end-user
Message
Withholds sending a block page to the end-user.
End-user
Message
Defines which message is sent in the Page Block/Warn
message. The end-user message list and associated text is
managed in Policies Æ End User Messages Æ Block/Warn
Messages. The end-user Message template can be modified
in Policies Æ End User Messages Æ Message Template.
NOTES:
•
The Coach action can be applied to URL Categories and URL
Lists in an Outgoing direction only. In addition, only the
following Conditions can be added: Time Frame, Header
Fields, File Extension.
•
The Allow-Advanced actions which allow container files through
without scanning can be placed anywhere in your Security
Policy.
• In certain circumstances, X-Ray block rules might block traffic.
This happens when the web server replies with non-standard
HTTP traffic. This is applicable only for X-ray rules and not for
X-ray policies.
M86 SECURITY
SECURITY POLICIES IN DEPTH
157
FIELDS AND OPTIONS IN THE SECURITY DEFINITION SCREENS
Condition Details Screen - Fields
The Condition Details screen displays the following information:
Field
Description
Condition Name
Displays the name of the Condition. If you are defining
a new condition, choose the required condition from
the drop-down list.
Applies To
You can select which options are to be included or
excluded. In other words, you can either choose to
apply this rule to everything selected below or to apply
this rule to everything EXCEPT for the items selected
below.
Select/Deselect
All
Choose to select/deselect all the items in the
Condition.
The items display differently according to the Condition you have chosen.
For the list of available conditions, see Available Conditions.
M86 SECURITY
SECURITY POLICIES IN DEPTH
158
APPENDIX A
APPENDIX A
The following diagrams are sample illustrations of the Master
Policy and Security Policy enforcement process.
Figure A-1: Blocked by Master Policy (Request)
M86 SECURITY
SECURITY POLICIES IN DEPTH
159
Figure A-2: Blocked by Master Policy (Response)
M86 SECURITY
SECURITY POLICIES IN DEPTH
160
APPENDIX A
Figure A-3: Blocked by Security Policy (Request)
M86 SECURITY
SECURITY POLICIES IN DEPTH
161
Figure A-4: Blocked by Security Policy (Response)
M86 SECURITY
SECURITY POLICIES IN DEPTH
162
APPENDIX A
Figure A-5: Security X-Ray (Request)
M86 SECURITY
SECURITY POLICIES IN DEPTH
163
Figure A-6: Security X-Ray (Response)
M86 SECURITY
SECURITY POLICIES IN DEPTH
164
APPENDIX A
Figure A-7: Security Coach Rule (Option 1)
M86 SECURITY
SECURITY POLICIES IN DEPTH
165
Figure A-8: Security Coach Rule (Option 2)
M86 SECURITY
SECURITY POLICIES IN DEPTH
166
APPENDIX A
Figure A-9: Security X-Ray DLP (Request)
M86 SECURITY
SECURITY POLICIES IN DEPTH
167