Creating Notification Policies: Coaching, Splash, and Compliance

Transcription

1 SGOS 5 Series Creating Notification Policies: Coaching, Splash, and Compliance What is a Notification Policy? Many organizations implement content filtering in order to control employee Web access; however, some blocked URLs need to be allowed for certain users. Additionally, organizations may want to inform employees of the Corporate Internet Usage policy before their first access to the Internet, and/or occasionally send announcements to employees. The Blue Coat ProxySG allows you to create notification policies for a user, group, time, and/or URL to handle all these needs. Notification policies consist of an HTML page that is displayed when triggered; these are described in three ways: Coaching pages advise users about corporate policies regarding the access of a particular Web site and then offer the option to proceed. The policy can ensure that all URLs accessed that way are intentionally requested. The policy can also act as a soft deny and provide a link to, or text of, the Corporate Internet Usage policy. Splash pages differ slightly in that they are used for announcements, such as maintenance schedules, or requirements (technical, usage, and so forth) of a Web site, rather than to advise users about a specific URL or URL category. Typically, a link to the originally requested URL is provided for the user, or the page can be set to automatically open the requested URL after a delay. Compliance pages inform the user of corporate Internet access requirements. They are often used to show users, upon first Internet access attempt per day, a Corporate Internet Usage page that requires an affirmative user-click to proceed. After the Corporate Internet Usage page has been viewed once, it may or may not splash future Internet access attempts. How it Works All of these notification policies are implemented by launching the Visual Policy Manager (VPM), configuring a Web Access layer, and then specifying a Destination (the notification trigger), and an Action; optionally, you can also specify a Source, (for a specific user or group) or a Time setting. All of the notification policies described in this document use the Notify User action object. You can change the HTML message for that object; example HTML messages that you can use are included in this document. To launch the VPM, go to Configuration > Policy > Visual Policy Manager and click Launch. To add a Web Access Layer, click Policy in the VPM and select Add Web Access Layer. The HTTP proxy service must be set to intercept traffic. To do this, go to Services > Proxy Services, select the HTTP service, set it to Intercept, and click Apply. For the policies to trigger on HTTPS (SSL) traffic as well, also set the HTTPS proxy service to Intercept. In order to record the user reaction to the notification, access logging must be enabled. To do this, go to the Configuration > General > Access Logging page, select Enable Access Logging, and click Apply.

2 About the Default Proxy Policy On the Management Console Configuration > Policy > Policy Options page you can set the default policy option to Deny or Allow. The two options provide two different approaches; however, as the Notify User action object does not modify the Allow or Deny state, the examples provided will function as expected within existing policy allow/deny settings. For more details on developing effective policies, see the Policy Best Practices tech brief. About the Variables The HTML code examples for the Notify User action in the policies described in this document use a few common variables, defined below. For a full list of variables that may be used in policy messages, see the CPL Guide, Appendix D. Variable $(exception.details) $(exception.contact) $(client.address) $(user) $(url.host) $(categories) Creates A link to the requested URL The name of the originator of the policy The IP Address of the requesting machine The name of the requestor The requested URL The category of the requested URL This document describes the following: Creating Notification Policies How to use a Web access layer policy with the Notify User action to create custom Notification policies and pages. Example Custom Notification Pages Provides the HTML code and the VPM procedure for creating notification policies. Creating Notification Policies This section describes how to create a notification policy to display a coaching, splash, or compliance page for a specific URL, a custom URL category, a URL filtering list category, or all Internet access. How to use the Notify User action object to either allow access to the requested (or an alternate) URL, to invisibly auto-request the URL (to prevent the policy being re-triggered) without requiring any user-interaction, or to auto-redirect to the requested (or an alternate) URL, is described. How to specify the policy for a user, a group, a time of day, or first-time (or any) Internet use is described. There are three parts to defining a notification policy with a Web Access Layer: 1 Defining the notification trigger 2 Optionally, specifying a user, group, and/or time period for the policy 3 Defining the Notify User action setting

