The Firepower ecosystem is a powerful NGIPS/NGFW solution. At that heart of the configuration construct is what is known as the Access Control Policy. Comparing this to something familiar is possible by thinking about the much simpler filtering feature in the ASA. For comparison, an ASA’s access-list (ACL) has multiple access-control entries (ACE’s). Each of these entries can refer to object-groups, networks, and protocols and can apply a permit or deny action.
The Access Control Policy in Firepower is a similar concept, but there are many additional facets that are pulled together to provide a more comprehensive policy application mechanism. This article only covers the major areas of this policy control construct. There are items which are beyond the scope including variable sets and manipulating the behavior of http response pages.
Specific to the policy application, there are two main areas of the the Access Control Policy. The first area is what is known as Security Intelligence. In the policy, this is found on the second tab from the left and provides a framework for blacklisting. There are many feeds provided directly from Cisco’s Talos organization and are ready for consumption by the security policy.
The action for each feed that is blacklisted can be set to monitor only or to block. These events will be logged as Security Intelligence Events and may raise an Indication of Compromise. It is also this tab that will allow for the selection of a DNS Policy. Worth noting is that whitelisting is an override for blacklisting. Whitelisting does not preclude processing against the remaining Firepower Access Control Rules.
The second, and most visible, component contains the Access Control Rules. This is located in the left-most tab of the Access Control Policy. The section is a familiar construct in which rules are processed in a top-down manner until a match occurs. In the case that the action is Monitor, further processing occurs. If the action is Trust, Allow or Block, rule processing terminates and the appliance will process the traffic accordingly. A Trust action indicates that the traffic should be fully trusted and not subject to IPS checks (against the Snort signatures). Allowed traffic may be sent to IPS for additional processing.
The power of the Firepower Access Control Rule is apparent when the match criteria is examined. Of note, rules can now match on source or destination by IP address, Country and Continent. There are also many ways to match on application and application criteria, including risk level and business relevance. In regards to URL filtering, a match may occur based on Category, Risk or manually using a substring of a URL.
The default action is only relevant if no match occurred that would otherwise Trust, Allow or Block the traffic. This action is also controllable. It is also important to note that this final action can include diverting traffic over to the IPS Snort engine for further processing and the logging behavior can be configured.
The Firepower Access Control policy is the most central component to the configuration of the solution. This article outlines many of the advanced feature that makes this a Next Generation solution. In the future, we will dig deeper into some of the key features that are unique to the platform.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This
may or may does not reflect the position of past, present or future employers.