Last updated at Sat, 03 Feb 2024 19:56:35 GMT

Monitoring and protecting your company’s assets is one of the most important jobs you can perform. It can be tedious sometimes, but overall it can have the biggest impact to the business if compromised.

Having alerts set up in your SIEM, IDS and FIM solutions can ultimately keep you on track. Eliminating false positive results can be a whole different story. Being able to pick out false positives from your environment is a huge undertaking but grants great reward.

Below are some steps that you can take to help increase the effectiveness of your IDS solution on your network.

Types of Alarms

There are many different types of alarms that can be triggered on a network. By the end of this walkthrough, you will be able to fine tune many true false positives and exclude them from your results.

Here are a few types of alarms:

  • Traffic alarms
  • Equipment related alarms
  • Protocol alarms
  • True false positive alarms
  • Non-malicious alarms

You want your acceptable amount of false positive alarms within 10% of total alarms set off. For example, if you have 10 alarms go off, you can expect that at least one of them will be a false positive.

Intrusion Detection System (IDS)

Being able to look at your Intrusion Detection and Prevention Systems (IDPS) and determine if it is providing you with the appropriate alarms is vital. Below are some things to consider within your IDS configuration.

Type of IDS:

  • Signature based
  • Anomaly based
  • Protocol based

Tip: Remember to focus on the what you are really trying to accomplish with the alarms. Below are a few examples:

  • Malware
  • Web attacks
  • Database compromise

There are no real true steps to fine tuning your IDS to capture all the bad stuff. Ideally, there are methods that if followed consistently can help further refine already pre-defined alerts to be more effective.

Also, simply turning on your SIEM or IDS tool won’t make you safe. It will give you a starting point to build from, then you fine tune the rest.

A good starting point would be to conduct a packet trace on a couple of IPs that your current IDS has alerted you on. Being able to breakdown your alerts and create a more refined alert criteria is the goal.

Below is an example of how to run a packet trace of both network traffic and a select IP range (you would run these in CMD, PowerShell, or Bash (OSX, Linux, etc.) and would need admin rights or access to the particular server itself in order to see traffic).

tcpdump –D

This command will show you all possible interfaces that are discoverable. From here, you will want to narrow your search down to the IP that you received from your IDS alert  by running the following command:

tcpdump –n dst host (xxx.xxx.xxx.xxx)

This would display all IP traffic going to that host, you could also trace an entire subnet the same way.

tcpdump –n dst net (xxx.xxx.xxx.xxx/xx)

Now keep in mind there will be more than likely a lot of traffic you will see with these specific searches, so let’s continue to narrow down our results.

Take your IP that you found and run the following command to further designate the scan on just one port and traffic protocol type.

tcpdump –n dst host (xxx.xxx.xxx.xxx) and udp dst port 53

This command will trace any traffic going to and from that IP address through port 53 over the UDP protocol. Now we are getting into the good stuff.

This is where you will have to determine regular traffic from irregular traffic. Two main vectors of attack to focus on would be a lot of packets going outbound or a lot of packets coming inbound. Port 53 is reserved for DNS and if you are not properly blocking unwanted traffic inbound or outbound you can overload the port causing a ICMP flood attack which is similar to a “denial of service”. Some points to consider here when looking into your current IDS alerts is confirming that indeed this alert would be detrimental to this device, therefore we want to know about it.

To take this investigation one more step further we need to capture the Hexadecimal logs from these transactions. To do this use the following command.

tcpdump –n –x dst host (xxx.xxx.xxx.xxx) and udp dst port 53

As you can see we add the –x for also displaying the hex value of the log.

At this point we (based on the IP you traced) will be able to tell if there was an ICMP packet accepted or not and then we will have the HEX value of this packet for further investigation. At this point, you may be able to say “we should not have any ICMP calls coming in over port 53 to this IP”.

Boom, you have identified your first false positive! Now you can properly update your IDS to leave out scanning for ICMP flood attacks for this particular port and IP. But, if you can’t say that, then you will need to dig further into the Hex value to determine the intent of this packet.

Here is an example of a Hex value packet:

4400 00c5 9746 0000 0206 6e7b c0a8 01a0 ac30 02c8 0912 0050

The following items are values that can be obtained from decoding the Hex value:

  • IP Version
  • Header Length
  • Length
  • IP ID
  • Protocol
  • Src IP
  • Dst IP
  • Src Port
  • Dst Port

There are several free resources that you can use to decode Hex (mostly due to preference), Below are a few examples:

Once you are able to fill in the blanks, you will have a great understanding of what is actually happening over this IP and determine if you need to consult with the business to help identify an unknown integration you are not aware of or confirming that indeed this is a malicious attempt.

This is just one example of a false positive and a way of drilling down into it. There are many other ways and tools to accomplish the same results as well. Wireshark is one of the more popular choices in the industry and has a nice GUI interface. This approach is bare bones and will get the job accomplished without too much effort.

It’s also important to note that different operating systems will have different ways of obtaining this information. For example, Tcpdump is a Linux based tool whereas the Windump is the equivalent version for Windows.

Moving forward, you will want to continue to increase your IDS knowledge base. Keeping it updated and continuing to stay informed on security events will help keep your company as safe as possible. There are several committees, forums and newsletters that will not only provide you with current vulnerabilities but also fixes or trends based on attack vector. One example for the financial industry would be FS-ISAC. They provide updated reports on current attacks to help you determine what to filter for in your IDS solution.