User Guide for ASA CX and Cisco Prime Security Manager 9.1
Use Cases for ASA CX
Downloads: This chapterpdf (PDF - 2.61MB) The complete bookPDF (PDF - 8.1MB) | The complete bookePub (ePub - 2.14MB) | Feedback

Use Cases for ASA CX

The following topics explain some common tasks you might want to accomplish with ASA CX.

How to Set Up ASA CX in Transparent Mode

Traditionally, a firewall is a routed hop and acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a “bump in the wire,” or a “stealth firewall,” and is not seen as a router hop to connected devices. Instead, the ASA connects the same network between its interfaces.

The following figure shows a typical example of a transparent firewall. You configure a bridge group interface to group the interfaces that are connected to the same network.

Figure 1. Transparent Firewall Network



Because the firewall is not a routed hop, you can easily introduce a transparent firewall into an existing network. When you configure the ASA to operate in transparent mode, the ASA CX automatically operates in transparent mode.

The following procedure shows a basic example of configuring an ASA in transparent mode. You configure the mode using the ASA CLI. For more extensive information on configuring transparent mode, see the chapter on transparent mode in any of the ASA configuration guides, for example, http:/​/​www.cisco.com/​en/​US/​docs/​security/​asa/​asa84/​configuration/​guide/​mode_​fw.html.

Before You Begin

This example assumes that you have already configured the ASA CX network settings as described in Setting Up the ASA CX Software. However, you can do the basic setup after completing this procedure.

