Security Policies In-Depth - TrustwaveWHERE TO GO FROM HERE M86 SECURITY SECURITY POLICIES IN DEPTH 6 About This Manual This manual supplements the security policy information described

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 ................................................... 6Where To Go From Here. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

CHAPTER 1: SECURITY POLICY CONCEPTS.................... 7Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Types of Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Master Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10X-Ray Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Emergency Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12HTTPS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Full Bypass Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Cloud User Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Security Policy Components . . . . . . . . . . . . . . . . . . . . . . . . . . 14Rules and Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Rule Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Available Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

CHAPTER 2: DETAILED RULE DESCRIPTIONS............... 37Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Allow Access to White Listed Sites . . . . . . . . . . . . . . . . . . . . . . . . . 37Allow All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Allow and Scan Customer-Defined File Extensions. . . . . . . . . . . . . 43Allow and Scan Customer-Defined True Content Type . . . . . . . . . . 44Allow Known Legitimate Content . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Allow Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Allow Trusted Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Allow Whitelisted ActiveX, Java Applets and Executables . . . . . . . 48Block Access to Adware Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Block Access to Blacklisted Sites . . . . . . . . . . . . . . . . . . . . . . . . . . 53Block Access to High-Risk Site Categories . . . . . . . . . . . . . . . . . . 58Block Access to Spyware Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Block ActiveX, Java Applets and Executables by ACL . . . . . . . . . . 65Block Binary Exploits in Textual Files . . . . . . . . . . . . . . . . . . . . . . . 68


TABLE OF CONTENTS

Block Binary Objects With Invalid Digital Certificate . . . . . . . . . . . . 69Block Binary Objects Without a Digital Certificate . . . . . . . . . . . . . . 71Block Binary VAD Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Block Blacklisted File Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . 76Block Customer-Defined File Extensions. . . . . . . . . . . . . . . . . . . . . 79Block Customer-Defined True Content Type . . . . . . . . . . . . . . . . . . 80Block Everything Except White Lists . . . . . . . . . . . . . . . . . . . . . . . . 81Block Files with COM Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Block Files with Suspicious Multiple Extensions . . . . . . . . . . . . . . . 83Block Illegitimate Archives (Including Password-Protected Archives). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Block IM Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Block Known Malicious Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Block Known Spyware (ACL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Block Known Viruses (McAfee / Sophos / Kaspersky). . . . . . . . . . . 93Block Malicious ActiveX, Java Applets and Executables. . . . . . . . . 96Block Malicious Content (Malware Entrapment Engine) . . . . . . . . 102Block Microsoft Office Documents containing Macros and/or Embedded Files . . . . . . . . . . . . . . . . . . 103Block Outgoing Microsoft Office Documents . . . . . . . . . . . . . . . . . 106Block Potentially Malicious Archives . . . . . . . . . . . . . . . . . . . . . . . 109Block Potentially Malicious Packed Executables . . . . . . . . . . . . . . 111Block Revoked Cloud Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Block Spoofed Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Block Suspicious File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Block Unscannable (McAfee / Sophos / Kaspersky) . . . . . . . . . . . 117Block Unscannable ActiveX, Java Applets and Executables. . . . . 117Block Unscannable Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Customer-Defined URL Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 120Data Leakage Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Detect Known Trojan Network Activity. . . . . . . . . . . . . . . . . . . . . . 122Temporarily Block Cloud Users . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Block Social Media Post Control . . . . . . . . . . . . . . . . . . . . . . . . . . 123Social Media Post Control Allowed Requests . . . . . . . . . . . . . . . . 124Bypass Whitelisted URLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Block All HTTPS URLS Except White Lists . . . . . . . . . . . . . . . . . . 127


TABLE OF CONTENTS

CHAPTER 3: IMPLEMENTING SECURITY POLICY.......... 128Pre-supplied Policies Containing Rules . . . . . . . . . . . . . . . . 128

Establishing Site Security Policy — Key Points . . . . . . . . . 129

List of Available Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Rules Available for Security Policies . . . . . . . . . . . . . . . . . . . . . . . 131Rule Available for HTTPS Policies. . . . . . . . . . . . . . . . . . . . . . . . . 133Rules Available for Emergency HTTPS Policy . . . . . . . . . . . . . . . 133

Defining Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Creating a Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Creating / Editing a Rule in a User-Defined Policy . . . . . . . . . . . . 135Adding / Editing Conditions in a Rule. . . . . . . . . . . . . . . . . . . . . . . 137Example - Creating a New Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Setting Which Policies are Implemented . . . . . . . . . . . . . . . 146Setting Policy Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Setting a Master Policy for an Administrator . . . . . . . . . . . . . . . . . 149Assigning Policies to User Groups and Users . . . . . . . . . . . . . . . . 149Defining User Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Fields and Options in the Security Definition Screens . . . . 153Options Available in the Policy Tree . . . . . . . . . . . . . . . . . . . . . . . 153Policy Details Screen - Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Rule Details Screen - Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Condition Details Screen - Fields . . . . . . . . . . . . . . . . . . . . . . . . . 158

APPENDIX A .............................................................. 159


WHERE TO GO FROM HERE


About This ManualThis 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 HereThe 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.

CHAPTER 1: SECURITY POLICY CONCEPTS

Chapter 1: Security Policy ConceptsThis chapter contains the following main sections:

• Introduction• Types of Policies

Master Security Policy

X-Ray Policy

Emergency Policies

HTTPS Policies

Full Bypass Policy

Cloud User Policies

• Security Policy ComponentsRules and Conditions

Rule Logic

Available Conditions

• User Management


INTRODUCTION

IntroductionSecure 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.



Types of PoliciesSecure Web Gateway provides the following pre-supplied security policies.

Policy For information, see:

• M86 Master Policy• M86 Basic Security Policy• M86 Medium Security Policy• M86 Strict Security Policy

Master Security Policy.

M86 X-Ray Policy (and X-Ray Mode)

X-Ray Policy

• M86 Emergency Policy• M86 HTTPS Emergency

Policy

Emergency Policies

M86 HTTPS Policy HTTPS Policies

• M86 Blocked Cloud Users Policy

• M86 Revoked Cloud Users Policy

Cloud User Policies

Full Bypass Policy Full Bypass Policy

• Caching Policy• Logging Policies• Identification Policies• Device Logging Policies

For details, see the Management Console Reference Guide.


TYPES OF POLICIES

Master Security PolicyMaster 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.

Figure 1-1 illustrates the relationships between Super Administrators, general Administrators, and Security policies.

Figure 1-1: Master Policy Dependencies

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.



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.


TYPES OF POLICIES

X-Ray PolicyAn 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).

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 PoliciesThe 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).

