Sourcefire Security Intelligence

Let’s talk a little bit about a nice capability of Sourcefire system called “Security Intelligence(SI). With the SI we have the option to block the traffic based on its reputation, before it reaches detection engine. We had this functionality with the old Cisco IPS systems, and many other vendors have it. The basic idea behind this is why bother passing the traffic through the detection engine while everybody in the world knows that the source IP or the site our users are visiting are malicious? How the whole world knows this? Well, there are tons of security devices throughout the world that share the information about malicious sites or IPs. There are centers that collect this information and distribute it to everybody participating in this process. For example, someone in Bosnia received the attachment, sent it to the (Cisco) cloud for the sand box analysis and the result came back as malware. Very soon people from other countries knows that this file is malware and they don’t scan it or send it for sendboxing. They know it is malware and drop it. Same goes for IP address that is a part of CnC network. Somebody learned this the hard way and why running this IP through the detection engine, thus wasting valuable resources, when we know for sure this IP is bad. This is what the Security Intelligence is all about.

In Cisco‘s Sourcefire, the SI is achieved through two types of sources that contain the bad IPs:

  • Lists
  • Feeds

Lists are static in nature and we are responsible for keeping these lists accurate. If global security center (called “Talos“) misses some IP that we know is bad, we can manually add it to our black list. Likewise, if they marked something as bad IP, we can manually place it in our white list. By the way, Talos is huge bronze man from Greek mythology that used to protect the Europe from invaders and pirates. Good to know for the job interview 🙂

Feeds, on the other hand are dynamic, provided by Talos team or some other vendor we trust. They update these feeds and our “Defense Center” picks them up every two hours by default.

At this point in our Sourcefire saga, we have two lists that are empty and applied to all security zones:

  • Global Blacklist  –  contains IP addresses we consider to be bad
  • Global Whitelist –  contains IP addresses we are sure are ok

Like I said, these are static and we have to take care of their content. By default both are empty.

Beside these two static lists, we can create our own lists as appropriate. The major difference between global lists and one we create is that we can populate global lists from Analysis pages by right clicking the IP address we want to paint black or white, while with the custom lists, we have to manually edit the file that contains the IP addresses and then (re)upload that file to the DC. Not an easy task to do, so we will stick to the defaults.

Alongside with the static lists, we have another way of populating our security intelligence by using feeds. We have one default feed called “Sourcefire Intelligence Feed” which is provided by Cisco and dynamically updated and downloaded every two hours by default.

We can find these elements by going to “Objects->Object Management->Security Intelligence“:

02-Jul-2015 12-43-21 PM

We can see the defaults squared green and what we added in blue. We have the option of adding a feed or list by clicking the “Add Security Intelligence“. We have the option to select the file containing IP addresses if we are adding a list, or providing the feed URL along with the feed MD5 sum if we are adding a feed:

02-Jul-2015 12-48-30 PM

02-Jul-2015 12-50-55 PM

Let’s stick to what Cisco provides us with…

How do we utilize this security intelligence? Well, we attach it to our “Access Control” policy, by going to “Policies->Access Control->WP TEST POLICY->Security Intelligence“:

02-Jul-2015 12-55-06 PM

If we pay attention to the right portion of the image, we can see that the “Global Whitelist” is applied as a white list to any zone, while the “Global Blacklist” is applied as a black list to any zone. This order from the screen also means that the white list entries are evaluated first and thus take precedence over entries from black list. Also we have to have in mind that these lists and feeds don’t refer to source or IP addresses but rather just IP addresses. This means that if the bad IP address is detected as either source or destination – it is dropped.

Let’s now focus our attention to the left side of this screen shot. We can see feed elements classified into several categories:

02-Jul-2015 1-49-56 PM

None of these elements are included in either white list or black list. I don’t think that including these into white list makes any sense. But including them into black list makes perfect sense. In order to include these elements into black list, we select one or more of them, then under “Available Zones” we select appropriate zone that this selection applies to (by default Any zone is selected) and click “Add to Blacklist“:

02-Jul-2015 1-55-55 PM

Now these elements will be included in black list for this particular “Access Control” policy and any address found in these elements will be dropped without going through the detection engine.

We need to be careful here, because this can produce a false positives. For example, I had a situation where some IP was found in CnC category, and thus was blocked, but at the same time Cisco‘s Senderbase marked this IP as perfectly valid. If we had a situation such as this, we could place this IP in the global white list for this policy. We could also change the default action for some category from Block to “Monitor Only“. The block action is marked with the red letter X next to the trash can icon. If we wanted to switch some category to “Monitor Only” we would right click the category, for example “Spam” and select “Monitor-only (do not block)“:

02-Jul-2015 2-02-56 PM

Now for this category, the Sourcefire would not drop, but rather just log the event.

Finally, there is one more important thing to note about using “Security Intelligence” option. By default the black listed events are not logged. In order to make them be logged, we need to click the white paper icon at the top right part of the Security Intelligence dialog box:

02-Jul-2015 3-36-43 PM

And we select to log and where to log these connections:

02-Jul-2015 2-14-31 PM

In order to see the SI in action, we first need to save and apply our “Access Control” policy and then go to “Analysis->Connections->Security Intelligence Events“:

02-Jul-2015 2-17-44 PM

