Choosing a Security Intelligence Strategy
License: Protection
The easiest way to construct a Block list is to use the Intelligence Feed, which tracks IP addresses known to be open relays, known attackers, bogus IP addresses (bogon), and so on. Because the Intelligence Feed is regularly updated, using it ensures that the system uses up-to-date information to filter your network traffic. Malicious IP addresses that represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster than you can update and apply new policies.
To augment the Intelligence Feed, you can perform Security Intelligence filtering using custom or third-party IP address lists and feeds, where:
-
a list is a static list of IP addresses that you upload to the ASA FirePOWER module
-
a feed is a dynamic list of IP addresses that the ASA FirePOWER module downloads from the Internet on a regular basis; the Intelligence Feed is a special kind of feed
For detailed information on configuring Security Intelligence lists and feeds, including Internet access requirements, see Working with Security Intelligence Lists and Feeds.
Using the Security Intelligence Global Block List
In the course of your analysis, you can build a global Block list. For example, if you notice a set of routable IP addresses in intrusion events associated with exploit attempts, you can add those IP addresses to a Block list. The ASA FirePOWER module uses this global Block list (and a related global Do-Not-Block list ) to perform Security Intelligence filtering in all access control policies. For information on managing these global lists, see Working with the Global Do-Not-Block List and Block list.
Note |
Although feed updates and additions to the global Block list (or global Do-Not-Block list; see below) automatically implement changes throughout your deployment, any other change to a Security Intelligence object requires you to reapply the access control policy. |
Using Network Objects
Finally, a simple way to construct a Block list is to use network objects or network object groups that represent an IP address, IP address block, or collection of IP addresses. For information on creating and modifying network objects, see Working with Network Objects.
Using Security Intelligence Do-Not-Block Lists
In addition to a Block list, each access control policy has an associated Do-Not-Block list, which you can also populate with Security Intelligence objects. A policy’s Do-Not-Block list overrides its Block list. That is, the system evaluates traffic with a source or destination IP address that is on a Do-Not-Block list using access control rules, even if the IP address is also on a Block list. In general, use the Do-Not-Block list if a Block list is still useful, but is too broad in scope and incorrectly blocks traffic that you want to inspect.
For example, if a reputable feed improperly blocks your access to vital resources but is overall useful to your organization, you can add only the improperly classified IP addresses to a Do-Not-Block list, rather than removing the whole feed from the Block list.
Enforcing Security Intelligence Filtering by Security Zone
For added granularity, you can enforce Security Intelligence filtering based on whether the source or destination IP address in a connection resides in a particular security zone.
To extend the Do-Not-Block list example above, you could add the improperly classified IP addresses to a Do-Not-Block list, but then restrict the object using a security zone used by those in your organization who need to access those IP addresses. That way, only those with a business need can access those IP addresses. As another example, you could use a third-party spam feed to block traffic on an email server security zone.
Monitoring—Rather than Blocking—Connections
If you are not sure whether you want to block a particular IP address or set of addresses, you can use a “monitor-only” setting, which allows the system to pass the matching connection to access control rules, but also logs the match to the Block list and generates an end-of-connection Security Intelligence event. Note that you cannot set the global Block list to monitor-only.
Consider a scenario where you want to test a third-party feed before you implement blocking using that feed. When you set the feed to monitor-only, the system allows connections that would have been blocked to be further analyzed by the system, but also logs a record of each of those connections for your evaluation.
In passive deployments, to optimize performance, Cisco recommends that you always use monitor-only settings. Devices that are deployed passively cannot affect traffic flow; there is no advantage to configuring the system to block traffic. Additionally, because blocked connections are not actually blocked in passive deployments, the system may report multiple beginning-of-connection events for each blocked connection.