NOTES: Rules within the X-Ray Policy are not marked as X-Ray mode.



HTTPS PoliciesM86 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 PolicyThis 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 PoliciesCloud 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.


SECURITY POLICY COMPONENTS

Security Policy Components

Rules and ConditionsThe 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:Allow: The web content is allowed, usually with a specified action requirement.Block: The web content is blocked.



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:

Advanced Actions: Used for Allow actions. 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):

Data Leakage Prevention (Applies to Confidential information)Direction (Applies to Incoming/Outgoing)



Rule LogicA 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:

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.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.



• 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 PhaseIf 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.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 PhaseAny content received in the response phase is evaluated regardless of the action taken in the Request phase.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.If a Block action is triggered, the content is not passed to the user, and an appropriate error message is displayed to the user.



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.



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.



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



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.



Available ConditionsEach 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.

Authenticate M86 SWG: Communicates with the client to get USERID information and uses an external Authentication Site to validate this information.Get user credentials: M86 SWG gets user identification via NTLM or another such method.Identify by headers: Identifies the end-user according to the Header (HTTP).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.



• 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:

Allowed: Allows trusted objects, which are blocked by the Default Security Policy.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.



• 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.



• 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:

Suspected Malware: Contains behavior profile patterns specific to Spyware objects. This option is displayed only if the Anti-Spyware engine is purchased.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:

Automatic Execution and Termination: Conditions for automatic file execution options considered unsafe when performed by ActiveX, Executables and by Java Applets.File Access: Conditions for file access options considered unsafe when performed by ActiveX, Executables and by Java Applets.Registry Access: Conditions for registry access options considered unsafe when performed by ActiveX, Executables and by Java Applets.Network Access: Conditions for network access options considered unsafe when performed by ActiveX, Executables and by Java Applets.Minor Risk Operations: Conditions for minor risk operations options considered unsafe when performed by ActiveX, Executables and by Java Applets.