From this colorful screenshot, we can deduce several things:

  • The action is Block because of IP Block reason (Security Intelligence)
  • Initiator IP is trying to reach some hosts that are known to be malicious
  • The connection is dropped because the responder is known to be
    • either CnC host or
    • phishing site
  • The initiator icon is colored pink, which indicate an “Indication of Compromise

Let’s see how to blacklist/whitelist some IP. First we check that our lists are empty. Under “Objects->Object Management->Security Intelligence” we click the yellow pencil icon next to “Global Blacklist” or “Global Whitelist” lists and make sure they are empty:

02-Jul-2015 2-29-41 PM

Now let’s ping some valid IP:

02-Jul-2015 2-34-23 PM

Which is what we would expected. Let’s go to the “Analysis->Connection Events->Events” and make sure of it:

02-Jul-2015 2-40-24 PM

As we can see, our ping went through. Let’s now right click the responder IP under the “Responder IP” column and click “Blacklist Now“:

02-Jul-2015 2-40-40 PM

And confirm:

02-Jul-2015 2-41-03 PM

Let’s now re-check our whitelist/blacklist:

02-Jul-2015 2-46-07 PM

We can see that the is blacklisted. If we try to ping it again, we have different result than before:

02-Jul-2015 2-49-27 PM

02-Jul-2015 2-52-18 PM

We can see that now the connection is blocked and the reason is “IP Block“. Furthermore, we can see that the block is done with the help of “Global Blacklist“.

A perfect time for an important note: if we add something to whitelist/blacklist, we don’t have to reapply our “Access Control” policy. On the other hand, when we remove an IP from either list, we have to reapply the policy. Another good job interview question 🙂

Finally, let’s do another cute thing. Let’s whitelist this IP:

02-Jul-2015 2-57-50 PM

And check our whitelist/blacklist:

02-Jul-2015 3-01-19 PM

Now we have in both lists. What will prevail? If we red the blog carefully up to now, we have the correct answer – whitelist overrides blacklist:

02-Jul-2015 3-04-05 PM

At the end, let’s do a cleanup and remove the from both lists. Remember, we have to reapply our policy after removing items from lists.


Thanks for reading!


This entry was posted in ASA, Cisco, FirePOWER, Firewall, IPS, Security, Sourcefire and tagged , , , , , . Bookmark the permalink.

18 Responses to Sourcefire Security Intelligence

  1. mikgruff says:


    Again thanks for preaching some Sourcefire. I have been deploying the Sourcefire/FirePower solution for a little under a year. All of your information is spot on every time. I learn something new EVERY TIME you blog about Sourcefire. Thanks so much for all that you do.


  2. Pingback: Sourcefire File Policies (aka Advanced Malware Protection) | popravak

  3. Justin says:

    Sasa, Please help me, I’m losing my mind. Awesome Guide. There’s just 1 thing I cannot figure out.

    In order to see the SI in action, we first need to save and apply our “Access Control” policy and then go to “Analysis->Connections->Security Intelligence Events“:

    I’m under Analysis->Connections and do not see ANYTHING for Security Intelligence Events. It looks like its a column on the blue bar, but I do not see it on my columns.

    Thanks for any help , Justin

    • Sasa says:

      Not really sure I’m following you. Is there something wrong with your display or you just can’t see events? Can you share a screenshot?

  4. Justin says:


    Sure –

    Analysis -> Connections, and I do not see anything my Security Intelligence Events. I made sure that these are logged in the Defence Center. Thanks again, Justin

    • Sasa says:

      Hi Justin.

      You are looking in a wrong place – “Analysis->Connections->Events”, but you should look in “Analysis->Connections->Security Intelligence Events”

      • Justin says:

        I found the issue. Security Intelligence is column is not listed by default. I had to click the “Table View of Connection Events” red text link, below “Connection Events(switch workflow)”. Thanks for your help, the guide is good.


  5. DavidC says:

    I created a local whitelist and applied it to both sensors. However, I am still seeing at least one whitelisted IP showing up under my Intrusion Events tab. Confused as to why…

    • dmaple5495 says:

      The only purpose of a whitelist is to bypass a blacklist. It does not prevent Intrusion policies from inspecting and blocking traffic. An example of this use is if you have addresses you never want blacklisted, no matter what list they are on, you can add that to a whitelist.

      Example: We host some websites through Akamai Edge (caching). Requests users make go to Akamai first and then Akamai connects to our origin servers to get the content. If we see a lot of intrusion events coming from a particular IP and decide to blacklist that without doing some research, we could block one of those Akamai Edge addresses and break the whole site. So, we have a whitelist that contains every address that Akamai Edge uses to get to us.

      It would be amazing, if the SourceFire could allow us to apply the SI logic to the original client IP in the HTTP header. Maybe some day…

  6. Chakuttha Riyaphan says:

    Respond category object what is it ? please explain for Definition Thank you :)))

  7. Pingback: Sourcefire Security Intelligence – DNS Policy | popravak

  8. mikgruff says:

    As always thanks for the in depth explanation…You Rock!!

  9. dalma says:

    I’ve been reading your blogs and I love it!!

    one q on SI:

    I’m running a test with an ASA5508 and Firesight.
    why is security intelligence by default filled up with addresses (responder ip) like : (phishing) (suspicious) (suspicious)

    more than 1500 rows.

    why would google dns multicast and broadcast address be visible in SI ? why would sourcefire alert on these addresses ?

  10. says:

    Will SI entries in Global Whitelist override Access-List on ASA? Curious regarding order of operation here.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s