Intrusion detection software best practices

If you or your organization is planning on implementing some form of intrusion detection software, it’s imperative to first understand the requirements and scope of the project. Depending on the size of your organization, you might not have a ton of resources to throw at standing up an IDS or IPS in your environment. 

While many different commercial vendors offer intrusion detection capabilities in their solutions, it’s important to first understand your needs and goals.

There are open source technologies available which we will dive into more in future articles, but most commercial offerings tend to be expensive. The cost associated with these technologies typically come from the following components:

1. Product fees (software license costs or hardware/appliance costs)   
2. Implementation fees (professional service fee for setup and configuration)
3. Maintenance (who on your team is responsible for maintaining the tool?)
4. Tuning (who on your team is responsible for properly tuning the system?)
5. Responding (who is actually using the tool to detect threats?)  

Intrusion detection product fees

If you are not using open source software such as Snort, Suricata, etc., you will have to go with a commercial vendor. In later articles, we will discuss the benefits and downsides of using open source detection technology, but we will now focus on commercial solutions and their costs. 

Some of the benefits of using a commercial product are that you do not need to update the source code or make configuration changes or patches when new versions of the technology are available. The vendor typically takes care of that for you. This is nice but can get costly when evaluating various products and pricing packages. 

Intrusion detection and prevention implementation

Once you decide which IDS or IPS you plan to buy (or build), you need to implement the system in your environment. Typically, if you're going with a vendor, they will do a lot of this work for you, but this comes at a price. They will still need to work with someone technical on your team to properly implement and configure the tool.  

If you're using open-source software, then your security engineer usually will work with a network engineer or admin together on the following:

• How the tool works
• Will we deploy on-prem or in the cloud
• How many sensors are required for this deployment
• Where in the network to place the sensors

If you go with a commercial offering, the vendor will still need to work with someone on your team to answer the above items; however, typically, they are responsible for deploying the system. 

Intrusion detection maintenance

So you’ve finally selected what type of detection system you want, and you’ve just implemented it in your environment. What is the next thing you need to do (aside from making sure it’s properly configured)? Maintenance.

Whether you go with a commercial offering or use open source, you will have to do this. Although the maintenance might be less with a commercial offering, depending on who you go with. Maintenance is required to keep the system up and running smoothly after being implemented. This typically involves performing any required updates regularly and consistently checking the hardware's health. 

This task is not as glamorous as responding and using the tool. However, it is just as important. If the system is not healthy or has not been updated to the latest stable version, it might not be detecting the latest threats. 

Intrusion detection tuning 

Next, we need to tune the system. This ongoing process requires constant iteration depending on how complex your network is and how often you add new resources and services. When an IDS is first deployed in an environment, it is typically very noisy. We need to create and update the variables to tune out the noise and focus on only the traffic and alerts we care to see.

First, you need to select relevant rules that are appropriate for your organization. Then you need to tune and update these rules as new signatures come out and things change in your network. Tuning is typically not the most glamorous part of an intrusion analyst, but it is required to produce good signatures that can catch malicious activity. 

Responding to intrusion detection alerts

Once the system is set up and configured, the fun begins: responding to the alerts.

You will most likely have a lot of false positives when you first deploy, but that's where tuning comes into play. Once everything is tuned correctly, you can then take action on the alerts the IDS produces and respond accordingly. 

Some intrusion detection systems have dashboards that show counts of Critical, High, Medium and Low alerts and a breakdown of where the traffic is coming from. Others have panes that display alerts in a table view. Typically you will start with investigating all the Critical and High alerts and (if you have time) then move to the Medium and Lows. When you’re investigating an alert and find a false positive, you can always tune the system so that the alert does not appear again in future investigations. 

Working with IDS tools like Suricata

We talked about the basics of intrusion detection systems and some of the best practices behind maintaining and tuning them. In the next article, we will look at an open-source IDS called Suricata. We’ll discuss some of the architecture and break down the parts of a rule/signature.   

Want to learn more? Take my Advanced Intrusion Detection courses in Infosec Skills.