Web Reputation Filters use data to assess the reliability of Internet domains and score the reputation of URLs. The web reputation calculation associates a URL with network parameters to determine the probability that malware exists. The aggregate probability that malware exists is then mapped to a Web Reputation Score between -10 and +10, with +10 being the least likely to contain malware.

Example parameters include the following:

• URL categorization data
• Presence of downloadable code
• Presence of long, obfuscated End-User License Agreements (EULAs)
• Global volume and changes in volume
• Network owner information
• History of a URL
• Age of a URL
• Presence on any block lists
• Presence on any allow lists
• URL typos of popular domains
• Domain registrar information
• IP address information

Note	Cisco does not collect identifiable information such as user names, passphrases, or client IP addresses.

Web Reputation Scores are associated with an action to take on a URL request. You can configure each policy group to correlate an action to a particular Web Reputation Score. The available actions depend on the policy group type that is assigned to the URL request:

The DVS engine performs anti-malware scanning on URL transactions that are forwarded from the Web Reputation Filters. Web Reputation Filters calculate the probability that a particular URL contains malware, and assign a URL score that is associated with an action to block, scan, or allow the transaction.

When the assigned web reputation score indicates to scan the transaction, the DVS engine receives the URL request and server response content. The DVS engine, in combination with the Webroot and/or Sophos or McAfee scanning engines, returns a malware scanning verdict. The DVS engine uses information from the malware scanning verdicts and Access Policy settings to determine whether to block or deliver the content to the client.

The DVS engine might determine multiple malware verdicts for a single URL. Multiple verdicts can come from one or both enabled scanning engines:

• Different verdicts from different scanning engines. When you enable both Webroot and either Sophos or McAfee, each scanning engine might return different malware verdicts for the same object. When a URL causes multiple verdicts from both enabled scanning engines, the appliance performs the most restrictive action. For example, if one scanning engine returns a block verdict and the other a monitor verdict, the DVS engine always blocks the request.
• Different verdicts from the same scanning engine. A scanning engine might return multiple verdicts for a single object when the object contains multiple infections. When a URL causes multiple verdicts from the same scanning engine, the appliance takes action according to the verdict with the highest priority. The following text lists the possible malware scanning verdicts from the highest to the lowest priority.
• Virus
• Trojan Downloader
• Trojan Horse
• Trojan Phisher
• Hijacker
• System monitor
• Commercial System Monitor
• Dialer
• Worm
• Browser Helper Object
• Phishing URL
• Adware
• Encrypted file
• Unscannable
• Other Malware

The Webroot scanning engine inspects objects to determine the malware scanning verdict to send to the DVS engine. The Webroot scanning engine inspects the following objects:

• URL request. Webroot evaluates a URL request to determine if the URL is a malware suspect. If Webroot suspects the response from this URL might contain malware, the appliance monitors or blocks the request, depending on how the appliance is configured. If Webroot evaluation clears the request, the appliance retrieves the URL and scans the server response.
• Server response. When the appliance retrieves a URL, Webroot scans the server response content and compares it to the Webroot signature database.

The McAfee scanning engine inspects objects downloaded from a web server in HTTP responses. After inspecting the object, it passes a malware scanning verdict to the DVS engine so the DVS engine can determine whether to monitor or block the request.

The McAfee scanning engine uses the following methods to determine the malware scanning verdict:

• Matching virus signature patterns
• Heuristic analysis

The Sophos scanning engine inspects objects downloaded from a web server in HTTP responses. After inspecting the object, it passes a malware scanning verdict to the DVS engine so the DVS engine can determine whether to monitor or block the request. You might want to enable the Sophos scanning engine instead of the McAfee scanning engine if McAfee anti-malware software is installed.

When Adaptive Scanning is enabled, some anti-malware and reputation settings that you can configure in Access Policies are slightly different:

• You can enable or disable web reputation filtering in each Access Policy, but you cannot edit the Web Reputation Scores.

• You can enable anti-malware scanning in each Access Policy, but you cannot choose which anti-malware scanning engine to enable. Adaptive Scanning chooses the most appropriate engine for each web request.

Note	If Adaptive Scanning is not enabled and an Access Policy has particular web reputation and anti-malware settings configured, and then Adaptive Scanning is enabled, any existing web reputation and anti-malware settings are overridden.

Per-policy Advanced Malware Protection settings are the same whether or not Adaptive Scanning is enabled.

