Access Control

The following topics explain access control rules. These rules control which traffic is allowed to pass through the device, and apply advanced services to the traffic, such as intrusion inspection.

Access Control Overview

The following topics explain access control policies.

Access Control Rules and the Default Action

Use the access control policy to allow or block access to network resources. The policy consists of a set of ordered rules, which are evaluated from top to bottom. The rule applied to traffic is the first one where all the traffic criteria are matched.

You can control access based on:

  • Traditional network characteristics such as source and destination IP addresses, protocol, ports, and interfaces (in the form of security zones).

  • The fully-qualified domain name (FQDN) of the source or destination (in the form of a network object). Traffic matching is based on the IP address returned for the name from a DNS lookup.

  • The application that is being used. You can control access based on the specific application, or you can create rules that cover categories of applications, applications tagged with a particular characteristic, the type of application (client, server, web), or the application's risk or business relevance rating.

  • The destination URL of a web request, including the generalized category of the URL. You can refine category matches based on the public reputation of the target site.

  • The user who is making the request, or the user groups to which the user belongs.

For unencrypted traffic that you allow, you can apply IPS inspection to check for threats and block traffic that appears to be an attack. You can also use file policies to check for prohibited files or malware.

Any traffic that does not match an access rule is handled by the access control Default Action. If you allow traffic by default, you can apply intrusion inspection to the traffic. However, you cannot perform file or malware inspection on traffic handled by the default action.

Application Filtering

You can use access control rules to filter traffic based on the application used in the connection. The system can recognize a wide variety of applications, so that you do not need to figure out how to block one web application without blocking all web applications.

For some popular applications, you can filter on different aspects of the application. For example, you could create a rule that blocks Facebook Games without blocking all of Facebook.

You can also create rules based on general application characteristics, blocking or allowing entire groups of applications by selecting risk or business relevance, type, category, or tag. However, as you select categories in an application filter, look over the list of matching applications to ensure you are not including unintended applications. For a detailed explanation of the possible groupings, see Application Criteria.

Application Control for Encrypted and Decrypted Traffic

If an application uses encryption, the system might not be able to identify the application.

The system can detect application traffic encrypted with StartTLS, including SMTPS, POPS, FTPS, TelnetS, and IMAPS. In addition, it can identify certain encrypted applications based on the Server Name Indication in the TLS ClientHello message, or the subject distinguished name value from the server certificate.

Use the application filters dialog box to determine if your application requires decryption by selecting the following Tags, then examining the list of applications.

  • SSL Protocol—You do not need to decrypt traffic tagged as SSL Protocol. The system can recognize this traffic and apply your access control action. Access control rules for the listed applications should match to expected connections.

  • Decrypted Traffic—The system can recognize this traffic only if you first decrypt the traffic. Configure SSL decryption rules for this traffic.

Filtering on Common Industrial Protocol (CIP) and Modbus Applications (ISA 3000)

You can enable the Common Industrial Protocl (CIP) and Modbus pre-processors on Cisco ISA 3000 devices, and filter on CIP and Modbus applications in access control rules. All CIP application names start with “CIP,” such as CIP Write. There is only one application for Modbus.

To enable the pre-processors, you must go into expert mode in a CLI session (SSH or Console) and issue the following command to enable one or both of these Supervisory Control and Data Acquisition (SCADA) applications.

sudo /usr/local/sf/bin/enable_scada.sh {cip | modbus | both}

For example, to enable both pre-processors:


> expert 
admin@firepower:~$ sudo /usr/local/sf/bin/enable_scada.sh both

Note

You must issue this command after every deployment. These pre-processors are disabled during deployment.

Best Practices for Application Filtering

Please keep the following recommendations in mind when designing your application filtering access control rules.

  • To handle traffic referred by a web server, such as advertisement traffic, match the referred application rather than the referring application.

  • Avoid combining application and URL criteria in the same rule, especially for encrypted traffic.

  • If you write a rule for traffic that is tagged Decrypted Traffic, ensure that you have an SSL Decryption rule that will decrypt the matching traffic. These applications can be identified in decrypted connections only.

  • The system can detect multiple types of Skype application traffic. To control Skype traffic, choose the Skype tag from the Application Filters list rather than selecting individual applications. This ensures that the system can detect and control all Skype traffic the same way.

  • To control access to Zoho mail, select both the Zoho and Zoho Mail applications.

URL Filtering

You can use access control rules to filter traffic based on the URL used in an HTTP or HTTPS connection. Note that URL filtering for HTTP is more straight-forward than it is for HTTPS, because HTTPS is encrypted.

You can use the following techniques to implement URL filtering.

  • Category and reputation-based URL filtering—With a URL filtering license, you can control access to web sites based on the URL’s general classification (category) and risk level (reputation). This is by far the easiest and most effective way to block unwanted sites.

  • Manual URL filtering—With any license, you can manually specify individual URLs, and groups of URLs, to achieve granular, custom control over web traffic. The main purpose of manual filtering is to create exceptions to category-based block rules, but you can use manual rules for other purposes.

The following topics provide more information on URL filtering.

Filtering URLs by Category and Reputation

With a URL filtering license, you can control access to web sites based on the category and reputation of the requested URLs:

  • Category—A general classification for the URL. For example, ebay.com belongs to the Auctions category, and monster.com belongs to the Job Search category. A URL can belong to more than one category.

  • Reputation—How likely the URL is to be used for purposes that might be against your organization’s security policy. Reputations range from Untrusted (level 1) to Trusted (level 5).

URL categories and reputations help you quickly configure URL filtering. For example, you can use access control to block untrusted URLs in the Illegal Drugs category.

For a description of the categories, see https://www.talosintelligence.com/categories.

Using category and reputation data also simplifies policy creation and administration. Sites that represent security threats, or that serve undesirable content, might appear and disappear faster than you can update and deploy new policies. As Cisco updates the URL database with new sites, changed classifications, and changed reputations, your rules automatically adjust to the new information. You do not need to edit your rules to account for new sites.

If you enable regular URL database updates, you can ensure that the system uses up-to-date information for URL filtering. You can also enable communications with Cisco Collective Security Intelligence (CSI) to obtain the latest threat intelligence for URLs with unknown category and reputation. For more information, see Configuring URL Filtering Preferences.


Note

To see URL category and reputation information in events and application details, you must create at least one rule with a URL condition.

Looking Up the Category and Reputation for a URL

You can check on the category and reputation for a particular URL. You can go to the URL tab of an access control rule, or SSL decryption rule, or go to Device > System Settings > URL Filtering Preferences. There, you can enter the URL in the URL to Check field and click Go.

You will be taken to a web site that shows the results of the lookup. You can use this information to help you check the behavior of your category- and reputation-based URL filtering rules.

If you disagree with the categorization, you can click the Submit a URL Category Dispute in the FDM to tell us what you think.

Manual URL Filtering

You can supplement or selectively override category and reputation-based URL filtering by manually filtering individual URLs or groups of URLs. You can perform this type of URL filtering without a special license.

For example, you might use access control to block a category of web sites that are not appropriate for your organization. However, if the category contains a web site that is appropriate, and to which you want to provide access, you can create a manual Allow rule for that site and place it before the Block rule for the category.

To configure manual URL filtering, you create a URL object with the destination URL. How this URL is interpreted is based on the following rules:

  • If you do not include a path (that is, there is no / character in the URL), the match is based on the server’s hostname only. The hostname is considered a match if it comes after the :// separator, or after any dot in the hostname. For example, ign.com matches ign.com and www.ign.com, but it does not match verisign.com.

  • If you include one or more / character, the entire URL string is used for a substring match, including the server name, path, and any query parameters. However, we recommend that you do not use manual URL filtering to block or allow individual web pages or parts of sites, as servers can be reorganized and pages moved to new paths. Substring matching can also lead to unexpected matches, where the string you include in the URL object also matches paths on unintended servers or strings within query parameters.

  • The system disregards the encryption protocol (HTTP vs HTTPS). In other words, if you block a website, both HTTP and HTTPS traffic to that website is blocked, unless you use an application condition to target a specific protocol. When creating a URL object, you do not need to specify the protocol when creating an object. For example, use example.com rather than http://example.com.

  • If you plan to use a URL object to match HTTPS traffic in an access control rule, create the object using the subject common name in the public key certificate used to encrypt the traffic. Also, the system disregards subdomains within the subject common name, so do not include subdomain information. For example, use example.com rather than www.example.com.

    However, please understand that the subject common name in the certificate might be completely unrelated to a web site’s domain name. For example, the subject common name in the certificate for youtube.com is *.google.com (this of course might change at any time). You will get more consistent results if you use the SSL Decryption policy to decrypt HTTPS traffic so that URL filtering rules work on decrypted traffic.


    Note

    URL objects will not match HTTPS traffic if the browser resumes a TLS session because the certificate information is no longer available. Thus, even if you carefully configure the URL object, you might get inconsistent results for HTTPS connections.

Filtering HTTPS Traffic

Because HTTPS traffic is encrypted, performing URL filtering directly on HTTPS traffic is not as straight-forward as it is on HTTP traffic. For that reason, you should consider using SSL Decryption policies to decrypt all HTTPS traffic that you intend to filter. That way, the URL filtering access control policies work on decrypted traffic, and you get the same results you would get for regular HTTP traffic.

However, if you do intend to allow some HTTPS traffic to pass undecrypted into the access control policy, you need to understand that rules match HTTPS traffic differently than they do for HTTP traffic. To filter encrypted traffic, the system determines the requested URL based on information passed during the SSL handshake: the subject common name in the public key certificate used to encrypt the traffic. There might be little or no relationship between the web site hostname in the URL and the subject common name.