3 Defining Notification Triggers The most common conditions used for triggering notification rules are URL based: A custom URL category. When a user attempts to access one of those URLs, they receive the associated coaching page. The page informs the user of the corporate policy for accessing the Web site in question and may include a link allowing access; if the user clicks on the link and proceeds to the Web site, the access is logged. This method is useful for specific instances of coaching, such as allowing or denying access to a list of specific sites. How to define a coaching URL category is described. An installed URL filtering list category (Blue Coat WebFilter, Websense, SmartFilter, etc.). When used this way, a user attempting to access any Web site that falls in the trigger category gets the associated coaching page. Again, the user may or may not be given a link to the trigger Web site. To install a URL filtering list, see the Blue Coat Tech Brief page for specific instructions. A URL condition matching all Internet accesses. This method is useful for bringing up a Corporate Internet Usage compliance page when an employee first attempts to access the Internet through the corporate network. This method is also useful for displaying splash pages, such as maintenance schedules, when any Internet access is attempted. The method described below configures a trigger for any Internet address but exempts internal addresses. Defining a Custom URL Category To define a custom URL category object for use in a coaching policy: 1 Launch the VPM; click Policy > Add Web Access Layer. Name the layer WebAccess_ShopURLs; for example. NOTE: To help maintain scalability, Blue Coat recommends giving relevant names to layers and objects.

4 2 Right-click the Destination setting and select Set. The Set Destination Object dialog displays. 3 Click New and select Request URL Category. The Add Request URL Category Object dialog displays. Name the object RequestURLCategory_ExCoShopUrls; for example. 4 Click the default Policy category. The Add button becomes active. 5 Click Add. An Object Name dialog displays. Name the object ShopURLs; for example, and click OK. The new category displays under the Policy branch. 6 Select the new category and click Edit URLs. The Edit Locally defined category Object dialog displays.

5 7 Enter URLs for the ShopURLs category, one per line. Once all the URLs for this category have been entered, click OK to dismiss the dialog. This custom URL category object is now available for use in any policy. 8 To set the custom URL category object in your policy, select it and click OK to add this Request URL Category object and dismiss the Add Request URL Category Object dialog. The Set Destination dialog re-displays with the custom Request URL Category object that you defined. 9 To use the object in a policy, select it and click OK. Using an Installed URL Filtering List To use an installed URL filtering list in a coaching policy: 1 Launch the VPM; click Policy > Add Web Access Layer. Name the layer WebAccess_WebFilter; for example. 2 Right-click the Destination setting and select Set. The Set Destination Object dialog displays. 3 Click New and select Request URL Category. The Add Request URL Category Object dialog displays. Name the object RequestURLCategory_BlueCoat; for example. 4 Select the installed URL filtering list that you want to use. A list of URL categories displays.

6 5 Select all of the categories that you want for triggers for this policy and click OK to add this Request URL Category object and dismiss the Add Request URL Category Object dialog. The Set Destination dialog re-displays with the Request URL Category object that you defined. 6 To use the object in a policy, select it and click OK. Note: You can use a custom URL category and an installed URL filtering list together. Defining Internet Access To identify Internet access for use in a splash or compliance policy: 1 Launch the VPM; click Policy > Add Web Access Layer. Name the layer; for example, WebAccess_InternetSplash. 2 Right-click the Destination setting and select Set. The Set Destination Object dialog displays. 3 Click New and select Destination IP Address/Subnet. The Add Destination Address Object dialog displays. 4 Enter a subnet pattern to match all internal (non-internet) addresses. Click Add. Click Close to dismiss the dialog. The Set Destination Object dialog re-displays with the newly-defined object.

7 5 Select the new destination object and click OK to set it and dismiss the dialog. 6 Right-Click the newly defined Destination Address object and select Negate to match not IP addresses in the defined internal subnet. In this way, all IP addresses except internal ones trigger the policy.