When Adaptive Scanning is enabled, the web reputation and anti-malware settings you can configure for Access Policies are slightly different than when Adaptive Scanning is turned off.

Note

If your deployment includes a Security Management appliance, and you are configuring this feature in a Primary Configuration, options on this page depend on whether Adaptive Security is enabled for the relevant primary configuration. Check the setting on the Security Management appliance, on the Web > Utilities > Security Services Display page.

When you install and set up the Secure Web Appliance, it has default settings for Web Reputation Scores. However, you can modify threshold settings for web reputation scoring to fit your organization’s needs.You configure the web reputation filter settings for each policy group.

The Secure Web Appliance maintains a filtering database that contains statistics and information about how different types of requests are handled. The appliance can also be configured to send web reputation statistics to a Cisco SensorBase Network server. SensorBase server information is leveraged with data feeds from the SensorBase Network and the information is used to produce a Web Reputation Score.

Transactions blocked and monitored by the adaptive scanning engine use the ACL decision tags:

• BLOCK_AMW_RESP
• MONITOR_AMW_RESP

Threat verdicts can change as new information emerges. A file may initially be evaluated as unknown or clean, and the user may thus be allowed to access the file. If the threat verdict changes as new information becomes available, you will be alerted, and the file and its new verdict appear in the AMP Verdict Updates report. You can investigate the point-of-entry transaction as a starting point to remediating any impacts of the threat.

Verdicts can also change from malicious to clean.

When the appliance processes subsequent instances of the same file, the updated verdict is immediately applied.

Information about the timing of verdict updates is included in the file-criteria document referenced in Supported Files for File Reputation and Analysis Services.

First, the website from which the file is downloaded is evaluated against the Web Based Reputation Service (WBRS).

If the web reputation score of the site is in the range configured to “Scan,” the appliance simultaneously scans the transaction for malware and queries the cloud-based service for the reputation of the file. (If the site’s reputation score is in the “Block” range, the transaction is handled accordingly and there is no need to process the file further.) If malware is found during scanning, the transaction is blocked regardless of the reputation of the file.

If Adaptive Scanning is also enabled, file reputation evaluation and file analysis are included in Adaptive Scanning.

Communications between the appliance and the file reputation service are encrypted and protected from tampering.

After a file’s reputation is evaluated:

• If the file is known to the file reputation service and is determined to be clean, the file is released to the end user .
• If the file reputation service returns a verdict of malicious, then the appliance applies the action that you have specified for such files.
• If the file is known to the reputation service but there is insufficient information for a definitive verdict, the reputation service returns a threat score based on characteristics of the file such as threat fingerprint and behavioral analysis. If this score meets or exceeds the configured reputation threshold, the appliance applies the action that you have configured in the access policy for malicious or high-risk files.
• If the reputation service has no information about the file, and the file does not meet the criteria for analysis (see Supported Files for File Reputation and Analysis Services), the file is considered clean and the file is released to the end user .

• If you have enabled the cloud-based File Analysis service, and the reputation service has no information about the file, and the file meets the criteria for files that can be analyzed (see Supported Files for File Reputation and Analysis Services), then the file is considered clean and is optionally sent for analysis.

• For deployments with on-premises file analysis, the reputation evaluation and file analysis occur simultaneously. If the reputation service returns a verdict, that verdict is used, as the reputation service includes inputs from a wider range of sources. If the file is unknown to the reputation service, the file is released to the user but the file analysis result is updated in the local cache and is used to evaluate future instances of the file .
• If the file reputation verdict information is unavailable because the connection with the server timed out, the file is considered as Unscannable and the actions configured are applied.

Low Risk Files

When a file is initially evaluated as unknown, and has no dynamic content, the appliance sends it to the pre-classification engine, where it is designated as low risk. This file is not uploaded for analysis. If the same file is accessed within the cache expiry, it is evaluated again as low risk, and is not uploaded for analysis. After the cache timeout, if the same file is accessed again, it is evaluated as unknown and low risk sequentially. This process is repeated for low risk files. Since these low risk files are not uploaded, they will not be a part of file analysis reports.

If the file is sent for analysis:

• If the file is sent to the cloud for analysis: Files are sent over HTTPS.

• Analysis normally takes minutes, but may take longer.

• A file that is flagged as malicious after File Analysis may not be identified as malicious by the reputation service. File reputation is determined by a variety of factors over time, not necessarily by a single file analysis verdict.