HTTPS filtering, unlike HTTP filtering, disregards subdomains within the subject common name. Do not include subdomain information when manually filtering HTTPS URLs. For example, use example.com rather than www.example.com. Also, review the content of the certificates used by the site to ensure you have the right domain, the one used in the subject common name, and that this name will not conflict with your other rules (for example, the name for a site you want to block might overlap with one you want to allow). For example, the subject common name in the certificate for youtube.com is *.google.com (this of course might change at any time).


Note

URL objects will not match HTTPS traffic if the browser resumes a TLS session because the certificate information is no longer available. Thus, even if you carefully configure the URL object, you might get inconsistent results for HTTPS connections.

Controlling Traffic by Encryption Protocol

The system disregards the encryption protocol (HTTP vs HTTPS) when performing URL filtering. This occurs for both manual and reputation-based URL conditions. In other words, URL filtering treats traffic to the following web sites identically:

  • http://example.com

  • https://example.com

To configure a rule that matches only HTTP or HTTPS traffic, but not both, either specify the TCP port in the Destination condition or add an application condition to the rule. For example, you could allow HTTPS access to a site while disallowing HTTP access by constructing two access control rules, each with an TCP port or application, and URL, condition.

The first rule allows HTTPS traffic to the website:

  • Action: Allow
  • TCP port or Application: HTTPS (TCP port 443)
  • URL: example.com

The second rule blocks HTTP access to the same website:

  • Action: Block
  • TCP port or Application: HTTP (TCP port 80)
  • URL: example.com

Comparing URL and Application Filtering

URL and application filtering have similarities. But you should use them for very distinct purposes:

  • URL filtering is best used to block or allow access to an entire web server. For example, if you do not want to allow any type of gambling on your network, you can create a URL filtering rule to block the Gambling category. With this rule, users cannot get to any pages on any web server within the category.

  • Application filtering is useful for blocking specific applications regardless of the hosting site, or for blocking specific features of an otherwise allowable web site. For example, you could block just the Facebook Games application without blocking all of Facebook.

Because combining application and URL criteria can lead to unexpected results, especially for encrypted traffic, it is a good policy to create separate rules for URL and application criteria. If you do need to combine application and URL criteria in a single rule, you should place these rules after straight-forward application-only or URL-only rules, unless the application+URL rule is acting as an exception to a more general application-only or URL-only rule. Because URL filtering block rules are more broad than application filtering, you should place them above application-only rules.

If you do combine application and URL criteria, you might need to monitor your network more carefully to ensure that you are not allowing access to unwanted sites and applications.

Best Practices for Effective URL Filtering

Please keep the following recommendations in mind when designing your URL filtering access control rules.

  • Use category and reputation blocking whenever possible. This ensures that new sites get blocked automatically as they are added to the categories, and that blocking based on reputation is adjusted if a site becomes more (or less) reputable.

  • When using URL category matching, note that there are cases where the login page for a site is in a different category than the site itself. For example, Gmail is in the Web-based Email category, whereas the login page is in the Search Engines and Portals category. If you have different rules with different actions for the categories, you might get unintended results.

  • Use URL objects to target entire web sites and to make exceptions to category blocking rules. That is, to allow specific sites that would otherwise get blocked in a category rule.

  • If you want to manually block a web server (using a URL object), it is much more effective to do so in the Security Intelligence policy. The Security Intelligence policy drops connections before the access control rules are evaluated, so you get a faster, more efficient, block.

  • For the most effective filtering of HTTPS connections, implement SSL decryption rules to decrypt traffic for which you are writing an access control rule. Any decrypted HTTPS connections are filtered as HTTP connections in the access control policy, so you avoid all of the limitations for HTTPS filtering.

  • Place URL blocking rules before any application filtering rules, because URL filtering blocks entire web servers, whereas application filtering targets specific application usage regardless of the web server.

  • If you want to block high risk sites whose category is unknown, select the Uncategorized category and adjust the reputation slider to Questionable or Untrusted.

What the User Sees When You Block Web Sites

When you block web sites with URL filtering rules, what the user sees differs based on whether the site is encrypted.

  • HTTP connections—The user sees a system default block response page instead of the normal browser page for timed out or reset connections. This page should make it clear that you blocked the connection on purpose.

  • HTTPS (encrypted) connections—The user does not see the system default block response page. Instead, the user sees the browser’s default page for a secure connection failure. The error message does not indicate the site was blocked due to policy. Instead, errors might indicate that there are no common encryption algorithms. It will not be obvious from this message that you blocked the connection on purpose.

In addition, web sites might be blocked by other access control rules that are not explicitly URL filtering rules, or even by the default action. For example, if you block entire networks or geolocations, any web sites on that network or in that geographic location are also blocked. Users blocked by these rules may, or may not, get a response page as described in the limitations below.

If you implement URL filtering, consider explaining to end users what they might see when a site is intentionally blocked, and what types of site you are blocking. Otherwise, they might spend a good deal of time troubleshooting blocked connections.

Limitations of HTTP Response Pages

HTTP response pages do not always appear when the system blocks web traffic.

  • The system does not display a response page when web traffic is blocked as a result of a promoted access control rule (an early-placed blocking rule with only simple network conditions).

  • The system does not display a response page when web traffic is blocked before the system identifies the requested URL.

  • The system does not display a response page for encrypted connections blocked by access control rules.

Intrusion, File, and Malware Inspection

Intrusion and file policies work together as the last line of defense before traffic is allowed to its destination:

  • Intrusion policies govern the system's intrusion prevention capabilities.

  • File policies govern the system's file control and malware defense capabilities.

All other traffic handling occurs before network traffic is examined for intrusions, prohibited files, and malware. By associating an intrusion or file policy with an access control rule, you are telling the system that before it passes traffic that matches the access control rule's conditions, you first want to inspect the traffic with an intrusion policy, a file policy, or both.

You can configure intrusion and file policies on rules that allow traffic only. Inspection is not performed on rules set to trust or block traffic. In addition, if the default action for the access control policy is allow, you can configure an intrusion policy but not a file policy.

For any single connection handled by an access control rule, file inspection occurs before intrusion inspection. That is, the system does not inspect files blocked by a file policy for intrusions. Within file inspection, simple blocking by type takes precedence over malware inspection and blocking. Until a file is detected and blocked in a session, packets from the session may be subject to intrusion inspection.


Note

By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured. Inspection works with unencrypted traffic only.

Best Practices for Access Control Rule Order

Rules are applied on a first-match basis, so you must ensure that rules with highly specific traffic matching criteria appear above policies that have more general criteria that would otherwise apply to the matching traffic. Consider the following recommendations:

  • Specific rules should come before general rules, especially when the specific rules are exceptions to general rules.

  • Any rules that drop traffic based on layer-3/4 criteria only (such as IP address, security zone, and port number) should come as early as possible. We recommend they come before any rule that requires inspection, such as those with application or URL criteria, because Layer-3/4 criteria can be evaluated quickly and without inspection. Of course, any exceptions to these rules must be placed above them.

  • Whenever possible, put specific drop rules near the top of the policy. This ensures the earliest possible decision on undesirable traffic.

  • Any rules that include both application and URL criteria should come after straight-forward application-only or URL-only rules, unless the application+URL rule is acting as an exception to a more general application-only or URL-only rule. Combining application and URL criteria can lead to unexpected results, especially for encrypted traffic, so we recommend that you create separate rules for URL and application filtering whenever possible.

NAT and Access Rules

Access rules always use the real IP addresses when determining an access rule match, even if you configure NAT. For example, if you configure NAT for an inside server, 10.1.1.5, so that it has a publicly routable IP address on the outside, 209.165.201.5, then the access rule to allow the outside traffic to access the inside server needs to reference the server’s real IP address (10.1.1.5), and not the mapped address (209.165.201.5).

How Other Security Policies Impact Access Control

Other security policies can affect how access control rules function and match connections. As you configure your access rules, keep the following in mind:

  • SSL Decryption policy—The SSL decryption rules are evaluated before access control. Thus, if an encrypted connection matches an SSL decryption rule that applies some type of decryption, it is the plain text (decrypted) connection that is evaluated by the access control policy. The access rules do not see the encrypted version of the connection. Additionally, any connections that match SSL decryption rules that drop traffic are never seen by the access control policy. Finally, any encrypted connection that matches a Do Not Decrypt rule is evaluated in its encrypted state.

  • Identity policy—Connections are matched to users (and thus, user groups) only if there is a user mapping for the source IP address. Access rules that key on user or group membership can match only those connections for which user identity was successfully collected by your identity policy.

  • Security Intelligence policy—Any connection that is dropped is never seen by the access control policy. Connections that match the do not block list are subsequently matched to access control rules and, ultimately, it is the access control rule that determines how the connection is handled (allowed or dropped).

  • VPN (site-to-site or remote access)—VPN traffic is always evaluated against the access control policy, and connections are allowed or dropped based on the matching rule. However, the VPN tunnel itself is decrypted before the access control policy is evaluated. The access control policy evaluates the connections that are embedded within the VPN tunnel, not the tunnel itself.

License Requirements for Access Control

You do not need a special license to use the access control policy.

However, you do need the following licenses for specific features within the access control policy. For information on configuring licenses, see Enabling or Disabling Optional Licenses.

  • URL license—To create rules that use URL categories and reputations as match criteria.

  • Threat license—To configure an intrusion policy on an access rule or the default action. You also need this license to use a file policy (the Malware license is also required).

  • Malware license—To configure a file policy on an access rule. The Threat is also required for file policies.

Guidelines and Limitations for Access Control Policies

