A common use-case I encounter is the ability to dynamically update object lists referenced in policies at security perimeters (Firepower, FTD or others). This can come in one of two flavors:

1. Security threat intelligence (aka IOCs). These are usually used for blocking policies. A common use-case is leveraging external threat list provides such as feeds from Spamhaus or similar.
2. System/vendor reference IP/URL objects. These typically specifies where certain vendors/services are located and are thus used for allowing traffic. One very common use-case is Office 365 IP addresses.

In the most basic form it is just URL pointing towards a list of object. One such could be the Talos IP black list. It could also be an list of known TOR exit nodes as provided here. Or something homegrown or aggregated through a purpose build tool. One thing to take special note about is the format the intelligence feed is provided in. More on this later on.

In FMC we have two tools we can utilize to harness external feeds.

1. Security Intelligence. Has been around for quite a while. Can be used both for blocking and for allowing!. 
2. Threat Intelligence Director (or TID). This has only been available from version 6.2.2 of the Cisco Firesight Management Center. Can only be used for block!

Security Intelligence

The first option has been the classical approch, where i.e. an external IP list can be referenced as an object in a policy. Be however aware that while a normal network object can contain the following (Freely pasted from the configuration guide):

A network object can be one of the following types:

Single Host (A single IP address.) 
i.e. 209.165.200.225 or 2001:DB8::0DB8:800:200C:417A
 
Network (An address block, also known as a subnet)
i.e. 209.165.200.224/27 or 2001:DB8:0:CD30::/60

Address Range (A range of IP addresses)
i.e. 209.165.200.225-209.165.200.250 or 2001:db8:0:cd30::1-2001:db8:0:cd30::1000

Group (A group of network objects or other network object groups.) 
I.e. 209.165.200.225, 209.165.201.1, 209.165.202.129 
You can create nested groups by adding one network object group to another network object group. You can nest up to 10 levels of groups.

A Network object feed only support the two first options. This can become important as some feed do uses address ranges which are not supported.

If for some reason the threat intelligence feed is malformed or otherwise rejected the following error message is seen. It can also be seen by a lack of “last updated” in the Security Intelligence tab.

The Threat Intelligence Director (Cisco TID)

The second option also comes with a few caveats. Most notably is the fact that STIX sources cannot be used for blocking but only for incidents. A good place for starting out with TAXII/STIX sources is HailATaxii.com. From here various open-source intelligence can be ingested into the FMC platform.

It is also possible to include a simple URL, which makes it very similar to the Security Intelligence Feed, and also has the possibility to to blocking.

The Threat Intelligence Director is meant (I believe) as a method of discovery and enrichment of the FMC monitoring capabilities and in that respect it is very successful. Applying the feeds as direct enforcement are somewhat more coarse but can also be done.

A nice thing about the TID is that it is possible to see all the different Indicators from the enabled feeds. A feature that are not present in the Security Intelligence.

Office 365 Feeds

Microsoft have scattered the IP pools potentially allocated to O365 around and are constantly updating the list. This is a textbook example as to where it could be a good idea to employ a dynamic object list. This feed is maintained by Microsoft but is unfortunately in an XML format containing various other information as well. In order for it to be useful it needs to be put through a parser, script or similar. I have used MineMeld with great success before, but alas it uses IP ranges which is not supported in FMC. I will write up a small XML parser in the near future and make some proper lists of the feed. One guy here went with a powershell solution, while I probably will rely on some stripped down Linux an a few lines of code.

(edit) No need to reinvent the wheel.. MineMeld is already capable of providing the correct format. Just append the ?tr=1 output variable in the end of the URL.

For a full how-to on O365  feed in MineMeld follow this cookbook 🙂

Another great resource for using MineMeld as a Splunk tool can be viewed here.