• Results for files analyzed using an on premises Cisco Secure Endpoint Malware Analytics appliance are cached locally.

For information about verdict updates, see File Threat Verdict Updates.

The reputation service evaluates most file types. File type identification is determined by file content and is not dependent on the filename extension.

Some files with unknown reputation can be analyzed for threat characteristics. When you configure the file analysis feature, you choose which file types are analyzed. New types can be added dynamically; you will receive an alert when the list of uploadable file types changes, and can select added file types to upload.

Details about what files are supported by the reputation and analysis services are available only to registered Cisco customers. For information about which files are evaluated and analyzed, see File Criteria for Advanced Malware Protection Services for Cisco Content Security Products, available from http://www.cisco.com/c/en/us/support/security/web-security-appliance/products-user-guide-list.html. The criteria for evaluating a file’s reputation and for sending files for analysis may change at any time.

In order to access this document, you must have a Cisco customer account with a support contract. To register, visit https://tools.cisco.com/RPF/register/register.do.

Your setting for DVS Engine Object Scanning Limits on the Security Services > Anti-Malware and Reputation page also determines the maximum file size for file reputation and analysis.

You should configure policies to block download of files that are not addressed by Advanced Malware Protection.

Note	A file that has already been uploaded for analysis from any source will not be uploaded again. To view analysis results for such a file, search for the SHA-256 from the File Analysis reporting page.

• Only the SHA that uniquely identifies a file is sent to the reputation service in the cloud. The file itself is not sent.

• If you are using the file analysis service in the cloud and a file qualifies for analysis, the file itself is sent to the cloud.

• Information about every file that is sent to the cloud for analysis and has a verdict of "malicious" is added to the reputation database. This information is used along with other data to determine a reputation score.

  Information about files analyzed by an on premises Cisco Secure Endpoint Malware Analytics appliance is not shared with the reputation service.

• All Secure Web Appliance that use these services must be able to connect to them directly over the internet (excluding File Analysis services configured to use an on-premises Cisco Secure Endpoint Malware Analytics Appliance.)

• By default, communication with file reputation and analysis services is routed through the Management port (M1) on the appliance. If your appliance does not route data through the management port, see Routing Traffic to File Reputation and File Analysis Servers Through a Data Interface.

• By default, communication with file reputation and cloud-based analysis services is routed through the interface that is associated with the default gateway. To route this traffic through a different interface, create a static route for each address in the Advanced section of the Security Services > File Reputation and Analysis page.

• The following firewall ports must be open:

  Firewall Ports	Description	Protocol	In/Out	Hostname	Appliance Interface
  32137 (default) or 443	Access to cloud services for obtaining file reputation.	TCP	Out	As configured in Security Services > Anti-Malware and Reputation, Advanced section: Advanced Settings for File Reputation, Cloud Server Pool parameter.	Management, unless a static route is configured to route this traffic through a data port.
  443	Access to cloud services for file analysis.	TCP	Out	As configured in Security Services > Anti-Malware and Reputation, Advanced section: Advanced Settings for File Analysis.

• When you configure the file reputation feature, choose whether to use SSL over port 443.

If you will use a Cisco AMP Virtual Private Cloud appliance as a private-cloud file analysis server:

• You can obtain the Cisco Advanced Malware Protection Virtual Private Cloud Appliance documentation, including the Installation and Configuration of FireAMP Private Cloud guide, from http://www.cisco.com/c/en/us/support/security/fireamp-private-cloud-virtual-appliance/tsd-products-support-series-home.html

  Use that documentation to perform the tasks described in this topic.

  Additional documentation is available using the Help link in the AMP Virtual Private Cloud appliance.

• Set up and configure the Cisco AMP Virtual Private Cloud appliance in either “proxy” or “air-gap” (on-premises) mode.

• Ensure the Cisco AMP Virtual Private Cloud appliance software version is 2.2, which enables integration with Cisco Secure Web Appliance.

• Download the AMP Virtual Private Cloud certificate and keys on that appliance for upload to this Secure Web Appliance

Note	After you have set up the on-premises file-reputation server, you will configure connection to it from this Secure Web Appliance; see Step 6 of Enabling and Configuring File Reputation and Analysis Services

If you will use a Cisco Secure Endpoint Malware Analytics Appliance as a private-cloud file analysis server:

