Make the most of your IDS by beefing up your incident reports

by Michael "Mullins CCNA, MCP" | Jul 20, 2006 4:43:00 PM

Tags: Intrusion detection, Network security, SECURITY, Michael Mullins CCNA, MCP, intrusion detection system, Security Solutions Newsletter

Takeaway: Intrusion detection systems have come a long way in recognizing and reporting security events, but it's not enough to know that an incident has occurred. To truly benefit from an IDS, you need to do more than report detected events to your superiors—you also need to provide enough information so someone can properly respond to the incident. In this edition of Security Solutions, Mike Mullins tells you what a detailed incident report should include.

Intrusion detection systems have come a long way over the past few years. Almost all organizations have some sort of intrusion detection system (IDS) running at the network and/or host-based level, and almost every IDS will automatically report bad or anomalous behavior via a console and e-mail or paging.

If configured properly, the IDS will do a good job of catching intrusion events that it knows about. It's typically the job of the security staff to monitor these events and report any problems to the manager and/or network administrator.

Once the IDS alerts you to something going on, the typical response might be to call or e-mail an administrator to impart this information. But before you make the call or send the e-mail, take a minute to consider how best to present the information. You need to find a way to translate this report into detailed information and actionable suggestions that will help defend your company's network from hostile attacks.

For example, you could say something like, "We're seeing an SMB service sweep coming from 10.100.64. 10 and BitTorrent activity from 10.100.55. 23." However, while this information might seem useful to you, it has little or no value when it comes to the administrator who has to take action on your report.

To truly benefit from an IDS, you need to do more than report detected events to your superiors—you also need to provide enough information so someone can properly respond to the incident. Here are two examples of a solid, detailed report:

Example 1:

Alert Name:SMB_Service_Sweep
Date: 7/20/06 14:02 EST
Source:10.100.26.73
MAC: 00-12-F0-3E-BE-32
Machine Name: N2320-1
User: unknown
Destination:10.100.0.0
Analysis: Service sweeps are being conducted on the entire 10.100.0.0
range. Such large-scale scanning is unusual and should not be taking
place without prior coordination with the security administrative team.
The Server Message Block (SMB) service runs on TCP port 445.
Recommendation: Physically locate the source machine and discontinue
the activity, or deactivate the switch port if deemed unnecessary.

Example 2:

Alert Name:P2P_Activity
Date: 7/20/06 14:04 EST
Source:10.200.59.180
MAC: 00-12-F0-3E-BE-12
Machine Name: A1320-5
User: Bad.User
Destination:10.1.0.7 (proxy)
Analysis:Peer-to-peer activity has been detected from an internal
machine. The user may be using a BitTorrent client to share software.
BitTorrent requires TCP ports 6881 to 6999. At the time of this
reporting, the user "Bad.User" was logged into the source machine.
Recommendation: Implement a network block from the internal network to
the Internet on TCP ports 6881 to 6999. Log on to the machine to
determine if the software is installed, and remove if found.

In both of these reports, you've now given the system administrator:

• The type of alert
• The time the activity occurred
• Information on the source address (to help locate the machine)
• The logged-on user (if known) during the alert
• The direction of the activity
• Your professional opinion of what occurred
• Suggested actions to respond to the event

Final thoughts

The IDS has come a long way in recognizing and reporting security events. But it's not enough to know that an incident has occurred. As a security administrator, it's your job to turn the IDS statement into an actionable report that includes enough information so the organization can respond appropriately to the incident. That's why your report should always include a professional analysis and recommended courses of action.

Miss a column?

Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.