Procedure
    Step 1   Log into the ASA CLI using the Console port.

    If you change the firewall mode while using an SSH client, you will be disconnected when the configuration is cleared, and you will have to reconnect to the ASA using the console port in any case.

    Step 2   Enter configuration mode and set the firewall mode to transparent.

    Example:
    ciscoasa# conf t 
    ciscoasa(config)# firewall transparent 
    INFO: UC proxy will be limited to maximum of 2 sessions 
    by the UC Proxy license on the device
    
    
    Step 3   Configure the interfaces and the bridge group.

    Example:

    The following example shows how to create the inside and outside interfaces, add them to bridge group 1, and assign a management IP address to the bridge group. The example assumes there is no previous interface configuration and uses show commands to verify input.

    ciscoasa(config)# int g0/0
    ciscoasa(config-if)# no shut
    ciscoasa(config-if)# nameif inside
    INFO: Security level for "inside" set to 100 by default.
    ciscoasa(config-if)# bridge-group 1
    ciscoasa(config-if)# int g0/1
    ciscoasa(config-if)# nameif outside
    INFO: Security level for "outside" set to 0 by default.
    ciscoasa(config-if)# no shut
    ciscoasa(config-if)# bridge-group 1
    ciscoasa(config-if)# int BVI1
    ciscoasa(config-if)# ip address 10.1.1.2 255.255.255.0
    ciscoasa(config-if)# sh run int g0/0
    !
    interface GigabitEthernet0/0
     nameif inside
     bridge-group 1
     security-level 100
    ciscoasa(config-if)# sh run int g0/1
    !
    interface GigabitEthernet0/1
     nameif outside
     bridge-group 1
     security-level 0
    ciscoasa(config-if)# sh run int BVI1
    !
    interface BVI1
     ip address 10.1.1.2 255.255.255.0 
    ciscoasa(config-if)# exit
    ciscoasa(config)#
    
    
    Step 4   Configure the traffic redirection policy.

    Example:

    The following example shows how to redirect all traffic to the ASA CX with the authentication proxy enabled, which supports active authentication policies. If the ASA CX is unavailable for any reason, traffic continues to pass through the ASA based on ASA security policies (fail-open).

    asa(config)# policy-map global_policy
    asa(config-pmap)# class class-default
    asa(config-pmap-c)# cxsc fail-open auth-proxy
    asa(config-pmap-c)# exit
    asa(config-pmap)# exit
    asa(config)#
    
    
    Step 5   If the policy map is not already an active service policy, you need to enable it using the service-policy command.

    If necessary, remove an existing service policy using the no form of the command. For example, the following commands remove a user-defined global policy and replace it with the default global policy.



    Example:
    asa(config)# no service-policy existing_global_policy global 
    asa(config)# service-policy global_policy global 
    asa(config)#
    
    
    Step 6   Enter write memory to save the changes to the running configuration.

    What to Do Next

    You can now configure ASA CX security policies and monitor traffic using the ASA CX web interface.

    Managing High Availability

    Cisco High Availability (HA) enables network-wide protection by providing fast recovery from faults that may occur in any part of the network. With Cisco High Availability, network hardware and software work together and enable rapid recovery from disruptions to ensure fault transparency to users and network applications.

    Configuring high availability on ASA CX devices requires two identical units connected to each other through a dedicated failover link, with one active unit passing traffic while the other unit waits in a standby state. The health of the active unit and its interfaces is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs and the standby unit begins processing traffic.

    The following conditions must be met in order to configure two ASA CX devices for high availability:

    • Both units must be the same model, have the same number and types of interfaces, and the same amount of RAM installed.
    • Both units must be operating in the same mode (routed or transparent, single or multiple context). They must have the same major (first number) and minor (second number) software version.
    • Each ASA CX must have the proper licenses.

    Please note the following ASA CX failover caveats:

    Scenario

    Solution with caveats

    Stateful Failover

    No stateful failover of transactions going through CX-1:

    • In-progress sessions will be processed by the ASA-2 correctly (they are not sent to CX-2).
    • New sessions are sent to the CX-2.

    Events

    Events are shown from both systems, but they are not aggregated.

    CX User Authentication

    CX user authentication does not fail over for in-progress transactions.

    Decryption

    For decrypted traffic, the user must clear the browser cache and reload the page.

    You can use Cisco Prime Security Manager (PRSM) to manage and monitor pairs of ASA CX devices operating in Active/Standby failover mode. Follow these steps to ensure a device pair is configured correctly for failover, and available for monitoring in PRSM:

    Procedure
      Step 1   Use the Adaptive Security Device Manager (ASDM) or the command-line interface (CLI) to configure the pair of ASA CX devices for Active/Standby failover, ensuring HTTP Replication is enabled.

      Using ASDM to configure the two devices is described in http:/​/​www.cisco.com/​en/​US/​docs/​security/​asa/​asa90/​asdm70/​configuration_guide/​ha_​active_​standby.html.

      Using the CLI to configure the two devices is described in http:/​/​www.cisco.com/​en/​US/​docs/​security/​asa/​asa90/​configuration/​guide/​ha_​active_​standby.html.

      Important:

      During failover configuration be sure to enable HTTP Replication. This allows HTTP connections to be included in the state information replication between devices, which in turn allows users to browse, stream and download files freely without interruption during a failover.

      To enable HTTP Replication on the active device using ASDM, navigate to the Configuration > Device Management > Failover > Setup tab, check the Enable HTTP Replication box, and then click Apply.

      To enable HTTP Replication on the active device using the CLI, enter the failover replication http command in global configuration mode.

      Step 2   One at a time, discover the pair with PRSM:

      Start withe the primary device. When you add the primary unit to the inventory, it will fail because the CX services are restarted. Wait for the services to come back up, and then use ASDM or the CLI to manually make the unit active again.

      Add the secondary device to the PRSM inventory.

      For information about discovering devices in PRSM, see Understanding Device Discovery and Managing the Device Inventory.

      Step 3   To ensure configuration and policy synchronization, make both devices members of the same PRSM device group.

      You can either create a new device group and assign the Active/Standby pair to it, or you can simply assign the secondary device to the primary device group. See Assigning Devices to Device Groups for more information.


      How to Gain Insight Into Your Network Traffic

      Before you start implementing policies on ASA CX, you might find it beneficial to gain insight into the traffic that is actually occurring on your network. You can set up ASA CX to process all of your traffic without prohibiting any traffic. By leaving your existing firewall rules on the ASA intact, you will be able to use the monitoring capabilities of the ASA CX to analyze network traffic without reducing your current level of security.

      ASA CX reporting helps you answer the following questions:
      • What is my network being used for?
      • Who is using the network the most?
      • Where are my users going?
      • What devices are they using?
      • What policies are being hit the most?
      The implicit access policy behavior for ASA CX is to allow all traffic. You can use this policy, which is named “Implicit Allow” in dashboards, but you might want to create an explicit allow all traffic policy. Although this rule is sufficient for providing a good amount of traffic analysis data, you need additional policies to provide more data:
      • You need an identity policy to get user-based information in the dashboards.
      • You need a decryption policy to gain insight into TLS/SSL (for example, HTTPS) traffic.

      The following procedure explains how to set up the ASA CX to monitor traffic and provides an overview of the end-to-end process of configuring and monitoring policies.

      Procedure
        Step 1   Redirect all traffic from the ASA to the ASA CX.

        When defining the redirection policy, do not limit the policy to specific interfaces or ports. Instead, simply send all traffic to ASA CX, so that dashboards will reflect all traffic. Note that if traffic is dropped at the incoming interface by ASA access rules, that traffic will not be sent to ASA CX.

        For detailed information on redirecting traffic, see Configuring the ASA to Send Traffic to the ASA CX SSP.

        Step 2   (Optional)Configure an explicit Allow All Traffic access policy.
        1. Select Policies > Policies.
        2. Mouse over the access policy set and click Add New Policy.
        3. In the access policy properties, enter a name for the policy, such as “Allow All Traffic,” keep the default “Any” for all traffic matching fields, and click Save Policy.

          The policy list will now show your new policy. The clock icon indicates that this is a pending change; the policy is not active until you commit changes.

        Step 3   (Optional)To gain insight into user behavior, you need to configure an identity policy to ensure that the user associated with a traffic flow is identified.
        You have two non-exclusive options for obtaining user information:
        • Use active authentication, which can transparently authenticate using NTLM or Kerberos or prompt users to respond to an authentication prompt when they make a network connection through the ASA CX. The benefit of active authentication is that you obtain user identity. However, users are authenticated only when they make their first HTTP connection attempt after logging into the network. Thus, there can be delay between login and having user identity for the user’s traffic, which can affect the value of identity-based policies.
        • Set up a Context Directory Agent (CDA) or Active Directory (AD) agent to passively obtain user-to-IP address mappings based on AD login. The benefit of using CDA or AD agent is that user identity is obtained at user login, so your identity-based policies can apply to the user before the user makes an HTTP connection.

        The following procedure explains how to use active authentication. You will need to create a directory realm, add directories to the realm, and then configure the identity policy.

        1. Select Device > Directory Realm.
        2. Select I Want To > Add Realm.
        3. In the Add Realm form, enter a name for the realm and select the directory type. If you select Active Directory, you also need to enter a primary domain name and username/password that can join the domain.

          For more detailed information, see Configuring Directory Realms. Click the Test Domain Join link to verify that you can join the device to the AD domain. The following illustration is an example of configuring an AD realm.

        4. Click Save to create the directory realm and return to the list of realms. If you are directly configuring an ASA CX (in Single Device mode), and this is your first realm, an identity policy for the realm is automatically created.
        5. Mouse over the realm you created and click Add New Directory.
        6. In the Add Directory form, enter the DNS name or IP address of the directory and the other attributes required to obtain user and group information from the directory.

          For detailed information on each field, see Directory Properties. Click the Test Connection link to verify the values you enter. The following illustration is an example of configuring an AD directory. Note the test result message next to the Save button.

        7. Click Save to add the directory to the realm.

          The following illustration shows the completed realm. Note the pending changes clock icon, which indicates you must commit the change before it becomes part of the active configuration.

        8. Select Policies > Policies.
        9. Do one of the following to configure the identity policy:
          • If an identity policy was automatically created when you added the realm, mouse over the policy and click Edit Policy.
          • Otherwise, mouse over the identity policy set and click Add New Policy.
        10. Select Get Identity via Active Authentication as the action and adjust the other policy settings as needed.

          If using AD, you can select the type of authentication to perform. Select Advanced to allow the device to negotiate the strongest method supported by your AD directory server and the client. You can also adjust the policy name and the source and destination if you do not want the policy to apply to all sources and destinations. For information on the other options, see Identity Policy Properties.

          The following illustration shows the action settings when configuring active authentication with a negotiated authentication method.

        11. Click Save Policy.
        Step 4   (Optional)To gain insight into HTTPS and other TLS/SSL traffic, you might want to enable decryption and define a decryption policy.

        By decrypting HTTPS traffic, you can gain insight into web destination, web category, and web reputation. If your decryption policy decision is to decrypt the traffic flow (after the initial analysis of the flow), you also gain insight into application and application type.

        Note   

        Proceed with caution when configuring decryption. Many sites, including most Financial sites, will not work with decryption. Thus, you might want to initially create a policy that decrypts low reputation traffic only, and gradually add more decryption policies as you gain experience with the product.

        1. Select Device > Decryption.
        2. Select Enable Decryption Policies: On.
        3. For Certificate Initialization Method, select whether to generate a new CA certificate or to import one you already have.

          This step is more complex than it looks, because you need to have a good understanding of decryption and certificate requirements. Before configuring the certificate, read Configuring the Decryption Certificate.

        4. Click Save.
        5. Select Policies > Policies.
        6. Mouse over the decryption policy set and select Add New Policy.
        7. Ensure that the policy has a meaningful name, adjust the source and destination if you do not want the policy to apply to all sources and destinations.

          If you want to ensure no traffic is actually decrypted, you can configure a URL object that specifies example.com as the destination. Because example.com is a reserved name, it should never apply to an actual destination server. Because traffic must be initially decrypted to determine whether the destination is matched, you will still collect valuable data from HTTPS traffic flows.

        8. Initially, you might want to select Decrypt Potentially Malicious Traffic to limit decryption to low-reputation traffic.

          Thus, even if a destination does not work with decryption, you are isolating access problems to low reputation sites that you probably do not want users accessing anyway. When you select this option, you also need to select a web reputation profile, which defines which reputation values are considered low. Initially, select the predefined Default Reputation Profile object, as shown in the following illustration.

        9. Click Save Policy.
        Step 5   Commit your changes.

        Policy changes are not immediately operational. You must explicitly commit them. This step ensures that you can make several closely-related changes without forcing you to operate the device in a partially-configured state.

        1. Click the Changes Pending link on the right side of the menu bar.
        2. Click Commit to commit the changes to the configuration database.
        Step 6   Use the dashboards and Event Viewer to analyze your traffic.
        You can view the following:
        • Overall network usage.
        • Top users, applications, destinations, policies hit.
        • Local vs. remote (VPN) traffic, top device types.
        • Threat information.
        • Device health and performance.

        You can also drill down detailed information, or link to events in the Event Viewer. In Event Viewer, you can view events as they happen in real time or view events that occurred in a specific time period.


        What to Do Next

        As you identify undesirable activity, you can create new policies or modify existing ones to implement your acceptable use policies:
        • Use access policies to control the use of applications and web sites.
        • Use access policies to selectively drop traffic to low reputation web sites.
        • Use access policies to selectively prevent file uploads or downloads.
        • Use decryption policies to decrypt traffic flows or to explicitly bypass decryption for TLS/SSL traffic that is safe and allowable. For example, you could create a rule that does not decrypt traffic to sites in the Finance web category. Decryption can give you additional insight into encrypted traffic, such as application behaviors and more precise threat analysis.
        • Adjust identity policies if you do not want to require everyone to actively authenticate. For example, if you use Active Directory, you could set up a CDA or AD agent and obtain user information passively.

        How to Control Application Usage

        The Web has become the ubiquitous platform for application delivery in the enterprise, whether that is browser based application platforms like Salesforce.com and Google Apps, or rich media applications like Cisco WebEx using web protocols as a widely available transport in and out of enterprise networks.

        ASA CX includes the Application Visibility and Control engine (AVC engine), which let’s you apply deeper controls to particular application types. The AVC engine inspects web traffic to gain deeper understanding and control of the traffic used for applications. Application control gives you more granular control over web traffic than just URL filtering, for example.

        The AVC engine allows you to create access policies to control application activity on the network without having to fully understand the underlying technology of each application.

        Application control gives you more control over the following types of applications:
        • Evasive applications, such as anonymizers and encrypted tunnels.
        • Collaboration applications, such as Cisco Webex and instant messaging.
        • Resource intensive applications, such as streaming media.

        Using the AVC engine, you can block or allow applications by application type or by a particular application. You can also apply deeper controls to particular application types. For example, you can allow media traffic but disallow file uploads.

        The AVC engine can dynamically receive updates from the Cisco update server, adding support for new applications or types.


        Note


        If an application uses an encrypted traffic flow (TLS/SSL), you might want to pair an access policy for the application with a decryption policy that will decrypt the traffic flow. Although some encrypted flows might be assigned an application, others will require decryption. Additionally, decryption might provide a more specific application assignment (for example, Facebook Games rather than just Facebook), and behaviors can be identified only with decryption. However, be aware that many applications do not work with decryption, so you might have to use URL filtering to control some TLS/SSL applications.


        The following example shows how to allow media applications, such as YouTube, yet block file uploads.

        Procedure
          Step 1   Select Policies > Policies.
          Step 2   Mouse over the access policy set and click Add New Policy.

          Alternatively, mouse over the policy above which you want to place the policy and click Add Above.

          Step 3   Enter a name for the policy and modify the source and destination fields if you want to limit the policy to specific networks. Leave source and destination as Any to create a policy for all uses of media applications on the network.

          Keep Allow as the action.

          Step 4   In the Application/Service field, select Media [Application Type].

          When you select an application or application type, if the applications contain any configurable behaviors, the behaviors appear beneath the Application field. For example, YouTube has Post and Upload behaviors. Behaviors provide granular control of activities available in an application, but not all applications have explicitly identifiable behaviors.

          In this example, because we are trying to block file uploads through media applications, select Deny as the action for the Upload behavior for all applications listed. Ignore the Set Global Behavior To check boxes; these simply reset all toggles to “allow” or “deny” for your convenience and are not part of the configured policy.

          Tip   

          Explore other application types to determine if there are additional upload behaviors that you would like to restrict.

          Step 5   Click Save Policy.
          Step 6   If necessary, move the policy to the appropriate location in the policy list.
          Step 7   Commit your changes.

          How to Use Passive Authentication

          To see user-based information in dashboards, or to implement user-based policies, the identity of the user associated with a traffic flow must be known. This requires that the user provide identification when connecting to the network.

          You have two options for obtaining user identification. You can use passive authentication, where the identity of the user is captured when the user logs into the network domain through Active Directory (AD), or you can actively prompt the user for authentication. If you are using OpenLDAP, active authentication is the only available method. The following table compares and contrasts these methods.

          Table 1 Comparing Passive and Active Authentication

          Passive Authentication

          Active Authentication

          A mapping between the user name and IP address of the user’s workstation is obtained during log in to the domain. The mapping is collected by the Cisco AD Agent, which sends the mapping to the ASA CX. Supports AD only.

          Supports basic authentication for LDAP and AD, and also NTLM and Kerberos for AD.

          Authentication occurs when the user attempts an HTTP connection only.

          Best-effort user identification, not real authentication.

          Real authentication.

          Useful for applications and clients that do not support active authentication.

          The client used to access the network must support active authentication, that is, it must be able to supply authentication information or prompt the user to supply it.

          Completely transparent to the user

          NTLM and Kerberos are usually transparent, while basic authentication shows a popup to the user to obtain username and password.

          The AD agent is required. AD agent is separate software that you must install and configure on a server in the network. It communicates with the AD server and with ASA CX.

          No agent is required.

          ASA CX uses the Cisco AD agent software to obtain passive authentication information for users in the network. When a user logs into Active Directory, the user’s IP address mapping is sent to the AD agent, which then communicates the mapping to ASA CX.

          User group membership is obtained directly from the AD or LDAP server; the ASA CX does not use the AD agent for this information.

          The following procedure explains how to set up the AD agent and configure it for use in ASA CX.

          Before You Begin
          • The AD agent software is separate from ASA CX. Download the AD agent application using this URL, or search for it on Cisco.com: http://www.cisco.com/cisco/software/release.html? mdfid=281191384&flowid=4378&softwareid=280775065 &release=AD_Agent&rellifecycle=&relind=AVAILABLE&reltype=all
          • For complete information about AD agent installation, configuration, and usage, see http:/​/​www.cisco.com/​en/​US/​docs/​security/​ibf/​setup_guide/​ad_​agent_​setup_​guide.html.
          • Configuring an AD agent is optional. Configure it only if you want to support passive mappings. Note that if you do not support passive mappings, you must force active authentication in your authentication rules or you will not have user names available for access control, and events and dashboards will not include user information.
          • Successful authentication is not required for network access. If the user fails to authenticate, whether passively or actively, it simply means that user identity is not available for traffic flows for the user.
          Procedure
            Step 1   Install and configure the AD agent according to the procedures explained in http:/​/​www.cisco.com/​en/​US/​docs/​security/​ibf/​setup_guide/​ibf10_​install.html.

            When you come to the client configuration, configure the ASA CX as the client (first, cd to IDF\CLI):

            adacfg client create -n ASA-CX-nickname -ip ASA-CX_mgmt_IP -secret RADIUS_secret
            where
            • ASA-CX-nickname is a name used by the AD agent to refer to the ASA CX client.
            • ASA-CX_mgmt_IP is either the IP address of the ASA CX management interface, or the subnet that contains the address, for example, 10.100.10.1 or 10.100.10.0/24.
            • RADIUS_secret is a RADIUS shared secret that you will also configure in ASA CX. This secret encrypts and protects communications between ASA CX and the AD agent.

            Tips:

            You might find the following AD agent commands useful for verifying or troubleshooting the configuration:
            • adacfg dc list, to verify the connection between the AD agent and AD server.
            • adacfg cache list, to verify that the agent is getting user-to-IP mappings.
            • adacfg client list, to list the clients currently served by the AD agent.
            Step 2   In PRSM (Single Device mode or Multiple Device mode ), identify the AD agent:
            1. Select Device > AD Agent.
            2. Enter the DNS host name or IP address of the AD agent.
            3. For Password, enter the RADIUS shared secret.
            4. Click Save.
            Step 3   If you have not created an AD realm, create a directory realm to identify the AD servers from which the AD agent is collecting login information:
            1. Select Device > Directory Realm.
            2. Select I Want To > Add Realm.
            3. In the Add Realm form, enter a name for the realm, select Active Directory as the directory type and enter a primary domain name and username/password that can join the domain.

              Click the Test Domain Join link to verify that you can join the device to the AD domain. For more detailed information, see Configuring Directory Realms

            4. Click Save to create the directory realm and return to the list of realms. If you are directly configuring an ASA CX (in Single Device mode), and this is your first realm, an identity policy for the realm is automatically created.
            5. Mouse over the directory realm and click Add New Directory. Enter the information for the primary AD server and click Save.

              Repeat the process to add all of the AD servers for the domain. If necessary, rearrange them in priority order. For detailed information on the directory properties, see Directory Properties.

            Step 4   Select Policies > Policies and create or edit the identity policy for the realm to provide the desired service.

            To use the passive mappings obtained from AD agent, the identity policy for the AD realm must use the Get Identity Using AD Agent action.

            You can optionally enable active authentication if there is no passive mapping for a user’s IP address by selecting Yes for the active authentication question. Also select the desired authentication type. For more information, see Identity Policy Properties.

            Step 5   Click Save Policy.

            Keep in mind that identity policies are applied first-match, so if you include a rule with source = any and destination = any, that rule will prevent all subsequent rules from ever being matched. If necessary, move the policy to the desired location in the policy set.

            Step 6   Click the Changes Pending link in the menu bar to open the Uncommitted Changes page.
            Step 7   Click Commit to commit the changes to the configuration database.

            How to Create Access Policies that Apply to AD/LDAP User Groups

            You might want to create policies that grant different levels of access to different users. For example, you might have a contract with a partner that allows access to a partner site for specific employees only. If the partner cannot, or does not want to, control access at the server by creating accounts for the allowed users, you can block access at the firewall using a user-based access policy that specifies a group name defined in your directory server, such as Active Directory.

            The following procedure shows how to create a pair of access policies that controls access to a destination, allowing only those users who are members of a specific user group. The procedure assumes that:
            • You have already created a user group named ContractTeam in Active Directory.
            • You have defined a directory realm for your active directory servers in PRSM.
            • Your identity policies are set up to require or allow for active authentication. You can optionally use CDA or AD agent to acquire user identity.
            • The partner site is a web site. If the partner site is not a web site, use a network group object to specify the IP address instead of a URL object as shown in this example.
            Procedure
              Step 1   Select Policies > Policies.
              Step 2   Create a policy that blocks all access to the partner site.
              1. Mouse over the access policy set and click Add New Policy.

                Alternatively, mouse over the policy above which you want to place the policy and click Add Above.

              2. Enter a name for the policy.
              3. Select Policy Action: Deny.
              4. Keep Any as the traffic source.
              5. Click the Create New Object link beneath the Destination field to create a URL object that identifies the partner site.

                The Create Object form opens to the right of the policy properties.

              6. Enter a name for the object, for example, Partner A Site.
              7. Select URL Object for Object Type.
              8. Enter the DNS name of the partner site in the URL field, for example, contractAserver.example.com, in the URL field of the Include list.
              9. Click Save Object to save the object and add it to the destination field.
              10. Click Save Policy.

                The policy is added to the policy set. If the policy is not already positioned correctly, move it to the desired position.

              Step 3   Create a policy that allows access to the partner site to users who are members of a specific user group.
              1. Mouse over the deny policy you just created and click Add Above.
              2. Enter a name for the policy.
              3. Keep Policy Action: Allow.
              4. Click the Create New Object link beneath the Source field to create an identity object that identifies the user group.
              5. Enter a name for the object, for example, Partner A Contract Team.
              6. Select Identity for Object Type.
              7. Enter the user group name in the format Realm_Name\group_name, for example, Our AD Realm\ContractTeam, in the Groups field of the Include list. As you type, matching names defined in the directory appear in the drop-down list; select the group from the list as it becomes available.
              8. Click Save Object to save the object and add it to the source field.
              9. Select the URL object you created above in the Destination field.
              10. Click Save Policy.

                The policy is added to the policy set above your deny policy.

              Step 4   Commit your changes.

              Going forward, only users who are members of the group can connect to the partner site. Keep in mind that group members only can access the partner site, so a user must be identified to the network or the user will be denied entry. Thus, if a member of the group connects to your network, but is not required to have identity by your identity policies, the user will not match this policy and will not be able to get to the partner site.


              How to Implement an Acceptable Use Policy (URL Filtering)

              You might have an acceptable use policy for your network. Acceptable use policies differentiate between network activity that is appropriate in your organization and activity that is considered inappropriate. These policies are typically focused on Internet usage, and are geared towards maintaining productivity, avoiding legal liabilities (for example, maintaining a non-hostile workplace), and in general controlling web traffic.

              You can use URL filtering to define an acceptable use policy with access policies. You can filter on broad categories, such as Gambling, so that you do not need to identify every individual web site that should be blocked. Cisco’s URL database categorizes over 20 million web sites worldwide in over 60 languages, and is automatically updated every five minutes.

              The following procedure explains how to implement an acceptable use policy using URL filtering. For purposes of this example, we will block the Gambling, Games, and Pornography categories, and an unclassified site, badsite.example.com.

              You must have a Web Security Essentials license to use category-based URL filtering.

              Procedure
                Step 1   Select Policies > Policies.
                Step 2   Mouse over the access policy set and click Add New Policy.

                Alternatively, mouse over the policy above which you want to place the policy and click Add Above.

                Step 3   Enter a name for the policy, for example, Block Bad Sites.
                Step 4   Select Policy Action: Deny.
                Step 5   Keep Any as the traffic source.
                Step 6   Create the URL object that will define the destinations that users are not allowed to access:
                1. Click the Create New Object link beneath the Destination field to create a URL object that identifies the objectionable categories and sites.

                  The Create Object form opens to the right of the policy properties.

                2. Enter a name for the object, for example, Bad Sites.
                3. Select URL Object for Object Type.
                4. Enter the DNS name of the undesirable site in the Include: URL field, in this example, badsite.example.com.
                5. Select Gambling in the Include: Web Category field.
                6. Select Games in the Include: Web Category field.
                7. Select Pornography in the Include: Web Category field.
                8. Click Save Object to save the object and add it to the destination field.
                Step 7   Click Save Policy.

                The policy is added to the policy set. If the policy is not already positioned correctly, move it to the desired position.

                Step 8   Commit your changes.

                Going forward, if you want to add other sites to your Bad Sites list, you merely need to add the site or category to the URL object; you do not need to create a new policy.


                How to Block Malware Using Web Reputation

                Users are continually at risk of obtaining malware from Internet sites. Even trusted sites can be hijacked to serve malware to unsuspecting users. As illustrated below, web pages can contain objects coming from different sources. These objects can include images, executables, Javascript, advertisements, and so forth. Compromised web sites often incorporate objects hosted on external sources. Real security means looking at each object individually, not just the initial request.

                The Cisco Threat Operations Center uses dynamic updates and actionable intelligence obtained from ASAs, IPSs, Email security appliances, web security appliances, and system administrators to calculate a web reputation score for web sites. Web reputation is a statistical assessment based on context and past behavior and combines many factors of varying significance into one correlated metric. Similar to a person’s credit score, web reputation is a continuous value along a graduated scale from -10 to 10. By defining a low reputation zone, you can implement predictive, zero-day protection against low reputation sites, the ones that are most likely to serve malware to your users.

                Following is a general guideline to the web reputation scores:

                -10 to -6

                Sites in the lowest reputation zone are dedicated or hijacked sites that persistently distribute key loggers, root-kits, and other malware. Also included are phishing sites, bots, and drive-by installers. Sites in this reputation range are almost guaranteed to be malicious.

                The pre-defined default web reputation profile defines this zone as the low reputation zone.

                -6 to -3

                Sites in this zone tend to be aggressive ad syndication and user tracking networks. These sites are suspected of being malicious, but maliciousness has not been confirmed.

                -3 to 3

                Sites in this zone tend to be well managed, responsible content syndication networks and user generated content sites.

                0 to 5

                Sites in this zone have some history of responsible behavior or third party validation.

                5 to 10

                Sites in this zone have a long history of responsible behavior, have significant traffic volume, and are widely accessed.


                Tip


                To look up the reputation of a site, you can use the tool at http:/​/​www.senderbase.org/​home.


                To implement reputation-based processing, you apply a web reputation profile to the following types of policy:
                • Access policies that allow traffic. By adding a web reputation profile, the policy will in general allow matching traffic, but drop any traffic from a low reputation site. You can apply the profile to any or all access policies that have the Allow action.
                • Decryption policies whose action is Decrypt Potentially Malicious Traffic. By adding a web reputation profile, any low reputation sites that match the policy will be decrypted, so that access policies have knowledge of the content of the traffic. The access policies can then drop the traffic if configured to do so. Even if you do not have a matching access policy that drops the traffic, decrypting the low reputation traffic provides data for reports that is otherwise unavailable for encrypted TLS/SSL traffic flows.

                The following procedure shows how to implement reputation-based processing to drop or decrypt traffic flows for sites in the -10 to -6 zone. This example assumes that you have defined your access policies, that you have enabled decryption, and that you have some decryption policies that use the Do Not Decrypt action (or that you would like to reduce the amount of traffic that you decrypt).

                Procedure
                  Step 1   Select Policies > Policies.
                  Step 2   Add the web reputation profile to the desired access policies.
                  1. Mouse over the “Allow” access policy that you want to modify and click Edit Policy.
                  2. In the Profile section, select Default Reputation Profile in the Web Reputation field.

                    If you want to define a different low reputation range, click the Create New Profile link and create your own web reputation profile. Name your object and simply move the slider to the top of your low reputation range, then click Save Object.

                  3. Click Save Policy.

                    Repeat the process for all access policies you want to modify.

                  Step 3   Add the web reputation profile to the desired decryption policies.

                  You can configure a web reputation profile only if you use the Decrypt Potentially Malicious Traffic action, in which case specifying a profile is required. Thus, to add a profile, you must also change the action, which might mean you need to create new policies. Consider adding the profile to policies that use the Do Not Decrypt action, or to Decrypt Everything policies if you want to back off the blanket decryption requirement.

                  1. Mouse over the decryption policy that you want to modify and click Edit Policy.
                  2. In the Action section, change the action to Decrypt Potentially Malicious Traffic.
                  3. Select Default Reputation Profile or another profile of your choosing in the Web Reputation field.
                  4. Click Save Policy.

                    Repeat the process for all decryption policies you want to modify. Add new policies as needed.

                  Step 4   Commit your changes.

                  How to Monitor and Control AnyConnect Secure Mobility Devices

                  If you configure remote access VPN on the parent ASA, ASA CX can use information about the remote VPN users who connect with the AnyConnect Secure Mobility client. Information about the clients are available in various dashboards, and you can also configure access and decryption policies that are based on location and client type. If you configure identity policies to collect user identity information, user information is also available in dashboards and for access and decryption control.

                  You can implement controls on the following types of remote access VPN client:
                  • Cisco IPSec VPN Client—IKEv1/IPSec connections.
                  • Cisco AnyConnect Secure Mobility Client version 2.5+—SSL VPN and IKEv2/IPSec connections.

                  Note


                  Clientless (browser-based) SSL VPN is not supported. You will not be able to apply Secure Mobility policies to these types of connections. However, they will be subject to your other access and decryption policies. Site-to-site VPN traffic is also not considered as matching Secure Mobility objects.


                  The following procedure summarizes what you need to do to use the AnyConnect Secure Mobility features of the ASA CX.

                  Procedure
                    Step 1   Install the AnyConnect Secure Mobility client on client devices.
                    There are AnyConnect clients for a wide range of devices. Review the following information for specific instructions:
                    Step 2   Configure the clients and the ASA to provide remote access VPN support.

                    Find specific instructions in the Cisco AnyConnect Secure Mobility Client Administrator Guide. You can find the guide for your AnyConnect version at:

                    http:/​/​www.cisco.com/​en/​US/​products/​ps10884/​products_​installation_​and_​configuration_​guides_​list.html

                    Step 3   Select Dashboard > User Devices to view information on Secure Mobility clients.

                    You can also see information on Secure Mobility clients in the Top Sources dashboard on the network overview, Dashboard > Network Overview.

                    Step 4   (Optional)Create access or decryption policies to selectively control Secure Mobility traffic.

                    For example, you might want to limit the bandwidth used by Secure Mobility clients by denying access to bandwidth-intensive applications. The following steps show an example of denying high-bandwidth applications for all remote users.

                    1. Select Policies > Policies.
                    2. Mouse over the access policy set and select Add New Policy.

                      Alternatively, find the policy above which you want to insert the new policy, mouse over it and click Add Above.

                    3. In the Create Policy form:
                      • Enter a name for the policy, for example, Control Secure Mobility Bandwidth.
                      • Select Policy Action: Deny.
                      • In the Source field, select the All Remote Devices Secure Mobility object.
                      • In the Destination field, keep the default, Any.
                      • In the Application/Service field, select the applications, application types, or objects that identify the services you want to deny. For example, YouTube, Facebook Photos, iTunes iPad, or perhaps the File Sharing application type, which covers many different applications with one selection.
                        Note   

                        Watch out for unintended consequences. For example, YouTube hosts a wide range of videos, including those used for educational purposes. Excluding an entire application could prevent network usage that might be required by your organization for remote access users, even though other uses of the application might not be appropriate for your network.

                    4. Click Save Policy.

                      If you did not insert the policy in the desired location, move it.

                    5. Commit and deploy your changes.