8 Specifying a User or Group (Optional) For notifications to a specific user or group: Along with the Notify User action described above, configure a Source setting for the particular user or group. Note: If you click New, many additional options display, including the following (most likely to be of use for a notification policy): User: An individual user in the form of a verifiable username or login name. Group: A verifiable group name. Attribute: An LDAP or Radius realm-specific attribute. Note: Some options for this setting require a configured authentication realm in order for the user/group to be identified. Scheduling Notifications (Optional) For scheduled notifications: Along with the Notify User action described above, configure a Time setting. This is used for regular notifications, such as maintenance schedules.

9 Defining the Notify User Action Three ways to define the Notify User action are described: Notify and require acceptance: When triggered, a notification page with a link to the requested URL displays. The user must click the link to satisfy the notification policy. Notify and auto-request: When triggered, a notification page displays; no click is required, the request is made invisibly to the user so the notification page is no longer triggered on future accesses. Notify and auto-redirect: When triggered, a notification page displays; an auto-request occurs and, after a set time period, the requested or an alternate URL automatically proceeds. Notify and Require Acceptance 1 In the Web Access layer previously defined, right-click the Action setting and select Set. The Set Action Object dialog displays. 2 Click New and select Notify User. The Add Notify User Object dialog displays. 3 Name the object CoachSports; for example. Modify the Body text as needed. (examples are provided below) 4 Select a Notify mode: Notify once for all hosts: The notification page is displayed only once for that user; this is often used for configuring compliance pages. This option uses a Virtual Notify URL. You do not need to change this URL; it simply works with the policy to display your notification page. If you must change the URL from the default value, please read the limitation section provided in the online help.

10 Notify only once for related domains: The notify page reappears each time the user visits a new Web site; this is used for configuring coaching pages. Notify on every host: The notify page reappears each time the user visits a new Web host. Note: Blue Coat recommends that only highly experienced administrators employ this option; on some Internet Web sites this option might cause JavaScript errors that impair the functionality of the site. 5 Select a Notify users again time interval: At next browser session: The notification page does not reappear until the next browser session (when a user reboots, logs out, or closes all Web browser windows). After <time interval>: Notification recurs after the specified elapsed time (minutes or hours). After <specified time>: Notification recurs at a specified time and day. NOTE: The time is referenced from the local workstation. If a compliance page is configured, verify the workstations and ProxySG appliance clocks are synchronized. 6 Click OK to add the object. Click OK to set the object. Click Install Policy to finish. Note: The Notify User action generates CPL that might interfere with other policy or cause undesired behavior. Please consider the following: Notifications will conflict with policy that modifies the Cookie request header. Notifications will conflict with policy that modifies the Set-Cookie and P3P response headers. Notification pages exist in the browser history. Therefore, if you click the provided link and are taken to the requested page, and then click Back, you get the notification page again. If you have a chain of SG appliances, with different notification pages configured on each appliance in the chain, then each notification page must have a different object name. Notify and Auto-Request You may want to further discourage access to the requested URL by removing the requested link from the page. In order to do this and not have the notification policy triggered every time access to the page is attempted, modify the code in the Body option of the Notify User object as follows: Replace the Body tag in the Notify User object HTML (Body text option) with: <body onload="accept();var notify_img=new Image(1,1);notify_img.src='$(exception. details)';"> Use the Notify Mode options (described above) to specify how often the policy is triggered. Now, when the notification page displays on a JavaScript enabled browser, there is no need for the user to click a link. The notification policy is not re-triggered because an auto-request was made behind-the-scenes. Notify and Auto-Redirect You can use the same modification described above (for notifications with auto-request) along with a Meta Refresh tag to auto-redirect the splash page to the requested URL. To do this, insert a Meta Refresh tag before the Body tag in the Body text option of the Notify User object, after making the modification described in Notifications with Auto-Request, above. An example specifying a redirect after 10 seconds would be this:

11 <meta http-equiv="refresh" content="10;url=$(url)">. Use the Notify Mode options (described above) to specify how often the policy is triggered. Now, when the notification page displays, there is no need for a link to the requested URL; the browser will automatically proceed after the set time (10 seconds in the example above). The notification policy will not be re-triggered. Note: To auto-direct to an alternate link rather than the requested link, simply replace the $(exception.details) variable in the Meta Refresh tag with the URL that you want to provide. Custom Notification Page Examples This section offers examples of custom notification pages that you can create by copying the HTML provided directly into the Body option of the Notify User object. Four example custom notification pages are provided: Notify and Require Acceptance Coaching Page Example: A coaching page including the requested link. Notify and Auto-Request Splash Page Example: A maintenance schedule splash page with no link. Notify and Auto-Request/Auto-Redirect Splash Page Example: A maintenance schedule splash page with no link but including an auto-redirect to the requested URL. Notify and Require Acceptance Compliance Page Example: A compliance page with an auto-redirect to the requested URL. Note: In the HTML code examples given in this section, the HTML and Head tags are automatically inserted by the policy. Notify and Require Acceptance Coaching Page Example The following illustration depicts a custom coaching page informing the user that the requested site is generally blocked; however, users that have a legitimate reason for accessing the site may click the here link, being forewarned that their activity is being logged. If the user clicks the provided link, they are given access. The HTML source used to define this page is provided below.

12 <body> <text align=center><h2>attention!</h2> access to this website has been barred under company Internet usage policy or to prevent excessive demand conflicting with core business activities. note: Internet usage is routinely monitored and logged. your IP address: $(client.address) Your username: $(user) The requested URL host is: $(url.host) Which has been categorized as: $(categories) if you have a legitimate reason to access this site please click <a href="$(exception. details)" onclick="accept();">here </a>, or <a href="mailto:support@example.com?subject="barred Web Page" $(url.host) category: $(categories), IP address: $(client.address), User ID: $(user)">employee Services </a> to request a permanent exception. warning: Those who ignore this message and persist in repeated attempts to access barred sites are traced and reported to their manager for disciplinary action. </body> To implement this coaching policy with a Web access layer in the VPM: 1 Use either a Request URL or Request URL Category destination object (see Defining Notification Triggers for details). 2 Use the Notify User action object and do the following: a. Paste into the Body option the HTML code given above, modified appropriately. b. Select the Notify only once for related domains option. c. Leave the Notify users again option at the default. To specify a user or group for the policy, add a Source object. To specify a time of day restriction for the policy, add a Time object. Notify and Auto-Request Splash Page Example The following illustration depicts a custom splash page informing the user of significant interrupting events. No link is provided; the user must re-enter the requested link in order to get access. The auto-request ensures that this page displays only once per policy trigger. Note the modified BODY tag at the top. The HTML source used to define this page is provided below.

13 <body onload="accept();var notify_img=new Image(1,1);notify_img.src='$(exception. details)';"> <text align=center><h2>important Notice!</ h2> system maintenance is scheduled for Sunday July 17, 2:00-4:00 am EST. to report any conflicts with the scheduled maintenance, see $(exception.contact) please NOTE: Internet usage is routinely monitored and logged. your IP address: $(client.address) Your username: $(user) </body> To implement this splash policy with a Web access layer in the VPM: 1 Use a Destination IP Address/Subnet destination object or other appropriate destination object (see Defining Notification Triggers for details). 2 Use the Notify User action object and do the following: a. Paste into the Body option the HTML code given above, modified appropriately. b. Select the Notify once for all hosts option. c. Set the Notify users again option appropriately. To specify a user or group for the policy, add a Source object. To specify a time of day restriction for the policy, add a Time object. Notify, Auto-Request and Auto-Redirect Splash Page Example Here is a similar splash page that auto-redirects the user to the requested URL after a set time period. No link needs to be provided if the browser supports JavaScript. This page may be used as a splash on any Internet access attempt by following the Defining Internet Access procedure. The auto-request ensures that this page displays only once per time period. Note the Meta Refresh tag within the Head tag as well as the modified Body tag. The HTML source used to define this page is provided below. Note: The HTML and Head tags are automatically inserted by the policy; to use the Meta Refresh tag, place it at the top as shown below and the policy will insert it within the Head tags.