Disclosure of Information: Conditions for Disclosure of Information options considered unsafe when performed by Java Applets.Java Runtime: Conditions for Java runtime options considered unsafe when performed by Java Applets, which can eliminate security restrictions.Change Settings: Conditions for Change Settings options considered unsafe when performed by ActiveX and Executables.System Settings: Conditions for system settings options considered unsafe when performed by Java Applets.General: Conditions for general options considered unsafe when performed by ActiveX and Executables.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.



• 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.



• 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.



• 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.



• 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.



Conditions can be set for the following certificate validation failures:

Invalid Certificate StructureCertificate Cannot be TrustedCertificate is Not Currently ValidCertificate RevokedHost Cannot be TrustedBad 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:

Cloud: The scanning server is located in the internet cloud.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.



• 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.



• 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.



• 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.



• 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:

Client IP Header and User Name Header: How user credentials are forwarded to the upstream proxy.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.


USER MANAGEMENT

User ManagementThe 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.

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.

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.


CHAPTER 2: DETAILED RULE DESCRIPTIONS

Chapter 2: Detailed Rule DescriptionsThis 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 SitesThis 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.


RULES

The following table describes the M86-provided rule definitions:

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).

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.



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.


http://www.finjan.com/EVG/passwordprotected.ziphttp://www.m86security.com/EVG/passwordprotected.zip

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 .


http://www.m86security.com/EVG/passwordprotected.zip


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.



http://www.finjan.com/EVG/passwordprotected.ziphttp://www.m86security.com/EVG/passwordprotected.zip

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.



Allow All

General Tab

Action Allow

Advanced Action Bypass Scanning

Apply to Tab


Exceptions Tab




Allow and Scan Customer-Defined File ExtensionsThis rule enables files with specific extensions to avoid scanning, and at the same time enables container file scanning, for example zipped files.


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.

Allow and Scan Customer-Defined File Extensions

General Tab

Action Allow


Apply to Tab


Exceptions Tab



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.


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.

Allow and Scan Customer-Defined True Content Type

General Tab

Action Allow


Apply to Tab


Exceptions Tab




Allow Known Legitimate ContentThis rule enables the scanning of files that have been approved as known legitimate content by M86 to be bypassed.


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.

Allow Known Legitimate Content

General Tab

Action Allow

Advanced Action Allow content and do not scan containers

Apply to Tab


Exceptions Tab



RULES

Allow StreamingThis rule enables media streaming such as audio and video to pass through the system.



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.

Allow Streaming

General Tab

Action Allow

Advanced Action Bypass scanning

Apply to Tab


Exceptions Tab




Allow Trusted SitesThis 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.

Allow Trusted Sites

General Tab

Action Allow

Advanced Action Bypass scanning

Apply to Tab


Exceptions Tab



RULES

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.


Allow Whitelisted ActiveX, Java Applets and Executables

General Tab

Action Allow

Advanced Action Allow content and do not scan containers

Apply to Tab


Exceptions Tab





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.


RULES

Block Access to Adware SitesThis rule blocks predefined Adware URLs. The rule is enforced, when its conditions are met, at the Request phase.



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.

Block Access to Adware Sites

General Tab

Action Block

End-user Message Blocked adware URL

Apply to Tab


Exceptions Tab




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.


www.infinityads.comwww.infinityads.com

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



Block Access to Blacklisted SitesThis rule blocks URLs on a predefined list specifying blacklisted sites. The rule is enforced, when its conditions are met, at the Request phase.



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).

Block Access to Blacklisted Sites

General Tab

Action Block

End-user Message Blacklisted URL

Apply to Tab


Exceptions Tab



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.


Figure 2-7: Edit URL to Customer Defined Black List



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).


To test that this website was blocked:

1. Copy and paste the following URL into your browser:

www.cnn.com


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.


http:/www.cnn.com www.cnn.comwww.cnn.com

RULES


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.

mp



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.



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.

Block Access to High-Risk Site Categories

General Tab

Action Block

End-user Message Blocked URL Category

Apply to Tab


Exceptions Tab




Conditions

For the following rules, SWG selects the following conditions:

• URL Filtering: Includes the following condition elements and sub-condition elements:

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:

Adult/Sexually ExplicitHackingProxies and TranslatorsSpyware

• URL Filtering (IBM): Includes the following condition elements:Anonymous ProxiesComputer Crime/HackingErotic/SexMalwarePhishing URLsPornographySpam URLsWarez/Software Piracy


