security policies in-depth.book - trustwave

Security Policies In-Depth.bookSecure Web Gateway Release 10.1
M86 SECURITY POLICIES IN DEPTH
© 2011 M86 Security All rights reserved. 828 W. Taft Ave., Orange, CA 92865, USA
Version 10.1.0.2, published May 2011 for SWG software release 10.1.
This document may not, in whole or in part, be copied, photo- copied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior written con- sent 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 ................................................... 7 Where To Go From Here. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
CHAPTER 1: SECURITY POLICY CONCEPTS.................... 8 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Types of Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Master Policy and Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 X-Ray Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Emergency Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HTTPS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Full Bypass Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Cloud User Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Security Policy Components . . . . . . . . . . . . . . . . . . . . . . . . . 15 Rules and Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Rule Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Rule Processing Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Output Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
CHAPTER 2: IMPLEMENTING SECURITY POLICY............ 23 Establishing Site Security Policy — Key Points . . . . . . . . . . 23
Defining Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Creating a Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Creating / Editing a Rule in a User-Defined Policy . . . . . . . . . . . . . 26 Adding / Editing Conditions in a Rule. . . . . . . . . . . . . . . . . . . . . . . . 28
Setting Which Policies are Implemented . . . . . . . . . . . . . . . . 28 Setting Policy Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Setting a Master Policy for an Administrator . . . . . . . . . . . . . . . . . . 30 Assigning Policies to User Groups and Users . . . . . . . . . . . . . . . . . 31
Fields and Options in the Security Definition Screens . . . . . 33 Options Available in the Policy Tree . . . . . . . . . . . . . . . . . . . . . . . . 34 Fields of the Security Policy Detail Screen . . . . . . . . . . . . . . . . . . . 35 Fields of the Security Rule Details Screen. . . . . . . . . . . . . . . . . . . . 36 Fields of the Condition Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
List of Available Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Rules Available for Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 39
TABLE OF CONTENTS
Rule Available for HTTPS Policies. . . . . . . . . . . . . . . . . . . . . . . . . . 41 Rules Available for Emergency HTTPS Policy . . . . . . . . . . . . . . . . 41
List of Available Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Conditions Available for Security Policy Rules . . . . . . . . . . . . . . . . 42 Conditions Available for HTTPS Rules . . . . . . . . . . . . . . . . . . . . . . 46
CHAPTER 3: DETAILED RULE DESCRIPTIONS............... 47 Data Leakage Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Allow Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Allow and Scan Customer-Defined File Extensions . . . . . . . 53
Block Access to Blacklisted Sites. . . . . . . . . . . . . . . . . . . . . . 54 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Block Access to Spyware Sites . . . . . . . . . . . . . . . . . . . . . . . . 58 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Block Access to Adware Sites. . . . . . . . . . . . . . . . . . . . . . . . . 61 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Allow Trusted Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Customer-Defined URL Filtering . . . . . . . . . . . . . . . . . . . . . . 64
Block Access to High-Risk Site Categories . . . . . . . . . . . . . 65 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Allow Whitelisted ActiveX, Java Applets and Executables. . 67
Allow Known Legitimate Content . . . . . . . . . . . . . . . . . . . . . . 68
Block ActiveX, Java Applets and Executables by ACL . . . . . 69 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Block Malicious Content (Malware Entrapment Engine). . . . 71
Block Known Spyware (ACL). . . . . . . . . . . . . . . . . . . . . . . . . . 73
Block Potentially Malicious Archives . . . . . . . . . . . . . . . . . . . 73 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
TABLE OF CONTENTS
Block Known Viruses (McAfee / Sophos / Kaspersky) . . . . . 76 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Block Customer-Defined File Extensions. . . . . . . . . . . . . . . . 78
Block Known Malicious Content . . . . . . . . . . . . . . . . . . . . . . . 79
Block IM Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Block Microsoft Office Documents containing Macros and/or Embedded Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Allow Access to White Listed Sites. . . . . . . . . . . . . . . . . . . . . 85 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Block Outgoing Microsoft Office Documents . . . . . . . . . . . . 88 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Block Files with Suspicious Multiple Extensions . . . . . . . . . 91 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Block Blacklisted File Extensions . . . . . . . . . . . . . . . . . . . . . . 93 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Block Files with COM Extension . . . . . . . . . . . . . . . . . . . . . . . 96
Block Unscannable Archives. . . . . . . . . . . . . . . . . . . . . . . . . . 97 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Block Potentially Malicious Packed Executables . . . . . . . . . 99 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Block Binary Objects Without a Digital Certificate . . . . . . . 101 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Block Binary Objects With Invalid Digital Certificate . . . . . 103 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Block Customer-Defined True Content Type . . . . . . . . . . . . 105
TABLE OF CONTENTS
Block Suspicious File Types . . . . . . . . . . . . . . . . . . . . . . . . . 106
Block Malicious ActiveX, Java Applets and Executables . . 107 Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Block Illegitimate Archives (Including Password- Protected Archives) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Rule Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Block Unscannable (McAfee / Sophos / Kaspersky) . . . . . . 115
Social Media Post Control Allowed Requests . . . . . . . . . . . 115
Block Social Media Post Control . . . . . . . . . . . . . . . . . . . . . . 116
Block Everything Except White Lists . . . . . . . . . . . . . . . . . . 117
Block Certificate Validation Errors . . . . . . . . . . . . . . . . . . . . 117 Additional HTTPS Policy Rule Details . . . . . . . . . . . . . . . . . . . . . . 118
Bypass Whitelisted URLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Temporarily Block Cloud Users . . . . . . . . . . . . . . . . . . . . . . 120
Block Revoked Cloud Users . . . . . . . . . . . . . . . . . . . . . . . . . 121
Allow All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
APPENDIX A .............................................................. 122
ABOUT THIS MANUAL
About This Manual Some of the information contained in this manual also appears in the Management Console Reference Guide.
Nevertheless, this manual is intended to supplement, not replace, the security policy information found in the Management Console Reference Guide, and it assumes that you are familiar with the information in that guide.
As mentioned above, this guide is generally concerned with the Advanced setup
Where To Go From Here The chapters in this guide are sequenced in the order you should use them.
Before customizing security policy, you should be familiar with the information in Chapter 1: Security Policy Concepts. When you are ready to customize security policy, you can find the needed instructions and related information in Chapter 2: Implementing Security Policy. For detailed descriptions of the rules listed in Chapter 2, see Chapter 3: Detailed Rule Descriptions. For details of the enforcement process of the Master Policy and Security Policy, including diagrams and sample illustrations, see Appendix A.
INTRODUCTION
Chapter 1: Security Policy Concepts This chapter contains the following main sections:
Introduction
Types of Policies
Master Policy and Security Policy X-Ray Policy Emergency Policies HTTPS Policies Cloud User Policies Full Bypass Policy
Security Policy Components
Rules and Conditions Rule Logic Rule Processing Flow Output Messages
Introduction The Secure Web Gateway application comes with a number of pre- supplied security policies. These policies are intended for use as is. You cannot edit them, nor should there be a need to do so.
However, many of these policies can be duplicated, and if need be, you can duplicate such a policy and then edit the duplicate. (Alternatively, you can create new policies from scratch).
In general, security policies are comprised of rules, and conditions associated with the rules. Rules definitions specify Actions to be performed (and in many cases, end-user messages to issue) if the rule is triggered. A rule if triggered if its associated conditions are satisfied.
Security policies must be associated with users and/or user groups to be active.
You access, duplicate, and define security policies and their rules and conditions in the Management Console. The Management
CHAPTER 1: SECURITY POLICY CONCEPTS
Console also provides a screen for identifying which polices to use in which situations.
Types of Policies The Secure Web Gateway application comes with the following pre-supplied security policies.
Master Policy and Security Policy The main SWG security policies are:
M86 Master Policy Security Policies
M86 Basic Policy
Policy For information, see:
• M86 Master Policy • M86 Basic Security Policy • M86 Medium Security Policy • M86 Strict Security Policy
Master Policy and Security Policy.
M86 X-Ray Policy (and X-Ray Mode)
X-Ray Policy
Emergency Policies
• M86 Blocked Cloud Users Policy • M86 Revoked Cloud Users Policy
Cloud User Policies
• Caching Policy • Logging Policies • Identification Policies • Device Logging Policies
Not described in this document. For details, see the Management Console Reference Guide.
TYPES OF POLICIES
M86 Master Policy
Master policies are created by Super Administrators and are assigned to General Administrators. (Master Policies are defined in addition to the other defined Security (Basic, Medium, Strict) policies.
Master policies are intended to enable the defining of a compulsory global policy for all groups within one organization.
Only the Super Administrator has the right to change this policy. Administrators for different user groups can only change the policy or rules that belong to their specific group.
Figure 1-1 illustrates the relationships between the Super Administrators, Administrators, and the Security policies.
Figure 1-1: Master Policy Dependencies
NOTE: A Master Policy can be comprised of any of the security policies from within the system. The Super Administrator can assign different Master Policies to different administrators or assign the same one to all administrators.
Security Policies
This section describes the following security policies:
M86 Basic Security Policy M86 Security Medium Policy M86 Security Strict Policy
Each of these policies achieves a different level of security, as described below.
Furthermore, each of the policies can be duplicated. Therefore, the conceptual information provided here is important for when you want to define new policies based on these existing policies.
Security Policies — Levels
M86 Security has designed three Security Policies intended to meet your individual organization's unique security needs. These polices represent a progression in the level of security provided.
• M86 Basic Security Policy: In this policy, only the basic engines for client web security are activated. This policy provides a baseline policy that can be used when connecting two relatively secure environments to each other.
• M86 Medium Security Policy: This policy builds on top of the basic security policy and adds more proactive, behavioral, real- time elements in order to provide better security when connecting to the internet. 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: This policy is used for higher sensitivity scenarios, where security cannot be compromised. It utilizes all the rules and standards for secure web behavior, while keeping HTML Repair enabled in order to still provide a usable browsing experience without blocking complete pages that may have violated some security standards.
TYPES OF POLICIES
Security Policies — Setup
Each of the above security policies come in two setup modes:
Simplified Setup Advanced Setup
Simplified Policy Setup Simplified setup utilizes four “building blocks” which are essentially made up of lists:
The four building blocks are:
URLs File Extensions True Content Type URL Categorization
The main list types are
White Lists — these list objects that you will allow through but the containers will be scanned for viruses, etc. Black Lists — these list objects that will be blocked to the end- user. Bypass Lists — these list object that will be exempt from scanning. Therefore, they should be highly trusted.
So, for example, you can have a URL White List, a URL Bypass List, and a URL Black List.
And you can have different combinations of lists for different user groups and users.
When duplicating a security policy, the advantage of the simplified setup is that you can configure the level of protection your organization needs with simple edits and a minimum of effort.
For more information, see the Management Console Reference Guide.
Advanced Setup
In Advanced Setup, the main components of Security Policies are:
Rules — define the actions to be performed. Conditions — determine if the rule gets is triggered.
These components are described in greater detail in Security Policy Components. Advanced setup policies are Intended for more experienced system administrators. By duplicating and editing the Advanced setup policies, you can fine-tune their rules and conditions. This guide generally focuses on Advanced setup.
X-Ray Policy The purpose of an X-Ray Policy is to evaluate the effects of a “would-be” security policy on the system before implementing it.
In an X-Ray policy, if a transaction meets the required conditions, the rule is logged but not activated, and the transaction continues with evaluation of 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).
X-Ray Mode
Even in non-X-Ray policies, you can place individual rules 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 action is not performed, and the next rule evaluated and so on.
If both X-Ray and non-X-Ray mode rules are activated in a non-X- Ray policy, only the last triggered rule will be reported.
NOTE: Rules within the X-Ray Policy are not marked as X-Ray mode.
TYPES OF POLICIES
Emergency Policies The M86 Emergency Policy and M86 HTTPS Emergency Policy were designed for cases where, for example, the Internet has encountered a massive infectious attack and/or for cases where the organization has been infected by malicious code.
The Emergency Policies prevent/minimize damage by blocking most of the network traffic while still enabling access to some predefined important web sites (e.g. Windows Update).
HTTPS Policies M86 HTTPS Policies contain rules which deal with access to HTTPS sites. They define which HTTPS sites are fully allowed, which are inspected, which request user approval to continue and which are blocked. The blocking mechanism is based on White Lists, URL categorization and checking to see if certificates have errors or comply with validation criteria.
The HTTPS Policies are only displayed for customers who have the required license.
Full Bypass Policy This policy contains one rule (Allow All) which bypasses scanning, ensuring that no items will be scanned by the M86 engines. This rule can be set by administrators and is intended for end-users who should be permitted to surf through the M86 SWG Appliance without any scanning.
Cloud User Policies Blocked Cloud Users Policy defines policy for Users who are temporarily blocked from using the cloud.
Revoked Cloud Users Policy defines policy for Users who are revoked from using the cloud.
Security Policy Components
Rules and Conditions The main components of Security Policies are:
Rules — define the actions to be performed. Conditions — determine if the rule gets is triggered.
Figure 1-2 illustrates the tree pane that is displayed in the for Policies in the Management Console.
Figure 1-2: Security Policy Tree Pane
NOTE: For policies that have both Simplified and Advanced setups (M86 Basic, Medium and Strict Security Policies), this section discusses Advanced Setup components.
SECURITY POLICY COMPONENTS
Note that two areas of the tree have been encircled and contain three numeric labels. These show:
# 1 — Security Policies # 2 — Rules (in the policy) # 3— Condition (which determines if the rule is triggered)
As stated above, rules specify the actions to be performed. Note the following about Actions defined in a rule:
The most common actions are Allow, Block, and Coach. Depending on the defined Action, the rule also contains one of the following:
Advanced Actions to be performed (generally used for Allow actions) End-user Message to be issued (generally used for Block and Coach actions)
Examples The M86 Basic Security Policy comes with several rules including the following (values appearing will be 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 Logic Note the following points about rules and rule placement.
One rule can include multiple conditions, all of which must be matched for the rule to be enforced. For example, a rule that includes conditions regarding file extensions, time frames and parent archive types, will be enforced only if all of the conditions are met. A Condition will be enforced even if only one of the selected options within a Condition is met. 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 priority rule at the bottom (You can moved rules up and down in the list to change their priority level.) Any action taken will be according to the rule of highest priority that matches a given transaction. After a rule is enforced, rules of lower priority 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 to 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, you should 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 will not be checked against content. In other words, each Allow rule creates a trust level - and content after that is not scanned by any blocking rules that come after it.
• If a rule is not specific to any of the listed values for the condition, instead of selecting all possible values, do not use the condition – leave it blank.
• All rules can be used in X-Ray mode, whereby a rule activity is logged but no action is taken. The rule activity is shown in the logs, and as such, a fine tuning or review of the rule (and its related policy) in the production environment will be possible.
Rule Processing Flow The security rule processing flow is divided into two phases:
Request phase Response phase
Request phase:
If a Block action was triggered by a rule in the Request phase, the request will not be sent to the destination server, and an appropriate message will be displayed to the user. If a Coach action was triggered by a rule in the Request phase, an appropriate message will be presented to the user. If the user then approves this message, the request will be sent to the destination server. The Coach action only applies to the Request phase.
Response phase:
The content received in the response phase (if any) will be evaluated regardless of the action taken in the request phase. If an Allow action was triggered, the content is passed to the user. (Also - if no action was taken, the default action is an implicit Allow) If a Block action was triggered, the content is not passed to the user. An appropriate error message is displayed.
When a Master Policy is being used (i.e. users will go through both a Master and a Security Policy) 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, response content is forwarded to Security Policy.
6. All response rules in the Security Policy are processed and content is delivered to the Client.
The diagram below illustrates the six primary steps in the rules transaction process detailed above:
NOTE: These rules are processed as long as a rule is not yet triggered.
Figure 1-3: Rules Transaction Process
For more detailed diagrams of the Request and Response phases of the Master Policy and Security Policies interaction, please refer to Appendix A.
Output Messages As the flow indicates, many rules, including those that perform Block actions, 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 informing them that a site was blocked due to the relevant reason. This message also contains a transaction ID. Using the same transaction ID, the administrator can trace this 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. This can be used as a warning 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 Coaching page
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.
ESTABLISHING SITE SECURITY POLICY — KEY POINTS
Chapter 2: Implementing Security Policy This chapter contains the following main sections:
Establishing Site Security Policy — Key Points
Defining Security Policies
Fields and Options in the Security Definition Screens
List of Available Conditions
List of Available Rules
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.
Master Policy Security Policy HTTPS Policy Logging Policy Emergency Policy HTTPS Emergency Policy
ESTABLISHING SITE SECURITY POLICY — KEY POINTS
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.)
Note the following:
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. 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:
Instructions for setting the defaults are provided in Setting Policy Defaults. Instructions for assigning a policy to a user group are provided in Assigning Policies to User Groups and Users.
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
CHAPTER 2: IMPLEMENTING SECURITY POLICY
Defining Security Policies This section contains the following procedures:
Creating a Security Policy
Adding / Editing Conditions in a Rule
Creating a Security Policy
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 branch in the tree and choosing Add 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.
DEFINING SECURITY POLICIES
The following table identifies how to access the each type of policy that can be duplicated, in the Management Console.
2. In the Duplicate Policy window, do the following:
a. Enter 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:
To edit an existing rule, click the rule in the tree, and then in the main pane, click Edit.
Policy Access
• M86 Basic Security Policy • M86 Medium Security Policy • M86 Strict Security Policy
Policies Security {Simplified |Advanced}. Note: For defining rules, choose Advanced.
• Full Bypass Policy • M86 Emergency Policy • M86 X-Ray Policy • M86 Blocked Cloud Users Policy • M86 Revoked Cloud Users Policy
Policies Security Advanced.
Policies HTTPS
If you are defining the first rule in the policy, right-click the policy and choose Add Rule. 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, do the following.
a. Enter (or edit) a name for the rule. b. If the rule should be an X-ray rule, select the X-Ray check
box. An X-ray rule is a rule that is evaluated and logged, but not activated.
c. Provide a description of the rule (optional). d. Select the Action for the rule (Allow, Block, or Coach.) For
more information, see Rules and Conditions and Rule Processing Flow.
e. Depending on whether or not the rule should be enabled, ensure that the Enabled check box is appropriately checked or unchecked (default: Enabled).
f. if the rule should be enabled, ensure that the Enabled g. 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.
h. Click Save.
SETTING WHICH POLICIES ARE IMPLEMENTED
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
For each condition to be added to the rule in a user-defined policy, do the following:
1. Do either of the following:
To edit an existing condition, click the condition under the rule in the tree, and then in the main pane, click Edit. 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.
e. Click Save. 3. (To delete a condition, right-click the condition and choose
Delete Condition).
Setting Which Policies are Implemented After setting default, you can override these defaults for specific user groups and users, and in the case of Master Policy, you can assign policies other than the default Master Policy to different administrators.
This section contains the following topics:
Setting Policy Defaults
Setting a Master Policy for an Administrator
Assigning Policies to User Groups and Users
Setting Policy Defaults You set policy defaults in the Default Policy Settings screen of the Management Console.
1. Select Policies Default Policies Settings.
The Default Policies Settings screen (Figure 2-1) lists a number of types of policies, and by each type it provides a drop-down list of all defined policies.
Figure 2-1: Default Policy Settings Screen
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: 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. 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.
5. When done, click Save.
Setting a Master Policy for an Administrator
1. In the Management Console, select Administration Administrators, and then, in the tree pane under Super Administrators, select Admin.
NOTE: The policies you define here will be the values referred to in User Groups and LDAP Groups.
NOTE: Before setting a security policy as the Master Policy for an administrator, you must ensure that the security policy is defined. For instruction on creating a security policy, see Creating a Security Policy.
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.
To assign policies to a User Group
1. Select Users Users/User Groups.
2. In the User Group tree, select the User Group.
3. In the main detail screen (Figure 2-2), do the following:
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.
NOTE: This procedure assumes that the User Group is already created. For instructions on creating other User Groups, see the Management Console Reference Guide.
Figure 2-2: 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.
To assign policies to individual users
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.
Fields and Options in the Security Definition Screens
Options Available in the Policy Tree
Fields of the Security Policy Detail Screen
Fields of the Security Rule Details Screen
Fields of the Condition Details
NOTE: This procedure assumes that the user, including IP addresses, is already defined. For instructions on defining users, see the Management Console Reference Guide.
FIELDS AND OPTIONS IN THE SECURITY DEFINITION SCREENS
Options Available in the Policy Tree The following table describes the options available when you right- click a tree entry at a particular level:.
Level Action Description
Root Level
Add Policy Available from top level folder only. Allows you to create a new Policy.
Policy Level
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.
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.
Fields of the Security Policy Detail Screen The Policies Details screen displays the following information:
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 Available from specific Condition. Allows to remove a Condition from a Rule.
Level Action 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.
Fields of the Security Rule Details Screen The Rules Details screen contains the following information:
Field Description
Rule Name Defines the name of the Security rule.
X-Ray If the X-Ray checkbox 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.
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, the following Conditions only 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.
Field Description
Fields of the Condition Details The Condition Details displays the following information:
For the list of available conditions, see List of Available Conditions.
Field Description
Condition Name Displays name of 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.
List of Available Rules This section contains the following topics:
Rules Available for Security Policies
Rule Available for HTTPS Policies
Rules Available for Emergency HTTPS Policy
Rules Available for Security Policies The following table lists predefined rules, and indicates (with an X in the accompanying columns) in which policies the rules appear. The following column labels indicate the following policies: B = Basic, M = Medium, S = Strict, Xr = X-Ray, F = Full Bypass, E = Emergency, BC = Blocked Cloud Users, RC = Revoked Cloud Users.
The listed rules link to detailed descriptions in Chapter 3: Detailed Rule Descriptions.
Table 1: Predefined Rules
Rule B M S Xr F E BC RC Allow Access to White Listed Sites X X X X Allow All X Allow and Scan Customer-Defined File Extensions X X X Allow and Scan Customer-Defined True Content Type X X X Allow Known Legitimate Content X X X Allow Streaming X X X X Allow Trusted Sites X X X X Allow Whitelisted ActiveX, Java Applets and Executables
X X X X
Block Access to Adware Sites X X X X Block Access to Blacklisted Sites X X X X Block Access to Spyware Sites X X X X Block Access to High-Risk Site Categories (including M86, Websense and IBM)
X X X X
Block ActiveX, Java Applets and Executables by ACL X X X Block Binary Exploits in Textual Files X X X
LIST OF AVAILABLE RULES
Block Binary Objects With Invalid Digital Certificate X X X X Block Binary Objects Without a Digital Certificate X X X Block Binary VAD Vulnerabilities X X X X X Block Blacklisted File Extensions X X X Block Customer-Defined True Content Type X X X Block Everything Except White Lists X Block Files with COM Extension X X X Block Files with Suspicious Multiple Extensions X X X Block Illegitimate Archives (Including Password- Protected Archives)
X X X X
Block IM Tunneling X X X Block Known Malicious Content X X X X Block Known Spyware (ACL) X X X X Block Known Viruses (McAfee / Sophos / Kaspersky) X X X X X Block Malicious ActiveX, Java Applets and Executables
X X X
X X X X
X X X
Block Outgoing Microsoft Office Documents X X X Block Potentially Malicious Archives X X X X Block Potentially Malicious Packed Executables X X X Block Revoked Cloud Users X Block Social Media Post Control X X X X Block Spoofed Content X X X Block Suspicious File Types X X X Block Unscannable (McAfee / Sophos / Kaspersky) X X X Block Unscannable ActiveX, Java Applets and Executables
X X X
Block Unscannable Archives X X X Customer-Defined URL Filtering (including M86, Websense and IBM)
X X X
Data Leakage Prevention X X X X X Detect Known Trojan Network Activity X X X X Social Media Post Control Allowed Requests X X X X Temporarily Block Cloud Users X
Rule B M S Xr F E BC RC
Note the following important points:
Rule Available for HTTPS Policies HTTPS policy contains a single rule:
Block Certificate Validation Errors
Rules Available for Emergency HTTPS Policy Emergency HTTPS policy contains the following rules:
Bypass Whitelisted URLs
Block All HTTPS URLS Except White Lists
IMPORTANT: The difference between the 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.
IMPORTANT: Malware Team, M86 Security Labs have provided Rule Demonstrations where possible for the above rules. Before beginning the Rule Demonstrations:
1. Ensure that your browser is configured with the SWG NG Appli- ance IP as an HTTP proxy. 2. Disable HTML Repair: Navigate to Administration System Settings Scanning Scanning Engines Malware Entrap- ment and deselect the Automatic Removal of Suspicious code check box.
LIST OF AVAILABLE CONDITIONS
List of Available Conditions Each rule can include multiple conditions, all of which must be met in order for the rule to be triggered.
Conditions Available for Security Policy Rules
Conditions Available for HTTPS Rules
Conditions Available for Security Policy Rules The following Conditions are available for Security policy rules. This includes conditions for the policies that can be set as Security policies. This is includes the following types of policies: Basic, Medium, Strict, X-Ray, Full Bypass, Emergency, Blocked Cloud Users, Revoked Cloud Users.
• Active Content List – The Active Content List condition 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 Executables will be automatically added to the Auto- generated list, which is the only list that cannot be used in a rule. Items from the Auto-generated list can be moved to other lists to create exception rules. The condition will apply to objects that match entries in these lists. SWG includes the following default lists 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. Spyware objects – Contains known spyware profiles in a non-editable list predefined by M86. This is not viewable. Unscannable – This list is automatically populated by items that the appliance failed to scan.
• Anti-Virus (McAfee/Sophos/Kaspersky) – Anti-Virus third party scanning engine which scans for known viruses.
• Approved Content – VuSafe is an M86 Security web portal that is used for streaming media content categorization and permissions management within the education market. The Approved Content condition allows the SWG to integrate VUSafe (http://www.m86vusafe.com) and perform the necessary actions required to filter out content that is deemed unsuitable for a particular audience. Administrators add a URL Encryption Key to the VuSafe portal. When the end-user (primarily students) tries to view an authorized video, the URL request will have an additional hash key of the UEK. This same UEK is entered into the SWG where it is then verified.
• Archive Errors – 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.
• Behavior Profile (Binary) – Behavior Profiles which define behaviors that could be considered malicious or suspicious when exhibited by ActiveX Controls, Java Applets, executable files and any other relevant files. These are configured in the Security Engines tab of the Management Console. This condition can also match objects to the following non-editable profiles:
Suspected Malware – This option only appears if the Anti- Spyware engine is purchased. It contains behavior profile patterns that are specific to Spyware objects. Unscannable Active Content – This profile will be assigned whenever the appliance could not scan an object.
• Binary VAD - The Binary Vulnerability Anti.dote (VAD) condition scans binary files, looking for patterns of exploits.
• Content Size – Specifies the content size range. For example, using this condition, one might apply a rule only to content size over 10MB. Traffic management cannot be carried out based on
content size as the Appliance always downloads the full content first.
• Digital Signatures – Specifies if the content has a digital signature which is invalid for a number of reasons, or is missing.
• Direction – Specifies the direction of the transaction (Incoming/ Outgoing) for which the rule may be triggered. For example, in HTTP, Outgoing means the request phase, and Incoming means the response phase of the protocol. If no direction is specifically applied – then the rule is checked on both the request and response phases.
• File Extensions – Refers to the ‘declared’ content type, i.e. the file extension. It also detects potentially malicious extensions such as multiple extensions (e.g. example txt.exe).
• Header Fields – This rule condition applies to requests and responses which contain a selected HTTP header.
• HTTP Method – This condition is used in conjunction with the Social Media Posts rule. The HTTP Method is a content processor that provides 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.
• IM – This condition applies to transactions using Instant Messaging protocols with HTTP tunnelling.
• Malware Entrapment Profile – M86 Security’s Malware Entrapment scanning engine monitors and identifies malicious content. The engine, created and designed by security experts from the Malware team at M86 Security Labs, 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. 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.
• Parent Archive Type – This condition allows the administrator to assign specific rules for items within archives such as ZIP, CAB, etc. This condition will not match files outside of archives or the archive files themselves.
• Protocol – This condition covers the different protocols used for browsing or downloading.
• Spoofed Content – This condition applies to malicious files disguised as harmless files.
• 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 the Malware Team, M86 Security Labs.
• Time Frame – This condition contains the time frame(s) during which this rule should be applied (e.g. Weekend, Lunch)
• 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 type of the content.
• URL Filtering (Websense/IBM) – Specifies which URL category (or categories) the rule should apply to. These categories are maintained by the respective 3rd party.
• URL Lists – This condition refers to lists of URLs that have been defined in the List Management tab in the Management Console. This condition can also match the following non- editable list: Spyware URL List. This option contains a list of known Spyware sites.
Conditions Available for HTTPS Rules The following Conditions are available for HTTPS policy rules:
• Certificate Validation: This condition includes many different types of certificate validation errors. These are provided with a Default HTTPS profile under the Security Engines tab.
• URL Filtering (Websense/IBM): This condition can be used to apply rules based on the type or category of the requested site.
• URL Lists: This condition refers to lists of URLs – both predefined and configurable.
DATA LEAKAGE PREVENTION
Chapter 3: Detailed Rule Descriptions This chapter provides detailed descriptions of the rules listed in Chapter 2 under List of Available Rules.
Data Leakage Prevention The Data Leakage Prevention (X-Ray default) rule was designed to scan web content in order to prevent vital information from leaving the company network.
The following table describes the Rule Editor definitions.
Note the following:
• The Data Leakage Prevention rule refers to the Data Leakage Prevention profile which can be found via Policies Condition Settings Data Leakage Prevention.
Block Data Leakage Prevention
Conditions
Direction This condition allows the administrator to trigger a rule specifically on the request (Outgoing) or response (Incoming) phase of the transaction.
Data Leakage Prevention This condition allows the administrator to monitor and prevent data leakage.
Test the Behavior Profile rule with the following file examples:
Example 1: Create a new Data Leakage Prevention Rule
1. In the Management Console navigate to Policies Security Advanced to create a new Security Policy.
2. In the right window pane, name the policy DLP Test Policy. Click Save.
3. Create a new rule by clicking on the left panel. Name it “Data leakage prevention” and select “Data Leakage Prevention” as the end user message:
Figure 3-1: Create New Rule
Create a new DLP condition
The following condition provides an example of how to block documents with credit card numbers as part of the content.
CHAPTER 3: DETAILED RULE DESCRIPTIONS
In the Management Console, navigate to Policies Condition Settings Data Leakage Prevention.
1. To create a new Filter Condition, right-click the Data Leakage Prevention node and select Add Filter Condition. (The left toolbar offers the same action by clicking )
Figure 3-2: Create New Filter
2. In the New Component window, enter an appropriate Condition Name in the Data Leakage Prevention Name field (for example, Block Documents with Diners CC).
To Edit in Condition Editor mode:
a Create new filter condition, and set the name to “Block Documents with Diners CC”.
b Build the condition using the available values, placeholders, and operators. For this example, build the following condition (as shown in the following screen shot): (Diners Club OR Carte Blanche) AND (300$$$$$$$$$$$ OR 305$$$$$$$$$$$ OR 36$$$$$$$$$$$$).
c Click Save.
Figure 3-3: Condition Builder Placeholders
The previous images provide an example of a condition created to ensure that Diner’s Club credit card numbers do not leave the company. For example, an entry such as Diners Club 3005 458696 5454 is recognized and blocked, since credit card information representative of Diners Club (such as a number beginning with 300 and a total of 14 digits) is recognized. However, an entry such as Diners Club 4005 458696 5454 will not be 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.
NOTE: Be sure to use the placeholders buttons for the right and left parentheses, the “OR” and “AND” logical operators, and the $ numeric wild card.
NOTE: This can also be performed using the Condition Builder.
Assigning Conditions to Policy Rules:
1. Navigate in the Management Console to Policies Security Advanced, and select the DLP Test Policy.
2. Expand the policy and select the Data Leakage Prevention rule.
3. Add a new condition to the rule by clicking in the left toolbar. Set the condition name to “Data leakage prevention” and enable the checkbox near the “Block Documents with Diners CC” entry.
4. Click Save.
5. To ensure that the new policy is in use, navigate to Policies Default Policy Settings and select “DLP Test Policy” as the default security policy.
Testing the new rule:
1. Copy and paste the following URL into your browser: http://www.m86security.com/EVG/diners.doc
2. To connect to the site, type in the username: getevg and password: HurNoc45, and click OK.
3. Copy and paste the following URL into your browser: http://www.m86security.com/EVG/data_leakage_test.asp
4. Click on Browse and select the file “diners.doc” downloaded previously.
5. Click Upload.
6. If everything was set correctly, you should receive a blocking message similar to the following:
Figure 3-4: Data Leakage Prevention Page Block Message
Allow Streaming The Allow Streaming rule was designed in order to allow media streaming (audio, video) to pass through the system.
The following table describes the definitions:
Allow and Scan Customer-Defined True Content Type
This rule allows files of a certain true type as defined by system administrators. These files are only subjected so scanning if they are within archive containers. This rule is only relevant if you have chosen categories through the Simplified Setup interface.
Allow Streaming
Allow and Scan Customer-Defined File Extensions
The Allow and Scan Customer-Defined File Extensions allows through files with specific extensions whilst scanning files that are containers for potential viruses. This File Extensions Condition Component is different for the three Security Policies: Basic, Medium and Strict.
Allow and Scan Customer-Defined True Content Type
Action Allow content and scan containers
Conditions
True Content Type
The categories that you choose in the Simplified Interface will be displayed here.
Allow and Scan Customer-Defined File Extensions
Action Allow content and scan containers
Conditions
File Extensions File Extensions White List (Basic/Medium/ Strict). This list can be edited both through the Simplified Setup and Policies Condition Settings.
BLOCK ACCESS TO BLACKLISTED SITES
Block Access to Blacklisted Sites The Block Access to Blacklisted Sites rule refers to blocking a list of predefined URLs.
The following table describes the Rule Editor definitions:
Note the following:
• The Customer Defined Black List is a user-defined list of restricted sites. It is accessible via Policies Condition Settings URL Lists Customer Defined Black List. You can add or delete entries to this list which will be blocked by SWG.
• The M86 Recommended Black List cannot be edited or viewed by the administrator.
• The Block Access to Blacklisted Sites rule will be enforced, when its conditions are met, at the request phase.
Rule Demonstration
To test the Block Access to Blacklisted Sites rule:
1. Open the Customer Defined Black List by navigating to Policies Condition Settings URL Lists Customer Defined
Black List.
Action Block
End-User Message
Blacklisted URL
Conditions
URL Lists Customer Defined Black List, M86 Recommended Black List, URL Black List (Strict/Medium/Basic)
2. Click Edit in the right pane. Next, click on to add a row.
3. Enter www.cnn.com/* (‘*’ is the wild card, meaning that all URLs contained within www.cnn.com will be blocked).
4. Click Save. The entry: www.cnn.com/* now appears in the Customer Defined Black List.
5. Next, click .
1. Copy and paste www.cnn.com into your browser:
The following message should appear:
Figure 3-5: Page Blocked Message – Blacklisted Sites
2. Return to the Management Console and select Logs & Reports View Web Logs menu in the Main Navigation bar.
NOTE: The transaction ID refers to the unique interaction between the end-user and the SWG system
Figure 3-6: Web Logs
3. In the same row as the blocked cnn.com transaction, click and select 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.
Figure 3-7: Request: Blacklisted Site
To remove this website from the Customer Defined Black List:
1. Navigate to the list via Policies Condition Settings URL Lists Customer Defined Black List.
2. Click Edit to open the screen for editing.
3. Click to the left of www.cnn.com, and select Delete in the right pane.
4. Click Save and then click .
BLOCK ACCESS TO SPYWARE SITES
Block Access to Spyware Sites The Block Access to Spyware Sites rule refers to blocking predefined Spyware Sites.
Note the following:
• The Block Access to Spyware Sites rule will be enforced, if its conditions were met, at the request phase.
• The Spyware URL List is generated by M86 and is not accessible by the administrator.
Rule Demonstration
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 should appear when trying to access any of the above pages.
Block Access to Spyware Sites
Action Block
End-User Message
Figure 3-8: Page Blocked Message – Spyware Sites
2. Return to the Management Console and select the Logs and Reports View Web Logs menu in the Main Navigation bar.
Figure 3-9: View Web Logs
3. 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.
BLOCK ACCESS TO SPYWARE SITES
Figure 3-10: Transaction Details - Spyware Site
Figure 3-11: Request: Spyware Sites
Block Access to Adware Sites The Block Access to Adware Sites rule refers to blocking predefined Adware Sites.
Note the following:
• The Block Access to Adware Sites rule will be enforced, if its conditions were met, at the request phase.
• The Adware URL List is generated by M86 and is not accessible by the administrator.
Rule Demonstration
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 should appear when trying to access this site.
Block Access to Adware Sites
Action Block
Conditions
Figure 3-12: Page Blocked Message – Adware Sites
Figure 3-13: Request: Adware Sites
Allow Trusted Sites The Allow Trusted Sites 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).
Allow Trusted Sites
Action Bypass Scanning
Conditions
URL Lists Trusted Sites, Allow Large Download Sites, URL Bypass List (Basic/Medium/Strict)
CUSTOMER-DEFINED URL FILTERING
Note the following:
• As this rule is run prior to other security rules (apart from blacklisted or spyware/adware sites), all the sites within the Trusted Sites and URL Bypass List will not be scanned for any security breach. Therefore, M86 recommends only using these for selected sites and using the regular Customer Defined White List for the majority of trusted sites.
Customer-Defined URL 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.
NOTE: 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.
Customer-Defined URL Filtering
Conditions
Customer-Defined URL Filtering (Websense/IBM)
The categories that you choose in the Simplified Setup URL Categorization block will be displayed here.
Block Access to High-Risk Site Categories
The Block Access to High-Risk Site Categories rule refers to blocking 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.
Note the following:
• The Block Access to High-Risk Sites Categories rule will be enforced, if its conditions were met, at the request phase.
• Websense and IBM Proventia Web Filter engines require a license.
Rule Demonstration
To test the Block Access to High-Risk Site Categories rule:
1. Copy and paste the following URL into your browser:
NOTE: 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.
Block Access to High-Risk Site Categories
Action Block
Conditions
URL Filtering (IBM) Anonymous Proxies, Computer Crime, Erotic/ Sex, Malware, Phishing URLs, Pornography, Spam URLs, Warez/Hacking/Illegal Software
BLOCK ACCESS TO HIGH-RISK SITE CATEGORIES
http://www.hackingexposed.com/. The following error message is displayed.
Figure 3-14: Page Blocked Message- Hacking
Figure 3-15: Request: High-Risk Site Categories - Hacking
Allow Whitelisted ActiveX, Java Applets and Executables
The Allow Whitelisted ActiveX, Java Applets and Executables rule will allow those items which were moved to the “Allowed” Active Content List.
Note the following:
• SWG creates signatures for active content (Java Applets, ActiveX and Executable files) that passes through it. These
Allow Whitelisted ActiveX, Java Applets and Executables
Action Allow
ALLOW KNOWN LEGITIMATE CONTENT
signatures are available in the Active Content List (navigate to Policies Condition Settings Active Content List Auto-generated).
• From the Auto-generated list you can move an entry to a destination group (i.e. Allowed list and Blocked list). For the Default M86 Security Policy, once you move an entry to the Allowed list, next time a client requests the Allowed entry, the content will be passed without scanning (based on signature only). This enables the administrator to specifically allow binary active content.
• The Allow Whitelisted ActiveX, Java Applets and Executables rule will be enforced, if its conditions were met, at the response phase.
Allow Known Legitimate Content The Allow Known Legitimate Content rule was designed to bypass scanning for a selection of files that have been approved as known legitimate content by M86.
Allow Known Legitimate Content
Conditions
Static Content This condition is used to identify known Malicious Objects based on their malicious behavior signatures.
Block ActiveX, Java Applets and Executables by ACL
The Block ActiveX, Java Applets and Executables by ACL rule will cause the SWG Appliance to block the items which were moved to the “Blocked” Active Content List.
Note the following:
• SWG creates signatures for active content (Java Applets, ActiveX and Executable files) that passes through the system. These signatures are available under the Active Content List, and can be seen via Policies Condition Settings Active Content List Auto-generated.
Block ActiveX, Java Applets and Executables by ACL
Action Block
Conditions
Active Content List Blocked
BLOCK ACTIVEX, JAVA APPLETS AND EXECUTABLES BY ACL
Figure 3-16: Auto-generated Screen
• From the Auto-generated screen, you can move an entry to a destination group (i.e. Allowed list and Blocked list). Once you have moved an entry to the Blocked list, the next time an end- user requests a blacklisted entry, the content will be blocked automatically (without scanning) – based on signature only.
• The Block ActiveX, Java Applets and Executables by ACL rule will be enforced, if its conditions were met, at the Response phase (unless it is uploaded).
Rule Demonstration
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. Click on one of the examples to the left, for example: Dither
Test.
3. Navigate to Policies Condition Settings Active Content List Auto-generated to open the Auto-generated screen showing active content.
Figure 3-17: Auto-generated Screen: Example
4. In the Find All field, enter the word Java and click Go.
5. Select all the found entries. In the To field, select the Blocked List.
6. Click Save and .
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.
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.
BLOCK MALICIOUS CONTENT (MALWARE ENTRAPMENT ENGINE)
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.
Block Malicious Content (Malware Entrapment Engine)
Action Block
Conditions
Block Known Spyware (ACL) The Block Known Spyware (ACL) refers to blocking a list of predefined malicious content. This list is generated by M86 and is not accessible by the administrator.
• Note that the Block Known Spyware (ACL) rule will be enforced, if its conditions were met, at the Response phase.
Block Potentially Malicious Archives The Block Potentially Malicious Archives rule was designed to block attacks that try to cause Denial of Service using archives.
Block Known Spyware (ACL)
Conditions
Active Content List Spyware Objects
Block Potentially Malicious Archives
BLOCK POTENTIALLY MALICIOUS ARCHIVES
http://www.m86security.com/EVG/ Potentially_Malicious_Archives_Demo.zip
2. To connect to the site, type in the username: getevg and password: HurNoc45, and click OK.
After the downloading box, the following error message is displayed:
Figure 3-18: Page Blocked: Potentially Malicious Archives
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.
Figure 3-19: Response: Block Potentially Malicious Archives
Block Binary VAD Vulnerabilities The Block Binary VAD Vulnerabilities rule blocks binary application level vulnerabilities based on Malware Team, M86 Security Labs detection rules.
Block Binary VAD Vulnerabilities
Conditions
BLOCK KNOWN VIRUSES (MCAFEE / SOPHOS / KASPERSKY)
Note the following:
• The Suspected Malware list is constantly updated by Malware Team, M86 Security Labs and cannot be accessed by the administrator.
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:
Rule Demonstration
http://www.m86security.com/EVG/eicar.com.txt 2. To connect to the site, type in the username: getevg and
password: HurNoc45, and click OK.
Block Known Viruses
The following error message is displayed:
Figure 3-20: Page Blocked: Virus
BLOCK CUSTOMER-DEFINED FILE EXTENSIONS
Figure 3-21: Response - Virus Detected
Block Customer-Defined File Extensions The Block Customer-Defined File Extensions rule only appears in the M86 Basic Security Policy and is only relevant if you selected file extensions through the Simplified Policies interface.
The following table describes the Rule definitions:
Block Customer-Defined File Extensions
Block Known Malicious Content The Block Known Malicious Content rule refers to blocking a list of predefined Malicious Objects by statically blocking malicious objects which were identified as such by Malware Team, M86 Security Labs.
Note the following:
• The Malicious Objects List cannot be manipulated or viewed by the administrator.
Block IM Tunneling The Block IM Tunneling rule blocks IM tunneling by default since these are known crimeware distribution vehicles.
Block Known Malicious Content
Block IM Tunneling
DETECT KNOWN TROJAN NETWORK ACTIVITY
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 checkbox.
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.
Detect Known Trojan Network Activity
Action Block
End-User Message Suspected Trojan traffic detected (appears in Logs on X-Ray action)
Condition
Rule Demonstration
To test the Block Microsoft Office Documents containing Macros and/or Embedded files rule:
http://www.m86security.com/EVG/macro.doc 2. To connect to the site, type in the username: getevg and
password: HurNoc45, and click OK.
The following message appears:
Action Block
Conditions
True Content Type Microsoft Office Document with Embedded Files, Microsoft Office Document with Macros
BLOCK BINARY EXPLOITS IN TEXTUAL FILES
Figure 3-23: Response: Microsoft Office document with