Following are some additional limitations for access control. Please consider them when evaluating whether you are getting the expected results from your rules.

  • If a URL database update includes added (new, incoming), deprecated (outgoing), or deleted categories, there is a grace period for you to make changes to any access control rules that are affected. Impacted rules are marked with informational messages, with explanations about the issues that impact the rule and links to the Cisco Talos Intelligence Group (Talos) web site for more information about the category changes. You need to update the rule so that it uses the appropriate categories available in the latest URL database.

    To accommodate the grace period, add the newly added incoming categories to the appropriate rules without removing the outgoing deprecated categories: your rules should contain both the new and old categories. The new categories will be effective when the old categories are marked for deletion. When the old categories are finally deleted, you need to edit the rules to remove the deleted categories and redeploy the configuration. You will be blocked from deploying the configuration until you fix any rules that use deleted categories. Click the See Problem Rules link above the table to filter on rules that need attention.

  • FDM can download information on up to 50,000 users from the directory server. If your directory server includes more than 50,000 user accounts, you will not see all possible names when selecting users in an access rule or when viewing user-based dashboard information. You can write rules on only those names that were downloaded.

    The 50,000 limit also applies to the names associated with groups. If a group has more than 50,000 members, only the 50,000 names that were downloaded can be matched against the group membership.

  • If a Vulnerability Database (VDB) update removes (deprecates) applications, you must make changes to any access control rules or application filters that use the application that was deleted. You cannot deploy changes until you fix these rules. In addition, you cannot install system software updates before fixing the issue. On the Application Filters object page, or the Application tab of the rule, these applications say “(Deprecated)” after the application name.

  • To use fully-qualified domain name (FQDN) network objects as source or destination criteria, you must also configure DNS for the data interfaces on Device > System Settings > DNS Server. The system does not use the management DNS server setting to do lookups for FQDN objects used in access control rules. For information on troubleshooting FQDN resolution, see Troubleshooting General DNS Problems.

    Note that controlling access by FQDN is a best-effort mechanism. Consider the following points:

    • Because DNS replies can be spoofed, only use fully trusted internal DNS servers.

    • Some FQDNs, especially for very popular servers, can have multiple and frequently changing IP addresses. Because the system uses cached DNS lookup results, users might get new addresses that are not yet in the cache. Thus, it is possible that blocking a popular site by FQDN will provide inconsistent results.

    • For popular FQDNs, different DNS servers can return a different set of IP addresses. Thus, if your users use a different DNS server than the one you configure, FQDN-based access control rules might not apply to all IP addresses for the site that are used by your clients, and you will not get the intended results for your rules.

    • Some FQDN DNS entries have very short time to live (TTL) values. This can result in frequent recompliation of the lookup table, which can impact overall system performance.

  • If you edit a rule that is actively in use, the changes do not apply to established connections that are no longer being inspected by Snort. The new rule is used to match against future connections. In addition, if Snort is actively inspecting a connection, it can apply the changed matching or action criteria to an existing connection. If you need to ensure that your changes apply to all current connections, you can log into the device CLI and use the clear conn command to end established connections, on the assumption that the sources for the connections will then attempt to reestablish the connection and thus be matched appropriately against the new rule.

  • It takes 3 to 5 packets for the system to identify the application or URL in a connection. Thus, the correct access control rule might not be matched immediately for a given connection. However, once the application/URL is known, the connection is handled based on the matching rule. For encrypted connections, this happens after the server certificate exchange in the SSL handshake.

  • The system applies the default policy action to packets that do not have a payload in a connection where an application is identified.

  • Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. For example, the system can more efficiently match traffic for all interfaces if you simply leave the security zone criteria blank, rather than if you create zones that contain all interfaces. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.

  • If you specify IP addresses for source or destination criteria, do not mix IPv4 and IPv6 addresses in the same rule. Create separate rules for IPv4 and IPv6 addresses.

  • Due to memory limitations, some device models perform most URL filtering with a smaller, less granular, set of categories and reputations. For example, even if a parent URL's subsites have different URL categories and reputations, some devices may only store the parent URL's data. For web traffic handled by these devices, the system may perform cloud lookups to determine category and reputation for sites not in the local database. Lower-memory devices include the following ASA models: 5508-X, 5516-X, and 5525-X.

  • GRE tunnels that violate the related RFCs will be dropped. For example, if a GRE tunnel contains non-zero values in the reserved bits, contrary to the RFCs, it is dropped. If you need to allow non-compliant GRE tunnels, you need to use a remote manager and configure a prefilter rule that trusts the sessions. You cannot configure prefilter rules using the FDM.

Configuring the Access Control Policy

Use the access control policy to control access to network resources. The policy consists of a set of ordered rules, which are evaluated from top to bottom. The rule applied to traffic is the first one where all the traffic criteria are matched. If no rules match the traffic, the default action shown at the bottom of the page is applied.

To configure the access control policy, select Policies > Access Control.

The access control table lists all rules in order. For each rule:

  • Click the > button next to the rule number in the left-most column to open the rule diagram. The diagram can help you visualize how the rule controls traffic. Click the button again to close the diagram.

  • Most cells allow inline editing. For example, you can click the action to select a different one, or click a source network object to add or change the source criteria.

  • To move a rule, hover over the rule until you get the move icon (Move rule icon.), then click, drag, and drop the rule to the new location. You can also move a rule by editing it and selecting the new location in the Order list. It is critical that you put the rules in the order that you want them processed. Specific rules should be near the top, especially for rules that define exceptions to more general rules

  • The right-most column contains the action buttons for a rule; mouse over the cell to see the buttons. You can edit (edit icon) or delete (delete icon) a rule.

  • Click the Toggle Hit Counts icon (Toggle hit counts button.) above the table to add or remove the Hit Counts column in the table. The Hit Count column appears to the right of the Name column with the total hit count for the rule and the date and time of the last hit. The hit count information is fetched at the time you click the toggle button. Click the refresh icon (Refresh hit count button.) to get the latest information.

  • If any rules have problems, for example, because of removed or changed URL categories, click the See Problem Rules link next to the search box to filter the table to show only those rules. Please edit and correct (or delete) these rules, so that they will provide the service that you require.

The following topics explain how to configure the policy.

Configuring the Default Action

If a connection does not match a specific access rule, it is handled by the default action for the access control policy.

Procedure

Step 1

Select Policies > Access Control.

Step 2

Click anywhere in the Default Action field.

Step 3

Select the action to apply to matching traffic.

  • Trust—Allow traffic without further inspection of any kind.
  • Allow—Allow the traffic subject to the intrusion policy.
  • Block—Drop the traffic unconditionally. The traffic is not inspected.
Step 4

If the action is Allow, select an intrusion policy.

For an explanation of the policy options, see Intrusion Policy Settings.

Step 5

(Optional.) Configure logging for the default action.

You must enable logging for traffic that matches the default action to be included in dashboard data or Event Viewer. See Logging Settings.

Step 6

Click OK.

Configuring Access Control Rules

Use access control rules to control access to network resources. Rules in the access control policy are evaluated from top to bottom. The rule applied to traffic is the first one where all the traffic criteria are matched.

Procedure

Step 1

Select Policies > Access Control.

Step 2

Do any of the following:

  • To create a new rule, click the + button.
  • To edit an existing rule, click the edit icon (edit icon) for the rule.

To delete a rule you no longer need, click the delete icon (delete icon) for the rule.

Step 3

In Order, select where you want to insert the rule in the ordered list of rules.

Rules are applied on a first-match basis, so you must ensure that rules with highly specific traffic matching criteria appear above policies that have more general criteria that would otherwise apply to the matching traffic.

The default is to add the rule to the end of the list. If you want to change a rule's location later, edit this option.

Step 4

In Title, enter a name for the rule.

The name cannot contain spaces. You can use alphanumeric characters and these special characters: + . _ -

Step 5

Select the action to apply to matching traffic.

  • Trust—Allow traffic without further inspection of any kind.
  • Allow—Allow the traffic subject to the intrusion and other inspection settings in the policy.
  • Block—Drop the traffic unconditionally. The traffic is not inspected.
Step 6

Define the traffic matching criteria using any combination of the following tabs:

  • Source/Destination—The security zones (interfaces) through which the traffic passes, the IP addresses or the country or continent (geographical location) for the IP address, or the protocols and ports used in the traffic. The default is any zone, address, geographical location, protocol, and port. See Source/Destination Criteria.
  • Application—The application, or a filter that defines applications by type, category, tag, risk, or business relevance. The default is any application. See Application Criteria.
  • URL—The URL or URL category of a web request. The default is any URL. See URL Criteria.
  • Users—The identity source, user or user group. Your identity policies determine whether user and group information is available for traffic matching. You must configure identity policies to use this criteria. See User Criteria.

To modify a condition, you click the + button within that condition, select the desired object or element, and click OK in the popup dialog box. If the criterion requires an object, you can click Create New Object if the object you require does not exist. Click the x for an object or element to remove it from the policy.

When adding conditions to access control rules, consider the following tips:

  • You can configure multiple conditions per rule. Traffic must match all the conditions in the rule for the rule to apply to traffic. For example, you can use a single rule to perform URL filtering for specific hosts or networks.

  • For each condition in a rule, you can add up to 50 criteria. Traffic that matches any of a condition's criteria satisfies the condition. For example, you can use a single rule to apply application control for up to 50 applications or application filters. Thus, there is an OR relationship among the items in a single condition, but an AND relationship between condition types (for example, between source/destination and application).

  • Some features require that you enable the appropriate license.

Step 7

(Optional.) For policies that use the Allow action, you can configure further inspection on unencrypted traffic. Click one of the following links:

  • Intrusion Policy—Select Intrusion Policy > On and select the intrusion inspection policy to inspect traffic for intrusions and exploits. See Intrusion Policy Settings.
  • File Policy—Select the file policy to inspect traffic for files that contain malware and for files that should be blocked. See File Policy Settings.
Step 8

(Optional.) Configure logging for the rule.

By default, connection events are not generated for traffic that matches a rule, although file events are generated by default if you select a file policy. You can change this behavior. You must enable logging for traffic that matches the policy to be included in dashboard data or Event Viewer. See Logging Settings.

Intrusion events are always generated for intrusion rules set to drop or alert regardless of the logging configuration on the matching access rule.