• Obtain the Cisco Secure Endpoint Malware Analytics Appliance Setup and Configuration Guide and the Cisco Secure Endpoint Malware Analytics Appliance Administration Guide. Cisco Secure Endpoint Malware Analytics Appliance documentation is available from https://www.cisco.com/c/en/us/support/security/amp-threat-grid-appliances/products-installation-guides-list.html.

  Use this documentation to perform the tasks described in this topic.

  Additional documentation is available from the Help link in the Cisco Secure Endpoint Malware Analytics appliance.

  In the Administration Guide, search for information about all of the following: integrations with other Cisco appliances, CSA, Cisco Sandbox API Secure Web Appliance.

• Set up and configure the Cisco Secure Endpoint Malware Analytics Appliance.

• If necessary, update your Cisco Secure Endpoint Malware Analytics Appliance software to version 1.2.1, which supports integration with Cisco Secure Web Appliance.

  See the AMP Malware Analytics documentation for instructions for determining the version number and for performing the update.

• Ensure that your appliances can communicate with each other over your network. Cisco Secure Web Appliance must be able to connect to the CLEAN interface of the Cisco Secure Endpoint Malware Analytics appliance.

• If you will deploy a self-signed certificate: Generate a self-signed SSL certificate from the Cisco Secure Endpoint Malware Analytics appliance to be used on your Secure Web Appliance. See instructions for downloading SSL certificates and keys in the administrator’s guide for your Cisco Secure Endpoint Malware Analytics appliance. Be sure to generate a certificate that has the hostname of your Cisco Secure Endpoint Malware Analytics appliance as CN. The default certificate from the Cisco Secure Endpoint Malware Analytics appliance does NOT work.

• Registration of your Secure Web Appliance with your Malware Analytics appliance occurs automatically when you submit the configuration for File Analysis, as described in Enabling and Configuring File Reputation and Analysis Services. However, you must activate the registration as described in the same procedure.

Note	After you have set up the on-premises file-analysis server, you will configure connection to it from this Secure Web Appliance; see Step 7 of Enabling and Configuring File Reputation and Analysis Services

If you plan to use a new public cloud File Analysis service, make sure you read the following instructions to maintain datacenter isolation:

• The existing appliance grouping information is not preserved in the new File Analysis server. You must regroup your appliances on the new File Analysis server.

• Messages that are quarantined to the File Analysis Quarantine are retained until the retention period. After the quarantine retention period, the messages are released from the File Analysis Quarantine, and re-scanned by the AMP engine. The file is then uploaded to the new File Analysis server for analysis but the message is not sent to the File Analysis Quarantine again.

For more details, refer to the Cisco AMP Malware Analytics documentation from https://www.cisco.com/c/en/us/support/security/amp-threat-grid-appliances/products-installation-guides-list.html.

Ensure that the appliance is configured to send you alerts related to Advanced Malware Protection.

You will receive alerts when:

If you will centralize reporting on a Security Management appliance, see important configuration requirements in the Advanced Malware Protection sections in the web reporting topic of the online help or user guide for your management appliance.

Because filenames can easily be changed, the appliance generates an identifier for each file using a Secure Hash Algorithm (SHA-256). If an appliance processes the same file with different names, all instances are recognized as the same SHA-256. If multiple appliances process the same file, all instances of the file have the same SHA-256 identifier.

In most reports, files are listed by their SHA-256 value (in an abbreviated format). To identify the filenames associated with a malware instance in your organization, select Reporting > Advanced Malware Protection and click an SHA-256 link in the table. The details page shows associated filenames.

Data for file reputation and analysis is available in other reports where relevant. A ;Blocked by Advanced Malware Protection" column may be hidden by default in applicable reports. To display additional columns, click the Columns link below the table.

The Report by User Location includes an Advanced Malware Protection tab.

When searching for file threat information in Web Tracking, keep the following points in mind:

• To search for malicious files found by the file reputation service, select Known Malicious and High-Risk Files for the Filter by Malware Category option in the Malware Threat area in the Advanced section in Web Message Tracking.