RULES

Testing the Rule

To test the Block Access to High-Risk Site Categories rule:


http://www.hackingexposed.com/


Figure 2-12: Page Blocked Message - Hacking


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.


NOTES: The transaction ID refers to the unique interaction between the end-user and the SWG system.



Figure 2-13: Request: High-Risk Site Categories - Hacking

Block Access to Spyware SitesThis rule blocks predefined Spyware Sites. The rule is enforced, when its conditions are met, at the Request phase.


Block Access to Spyware Sites

General Tab

Action Block

End-user Message Blocked Spyware URL

Apply to Tab


Exceptions Tab



RULES


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:

www.dplog.com www.cashsearch.biz

The following message opens when trying to access the sites.

Figure 2-14: Page Blocked Message – Spyware Sites



http://www.dplog.comwww.dplog.comwww.cashsearch.biz


Figure 2-15: View Web Logs


Figure 2-16: Transaction Details - Spyware Site


RULES


Figure 2-17: Request: Spyware Sites



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.



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.

Block ActiveX, Java Applets and Executables by ACL

General Tab

Action Block

End-user Message Active Content List

Apply to Tab


Exceptions Tab



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.



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.

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.


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.

p


http://www.hackingexposed.com/ http://java.sun.com/applets/jdk/1.3/http://java.sun.com/applets/jdk/1.3/http://java.sun.com/applets/jdk/1.3/

RULES

Block Binary Exploits in Textual FilesThis rule blocks potential exploitations of vulnerable applications by detecting and blocking textual files with binary data.



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.

Block Binary Exploits in Textual Files

General Tab

Action Block

End-user Message Blocked Binary Exploit in Textual File

Apply to Tab


Exceptions Tab




Block Binary Objects With Invalid Digital CertificateThis rule blocks binary objects which, for various reasons, have an incorrect digital certificate attached.



Conditions

For this rule, SWG selects only the condition Digital Signatures, which specifies if the content has an invalid digital signature.

Block Binary Objects With Invalid Digital Certificate

General Tab

Action Block

End-user Message Digital Signature Violation

Apply to Tab


Exceptions Tab



RULES

Testing the Rule

To test the Block Binary Objects with Invalid Digital Certificate rule:


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




http://www.finjan.com/EVG/no_digital_signature.exe http://www.m86security.com/EVG/invalid%20signature.exe


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 CertificateThis 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.


RULES



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.

Block Binary Objects Without a Digital Certificate

General Tab

Action Block

End-user Message Digital Signature Violation

Apply to Tab


Exceptions Tab




Testing the Rule

To test the Block Binary Objects without a Digital Certificate rule:


http://www.m86security.com/EVG/no_digital_signature.exe



Figure 2-22: Page Blocked - Missing Digital Signature




http://www.finjan.com/EVG/no_digital_signature.exe http://www.finjan.com/EVG/no_digital_signature.exe

RULES


Figure 2-23: Response: Missing Digital Signature



Block Binary VAD VulnerabilitiesThis rule blocks binary application level vulnerabilities based on Trustwave SpiderLabs detection rules.



Conditions

The condition is actually a Suspected Malware list which is updated by Trustwave SpiderLabs, and cannot be accessed by the administrator.

Block Binary VAD Vulnerabilities

General Tab

Action Block

End-user Message Binary VAD Violation

Apply to Tab


Exceptions Tab



RULES

Block Blacklisted File ExtensionsThis rule blocks file types which may be a security hazard and are not normally used by legitimate sites/applications.



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).



Block Blacklisted File Extensions

General Tab

Action Block

End-user Message File Extension

Apply to Tab


Exceptions Tab




Testing the Rule

To test the Block Blacklisted File Extensions rule:


http://www.m86security.com/EVG/dir.cmd



:

Figure 2-24: Page Blocked - Forbidden File Extensions



http://www.m86security.com/EVG/dir.cmd

RULES


Figure 2-25: Request - Forbidden File Extensions



Block Customer-Defined File ExtensionsThis rule blocks files with a specific extension, defined and selected by the administrator.

The rule is enabled only in the M86 Basic Security Policy.



Conditions



Block Customer-Defined File Extensions

General Tab

Action Block

End-user Message File Extension

Apply to Tab


Exceptions Tab

