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“:

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:

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“:

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:

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“:

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)“:

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:

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

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“:

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:

Now let’s ping some valid IP:

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

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“:

And confirm:

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

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

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 8.8.8.8 IP:

And check our whitelist/blacklist:

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

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

 

Thanks for reading!