From a McAfee product perspective, the Global Threat Intelligence (GTI) feed is a nice one for users of the SIEM.  You get many data feeds normalized on IP address (source or destination); you have a great fit with a source that tells you which ones have a reputation for being malicious or suspicious sites.  There are many great correlation rules that can be written to take advantage of FTI: successfui login from a GTI suspicious source, DNS communication with a GTI malicious source, and many more.

 

How do you take advantage of the GTI feed when you are keeping an eye on the overall risk level across your perimeter? 

 

I thought it was a good example to frame up the questions to ask when you are putting a risk correlation manager in place.  This post does not cover setting up the GTI feed with the McAfee SIEM (add a comment if you'd like to see a post or demo video on that topic).  From here we assume that you see two GTI related watchlists available, one for suspicious and one for malicious.

 

What do I filter?

While the filter tab is last in the editor, I usually start there.  Since you have a watchlist (stick with malicious only for now), you know you want IPs that match that list.  Traffic could be coming from that malicious source, or it could be going to it.  Unless your internal network is on the watchlist , it will be one or the other.  So your filter might look like this.

GTI risk filter.png

What fields do I include? What percentage of each?

Now that you know are getting the events you want to score, you have to figure out what you want numbers you want to use to quantify risk.  In this case, it is pretty straightforward: you want either the count of events with a malicious source IP, or the count of events with a malicious destination IP.

 

GTI risk fields.png

When you choose what percentage each count will contribute, it will depend on the risk-based discussion that came out of your company.  If you are looking at all the traffic coming in, you might be getting an enormous amount of malicious source traffic (network probing, DoS, etc.).  If you are filtering by successful login, you would *likely* expect there to be more way more malicious outbound connections than inbound ones.  The safe bet is above, splitting them down the middle, but your risk conversation may steer you toward weighting source traffic over destination traffic, or vice versa.

 

Which fields do I correlate?

In the screen shot above, I chose to check both source IP and destination IP fields.  When you select a field to correlate it causes it becomes a key.  Since you can have traffic that will have a malicious destination or a malicious source (but highly likely not both), you need keys from both fields.  While doing correlation on two fields of high cardinality is not recommended, remember that you are filtering down to a small enough number of IPs for this not to be an issue.

 

Which thresholds to set?

This is the part where mileage does (and should vary).  Some folks think qualitatively about risk, while others think quantitatively.  You want to make sure that the right message gets communicated.  From my brain, you want to set thresholds that correspond to the right impact.  If an infected machine is communicating with a command and control server, you may not see a lot of traffic; this doesn't mean its not a risk or you don't want to know about it.  However, if an external IP is bombarding your network with malformed packets, this will likely cause a disruption in some form in short order.  One is a risk to confidentiality or integrity, the other is a risk to availability.  How do you configure thresholds to be effective for both types of risk?

 

GTI risk thresholds.png

One suggestion is to use Critical as a bucket for a denial of service/critical availability indicator, major as an indicator of a significant outbreak (virus/botnet), and the rest of the categories as a way to separate the risk based on frequency.  The idea here is to move out the annoying or dangerous noisy events from the ones that need a quieter background to follow up on, using threshold as a way to do this.

 

Another thing to point out is the numbers themselves: the ranges or buckets they represent, not the actual values.  Phenomena like network traffic does not usually fit a normal distribution (the "bell curve" we hated in school).  It is something more like an exponential distribution; although it actually a little more complicated than that, it's closer to that than any bell-shape.  If you truly want to bracket out risk for effective risk management, you have set thresholds in line with the distribution.

 

Do I Stop There?

No way.

Once you start getting risk event data flowing into ESM, you can go much, much further.  You can add the Malicious watchlist to the OR filter above.  You could start over and use GTI traffic as just one input to the reputation of an IP, gettting a certain percentage of the risk score based on the weight you want to give it.  You can add several GTI-specific correlation rules and then use those to calculate risk for specific threats.  Or, best of all, you can add ideas as a comment below

 

Grant Babb