• Web Tracking includes only information about file reputation processing and the original file reputation verdicts returned at the time a transaction message was processed. For example, if a file was initially found to be clean, then a verdict update found the file to be malicious, only the clean verdict appears in Tracking results.

  No information is provided for clean or unscannable attachments.

  “Block – AMP” in search results means the transaction was blocked because of the file's reputation verdict.

  In Tracking details, the “AMP Threat Score” is the best-effort score that the cloud reputation service provides when it cannot determine a clear verdict for the file. In this situation, the score is between 1 and 100. (Ignore the AMP Threat Score if an AMP Verdict is returned or if the score is zero .) The appliance compares this score to the threshold score (configured on the Security Services > Anti-Malware and Reputation page) to determine what action to take. By default, files with scores between 60 and 100 are considered malicious. Cisco does not recommend changing the default threshold score. The WBRS score is the reputation of the site from which the file was downloaded; this score is not related to the file reputation.

• Verdict updates are available only in the AMP Verdict Updates report. The original transaction details in Web Tracking are not updated with verdict changes. To see transactions involving a particular file , click a SHA-256 in the verdict updates report.

• Information about File Analysis, including analysis results and whether or not a file was sent for analysis, are available only in the File Analysis report.

  Additional information about an analyzed file may be available from the cloud or on-premises File Analysis server. To view any available File Analysis information for a file, select Reporting > File Analysis and enter the SHA-256 to search for the file , or click the SHA-256 link in Web Tracking details. If the File Analysis service has analyzed the file from any source, you can see the details. Results are displayed only for files that have been analyzed.

  If the appliance processed a subsequent instance of a file that was sent for analysis, those instances will appear in Web Tracking search results.

In logs:

• AMP and amp refer to the file reputation service or engine.

• Retrospective refers to verdict updates.

• VRT and sandboxing refer to the file analysis service.

Information about Advanced Malware Protection including File Analysis is logged in Access Logs or in AMP Engine Logs. For more information, see the topic on monitoring system activity through logs.

In the log message “Response received for file reputation query” possible values for “upload action” are:

• 1: SEND. In this case, you must send the file for File Analysis.

• 2: DON’T SEND. In this case, you do not send the file for File Analysis.

• 3: SEND ONLY METADATA. In this case, you send only the metadata and not the entire file for File Analysis.

• 0: NO ACTION. In this case, no other action is required.

Problem

You receive several alerts about failures to connect to the file reputation or analysis services in the cloud. (A single alert may indicate only a transient issue.)

Solution

• Ensure that you have met the requirements in Requirements for Communication with File Reputation and Analysis Services.

• Check for network issues that may prevent the appliance from communicating with the cloud services.

• Increase the Query Timeout value:

  Select Security Services > Anti-Malware and Reputation. The Query Timeout value is in the Advanced settings area of the Advanced Malware Protection Services section.

Problem

You receive an API key alert when attempting to view File Analysis report details, or the Secure Web Appliance is unable to connect to the AMP Malware Analytics server to upload files for analysis.

Solution

This error can occur if you change the hostname of the AMP Malware Analytics server and you are using a self-signed certificate from the AMP Malware Analytics server, as well as possibly under other circumstances. To resolve the issue:

• Generate a new certificate from the AMP Malware Analytics appliance that has the new hostname.

• Upload the new certificate to the Secure Web Appliance.

• Reset the API key on the AMP Malware Analytics appliance. For instructions, see the online help on the AMP Malware Analytics appliance.

Problem

Files are not evaluated or analyzed as expected. There is no alert or obvious error.

Solution

Consider the following:

• The file may have been sent for analysis by another appliance and thus already be present on the File Analysis server or in the cache of the appliance that is processing the file.

• Check the maximum file size limit configured for the DVS Engine Object Scanning Limits on the Security Services > Anti-Malware and Reputation page. This limit applies to Advanced Malware Protection features.

Problem

Complete file analysis results in the public cloud are not available for files uploaded from other Secure Web Appliances in my organization.

Solution

Be sure to group all appliances that will share file analysis result data. See (Public Cloud File Analysis Services Only) Configuring Appliance Groups. This configuration must be done on each appliance in the group.

Problem

You receive alerts of severity Info about file types that can be sent for file analysis.

Solution

This alert is sent when supported file types change, or when the appliance checks to see what file types are supported. This can occur when:

• You or another administrator changes the file types selected for analysis.
• Supported file types change temporarily based on availability in the cloud service. In this case, support for the file types selected on the appliance will be restored as soon as possible. Both processes are dynamic and do not require any action from you.
• The appliance restarts, for example as part of an AsyncOS upgrade.

When HTTP range requests are disabled and a large file is downloaded over multiple streams, the consolidated package is scanned. This disables the performance advantages of download-management utilities and applications that are used to download large objects.

