IDS device installed? Check. IDS seeing traffic? Check. IDS generating Events? Check. Analysts investigating Events? Ummm…..
Investigating IDS alerts is a process like any other; however the variable nature of Information Security often makes this process difficult to adhere to. Maintaining this process is the first step to managing your IDS and its generated events. Let’s examine the steps an IDS analyst can take immediately after the device has been provisioned.
Soak it up
It may sound counter-productive but one of the first things you might do is nothing. Nothing? At first you will want to take an observational approach. The events generated from the IDS device are a record of the currently normal behavior of your network. You will want to run the IDS without deleting events for a reasonable period, two weeks is a great start. There may be things you want to filter immediately of course, but reserve as much judgment as you can before seeing the patterns of your network. The act of collecting this data is a key component of the next step. (Other terms for this are Soak Period, Baselining, Maintenance mode….)
Evaluation [Question Everything]
After you’ve gone through the data collection phase, it is time to start making decisions. These decisions will revolve around the following questions:
- Which of these events are both valuable and applicable to my environment?
- Which events are network policy and not potential threats?
- Is the risk of the event properly evaluated?
- Which of these events are valuable for reporting?
- Who should be notified when this event occurs?
Answering these questions for the first time is best done in a group setting with the relevant stakeholders. In subsequent iterations of this process, usually only the analysts will participate, as the fundamental questions for each event can be applied through taxonomy. This decision process will be a recurring theme in IDS analysis and reporting as new signatures are released frequently. More on this below.
Cut the noise
Tuning is reducing false positives and unnecessary noise. The goal is to have actionable alerts and useful reports, not huge numbers of things to review. We adjust the current IDS posture based on what we learned from the soak period and the decisions from the evaluation process to reduce the number of events. In IDS terms, this is often called the Policy. A policy informs the IDS what is important and what is not, this same concept also carries over to SIEM. Policies can also be archived to maintain a snapshot of your security posture and also re-applied to future devices as part of your best practice.
There will likely be some amount of false positive (FP) reduction that needs to be done right away. Common examples are reply traffic from a busy server being flagged as a scan or multicast announcements showing up as P2P or VoIP alerts. Start with the most frequent alerts and work your way down, investigating them and figuring out if you have a recurring FP. When you do, tune granularly-- don’t pick up the big hammer and smash the signature (unless it’s really bad), instead create exceptions in your policy that prevent that specific alert from firing on those IPs and ports. The idea is to reduce noise, not to blind yourself.
Documentation
As exciting as it would be, not every investigation is unique. The same event or series of events is likely to occur again. Often this can be tuned and never seen again, however repeating an investigation can be a very costly effort and should be avoided. Documenting the results of your investigation is a key step to avoiding this repetition. It also has several ancillary benefits.
- If ever audited you have proof of your diligence
- New analysts can get up to speed quicker by reading previous results
- Metrics can be derived from this data for future automation
For some products, the Policy itself can be used as part of your documentation. If Policy changes, rules, filters or exceptions allow you to enter comments or descriptions use them to annotate who made the change, when and briefly why.
Preparation
With a disciplined process, IDS can be one of the most valuable tools for detecting threats that find their way past your preventative controls. Following the steps above will get you started down the right path to alerts and data you can actually use and apply your analyst skills to.
Want more IDS tips? Check out these resources "IDS for Security Analysts: How to Get Actionable Insights from your IDS".
Follow Joe on Twitter https://twitter.com/pkt_inspector