Cisco Cloud Web Security Account Creation and Initial Login to ScanCenter
After subscribing to Cisco® Cloud Web Security (CWS), formerly known as Cisco ScanSafe, you will receive a provisioning email message that includes important information. In the provisioning email message you will find details about your primary and secondary web services proxy addresses. Keep these addresses because you will need them when configuring your Cisco Adaptive Security Appliance (ASA) Firewall.
In the message you will also find your credentials for logging in to the Cisco Web Security administrator portal, Cisco ScanCenter. The password supplied is a temporary password, so you must change it when you first log in. When you can successfully log in to your Cisco ScanCenter account, you are ready to start the configuration steps.
Decision Tree for Creating Company or Group Key in Cisco ScanCenter
When traffic is redirected to the cloud, it needs to be identified in order to verify that the redirecting company is a licensed customer, and to recognize who that company is in order to apply the correct policy. This identification is achieved by generating a company or group key in your ScanCenter account; you then use this key in your ASA configuration settings. You should consider the following when deciding whether to use a company or a group key:
• You can create only one company key, which, as the name suggests, is used by the whole company. The company key is typically used when installing and configuring a single ASA to redirect to the Cloud Web Security (CWS) service, and in cases where one or more ASAs are integrated with a Microsoft Active Directory Network. Integrating the ASA with Active Directory enables you to apply policies according to group membership, and provides user granularity in reports.
• If you are configuring multiple ASAs (or an ASA in multiple context mode), you can create custom groups in ScanCenter and assign a group key to each group. You can then use separate group keys on each ASA device or context in order to associate them to your custom groups, and apply separate policy rules to the groups. This method can provide location granularity in cases where the ASA is not integrated with an AD, but users will not be named in reports (their IP addresses will be seen, however).
Creating a Company Key
Because there is only one company key, the procedure is simple. This procedure is performed in ScanCenter.
1. Log in to ScanCenter and navigate to the Admin tab.
2. Under the Authentication menu, select Company Key.
3. If a key has already been created, you will see only the last four characters, so if you have not saved it elsewhere, you will have to revoke it and create a new one.
Note: If you revoke a company key that is already in use, the new one will have to be updated in the configurations of all devices where it is already used.
4. To create a new company key, click Create new.
5. After you create a new company key, the full key is shown upon creation. You can send it to yourself in an email message from the page or copy and save it locally for use on the ASA configuration.
Creating a Group Key
Group keys are associated with custom groups, so first define your custom groups in ScanCenter:
1. Navigate to the Admin tab and under the Management menu, select Groups.
2. Click Add Custom Group from the foot of the page.
3. The Add New Custom Group window will appear. Give your new custom group a name.
4. Next associate a group key with the custom group. Stay on the Admin tab and from the Authentication menu, select Group Keys.
5. Find your group on the list and click Create Key to create a new group key.
6. As with the company key, the whole string is shown only once upon completion, and after that only the last four characters are shown, so be sure to save it.
Cisco ASA Configuration for Redirection to CWS
Before you proceed with this step, make sure you have following information ready:
• Fully qualified domain name (FQDN) or IP address of the primary or backup CWS proxy servers
• License hex-keys
To configure ASA to send traffic, enter the following commands:
server primary ip 18.104.22.168 port 8080
Configuration through the Cisco Adaptive Security Device Manager (ASDM) (native device manager) follows:
You can also verify the status of the CWS (ScanSafe) link as follows:
The next step is to identify the traffic pattern for which you want to redirect to the CWS proxy. This step requires some knowledge of the ASA modular policy framework (MPF). The details of MPF are available at: http://tools.cisco.com/squish/eF3bE.
In the following example, we will configure ASA to send all the port 80 traffic to CWS. You can use a similar approach to send port 443 traffic to CWS too. The configuration can be done by following a simple
1. Create a policy map for CWS on the ASA.
2. Define the protocol (in this case HTTP).
The following configuration line items are required to achieve these steps:
hostname(config)# policy-map type inspect scansafe cws_inspect_pmap1
Now ASA is ready to send all the port 80 traffic to the CWS proxy.
Cisco ASA Configuration for Whitelisting (optional)
Customers can also selectively identify whitelisted websites for which the traffic should not get redirected through CWS proxy. Please note that this feature requires identification of source based on user and group. We highly recommend that you include in this list all URLs from which regular software updates originate, such as Microsoft, Apple, and Adobe, as well as antivirus signature update files that you regularly download from the Internet.
Following is an example of configuration of FQDN network objects for URLs that should be bypassed, and are set in the Service Access Policy to not match. In this example, the bypassed URLs are stage-updates.ironport.com and download.ironport.com:
Use the Add Network Object option to add the FQDN of the hosts that should be bypassed from CWS:
Add rules to the existing CWS service policy to exclude requests from any source to these hosts, and position them at the right priority in the list:
Cisco ASA Configuration for Identity Firewall Integration (optional)
ASA Identity Firewall (IDFW) over the Microsoft Active Directory Network provides Single Sign-On (SSO) within an Active Directory domain and embeds user and group identity in firewall access policies. This setup enables enterprises to configure policies and identify users directly by username or group name rather than through IP addresses. The advantages of this integration include:
• Increased flexibility and simplicity in policy creation by decoupling policy from topology
• Decreased costs of creating and maintaining security policies
• Better visibility on who is doing what
• Decoupling of policy from network topology
• Significant reduction of policy count
ASA Identity Firewall polices can be used in conjunction with CWS policies, and when used they will be carried to the CWS service, which can then use this identity information for the cloud polices.
For ASA Identity Firewall to be active, you must have an Active Directory domain-based network, and you must also have an Active Directory Agent (Cisco Directory Agent) installed in your network.
Following are the requirements:
• Download the Active Directory group from the Active Directory domain controller with the Lightweight Directory Access Protocol (LDAP).
• Receive IP-user mappings from the Active Directory Agent with the RADIUS protocol.
• Report IP-user mappings from VPN or cut-through proxy to the Active Directory Agent.
• Apply policies (access control list [ACL] and Multi-Processor Forwarding [MPF]) based on user identity.
Active Directory Agent:
• Monitor the security logs of the Active Directory domain controllers with Windows Management Instrumentation (WMI).
• Push IP-user mappings to ASA with the RADIUS protocol.
• Receive IP-user mappings from ASA with the RADIUS protocol.
Active Directory domain controller:
• Authenticate users.
• Generate user logon security logs.
• Reply to the ASA LDAP query for user and group information.
There are various ways to test redirection to the CWS proxy. Perform the following steps to confirm that the web traffic of clients is being redirected to the proxy:
1. Open a web browser on a client machine that is behind the ASA.
2. In the URL window of your browser, type http://whoami.scansafe.net. Details such as your ScanCenter account name, group name(s), and usernames will be displayed. If a message is displayed stating "User is not currently using the service", then the client's web traffic is not being redirected to the cloud web proxy.
3. Try to browse to www.gator.com. The site should be blocked and you should see the default blocking page. Confirm that the reason for the block is identified spyware.
4. Browse to the homepage of one of the major search engines (Google, Yahoo, or Bing) and run a search. SearchAhead icons should be present next to the search results.
Note: If you do not see SearchAhead results, log in to ScanCenter, navigate to the Web Filtering tab, then the Management menu, and then under Global Settings ensure the Enable SearchAhead for all users checkbox is selected.
Directory Groups Definition in Cisco ScanCenter (optional)
If you have integrated your ASA with an IDFW for group identification in rules and user granularity in reports, you need to define in ScanCenter any directory groups for use in web filtering rules.
1. Log in to ScanCenter and click the Admin tab.
2. Under the Management tab, click Groups. The list of defined groups will be shown.
3. Click Add Directory Group from the bottom of the page.
4. Type in the name of a directory group in the format of domain-name\group-name.
5. Click Save to save the directory group.
6. Repeat the previous three steps to add additional directory groups.
Web Filtering Policy in Cisco ScanCenter
To get started, you need to create a basic web filtering policy in ScanCenter.
The policy is a set of rules that runs from top to bottom, checking each rule until it makes the first "match", and applies the action of that rule and then stops. In order for a rule to make a match and apply an action, it must make a match on all three of the following entities:
• Groups, Users, or IP Addresses
So the rule is actually asking "Can this user access this web content at this time?"
If no rule is matched, the Default rule at the bottom will always apply.
The following steps demonstrate how to set up a basic policy, which you can then build on and develop further.
Note: In a new account, no policy will be defined and all users can access all sites at all times, so all you will see is a default rule in the list.
In your ScanCenter account, click the Web Filtering tab to show the policy.
1. If you want rules to apply at all times, there is no need to create any schedules. A default schedule named Anytime already exists and cannot be edited. If you do not apply any schedule to a rule, it will also always be active.
2. If you need to create any schedules, under the Management menu, click Schedules.
3. You can create new schedules according to your needs. For instance, you can customize policies for lunch and working hours. Note that a schedule can apply to a certain time zone and be active on any combination of days.
4. Create and save any schedules as required.
Filters are used for identifying the web content that you want to control. When creating a filter, think in advance what you want to achieve with the filter. Ask yourself questions such as "What action will be applied when this filter is matched?", "To whom will this filter apply?", and "What type of web content should this filter look for?" It is good practice to include numerous common web content types in the same filter if you plan to use them later to control the same users at the same time.
1. Under the Management menu, select Filters.
2. You will see a default filter in a new account. Create a new filter by clicking Create a filter. Give your new filter a name. It is good practice to use a meaningful name in line with what the filter will achieve. For example, "IT Allowed Sites".
When creating a filter for identifying users' web requests, you can identify the web content in many ways. You can identify all of the contentthrough the various objects of the filter, all of which are listed down the left side of the filter.
Note that the logic between any objects in a filter is OR, meaning that it is enough that any of the objects is matched in order for the complete filter to be matched.
3. Click the various filter objects using the menu down the left side, starting with the Inbound Filters. Click Save after modifying a page, or click Save all settings at the end.
4. On the Categories page, select the categories that you wish to control with this filter. Note that you can also select a category named Uncategorized.
5. On the Domains/URLs page you can add a list of up to 1000 complete domains (for example, cnn.com) and specific URLs (for example, cnn.com/news).
6. On the same page, you have the option to add IP addresses or networks if you need to control them too.
7. Use the Content Types page to list any high-level content types that you want to control in this filter. Note that these types apply to a content type on requested webpages, and not to any outbound content that users post.
8. Use the File Types page to list any file types that you want to include in this filter. Note that these types apply to file types on requested webpages, and not to any outbound content that is posted by users.
9. Under Bi-directional Filters, click Applications. Here you can control access to web applications and their activities.
10. Expand the tree to the level required. Use the checkboxes on the left to control application access. You can control this access at the level of a single application or at a higher level for the complete group of applications.
11. Use the arrows on the right to open the Activities panel and then use the checkboxes in those panels to control Activities Here too you can control these activities at the level of a single application or at a higher level for the complete group of applications.
12. Above the list of applications is a window for typing in search phrases; for example, "video". The matching results will be filtered as you type. Note that after the applications are filtered, you should select the ones you want by checking the checkboxes, not by clicking Select All, because clicking Select All will select all applications, including the ones that are currently filtered from view.
13. Use the Exceptions window to list specific domains, URLs, IP addresses, and networks that should be excluded from the filter. Remember that anything listed here has higher priority than everything else in the filter.
14. In the Protocols window, you can select certain protocols to be included in this filter. The options available are HTTP, Secure HTTP (HTTPS), and FTP over HTTP. If nothing is selected, the filter will apply to all of these protocols.
15. In the User Agents window you can choose to control certain web browsers.
After you have created groups, schedules, and filters, you can create a rule for your policy.
1. Under the Management menu, select Policy. The policy will be shown again.
2. Click Create a rule at the top of the policy window.
3. Give your new rule a name. It is good practice to use a name that is meaningful, and in line with the filter that will be used in the rule; for example, "Warn Social Networking".
4. Select the action that this rule should apply when matched. The following actions can be applied to a rule:
• Block: The requested web content will be blocked.
• Allow: The requested web content will be allowed.
• Anonymize: Users' identities will be hidden in reports.
• Warn: A warning page will be presented to users for their compliance before the requested site is allowed.
• Authenticate: This action triggers an authentication process. It is typically not used when configuring an ASA to redirect to the cloud.
Note that when using the anonymize action, the subsequent rules in the policy are still applied, but the users' identities will be stripped from the following reporting attributes in all data entries:
• User: Reports will show undisclosed.
• Group: Reports will show undisclosed.
• Internal IP: Reports will show 0.0.0.0.
Groups in Rules
5. If the rule is to apply to everyone, then there is no need to add any users. If you have defined groups, you can add them to your rules if you want to have different rules applied to different groups of users.
6. Click Add group to open the group selection window.
7. Click the first letter of a group to view certain groups.
8. You can type in the search window and click Go to search for a specific string. If you click Go without typing anything, all groups will be displayed.
9. Select the required group and then click Confirm selection. The selected group will be added to the rule.
10. You can add numerous groups to a rule. Click Add group and repeat the previous steps as necessary. You can add only one group at a time.
Note: You can add a group as an exception. For example, the Sales group should not be able to access Facebook, but if there are any users in that group who are also managers, then they should be allowed. In this case, add the Sales group to the rule and add the Management group to the rule as an exception.
Note: You can add a mixture of custom groups and directory groups to a rule. In case of a conflict, the directory rule will have priority, unless you included the word scansafe in the name of the custom group , in which case the custom group will have priority.
Filters in Rules
11. From the list of filters, select any filters you have created and then click Add. You must add a filter to a rule.
Note: As mentioned previously, when creating a rule it is enough that any of the objects in the filter is matched in order for the complete filter to be matched. It is also possible to use a set of two filters in a rule that must both be matched in order for the filter to apply. In order to have two conditions matched in a filter (the logical AND operation), add two separate filters to the rule, each with its own objects. You cannot add more than two filters to the rule. Remember to click Add after selecting each filter.
Schedules in Rules
12. From the list of schedules, select any available schedules. If none are selected, then the rule will apply at all times.
13. You can add numerous schedules, and you can also set a schedule as an exception.
For example, a schedule for work hours is defined from 09:00 to 18:00 and another schedule for lunch is from 12:00 to 13:00. "Work hours" is added to the rule as a schedule and the lunch schedule is added as an exception. The rule will be active during work hours, but not during lunch time.
14. Use the Active checkbox to activate your rule now. You can activate your rule later from the policy.
15. Click Create rule at the bottom of the page to save your rule.
16. The policy page will be shown again and the new rule will be placed above the default rule. Use the up and down arrows to place the rule in the relevant priority in the policy, and click Apply changes to save the policy.
After you save changes in your policy, allow up to 5 minutes for the changes to come into effect, although it will usually happen within 1 or 2 minutes.
Note that any rules with the Anonymize action will be grouped together separately at the top of the policy.
Web Filtering Verification
1. In order to test your web filtering policy, open a web browser on a client machine that is behind the ASA, and try to browse to websites that should be blocked for all users, if relevant.
2. If you have set any rules with warn actions, try to browse to these websites and confirm that you receive the warning message, and that you can access the site after you agree by pressing Accept.
3. If you have any rules that apply to certain groups, check to ensure that they apply to the relevant users in the groups.
4. If you have any "Anonymizing" rules for certain users or for certain websites, perform some test browsing to ensure the correct policy applies. Later you can confirm in reports that the traffic was anonymized.
5. If you have any rules that should apply according to schedules, you can also test them.
Global Settings and Fine-Tuning of Web Filtering Policy
After you have defined your basic policy, you can expand it by adding additional rules and fine-tuning it to meet your requirements.
On the Web Filtering tab, click the Global Settings menu under Management to define some additional settings. As the name suggests, these settings, when configured, are global for all users at all times.
• SearchAhead: This option will add icons next to all search results made in Google, Bing, and Yahoo for all users, indicating to the users if the result will be allowed or blocked if clicked. Resulting websites will also be scanned for malware. As long as a user does not click a result, there will be no record of that user requesting to browse to this site (although the original search is recorded).
• Separate HTTPS Restrictions: When enabled, the list of categories in filters will be duplicated and there will be separate category lists for HTTP and HTTPS protocols that you can configure separately.
• Acceptable Usage Policy: This option is not supported for use when integrating with the ASA.
• Dynamic Classification Engine: This engine will attempt to dynamically classify any uncategorized traffic to one of the six top extreme sites as listed by this feature in ScanCenter.
On the Web Filtering tab, click the User Messages menu under Notifications to customize alert and warn pages that users will see when getting blocked and warned. You can view the default pages, and you can also customize them in HTML. You can include the following variables in customized alert pages:
In a similar way, you can also customize the block pages seen when users' requests are blocked because of malware (through the Web Virus tab) and spyware (through the Spyware tab).
On the Web Filtering tab, click the Email Alerts menu under Notifications to define email recipients who will receive email alerts when a page is blocked. You can define up to five email addresses (one of them could be a mailing list to reach a larger number of recipients). You can limit the number of email messages (1 to 20) per number of hours (1 to 24).
In a similar way, you can also define email message recipients who will receive email alerts when users' requests are blocked because of malware (through the Web Virus tab) and spyware (through the Spyware tab).
Basic User Reports in Cisco ScanCenter for User Traffic
You can run reports on browsing activity roughly 2 to 4 minutes after you have browsed. Perform the following basic steps for verification of reporting:
1. Click the reports tab in ScanCenter.
2. Ensure the Time period at the top is set to Last 24 hours, and the Auto Run Report checkbox is selected.
3. From the list of Predefined reports, expand the Host Analysis folder and click one of the listed reports to run it.
4. The report will run in the Search page and results will be displayed within a few seconds.
5. Scroll down and find the graphic output icons on the left below the results. Try clicking them to see the different ways the reports can be displayed.
6. Use the Reports menu at the top left side of the page and select Reports to take you back to the list of Predefined reports.
7. Try to run some additional reports from the Host Analysis, Group Analysis, and User Analysis folders, repeating the previous steps.
8. If you have integrated your ASA with an Active Directory Network, ensure that group names and usernames are included in reports.
9. If you have set any rules in your web filtering policy that apply the anonymize action, ensure that you can see results where the group and user attributes state Undisclosed, and the Internal IP attribute shows 0.0.0.0.