One of the sources we use to identify incidents is the network-based intrusion detection system (NIDS) that most of our enterprises have, at least at the border, at our known internet connections.  The NIDS, however, can be pretty noisy, how do we turn the noise into actionable data?  How much access does the incident handler have to the raw NIDS data?  As Steve pointed out yesterday, the alerts from the NIDS are just events, they don't become an incident (usually) until these events have been correlated with other data.  How do you use NIDS data to indentify incidents requiring activation of your IH process?  Let us know via the contact page and this story will be updated throughout the day.

Update 1:

From David:  This is a great question, but I'm really interested in the answer to a related question: "How do you use non-NIDS data to validate NIDS alerts?"  I don't have to tell you guys that the amount of data that comes from a single alert is sometimes very skimpy, and doesn't always provide good decision-making support.

As I evaluate an alert, I routinely ask myself a series of questions, then try to find the answers.  In most cases, the questions are something like:

1. Was this an actual attack?
2. If so, was the attack successful?
3. What other systems may also have been attacked?
4. What activities did the intruder try to carry out?
5. What other resources were they able to gain access to?
6. How should we contain, eradicate and recover from the intrusion?

Most of these questions are difficult to answer just by looking at an individual alert, but I can usually answer them quite easily (and quickly) by examining sessions and/or PCAP data.  Well, except for #6, which is usually pretty tricky.  

I'm curious to know what your other readers are doing to validate their NIDS alerts, even before they feed into the incident handling processes. 

So, what do you think?  Keep the thoughts and ideas coming.  Over the next couple of days, we will be looking at some other non-NIDS sources for identification, but there's no reason we can't start some of that conversation today.

Welcome to day 5 of the Cyber Security Awareness Month and the first day of what is the second half of the steady state that incident handling teams work in. When everything in the Incident Handling world is good, handlers rotate around the step Preparation and Identification. But what triggers the move to step 3, containment?

This is why today we discuss Events versus Incidents.

An event is the name given to the pieces of information which flow into you incident handling process.

An incident is the event which triggers when you determine that an event is malicious.

So, how does your incident team perform this crucial task so you know you've not missed anything? What hints and tips can you give your fellow incident handlers to improve their detect rate, or to make the job easier?

What questions do you ask of the event reporter which improves your decision making? How do you gather this information?

Drop me a note during today, and I'll update the diary with your advice!

Update:

Janantha wrote in saying:

I assume that in the preparation you have compiled a list of Windows Event Id's that are related to popular incidents. Also if your in Linux you know the Regex to parse through the log files.

1. Make a habit to review the log files daily or regularly! Also keep in mind of attack patterns so you recognize attacks just by browsing through the event log!

2. Look for critical event id's that may have indicate irregular behavior. You can do this by using tools like Event log explorer which is free of charge as it provides powerful interface to sort your events and go through them in a proper manner.

3.Cross reference multiple logs (firewall logs) to verify if the event is actually an event that is worth taking any action!.