Step 9

Click OK.

Source/Destination Criteria

The Source/Destination criteria of an access rule define the security zones (interfaces) through which the traffic passes, the IP addresses or the country or continent (geographical location) for the IP address, or the protocols and ports used in the traffic. The default is any zone, address, geographical location, protocol, and port.

To modify a condition, you click the + button within that condition, select the desired object or element, and click OK. If the criterion requires an object, you can click Create New Object if the object you require does not exist. Click the x for an object or element to remove it from the policy.

You can use the following criteria to identify the source and destination to match in the rule.

Source Zones, Destination Zones

The security zone objects that define the interfaces through which the traffic passes. You can define one, both, or neither criteria: any criteria not specified applies to traffic on any interface.

  • To match traffic leaving the device from an interface in the zone, add that zone to the Destination Zones.

  • To match traffic entering the device from an interface in the zone, add that zone to the Source Zones.

  • If you add both source and destination zone conditions to a rule, matching traffic must originate from one of the specified source zones and egress through one of the destination zones.

Use this criteria when the rule should apply based on where the traffic enters or exits the device. For example, if you want to ensure that all traffic going to inside hosts gets intrusion inspection, you would select your inside zone as the Destination Zones while leaving the source zone empty. To implement intrusion filtering in the rule, the rule action must be Allow, and you must select an intrusion policy in the rule.


Note

You cannot mix passive and routed security zones in a single rule. In addition, you can specify passive security zones as source zones only, you cannot specify them as destination zones.

Source Networks, Destination Networks

The network objects or geographical locations that define the network addresses or locations of the traffic.

  • To match traffic from an IP address or geographical location, configure the Source Networks.

  • To match traffic to an IP address or geographical location, configure the Destination Networks.

  • If you add both source and destination network conditions to a rule, matching traffic must originate from one of the specified IP addresses and be destined for one of the destination IP addresses.

When you add this criteria, you select from the following tabs:

  • Network—Select the network objects or groups that define the source or destination IP addresses for the traffic you want to control. You can use objects that define the address using the fully-qualified domain name (FQDN); the address is determined through a DNS lookup.

  • Geolocation—Select the geographical location to control traffic based on its source or destination country or continent. Selecting a continent selects all countries within the continent. Besides selecting geographical location directly in the rule, you can also select a geolocation object that you created to define the location. Using geographical location, you could easily restrict access to a particular country without needing to know all of the potential IP addresses used there.


    Note

    To ensure that you are using up-to-date geographical location data to filter your traffic, Cisco strongly recommends that you regularly update the geolocation database (GeoDB).

Source Ports, Destination Ports/Protocols

The port objects that define the protocols used in the traffic. For TCP/UDP, this can include ports. For ICMP, it can include codes and types.

  • To match traffic from a protocol or port, configure the Source Ports. Source ports can be TCP/UDP only.

  • To match traffic to a protocol or port, configure the Destination Ports/Protocols. If you add only destination ports to a condition, you can add ports that use different transport protocols. ICMP and other non-TCP/UDP specifications are allowed in destination ports only; they are not allowed in source ports.

  • To match traffic both originating from specific TCP/UDP ports and destined for specific TCP/UDP ports, configure both. If you add both source and destination ports to a condition, you can only add ports that share a single transport protocol, TCP or UDP. For example, you could target traffic from port TCP/80 to port TCP/8080.

Application Criteria

The Application criteria of an access rule defines the application used in an IP connection, or a filter that defines applications by type, category, tag, risk, or business relevance. The default is any application.

Although you can specify individual applications in the rule, application filters simplify policy creation and administration. For example, you could create an access control rule that identifies and blocks all high risk, low business relevance applications. If a user attempts to use one of those applications, the session is blocked.

In addition, Cisco frequently updates and adds additional application detectors via system and vulnerability database (VDB) updates. Thus, a rule blocking high risk applications can automatically apply to new applications without you having to update the rule manually.

You can specify applications and filters directly in the rule, or create application filter objects that define those characteristics. The specifications are equivalent, although using objects can make it easier to stay within the 50-items-per-criteria system limit if you are creating a complex rule.

To modify the application and filters list, you click the + button within the condition, select the desired applications or application filter objects, which are listed on separate tabs, and click OK in the popup dialog box. On either tab, you can click Advanced Filter to select filter criteria or to help you search for specific applications. Click the x for an application, filter, or object to remove it from the policy. Click the Save As Filter link to save the combined criteria that is not already an object as a new application filter object.


Note

If a selected application was removed by a VDB update, “(Deprecated)” appears after the application name. You must remove these applications from the filter, or subsequent deployments and system software upgrades will be blocked.

You can use the following Advanced Filter criteria to identify the application or filter to match in the rule. These are the same elements used in application filter objects.


Note

Multiple selections within a single filter criteria have an OR relationship. For example, Risk is High OR Very High. The relationship between filters is AND, so Risk is High OR Very High, AND Business Relevance is Low OR Very Low. As you select filters, the list of applications in the display updates to show only those that meet the criteria. You can use these filters to help you find applications that you want to add individually, or to verify that you are selecting the desired filters to add to the rule.

Risks

The likelihood that the application is used for purposes that might be against your organization's security policy, from very low to very high.

Business Relevance

The likelihood that the application is used within the context of your organization's business operations, as opposed to recreationally, from very low to very high.

Types

The type of application:

  • Application Protocol—Application protocols such as HTTP and SSH, which represent communications between hosts.

  • Client Protocol—Clients such as web browsers and email clients, which represent software running on the host.

  • Web Application—Web applications such as MPEG video and Facebook, which represent the content or requested URL for HTTP traffic.

Categories

A general classification for the application that describes its most essential function.

Tags

Additional information about the application, similar to category.

For encrypted traffic, the system can identify and filter traffic using only the applications tagged SSL Protocol. Applications without this tag can only be detected in unencrypted or decrypted traffic. Also, the system assigns the decrypted traffic tag to applications that the system can detect in decrypted traffic only, not encrypted or unencrypted.

Applications List (bottom of the display)

This list updates as you select filters from the options above the list, so you can see the applications that currently match the filter. Use this list to verify that your filter is targeting the desired applications when you intend to add filter criteria to the rule. If your intention is to add specific applications, select them from this list.

URL Criteria

The URL criteria of an access rule defines the URL used in a web request, or the category to which the requested URL belongs. For category matches, you can also specify the relative reputation of sites to allow or block. The default is to allow all URLs.

URL categories and reputations allow you to quickly create URL conditions for access control rules. For example, you could block all Gambling sites, or untrusted Social Networking sites. If a user attempts to browse to any URL with that category and reputation combination, the session is blocked.

Using category and reputation data also simplifies policy creation and administration. It grants you assurance that the system will control web traffic as expected. Finally, because Cisco's threat intelligence is continually updated with new URLs, as well as new categories and risks for existing URLs, you can ensure that the system uses up-to-date information to filter requested URLs. Malicious sites that represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster than you can update and deploy new policies.

To modify the URL list, you click the + button within the condition and select the desired categories or URLs using one of the following techniques. Click the x for a category or object to remove it from the policy.

URL Tab

Click +, select URL objects or groups, and click OK. You can click Create New URL if the object you require does not exist.


Note

Before configuring URL objects to target specific sites, carefully read the information on manual URL filtering.

Categories Tab

Click +, select the desired categories, and click OK.

For a description of the categories, see https://www.talosintelligence.com/categories.

The default is to apply the rule to all URLs in each selected category regardless of reputation. To limit the rule based on reputation, click the down arrow for each category, deselect the Any checkbox, and then use the Reputation slider to choose the reputation level. The left of the reputation slider indicates sites that will be allowed, the right side are sites that will be blocked. How reputation is used depends on the rule action:

  • If the rule blocks or monitors web access, selecting a reputation level also selects all reputations more severe than that level. For example, if you configure a rule to block or monitor Questionable sites (level 2), it also automatically blocks or monitors Untrusted (level 1) sites.

  • If the rule allows web access, selecting a reputation level also selects all reputations less severe than that level. For example, if you configure a rule to allow Favorable sites (level 4), it also automatically allows Trusted (level 5) sites.

Check the Category for a URL

You can check on the category and reputation for a particular URL. Enter the URL in the URL to Check box and click Go. You will be taken to an external website to see the results. If you disagree with a categorization, click the Submit a URL Category Dispute link and let us know.

User Criteria

The User criteria of an access rule defines the user or user group for an IP connection. You must configure identity policies and the associated directory server to include user or user group criteria in an access rule.

Your identity policies determine whether user identity is collected for a particular connection. If identity is established, the IP address of the host is associated with the identified user. Thus, traffic whose source IP address is mapped to a user is considered to be from that user. IP packets themselves do not include user identity information, so this IP-address-to-user mapping is the best approximation available.

Because you can add a maximum of 50 users or groups to a rule, selecting groups usually makes more sense than selecting individual users. For example, you could create a rule allowing the Engineering group access to a development network, and create a subsequent rule that denies all other access to the network. Then, to make the rule apply to new engineers, you only need to add the engineer to the Engineering group in the directory server.

You an also select identity sources to apply to all users within that source. Thus, if you support multiple Active Directory domains, you can provide differential access to resources based on the domain.