14 <meta http-equiv="refresh" content="15;url='$(exception.details)'> <body onload="accept();var notify_img=new Image(1,1);notify_img.src='$(exception. details)';"> <text align=center><h2>important Notice!</ h2> system maintenance is scheduled for Sunday July 17, 2:00-4:00 am EST. to report any conflicts with the scheduled maintenance, see $(exception.contact) please NOTE: Internet usage is routinely monitored and logged. your IP address: $(client.address) Your username: $(user) you will be connected in 15 seconds. </body> To implement this splash policy with a Web access layer in the VPM: 1 Use a negated Destination IP Address/Subnet destination object to match the entire Internet; see Defining Internet Access for details. 2 Use the Notify User action object and do the following: a. Paste into the Body option the HTML code given above, modified appropriately. b. Select the Notify once for all hosts option. c. Set the Notify users again option appropriately. To specify a user or group for the policy, add a Source object. To specify a time of day restriction for the policy, add a Time object. Notify and Require Acceptance Compliance Page Example The following illustration depicts a custom compliance page. The link provided connects the user to the requested URL, but requires them to agree to the Corporate Internet Use policy to do so. The HTML source used to define this page is provided below.

15 <body> <text align=center><h2>attention!</h2> you are about to access the Internet from the Example Company Network. your IP address: $(client.address) Your username: $(user) you must agree to the Example Company Corporate Internet Use policy before accessing the Internet. We have a common-sense Internet use policy. Obscene, foul, or pornographic sites are not to be visited while at work. Personal shopping, browsing, or communications are discouraged. Any abuse of this professional, common sense policy may result in disciplinary action, up to and including termination. Please read the entire policy in the Company Handbook. if you agree to the Corporate Internet Use policy, please click <a href="$(exception.details)" onclick="accept();">i agree</a>, to be connected. for any comments <a href="mailto:support@example.com?subject=corporate Internet Use Policy">Employee Services</a> please NOTE: Internet usage is routinely monitored and logged. Content filtering and virus scanning are applied. </body> To implement this compliance policy with a Web access layer in the VPM: 1 Use a negated Destination IP Address/Subnet destination object to match the entire Internet; see Defining Internet Access for details. 2 Use the Notify User action object and do the following: a. Paste into the Body option the HTML code given above, modified appropriately. b. Select the Notify once for all hosts option (for the page to display only once per user). c. Leave the Notify users again option at the default. To specify a user or group for the policy, add a Source object. To specify a time of day restriction for the policy, add a Time object. Conclusion The Blue Coat ProxySG provides a security administrator with the ability to notify their user community about access to various Web sites, system maintenance schedules, and Corporate Internet Use policies. Policies can be designed to display only once; for example, upon first Internet access attempt; or at a set interval. Policies can be triggered for only a particular user, user group, or during specific times of day. Blue Coat Systems, Inc. Corporate Headquarters Sunnyvale, CA USA // EMEA Headquarters Hampshire, UK // APAC Headquarters Hong Kong // Copyright 2009 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor translated to any electronic medium without the written consent of Blue Coat Systems, Inc. Specifications are subject to change without notice. Information contained in this document is believed to be accurate and reliable, however, Blue Coat Systems, Inc. assumes no responsibility for its use. Blue Coat, ProxySG, PacketShaper, ProxyClient and BlueSource are registered trademarks of Blue Coat Systems, Inc. in the U.S. and worldwide. All other trademarks mentioned in this document are the property of their respective owners. v.tb-create_notification_policies-v3-0409