We should have in mind that the Sourcefire is not by any means a SIEM solution. This correlation thing is most powerful weapon of SIEMs, but with Sourcefire we have the also some capability to correlate different events. The main idea behind correlations is to tie several events together in order to make a decision on something in our network is acting bad or not. So, how does Sourcefire do that?
In our Defense Center or DC (I believe they don’t call it DC any more, but I just got used to it) we can create a Correlation Policy which will alert us if certain criteria is met. This criteria can be almost anything that our SFRs collected while doing a network discovery. We will see examples in just a second. A correlation policy consists of Compliance White List and/or Correlation Rules. The following diagram can help us understand the architecture of correlation policy.
As we can see, the policy can contain one or more compliance white lists and/or one or more correlation rules. There are one Default White List that is not assigned to any policy by default, but we can also create our own white lists, as we will see. By default there is also no rules in a policy, but we will create them as well.
Further down our diagram, we can see that the compliance white list, either default or custom, contains one or more Target Networks and Allowed Host Profiles tied to these networks. There is no point in having one but not the other. In fact, we won’t receive any violations if we don’t have both defined. This network-profile pair simply says what applications and protocols are allowed in what network. If the violation occurs – sound the alarm. For example, we can create a white list that contains a network 192.168.254.0/24 and we can specify through the host profile that on that segment we host only servers. So this is a server farm containing only web servers. Our host profile would state that in this segment is allowed only HTTPS as a server application and that only a Linux server is allowed. If somehow anything else appears in that segment, for example an attacker or a rogue admin installs a FTP server or begins surfing the web from that segment, an alert would be generated and an action would be carried out. Nice!
Our target network can be The Entire Network, which contains all hosts our DC knows about, or we can create a Custom Network and cover only hosts we want. The entire network is defined as 0.0.0.0/0, which means anything and is tied to default white list. If we wanted to create our custom server farm such as one from the paragraph above, we could give it a name and list 192.168.254.0/24 as the address space.
When it comes to the allowed host profiles, there are three types of those. Each type servers the same purpose but is used differently. We have Global Host Profile which defines any operating system. This profile is a member of any list we create and it does not specify any applications but rather only allowed protocols. This profile basically describes any network capable device. This host profile is recognized as being written in bold and called Any Operating System within a compliance white list:
The second host profile type is Shared Host Profile. As the name implies, this profile can be shared among many white lists. We can create this profile or it comes predefined. If it is predefined, then it is listed under Built-in Host Profiles within a white list. These profiles are defined by Cisco and there are tons of them. Each of these profiles contains application categories that are typical for that host profile. For example, this is what makes typical Debian Linux:
We can see that one Debian typically runs a DHCP server (really???), a SSH server and a FTP server. Further more, typical Debian does not run any client applications and we find all standard protocols on it (ARP, IPv4, IPv6, TCP, UDP and icmp). The predefined host profiles are distinguished with a small gift package icon next to its name. We can tweak these profiles and revert them back to their defaults if we are not satisfied with modifications we made. I would most likely remove the DHCP server from Debian profile, but that’s just me 🙂
We can define our own host profile. This can be done manually, when we define such and such applications, or we can find some host already known by network discovery process and make it a shared profile. For example, a specific Windows machine is selected to represent a host profile called pop-400g2 and this host profile is based on the network analysis process which identified this PC as a Windows 7/8 with applications that are identified at the time the profile is created:
At the time this blog is written, no Windows 10 OS host profile existed.
Finally, there are Operating System Specific host profiles which describes what apps a certain OS should run. Debian from the above paragraph is actually an OS host profile. A shared host profile is actually a OS specific host profile.
To sum up, each compliance white list should have a target network, which describes a portion of our network that has some significance to us, and allowed host profiles that can contain elements that belong to one of four sections:
- Allowed Application Protocols – contains server side applications, such as RDP or SSH
- Allowed Clients – applications that run on a client PC, such as web browser
- Allowed Web Applications – applications that uses a HTTP protocol (Gmail, Linkedin)
- Allowed Protocols – ARP, IPv4, IPv6, TCP, UDP or IPX
Now when we know everything about compliance white lists, let’s create a scenario. We want to pay attention to a network segment 10.0.0.0/24. This segment has some importance to us. We will create a custom white list that will have this segment as a target network with all operating systems detected by network discovery process so far. Then we will assign this white list to a custom correlation policy. Finally, we will plug in in that segment a PC that should not be there and see violation triggers. Let’s go…
First, let’s define our white list. Under Policies->Correlation->White List, we click New White List from the top right corner. First we fill the target network in:
If we just click Add here, we will have to specify allowed protocols and applications manually. This can do the trick, but it is time consuming and we want to make use of the network discovery process ran so far to fill these for us. So we click Add And Survey Network. We give this list a name and we can see that we already have our allowed host profiles filled in:
We have to have in mind that there is no network scanning process involved in this step. The operating systems we see in this segment are result of the network discovery process running up to this point. This process discovered operating systems above. We make note that there is no Windows server listed here. When we are done with the testing, the server still won’t be listed here because it will be detected as Windows7/8, but if we pluged in one HP-UX server, for example, it would show up here. Let’s pretend that the Windows server is forbidden in this segment. We will introduce one later and provoke a compliance violation. For now we click Save White List.
Now we create our correlation policy and assign this white list to it. Under Policies->Correlation->Policy Management we click Create Policy. We give it a name and click Add Rules to assign correlation rules or white lists to this policy. We will deal with the correlation rules in the next blog post, so for now we just assign a white list to this policy:
We select our list and click Add. Before we save this policy, we should have in mind that we can assign an action to the violation event. By default only an alert will be logged to the DC, but we can run certain actions, such as send an email, SNMP trap, send the message to SIEM or even try blocking such events. For now we will specify no further actions, so we click Save to save policy. Important thing about correlation policies is that we don’t have to attach it to anything. They are active as soon as we save and activate them by clicking Activate icon on the right. Here we can see one active and one inactive policy:
As soon as we activate policy it is running and waiting for violation to occur. So, let’s introduce a Windows server 2012R2 into network…
Once we place this server in this segment a violation occurs which can be observed by going to Analysis->Correlation->White List Violations:
Here we can see a server called w2012r2.popravak.local with the IP address 10.0.0.135. Now, if we select this server and click View, we will see all events that violates the policy:
Now we select one event and click View again to drill down in more details:
We can see here details about this host and with a black exclamation mark is marked a protocol or application that violated our policy.
If we go to Analysis->Correlation->White List Events, we can see the actual reason for this violation:
If in this segment a Windows PC appears with, for example, VNC protocol on it, this will also be reported as a violation, because this protocol is not allowed as per our white list specification:
If these Windows server and Windows PC stay here and policy sticks, we will see more and more violations as they are being discovered.
The violation can occur for number of reasons including:
- when the OS changes
- when a new TCP/UDP server port is detected
- after an upgrade of a server application
- new client or web application is spotted on a host
- client or web application is removed from a database
- new network or transport protocol is detected
- jailbroken device is detected
- we add application, server or protocol to a host
- we delete application, server or protocol from host
- we change OS definition for a host
- we change one or more attributes for a host
Next time we will see the other part of correlation policy which are correlation rules.
Thanks for reading.