To modify the users list, you click the + button within the condition and select the desired identities using one of the following techniques. Click the x for an identity to remove it from the policy.

  • Identity Sources—Select an identity source, such as an AD realm or the local user database, to apply the rule to all users obtained from the selected sources. If the realm you need does not yet exist, click Create New Identity Realm and create it now.

  • Groups—Select the desired user groups. Groups are available only if you configure groups in the directory server. If you select a group, the rule applies to any member of the group, including subgroups. If you want to treat a sub-group differently, you need to create a separate access rule for the sub-group and place it above the rule for the parent group in the access control policy.

  • Users—Select individual users. The user name is prefixed with the identity source, such as Realm\username.

    There are some built-in users under the Special-Identities-Realm:

    • Failed Authentication—The user was prompted to authenticate, but failed to enter a valid username/password pair within the maximum number of allowed attempts. Failure to authenticate does not itself prevent the user from accessing the network, but you can write an access rule to limit network access for these users.

    • Guest—Guest users are like Failed Authentication users, except that your identity rule is configured to call these users Guest. Guest users were prompted to authenticate and failed to do so within the maximum number of attempts.

    • No Authentication Required—The user was not prompted to authentication, because the user's connections matched identity rules that specified no authentication.

    • Unknown—There is no user mapping for the IP address, and there is no record of failed authentication yet. Typically, this means that no HTTP traffic has yet been seen from that address.

Intrusion Policy Settings

Cisco delivers several intrusion policies with the Firepower System. These policies are designed by the Cisco Talos Intelligence Group (Talos), who set the intrusion and preprocessor rule states and advanced settings. You cannot modify these policies. However, you can change the action to take for a given rule, as described in Changing Intrusion Rule Actions.

For access control rules that allow traffic, you can select one of the following intrusion policies to inspect traffic for intrusions and exploits. An intrusion policy examines decoded packets for attacks based on patterns, and can block or alter malicious traffic.

To enable intrusion inspection, select Intrusion Policy > On and select the desired policy. The policies are listed from least to most secure.

  • Connectivity over Security—This policy is built for organizations where connectivity (being able to get to all resources) takes precedence over network infrastructure security. The intrusion policy enables far fewer rules than those enabled in the Security over Connectivity policy. Only the most critical rules that block traffic are enabled. Select this policy if you want to apply some intrusion protection but you are fairly confident in the security of your network.

  • Balanced Security and Connectivity—This policy is designed to balance overall network performance with network infrastructure security. This policy is appropriate for most networks. Select this policy for most situations where you want to apply intrusion prevention.

  • Security over Connectivity—This policy is built for organizations where network infrastructure security takes precedence over user convenience. The intrusion policy enables numerous network anomaly intrusion rules that could alert on or drop legitimate traffic. Select this policy when security is paramount or for traffic that is high risk.

  • Maximum Detection—This policy is built for organizations where network infrastructure security is given even more emphasis than is given by the Security Over Connectivity policy, with the potential for even greater operational impact. For example, the intrusion policy enables rules in a large number of threat categories including malware, exploit kit, old and common vulnerabilities, and known in-the-wild exploits. If you select this policy, carefully evaluate whether too much legitimate traffic is being dropped.

File Policy Settings

Use file policies to detect malicious software, or malware, using malware defense. You can also use file policies to perform file control, which allows control over all files of a specific type regardless of whether the files contain malware.

Malware defense uses the AMP Cloud to retrieve dispositions for possible malware detected in network traffic, and to obtain local malware analysis and file pre-classification updates. The management interface must have a path to the Internet to reach the AMP Cloud and perform malware lookups. When the device detects an eligible file, it uses the file's SHA-256 hash value to query the AMP Cloud for the file's disposition. The possible dispositions are:

  • Malware—The AMP Cloud categorized the file as malware. An archive file (e.g. a zip file) is marked as malware if any file within it is malware.

  • Clean—The AMP Cloud categorized the file as clean, containing no malware. An archive file is marked as clean if all files within it are clean.

  • Unknown—The AMP Cloud has not assigned a disposition to the file yet. An archive file is marked as unknown if any file within it is unknown.

  • Unavailable—The system could not query the AMP Cloud to determine the file's disposition. You may see a small percentage of events with this disposition; this is expected behavior. If you see a number of "unavailable" events in succession, ensure that the Internet connection for the management address is functioning correctly.

Available File Policies

You can select one of the following file policies:

  • None—Do not evaluate transmitted files for malware and do no file-specific blocking. Select this option for rules where file transmissions are trusted or where they are unlikely (or impossible), or for rules where you are confident your application or URL filtering adequately protects your network.

  • Block Malware All—Query the AMP Cloud to determine if files traversing your network contain malware, then block files that represent threats.

  • Cloud Lookup All—Query the AMP Cloudto obtain and log the disposition of files traversing your network while still allowing their transmission.

  • (Custom File Policy)—You can create your own file policies using the FTD API filepolicies resource, and the other FileAndMalwarePolicies resources (such as filetypes, filetypecategories, ampcloudconfig, ampservers, and ampcloudconnections). After you create the policies, and deploy changes, you can select your policies when editing an access control rule in the FDM. The policy description appears below the policy when you select it.

Logging Settings

The logging settings for an access rule determine whether connection events are issued for traffic that matches the rule. You must enable logging to see events related to the rule in the Event Viewer. You must also enable logging for matching traffic to be reflected in the various dashboards you can use to monitor the system.

You should log connections according to the security and compliance needs of your organization. If your goal is to limit the number of events you generate and improve performance, only enable logging for the connections critical to your analysis. However, if you want a broad view of your network traffic for profiling purposes, you can enable logging for additional connections.


Caution

Logging blocked TCP connections during a Denial of Service (DoS) attack can affect system performance and overwhelm the database with multiple similar events. Before you enable logging for a Block rule, consider whether the rule is for an Internet-facing interface or other interface vulnerable to DoS attack.

You can configure the following logging actions.

Select Log Action

You can select one of the following actions:

  • Log at Beginning and End of Connection—Issue events at the start and end of a connection. Because end-of-connection events contain everything that start-of-connection events contain, plus all of the information that could be gleaned during the connection, Cisco recommends that you do not select this option for traffic that you are allowing. Logging both events can impact system performance. However, this is the only option allowed for blocked traffic.

  • Log at End of Connection—Select this option if you want to enable connection logging at the end of the connection, which is recommended for allowed or trusted traffic.

  • No Logging at Connection—Select this option to disable logging for the rule. This is the default.


Note

When an intrusion policy invoked by an access control rule detects an intrusion and generates an intrusion event, the system automatically logs the end of the connection where the intrusion occurred, regardless of the logging configuration of the rule. For connections where an intrusion was blocked, the action for the connection in the connection log is Block, with a reason of Intrusion Block, even though to perform intrusion inspection you must use an Allow rule.

File Events

Select Log Files if you want to enable logging of prohibited files or malware events. You must select a file policy in the rule to configure this option. The option is enabled by default if you select a file policy for the rule. Cisco recommends you leave this option enabled.

When the system detects a prohibited file, it automatically logs one of the following types of event:

  • File events, which represent detected or blocked files, including malware files.

  • Malware events, which represent detected or blocked malware files only.

  • Retrospective malware events, which are generated when the malware disposition for a previously detected file changes.

For connections where a file was blocked, the action for the connection in the connection log is Block even though to perform file and malware inspection you must use an Allow rule. The connection's Reason is either File Monitor (a file type or malware was detected), or Malware Block or File Block (a file was blocked).

Send Connection Events To

If you want to send a copy of the events to an external syslog server, select the server object that defines the syslog server. If the required object does not already exist, click Create New Syslog Server and create it. (To disable logging to a syslog server, select Any from the server list.)

Because event storage on the device is limited, sending events to an external syslog server can provide more long term storage and enhance your event analysis.

This setting applies to connection events only. To send intrusion events to syslog, configure the server in the intrusion policy settings. To send file/malware events to syslog, configure the server on Device > System Settings > Logging Settings.

Monitoring Access Control Policies

The following topics explain how you can monitor the access control policy.

Monitoring Access Control Statistics in the Dashboards

Most of the data on the Monitoring dashboards are directly related to your access control policy. See Monitoring Traffic and System Dashboards.

  • Monitoring > Access And SI Rules shows the most-hit access rules and Security Intelligence rule-equivalents and related statistics.

  • You can find general statistics on the Network Overview, Destinations, and Zones, dashboards.

  • You can find URL filtering results on the URL Categories and Destinations dashboards. You must have at least one URL filtering policy to see any information on the URL Categories dashboard.

  • You can find application filtering results on the Applications and Web Applications dashboards.

  • You can find user-based statistics on the Users dashboard. You must implement identity policies to collect user information.

  • You can find intrusion policy statistics on the Attackers and Targets dashboards. You must apply an intrusion policy to at least one access control rule to see any information on these dashboards.

  • You can find file policy and malware filtering statistics on the File Logs and Malware dashboards. You must apply a file policy to at least one access control rule to see any information on these dashboards.

  • Monitoring > Events also shows events for connections and data related to the access control rules.

Examining Rule Hit Counts

You can view the hit count for each access control rule. The hit count indicates how often connections matched the rule. You can use this information to identify your most active rules and the rules that are less active.

The count is from the last time the system rebooted, whether from your action or from a system upgrade, or from when you reset the hit count for a rule or all rules.

You can also see rule hit count information in the device CLI using the show rule hits command.

Procedure

Step 1

Select Policies > Access Control.

Step 2

Click the Toggle Hit Counts icon (Toggle hit counts button.).

The Hit Count column appears to the right of the Name column with the total hit count for the rule and the date and time of the last hit. The hit count information is fetched at the time you click the toggle button.

You can do the following with the hit count information:

  • To the left of the button, you will see information on when the hit count was last updated. Click the refresh icon (Refresh hit count button.) to get the latest numbers.

  • To open a detailed view of the hit count for a given rule, click the hit count number in the table to open the Hit Count dialog box. The hit count information includes the number of hits and the date and time of the last connection that matched the rule. Click the Reset link to reset the counter to zero.

    If you want to reset the hit count for all rules at once, open an SSH session to the device and issue the clear rule hits command.

  • Click the Toggle Hit Counts icon (Toggle hit counts button.) again to remove the hit count column from the table.

Monitoring Syslog Messages for Access Control