Alternatively, when Range Request Forwarding is enabled (see Configuring Web Proxy Settings), you can control how incoming range requests are handled on a per-policy basis. This process is known as “byte serving” and is a means of bandwidth optimization when requesting large files.

However, enabling range request forwarding can interfere with policy-based Application Visibility and Control (AVC) efficiency, and can compromise security. Please exercise caution and enable HTTP Range Request Forwarding only if the advantages outweigh the security implications.

Note	The Range Request Settings are available only when Range Request Forwarding is enabled, and at least one application is set to Block, Restrict, or Throttle.

Consider the following rules and guidelines when configuring application control settings:

• The supported Application Types, applications, and application behaviors may change between AsyncOS for Web upgrades, or after AVC or ADC engine updates.

• If you enable Safe Search or Site Content Rating, the AVC Engine is tasked with identifying applications for safe browsing. As one of the criteria, the AVC engine will scan the response body to detect a search application. As a result, the appliance will not forward range headers.

• In Application Type listings, the summary for each Application Type lists the final actions for its applications, but does not indicate whether these actions are inherited from the global policy or configured in the current Access Policy. To learn more about the action for a particular application, expand the application type.

• In the Global Access Policy, you can set the default action for each Application Type, so new applications introduced in an AVC or ADC engine update automatically inherit the default action.

• You can quickly configure the same action for all applications in an application type by clicking the “edit all” link for the Application Type in Browse view. However, you can only configure the application action, not application behavior actions. To configure application behaviors, you must edit the application individually.

• In Search view, when you sort the table by the action column, the sort order is by the final action. For example, “Use Global (Block)” comes after “Block” in the sort order.

• Decryption may cause some applications to fail unless the root certificate for signing is installed on the client.

You can define user bandwidth limits by configuring bandwidth control settings on the Applications Visibility and Control page of Access Policies. You can define the following types of bandwidth controls for users in Access Policies:

The access log file records the information returned by the AVC or ADC engine for each transaction. The scanning verdict information section in the access logs includes the fields listed below:

Note	If you configure the ADC Application behavior for a particular application, then only it can be searched. Otherwise the custom behavior will be "Unknown".

To help reduce the number of upload requests recorded in the log files, you can define a minimum request body size, below which upload requests are not scanned by the Cisco Data Security Filters or the external DLP server.

To do this, use the following CLI commands:

• datasecurityconfig. Applies to the Cisco Data Security filters.
• externaldlpconfig. Applies to the configured external DLP servers.

The default minimum request body size is 4 KB (4096 bytes) for both CLI commands. Valid values are 1 to 64 KB. The size you specify applies to the entire size of the upload request body.

Note	All chunk encoded uploads and all native FTP transactions are scanned by the Cisco Data Security filters or external DLP servers when enabled. However, they can still be bypassed based on a custom URL category.

When the Cisco Data Security filters or an external DLP server blocks an upload request, it provides a block page that the Web Proxy sends to the end user. Not all websites display the block page to the end user. For example, some Web 2.0 websites display dynamic content using javascript instead of a static Web page and are not likely to display the block page. Users are still properly blocked from performing data security violations, but they may not always be informed of this by the website.

To determine the policy group that a client request matches, the Web Proxy follows a specific process for matching the group membership criteria. It considers the following factors for group membership:

• Identity. Each client request either matches an Identification Profile, fails authentication and is granted guest access, or fails authentication and gets terminated.
• Authorized users. If the assigned Identification Profile requires authentication, the user must be in the list of authorized users in the Data Security or External DLP Policy group to match the policy group. The list of authorized users can be any of the specified groups or users or can be guest users if the Identification Profile allows guest access.
• Advanced options. You can configure several advanced options for Data Security and External DLP Policy group membership. Some options (such as proxy port and URL category) can also be defined within the Identity. When an advanced option is configured in the Identity, it is not configurable in the Data Security or External DLP Policy group level.

The information in this section gives an overview of how the Web Proxy matches upload requests to both Data Security and External DLP Policy groups.

The Web Proxy sequentially reads through each policy group in the policies table. It compares the upload request status to the membership criteria of the first policy group. If they match, the Web Proxy applies the policy settings of that policy group.

If they do not match, the Web Proxy compares the upload request to the next policy group. It continues this process until it matches the upload request to a user defined policy group. If it does not match a user defined policy group, it matches the global policy group. When the Web Proxy matches the upload request to a policy group or the global policy group, it applies the policy settings of that policy group.