In addition to seeing events in the Event Viewer, you can configure access control rules, intrusion policies, file/malware policies, and Security Intelligence policies to send events to a syslog server. The events use the following message IDs:

  • 430001—Intrusion event.

  • 430002—Connection event logged at the beginning of a connection.

  • 430003—Connection event logged at the end of a connection.

  • 430004—File events.

  • 430005—Malware events.

Monitoring Access Control Policies in the CLI

You can also open the CLI console or log into the device CLI and use the following commands to get more detailed information about access control policies and statistics.

  • show access-control-config displays summary information about the access control rules along with per-rule hit counts.

  • show access-list displays the access control lists (ACLs) that were generated from the access control rules. The ACLs provide an initial filter and attempt to provide quick decisions whenever possible, so that connections that should be dropped do not need to be inspected (and thus consume resources unnecessarily). This information includes hit counts.

  • show rule hits displays consolidated hit counts that are more accurate than the counts shown with show access-control-config and show access-list. If you want to reset the hit count, use the clear rule hits command.

  • show snort statistics displays information about the Snort inspection engine, which is the main inspector. Snort implements application filtering, URL filtering, intrusion protection, and file and malware filtering.

  • show conn displays information about the connections currently established through the interfaces.

  • show traffic displays statistics about traffic flowing through each interface.

  • show ipv6 traffic displays statistics about IPv6 traffic flowing through the device.

Examples for Access Control

The use case chapter includes several examples of implementing access control rules. Please see the following examples:

Following are additional examples.

How to Control Network Access Using TrustSec Security Group Tags

If you use Cisco Identity Services Engine (ISE) to define and use security group tags (SGT) for classifying traffic in a Cisco TrustSec network, you can write access control rules that use SGT as matching criteria. Thus, you can block or allow access based on security group membership rather than IP addresses directly.

About Security Group Tags (SGT)

In Cisco Identity Services Engine (ISE), you can create security group tags (SGT) and assign host or network IP addresses to each tag. You can also assign SGTs to user accounts, and the SGT is assigned to the user's traffic. If the switches and routers in the network are configured to do so, these tags then get assigned to packets as they enter the network controlled by ISE, the Cisco TrustSec cloud.

When you configure an ISE identity source in the FDM, the FTD system automatically downloads the list of SGTs from ISE. You can then use SGT as a traffic matching condition in access control rules.

For example, you could create a Production Users tag, and associate the 192.168.7.0/24 network to the tag. This would be appropriate if you use that network for user end points, such as laptops, Wi-Fi clients, and so forth. You could create a separate tag for Production Servers, and assign the IP addresses of the relevant servers or subnet to the tag. Then, in the FTD, you could allow or block access from the user network to the production servers based on the tag. If you later alter the host or network addresses associated with the tag in ISE, you do not need to change the access control rule defined for the FTD device.

When the FTD evaluates SGT as a traffic matching criteria for an access control rule, it uses the following priority:

  1. The source SGT tag defined in the packet, if any. For the SGT tag to be in the packet, the switches and routers in the network must be configured to add them. See the ISE documentation for information on how to implement this method.

  2. The SGT assigned to the user session, as downloaded from the ISE session directory. You need to enable the option to listen to session directory information for this kind of SGT matching, but this option is on by default when you first create the ISE identity source. The SGT can be matched to source or destination. Although not required, you would also normally set up a passive authentication identity rule, using the ISE identity source along with an AD realm, to collect user identity information.

  3. The SGT-to-IP address mapping downloaded using SXP. If the IP address is within the range for an SGT, then the traffic matches the access control rule that uses the SGT. The SGT can be matched to source or destination.

    ISE uses the Security-group eXchange Protocol (SXP) to propagate the IP-to-SGT mapping database to network devices. When you configure the FTD device to use an ISE server, you must turn on the option to listen to the SXP topic from ISE. Thus, the FTD device learns about the security group tags and mappings directly from ISE, and is notified whenever ISE publishes updated security group tags and mappings. This ensures that the list of security group tags and mappings stay up-to-date on the device, so that the FTD can effectively enforce the policy defined in ISE.

Configure Access Control Based on Security Group Tag (SGT)

To configure access control rules that use security group tags (SGT) as matching criteria, you must first configure the device to obtain the SGT mappings from an ISE server.

The following procedure explains the end-to-end process based on the assumption that you want to get all mappings that are defined in ISE, including SGT-to-IP address mappings published through SXP. Alternatively:

  • If you want to use SGT information in the packets only, and not use mappings downloaded from ISE, simply do the steps defined in Create SGT Dynamic Objects for Downloaded Tags and Configure an Access Control Rule Based on SGT. Note that in this case, you can use SGT tags as a source condition only; these tags will never match destination criteria.

  • If you want to use SGT in packets plus user session SGT mappings only, you do not need to turn on the option to subscribe to the SXP topic in the ISE identity source, nor do you need to configure ISE to publish SXP mappings. You can use this information for both source and destination matching conditions.

Before you begin

The assumption here is that you have already configured Cisco TrustSec in your network, and you are simply adding the FTD device as a policy enforcement point. If you have not deployed Cisco TrustSec, please start with ISE and configure your network, then return to this procedure. Explaining Cisco TrustSec is outside the scope of this document.

Procedure
Step 1

Configure Security Groups and SXP Publishing in ISE.

Step 2

Configure the ISE Identity Source in the FDM.

Step 3

Create SGT Dynamic Objects for Downloaded Tags.

Step 4

Configure an Access Control Rule Based on SGT.

Configure Security Groups and SXP Publishing in ISE

There is a lot of configuration that you must do in Cisco Identity Services Engine (ISE) to create the TrustSec policy and security group tags (SGT). Please look at the ISE documentation for more complete information on implementing TrustSec.

The following procedure picks out the highlights of the core settings you must configure in ISE for the FTD device to be able to download and apply static SGT-to-IP address mappings, which can then be used for source and destination SGT matching in access control rules. See the ISE documentation for detailed information.

The screen shots in this procedure are based on ISE 2.4. The exact paths to these features might change in subsequent releases, but the concepts and requirements will be the same. Although ISE 2.4 or later is recommended, and preferably 2.6 or later, the configuration should work starting with ISE 2.2 patch 1.

Before you begin

You must have the ISE Plus license to publish SGT-to-IP address static mappings and to get user session-to-SGT mappings so that the FTD device can receive them.

Procedure
Step 1

Choose Work Centers > TrustSec > Settings > SXP Settings, and select the Publish SXP Bindings on PxGrid option.

This option makes ISE send the SGT mappings out using SXP. You must select this option for the FTD device to “hear” anything from listing to the SXP topic. This option must be selected for the FTD device to get static SGT-to-IP address mapping information. It is not necessary if you simply want to use SGT tags defined in the packets, or SGTs that are assigned to a user session.


Turn on Publish SXP Bindings on PxGrid option in ISE.
Step 2

Choose Work Centers > TrustSec > SXP > SXP Devices, and add a device.

This does not have to be a real device, you can even use the management IP address of the FTD device. The table simply needs at least one device to induce ISE to publish the static SGT-to-IP address mappings. This step is not necessary if you simply want to use SGT tags defined in the packets, or SGTs that are assigned to a user session.


Add an SXP device in ISE.
Step 3

Choose Work Centers > TrustSec > Components > Security Groups and verify there are security group tags defined. Create new ones as necessary.


Configure security group tags (SGT) in ISE.
Step 4

Choose Work Centers > TrustSec > Components > IP SGT Static Mapping and map host and network IP addresses to the security group tags.

This step is not necessary if you simply want to use SGT tags defined in the packets, or SGTs that are assigned to a user session.


Configure IP to SGT static mappings in ISE.
Configure the ISE Identity Source in the FDM

You can use ISE to obtain user session SGT mappings, static SGT-to-IP address mappings through SXP, or both. By default, when you configure the ISE identity source, it obtains user session mappings only; you must turn on the option to listen to the SXP topic from ISE.

Procedure
Step 1

In the FDM, create the ISE identity object as explained in Configure Identity Services Engine.

Configuring an AD realm is not required for the SXP configuration, but you need an AD server if you also want to obtain user identity from ISE.

Step 2

Deploy your changes.

Although deploying changes at this time is not required, it is a best practice to deploy the FDM changes before you start using API methods to simplify troubleshooting. The exception is when you are creating a partial configuration in the FDM, such as with access control rules, where the object will interfere with normal operations if it is deployed in a half-configured state.

Step 3

Click the more options button (More options button.) and choose API Explorer.

The system opens the API Explorer in a separate tab or window, depending on your browser settings.

Step 4

Click IdentityServicesEngine to open the folder and see the available methods.

Step 5

Get the ISE identity object you created in the FDM.

  1. Click the GET /integration/identityservicesengine method.

  2. Click the Try It Out! button at the end of the method explanation.

    The system submits the GET call and should successfully retrieve the ISE identity object. The object appears in the Response Body field, and look for a Return Code of 200. If you get any other result, examine the response body for error messages, and try creating the ISE identity source again.

  3. Use click and drag, and Ctrl+C, to copy the object body to the clipboard. Start with the first brace { after the “items [” bracket, and end with the closing brace } immediately prior to the ending bracket ]. Leave out the lines including and prior to “items” and the paging attributes at the end. The first attribute in the object should be “version,” and the last attribute, “self.”

    Following is an example, where the attributes you need for the next step are highlighted: 

    
{
  "version": "kbpeihi5cbarm",
  "name": "ISE",
  "description": null,
  "ftdCertificate": {
    "version": "epnkrwowkuhgk",
    "name": "ISE",
    "id": "565b03fd-8874-11e9-87fd-29bbc348546c",
    "type": "internalcertificate"
  },
  "pxGridCertificate": {
    "version": "pyzuuw7ja6coq",
    "name": "ISE_CA",
    "id": "5cf3b4b0-8874-11e9-87fd-6b0eb83b0b10",
    "type": "externalcacertificate"
  },
  "mntCertificate": {
    "version": "pyzuuw7ja6coq",
    "name": "ISE_CA",
    "id": "5cf3b4b0-8874-11e9-87fd-6b0eb83b0b10",
    "type": "externalcacertificate"
  },
  "iseNetworkFilters": [],
  "enabled": true,
  "subscribeToSessionDirectoryTopic": true,
  "subscribeToSxpTopic": false, 
  "secondaryIseServer": null,
  "primaryIseServer": "192.168.0.9",
  "id": "8252f773-8874-11e9-87fd-67c87c391f4d", 
  "type": "identityservicesengine",
  "links": {
    "self": "https://ftd.example.com/api/fdm/v3/integration/
identityservicesengine/8252f773-8874-11e9-87fd-67c87c391f4d"
  }
}
    Note 

    The subscribeToSessionDirectoryTopic is set to true by default when you create the ISE identity source. This is the attribute that determines whether the system obtains user session SGT mappings. If you want to use static SGT-to-IP address mappings only, and do not want user session SGT information, you can set this option to false.

Step 6

Use PUT to update the object and turn on the option to subscribe to the SXP topic in ISE.

By default, the subscribeToSxpTopic attribute is set to false. You need to set it to true.

  1. Click the PUT /integration/identityservicesengine/{objId} method.

  2. Paste the current version of the object into the body parameter edit box, and delete the links attribute, including the self attribute within it.

  3. Change the subscribeToSxpTopic attribute value to true. 

    
...
  "subscribeToSessionDirectoryTopic": true,
  "subscribeToSxpTopic": true, 
  "secondaryIseServer": null,
...

    With this attribute set to true, the system will download SGT-to-IP address mappings. If you do not set it to true, the system will not get the static SGT-to-IP address mappings defined in ISE. You will not be able to apply access control based on these mappings.

  4. Copy the value of the object id attribute. Note that there are 4 id attributes, one each for the ftdCertificate, pxGridCertificate, mntCertificate, and ISE object. The id for the object is the last one displayed, right before the "type": "identityservicesengine" attribute.

  5. Paste the object id into the objId parameter, right above the body parameter. Do not include the opening/closing parentheses.


    Enable the subscribeToSxpTopic attribute in the ISE identity source object using the FTD API.

  6. Click the Try It Out! button. A successful call should return a 200 response code and the response body should show the new object with your changes.

    For example: 

    
{
  "version": "ll7jndfp2qriq",
  "name": "ISE",
  "description": null,
  "ftdCertificate": {
    "version": "epnkrwowkuhgk",
    "name": "ISE",
    "id": "565b03fd-8874-11e9-87fd-29bbc348546c",
    "type": "internalcertificate"
  },
  "pxGridCertificate": {
    "version": "pyzuuw7ja6coq",
    "name": "ISE_CA",
    "id": "5cf3b4b0-8874-11e9-87fd-6b0eb83b0b10",
    "type": "externalcacertificate"
  },
  "mntCertificate": {
    "version": "pyzuuw7ja6coq",
    "name": "ISE_CA",
    "id": "5cf3b4b0-8874-11e9-87fd-6b0eb83b0b10",
    "type": "externalcacertificate"
  },
  "iseNetworkFilters": [],
  "enabled": true,
  "subscribeToSessionDirectoryTopic": true,
  "subscribeToSxpTopic": true,
  "secondaryIseServer": null,
  "primaryIseServer": "192.168.0.9",
  "id": "8252f773-8874-11e9-87fd-67c87c391f4d",
  "type": "identityservicesengine",
  "links": {
    "self": "https://ftd.example.com/api/fdm/v3/integration/
identityservicesengine/8252f773-8874-11e9-87fd-67c87c391f4d"
  }
}
Step 7

Go back to the FDM window and deploy changes.

Create SGT Dynamic Objects for Downloaded Tags

After you configure the ISE identity source and deploy changes, the system retrieves security group tag (SGT) information from the ISE server.

However, you cannot use the information retrieved from ISE directly in an access control rule. Instead, you need to create SGT dynamic objects, which refer to the downloaded SGT information. Your SGT dynamic objects can refer to more than one SGT, so you can apply policy based on relevant collections of tags if that is appropriate.

Procedure
Step 1

Click the more options button (More options button.) and choose API Explorer.

Step 2

View the SGT information downloaded from ISE.

  1. Click SecurityGroupTag to open the folder and see the available methods.

  2. Click the GET /object/securitygrouptags method.

  3. Click the Try It Out! button at the end of the method explanation.

    The system submits the GET call and should successfully retrieve the SGT information retrieved from ISE. This information is a list of tags only, and does not include IP address mappings. The response body should show the SGT information, and the response code should be 200.

    Note that by default, the GET call limits the information to the first 10 objects.

    Scroll to the bottom of the response body and look at the paging information. For example: 

    
"paging": {
    "prev": [],
    "next": [
"https://ftd.example.com/api/fdm/v3/object/
securitygrouptags?limit=10&offset=10"
    ],
    "limit": 10,
    "offset": 0,
    "count": 119,
    "pages": 0
  }

    This example shows that you are seeing just the first 10 SGTs, but that there are a total of 119 SGTs downloaded (the count attribute). The total number of SGTs depends on how many are configured in your ISE server.

  4. To get a complete list, scroll up and enter 120 in the limit parameter value, then click Try It Out! again.

    The paging attributes should now show a 120 limit, 119 count, and no pages.

    
"paging": {
    "prev": [],
    "next": [],
    "limit": 120,
    "offset": 0,
    "count": 119,
    "pages": 0
  }

    You might want to copy/paste the response body into a text file to make it easier to examine the list and plan for the SGT dynamic objects that you will need to implement your access control policies.

Step 3

Create the SGT dynamic objects that you need.

There is no requirement to create SGT dynamic objects for each SGT. You need only those objects you will use in access control rules.

For this example, we will consider the following two SGTs downloaded from ISE: 


{
  "tag": 11,
  "name": "Production_Servers",
  "description": "Production Servers Security Group",
  "deleted": false,
  "id": "9423aa00-8c01-11e6-996c-525400b48521",
  "type": "securitygrouptag",
  "links": {
    "self": "https://ftd.example.com/api/fdm/v3/object/
securitygrouptags/9423aa00-8c01-11e6-996c-525400b48521"
  }
},
{
  "tag": 7,
  "name": "Production_Users",
  "description": "Production User Security Group",
  "deleted": false,
  "id": "9437a730-8c01-11e6-996c-525400b48521",
  "type": "securitygrouptag",
  "links": {
    "self": "https://ftd.example.com/api/fdm/v3/object/
securitygrouptags/9437a730-8c01-11e6-996c-525400b48521"
  }
},

The objective is to allow traffic from the Production_Users security group (SGT 7) to the Production_Servers security group (SGT 11). Because you need to specify these SGT separately as source and destination criteria, you need two SGT dynamic objects. Following are the steps to create the objects.

  1. Click SGTDynamicObject to open the folder and see the available methods.

  2. Click the POST /object/sgtdynamicobjects method.

  3. In the Parameters section, click the Example Value edit box on the right, in the Data Type column, to load the example into the body edit box.

  4. Remove the version and id attribute lines, then define the other attributes as follows.

    
{
  "name": "Production_Users_DSGT",
  "tags": [
    {
      "tag": 7,
      "externalId": "9437a730-8c01-11e6-996c-525400b48521",
      "type": "securitygrouptagentry"
    }
  ],
  "type": "sgtdynamicobject"
}

    The attributes are:

    • name—The name of the SGT dynamic object, not the name of the tag itself. For example, Production_Users_DSGT.

    • tags—This can be one or more tags as downloaded from ISE. To reference more than one SGT in a dynamic object, copy/paste the attributes within the {braces}, and separate each set of attributes with a comma. Ensure the sets remain within the tags [brackets]. Each tag must have the following attributes:

      • tag—The SGT tag number, as defined in ISE and shown in the tag attribute of the downloaded list of SGTs. In this example, 7.

      • externalId—The id value for the downloaded SGT. This is “external” because the downloaded list reflects items that are configured in ISE rather than in the FTD. In this example, 9437a730-8c01-11e6-996c-525400b48521.

      • type—This is always securitygrouptagentry.

    The following graphic shows the relationship between the attributes in the downloaded tags and the SGT dynamic object.


    Relationship between downloaded tag attributes and SGT dynamic object attributes.

  5. Click Try It Out!

    A successful POST results in a response code of 200 and a response body with the new object. For example:

    
{
  "version": "odswykttumaeo",
  "name": "Production_Users_DSGT",
  "tags": [
    {
      "tag": 7,
      "externalId": "9437a730-8c01-11e6-996c-525400b48521",
      "type": "securitygrouptagentry"
    }
  ],
  "id": "ba09cd90-8959-11e9-87fd-a7644255b0cd",
  "type": "sgtdynamicobject",
  "links": {
    "self": "https://ftd.example.com/api/fdm/v3/object/
sgtdynamicobjects/ba09cd90-8959-11e9-87fd-a7644255b0cd"
  }
}

  6. Repeat the process to create the SGT dynamic object for the production servers. Simply replace the body for the POST call with the one needed for the new object, and click Try It Out!. 

    
{
  "name": "Production_Servers_DSGT",
  "tags": [
    {
      "tag": 11,
      "externalId": "9423aa00-8c01-11e6-996c-525400b48521",
      "type": "securitygrouptagentry"
    }
  ],
  "type": "sgtdynamicobject"
}

    The response body should be similar to the following:

    
{
  "version": "hbfqoryvhz5xj",
  "name": "Production_Servers_DSGT",
  "tags": [
    {
      "tag": 11,
      "externalId": "9423aa00-8c01-11e6-996c-525400b48521",
      "type": "securitygrouptagentry"
    }
  ],
  "id": "eeede223-895a-11e9-87fd-31336e1d6199",
  "type": "sgtdynamicobject",
  "links": {
    "self": "https://ftd.example.com/api/fdm/v3/object/
sgtdynamicobjects/eeede223-895a-11e9-87fd-31336e1d6199"
  }
}

  7. (Optional.) You can use GET /object/sgtdynamicobjects to verify both SGT dynamic objects were created.