AsyncOS for Web allows you to configure how the appliance handles a transaction based on the URL category of a particular request. Using a predefined category list, you can choose to monitor or block content by category. You can also create custom URL categories and choose to allow, monitor, or block traffic for a website in the custom category.

The Web Reputation setting inherits the global setting. To customize web reputation filtering for a particular policy group, you can use the Web Reputation Settings pull-down menu to customize web reputation score thresholds.

Only negative and zero values can be configured for web reputation threshold settings for Cisco Data Security policies. By definition, all positive scores are monitored.

You can use the settings on the Cisco Data Security > Content page to configure the Web Proxy to block data uploads based on the following file characteristics:

• File size. You can specify the maximum upload size allowed. All uploads with sizes equal to or greater than the specified maximum are blocked. You can specify different maximum file sizes for HTTP/HTTPS and native FTP requests.

  When the upload request size is greater than both the maximum upload size and the maximum scan size (configured in the “DVS Engine Object Scanning Limits” field on Security Services > Anti-Malware page), the upload request is still blocked, but the entry in the data security logs does not record the file name and content type. The entry in the access logs is unchanged.

• File type. You can block predefined file types or custom MIME types you enter. When you block a predefined file type, you can block all files of that type or files greater than a specified size. When you block a file type by size, the maximum file size you can specify is the same as the value for the “DVS Engine Object Scanning Limits” field on Security Services > Anti-Malware page. By default, that value is 32 MB.

  Cisco Data Security filters do not inspect the contents of archived files when blocking by file type. Archived files can be blocked by its file type or file name, not according to its contents.

  Note	For some groups of MIME types, blocking one type blocks all MIME types in the group. For example, blocking application/x-java-applet blocks all java MIME types, such as application/java and application/javascript.

• File name. You can block files with specified names. You can use text as a literal string or a regular expression for specifying file names to block.

  Note	Only enter file names with 8-bit ASCII characters. The Web Proxy only matches file names with 8-bit ASCII characters.

The end-user acknowledgment page works because it displays an HTML page to the end user that forces them to click an acceptable use policy agreement. After users click the link, the Web Proxy redirects clients to the originally requested website. It keeps track of when users accepted the end-user acknowledgment page using a surrogate (either by IP address or web browser session cookie) if no username is available for the user.

• HTTPS. The Web Proxy tracks whether the user has acknowledged the end-user acknowledgment page with a cookie, but it cannot obtain the cookie unless it decrypts the transaction. You can choose to either bypass (pass through) or drop HTTPS requests when the end-user acknowledgment page is enabled and tracks users using session cookies. Do this using the advancedproxyconfig > EUN CLI command, and choose bypass for the “Action to be taken for HTTPS requests with Session based EUA (“bypass” or “drop”).” command.
• FTP over HTTP. Web browsers never send cookies for FTP over HTTP transactions, so the Web Proxy cannot obtain the cookie. To work around this, you can exempt FTP over HTTP transactions from requiring the end-user acknowledgment page. Do this by creating a custom URL category using “ftp://” as the regular expression (without the quotes) and defining and Identity policy that exempts users from the end-user acknowledgment page for this custom URL category.

• When a user is tracked by IP address, the appliance uses the shortest value for maximum time interval and maximum IP address idle timeout to determine when to display the end-user acknowledgment page again.
• When a user is tracked using a session cookie, the Web Proxy displays the end-user acknowledgment page again if the user closes and then reopens their web browser or opens a second web browser application.
• Using a session cookie to track users when the client accesses HTTPS sites or FTP servers using FTP over HTTP does not work.
• When the appliance is deployed in explicit forward mode and a user goes to an HTTPS site, the end-user acknowledgment page includes only the domain name in the link that redirects the user to the originally requested URL. If the originally requested URL contains text after the domain name, that text is truncated.
• When the end-user acknowledgment page is displayed to a user, the access log entry for that transaction shows OTHER as the ACL decision tag. This is because the originally requested URL was blocked, and instead the user was shown the end-user acknowledgment page.

The Web Proxy can be configured to redirect all HTTP end-user notification pages to a specific URL that you specify.

• Displaying the Correct Off-Box Page Based on the Reason for Blocking Access
• URL Criteria for Off-Box Notification Pages
• Off-Box End-User Notification Page Parameters
• Redirecting End-User Notification Pages to a Custom URL (Off-Box)