Configure an Access Control Rule Based on SGT

After you configure FTD to connect to an ISE server, and create the SGT dynamic objects, you can create access control rules to use the SGT dynamic objects.

To add the SGT dynamic objects to an access rule, you must use the FTD API. However, for creating the initial rule object, you can simplify matters by first creating the rule using the FDM, with all the other attributes you want, and then simply use the API to add the SGT criteria. You could also create the entire rule from scratch using the API if that is your preference.

The following procedure explains how to use the FDM to create the base rule, then add the SGT dynamic objects as traffic matching criteria. This rule allows traffic from production users to production servers. The rule depends completely on SGT; it is not limited by source/destination interface or any other criteria. Thus, the rule will dynamically apply to traffic as it comes from different interfaces, and as you change security group membership in ISE. If the packet does not explicitly contain a source SGT tag, source/destination matching will be based on the packet IP addresses compared to the SGT-to-IP address mappings obtained from user session information or from SXP-published mappings.

Before you begin

You must know the attributes of the SGT dynamic objects you will add to the rules. If you do not have a copy of the attribute-value pairs for each object, get the information now using GET /object/sgtdynamicobjects. See Create SGT Dynamic Objects for Downloaded Tags.

Procedure
Step 1

Choose Policies > Access Control.

Step 2

Click + to add a new rule and configure the following:

  • Order—Select the position where you want to insert the rule. The default is to add it to the end of the policy. You can move the rule later if necessary.

  • Name—A name for the rule, for example, ProductionServers.

  • Action—Select Allow.

  • Logging tab, Select Log Action—Select At Beginning and End of Connection. You must enable logging if you want to see traffic statistics on the dashboard. If you do not want to see this information, you can leave logging disabled.

  • All other tabs—For the purposes of this example, leave these settings at their defaults, so that traffic matches the rule based on SGT or SGT-to-IP address mappings only. This again is up to your specific needs. For example, you could add URL filtering. You can also apply an intrusion policy to protect against threats.

Note 

Do not deploy changes yet! This rule is not complete until you edit it in API Explorer. If you deploy now, you will get unintended results.

Step 3

Click the more options button (More options button.) and choose API Explorer.

Step 4

Edit the new rule to add SGT criteria.

  1. Click AccessPolicy to open the folder and see the available methods.

  2. Click GET /policy/accesspolicies/{parentId}/accessrules, and configure the following parameters:

    • parentId—Enter default. Because there can be only one access control policy, you can use default instead of the actual UUID of the policy object.

    • offset, limit—If you have a large list of access rules, it might be a challenge to find the rule object. One option is to enter the rule order number minus 1 as the offset, and for limit, specify 1. For example, if the rule order is 2, the offset should be 1 (that is, 2-1=1). That will return the one rule at that order in the policy. (It is necessary to subtract 1 from the rule order because the offset variable starts at 0, not 1.)

  3. Click Try It Out!

    Find the object for the new rule in the response body. For example, using the offset/limit technique, the response body should be similar to the following. In this example, the count in the paging attributes indicates there are 2 total rules in the access control policy, but we see a single rule here. 

    
{
  "items": [
    {
      "version": "bfd2jm5cmv3h2",
      "name": "ProductionServers",
      "ruleId": 268435458,
      "sourceZones": [],
      "destinationZones": [],
      "sourceNetworks": [],
      "destinationNetworks": [],
      "sourcePorts": [],
      "destinationPorts": [],
      "ruleAction": "PERMIT",
      "eventLogAction": "LOG_BOTH",
      "identitySources": [],
      "users": [],
      "embeddedAppFilter": null,
      "urlFilter": {
        "urlObjects": [],
        "urlCategories": [],
        "type": "embeddedurlfilter"
      },
      "intrusionPolicy": null,
      "filePolicy": null,
      "logFiles": false,
      "syslogServer": null,
      "destinationDynamicObjects": [],
      "sourceDynamicObjects": [],
      "id": "8d5e1db6-895d-11e9-87fd-894b42e34ebf",
      "type": "accessrule",
      "links": {
        "self": "https://ftd.example.com/api/fdm/v3/policy/
accesspolicies/default/accessrules/8d5e1db6-895d-11e9-87fd-894b42e34ebf"
      }
    }
  ],
  "paging": {
    "prev": [],
    "next": [],
    "limit": 1,
    "offset": 1,
    "count": 2,
    "pages": 0
  }
}

  4. Copy/paste the rule object into a text editor (or into the body parameter of the PUT /policy/accesspolicies/{parentId}/accessrules/{objId} method), and add the SGT dynamic objects as source and destination criteria.

    The fields are destinationDynamicObjects (for destination criteria) and sourceDynamicObjects (for source criteria). Each attribute can take a comma-separated list of objects, so you can include multiple SGT dynamic objects in the source or destination criteria.

    Each object in the list must have the following attributes, which you can get from the response body to GET /object/sgtdynamicobjects. These are the attributes that identity the object, but do not define the object content. 

    
{
  "version": "string",
  "name": "string",
  "id": "string",
  "type": "sgtdynamicobject"
}

    Using the objects created in Create SGT Dynamic Objects for Downloaded Tags, adding Production_Servers_DSGT to destinationDynamicObjects, and Production_Users_DSGT to sourceDestinationObjects, would look like the following (changes are highlighted). 

    
{
 "version": "bfd2jm5cmv3h2",
 "name": "ProductionServers",
 "ruleId": 268435458,
 "sourceZones": [],
 "destinationZones": [],
 "sourceNetworks": [],
 "destinationNetworks": [],
 "sourcePorts": [],
 "destinationPorts": [],
 "ruleAction": "PERMIT",
 "eventLogAction": "LOG_BOTH",
 "identitySources": [],
 "users": [],
 "embeddedAppFilter": null,
 "urlFilter": {
  "urlObjects": [],
  "urlCategories": [],
  "type": "embeddedurlfilter"
 },
 "intrusionPolicy": null,
 "filePolicy": null,
 "logFiles": false,
 "syslogServer": null,
 "destinationDynamicObjects": [
  {
  "version": "hbfqoryvhz5xj",
  "name": "Production_Servers_DSGT",
  "id": "eeede223-895a-11e9-87fd-31336e1d6199",
  "type": "sgtdynamicobject"
  }
 ],
 "sourceDynamicObjects": [
  { 
  "version": "odswykttumaeo", 
  "name": "Production_Users_DSGT", 
  "id": "ba09cd90-8959-11e9-87fd-a7644255b0cd", 
  "type": "sgtdynamicobject" 
  }
 ], 
 "id": "8d5e1db6-895d-11e9-87fd-894b42e34ebf",
 "type": "accessrule" 
}

  5. Click PUT /policy/accesspolicies/{parentId}/accessrules/{objId} to open the method.

  6. Configure the following attributes:

    • parentID—Enter default.

    • objectID—Enter the id value from the new access rule object. In the above example, this is 8d5e1db6-895d-11e9-87fd-894b42e34ebf. This is the id attribute immediate preceding the “type”: “accessrule” attribute.

    • body—Paste in the body with the updated destinationDynamicObject and sourceDynamicObject properties.

  7. Click Try It Out!

    A 422 (Unprocessable Entity) error indicates that you made a typo. Examine the response body for error messages. For example, it is easy to miss-match opening/closing braces, brackets, and parentheses, or to have commas where they do not belong. In fact, you might get a message about expected parentheses when the real problem is an extra comma, because the parser will expect a parenthesis due to the presence of the comma.

    A good result is a 200 response code. The response body should look something like the following:

    
{
  "version": "kugnhxghj2ubx",
  "name": "ProductionServers",
  "ruleId": 268435458,
  "sourceZones": [],
  "destinationZones": [],
  "sourceNetworks": [],
  "destinationNetworks": [],
  "sourcePorts": [],
  "destinationPorts": [],
  "ruleAction": "PERMIT",
  "eventLogAction": "LOG_BOTH",
  "identitySources": [],
  "users": [],
  "embeddedAppFilter": null,
  "urlFilter": {
    "urlObjects": [],
    "urlCategories": [],
    "type": "embeddedurlfilter"
  },
  "intrusionPolicy": null,
  "filePolicy": null,
  "logFiles": false,
  "syslogServer": null,
  "destinationDynamicObjects": [
    {
      "version": "hbfqoryvhz5xj",
      "name": "Production_Servers_DSGT",
      "id": "eeede223-895a-11e9-87fd-31336e1d6199",
      "type": "sgtdynamicobject"
    }
  ],
  "sourceDynamicObjects": [
    {
      "version": "odswykttumaeo",
      "name": "Production_Users_DSGT",
      "id": "ba09cd90-8959-11e9-87fd-a7644255b0cd",
      "type": "sgtdynamicobject"
    }
  ],
  "id": "8d5e1db6-895d-11e9-87fd-894b42e34ebf",
  "type": "accessrule",
  "links": {
    "self": "https://ftd.example.com/api/fdm/v3/policy/
accesspolicies/default/accessrules/8d5e1db6-895d-11e9-87fd-894b42e34ebf"
  }
}
Step 5

Go back to the FDM window and deploy changes.

The pending change window should show the updated access rule, with the SGT changes. If you have not deployed the SGT dynamic objects yet, they should also be shown.


Pending changes with API updates.

Although the change history shows changes you make through the FTD API, you cannot see the SGT information when you edit the rule in the FDM.