You can use HTML tags to format the text in any notification on the Edit End User Notification page that offers a “Custom Message” box. Tags must be in lower case and follow standard HTML syntax (closing tags, etc.)

You can use the following HTML tags.

• <a></a>
• <span></span>
• <b></b>
• <big></big>
• <br>
• <code></code>
• <em></em>
• <i></i>
• <small></small>
• <strong></strong>

For example, you can make some text italic:

Please acknowledge the following statements <i>before</i> accessing the Internet. 
	 

With the <span> tag, you can use any CSS style to format text. For example, you can make some text red:

 <span style=”color: red”>Warning:</span> You must acknowledge the following statements <i>before</i> accessing the Internet. 
	 

Note

If you need greater flexibility or wish to add JavaScript to your notification pages, you must edit the HTML notification files directly. JavaScript entered into the Custom Message box for notifications in the web user interface will be stripped out. See Editing Notification Page HTML Files Directly.

This section applies if you will make any of the following customizations:

• Enter text into the “Custom Message” box for any notification on the Edit End User Notification page
• Directly edit HTML files for on-box notifications
• Use a custom logo

All combinations of URL paths and domain names in embedded links within custom text, and the custom logo, are exempted from the following for on-box notifications:

• User authentication
• End-user acknowledgment
• All scanning, such as malware scanning and web reputation scoring

For example, if the following URLs are embedded in custom text:

http://www.example.com/index.html

http://www.mycompany.com/logo.jpg

Then all of the following URLs will also be treated as exempt from all scanning:

http://www.example.com/index.html

http://www.mycompany.com/logo.jpg

http://www.example.com/logo.jpg

http://www.mycompany.com/index.html

Also, where an embedded URL is of the form: <protocol>://<domain-name>/<directory path>/ then all sub-files and sub-directories under that directory path on the host will also be exempted from all scanning.

For example, if the following URL is embedded: http://www.example.com/gallery2/ URLs such as http://www.example.com/gallery2/main.php will also be treated as exempt.

This allows you to create a more sophisticated page with embedded content so long as the embedded content is relative to the initial URL. However, you should also take care when deciding which paths to include as links and custom logos.

• Each notification page file must be a valid HTML file. For a list of HTML tags you can include, see Supported HTML Tags in Custom Messages on Notification Pages.

• The customized notification page file names must exactly match the file names shipped with the Secure Web Appliance.

  If the configuration\eun directory does not contain a particular file with the required name, then the appliance displays the standard on-box end-user notification page.

• Do not include any links to URLs in the HTML files. Any link included in the notification pages are subject to the access control rules defined in the Access Policies and users might end up in a recursive loop.

• Test your HTML files in supported client browsers to ensure that they behave as expected, especially if they include JavaScript.

• For your customized pages to take effect, you must enable the customized files using the advancedproxyconfig > EUN > Refresh EUN Pages CLI command.

When editing notification HTML files, you can include conditional variables to create if-then statements to take different actions depending on the current state.

The table describes the different conditional variable formats.

For example, the following text is some HTML code that uses %R as a conditional variable to check if re-authentication is offered, and uses %r as a regular variable to provide the re-authentication URL.

%?R
<div align="left">
  <form name="ReauthInput" action="%r" method="GET">
    <input name="Reauth" type="button" OnClick="document.location='%r'"
id="Reauth" value="Login as different user...">
  </form>
</div>
%#R

Any variable included in Variables for Customizing Notification HTML Files can be used as a conditional variable. However, the best variables to use in conditional statements are the ones that relate to the client request instead of the server response, and the variables that may or may not evaluate to TRUE instead of the variables that always evaluate to TRUE.

You can use variables in the notification HTML files to display specific information to the user. You can also turn each variable into a conditional variable to create if-then statements. For more information, see Using Variables in Notification HTML Files.

The Reporting > L4 Traffic Monitor page provides statistical summaries of monitoring activity. You can use the following displays and reporting tools to view the results of L4 Traffic Monitor activity:

Note

If the Web Proxy is configured as a forward proxy and L4 Traffic Monitor is set to monitor all ports, the IP address of the proxy’s data port is recorded and displayed as a client IP address in the client activity report on the Reporting > Client Activity page. If the Web Proxy is configured as a transparent proxy, enable IP spoofing to correctly record and display the client IP addresses.

The L4 Traffic Monitor log file provides a detailed record of monitoring activity.