This week I took a brief hiatus from security staff recruiting to attend the six-day Intrusion Detection In-Depth training class run by the SANS Institute Inc. in Cary, N.C.
Intrusion-detection systems (IDS) are something in which I've had to invest significant amounts of time of late, so I can readily put this hands-on training to use. I also wanted to hear the two speakers, whom I consider experts in the field. Stephen Northcutt is an expert in packet analysis. And since a significant amount of my IDS infrastructure is based on Snort, an open-source IDS application, I jumped at the chance to listen to its creator, Martin Roesch.
During the classes, Roesch provided a general history of Snort and its development into a commercial-grade packet-capturing and intrusion-detection tool, and he was eager to demonstrate some of its cool features.
I particularly liked a feature called session replay, which lets an administrator capture and replay the actions of a specific user. This is nice to be able to do if you suspect an individual of malicious activity. With session replay, you can capture the user's keystrokes and either replay them in real time or store them in a capture file for later analysis.
Fast and Furious
SANS courses aren't for the faint of heart. The curriculum is fast-paced, and students are expected to possess specific skills before attending. For the intrusion-detection class, students must already understand TCP/IP fundamentals such as IP addresses, ports and protocols, as well as TCP concepts such as flags, sequence numbers and the three-way handshake.
Security professionals not familiar with these terms shouldn't take this course. Those who did so ended up getting lost, falling asleep, wasting class time by asking basic questions and feeling frustrated.
Fortunately, I had the background, so I found the course stimulating. Northcutt spoke with great intensity, and it's obvious that he's comfortable with the subject matter he teaches. He moves quickly through the material, but if you understand the fundamentals, his lectures make for a fabulous training experience.
Most of the technical tracks SANS offers include a hands-on lab portion, and the intrusion-detection course was no exception. My class used the freely available packet-capturing programs WinDump, Tcpdump and Snort to view precaptured network traffic, which we also used in the data analysis portion of the class. In addition, we spent a whole day configuring and running Snort with Roesch. I had specific questions regarding the way I have Snort running at my company, and Roesch readily answered them -- both during and after class.
Another SANS course I've been looking into is Hacker Techniques, Exploits and Incident Handling. While attending the IDS class, I was able to get a copy of the course materials for this track, and it looks quite good. The program combines theory and hands-on exercises in hacking different operating systems and then follows up with incident-handling techniques.
In the past, I've been called into the CEO's office, shown a defaced company Web page and asked to explain why our IDS infrastructure didn't pick up the attack. Believe me, you want to be prepared. This will be my next SANS course.
Back to Reality
I returned from the SANS training to a series of 1.7 million Snort IDS alerts. These were primarily generated by employees using music- and file-sharing programs.
Since we're short-staffed, I'm currently the only individual responsible for monitoring the IDS alerts, and I was unable to do so while away due to slow dial-up connections. For serious issues, I had rules configured to send e-mail alerts to my pager. Thankfully, none was triggered.
During the class, I had the chance to share my IDS woes over music-sharing sites with the other attendees. They asked why I don't just block users from accessing those sites, since they're violating company policy. But we don't yet have an acceptable-use policy in place to address music- and file-sharing programs, and we can't control network abuse by implementing firewall restrictions until we have that policy in place.
The holdup is mainly because of European privacy laws, which are a bit more stringent than those in the U.S. For example, if our company policy is to filter e-mail for certain words that might be an indicator of malicious activity, as a U.S. company we can make a blanket policy statement. But European privacy laws require individual agreement before this filtering can take place.
Until those issues are resolved, we can't configure our firewalls to block access to those sites. We can, however, identify individuals who visit them and contact their managers. I mainly collect such traffic for identification. Yes, it doesn't seem right, but it's a political issue and a business problem.
Now that I'm back, I'm going to start putting my new IDS packet analysis knowledge to work. I've already reconfigured the way my sensors filter certain types of network traffic by having them drop the packets at the network layer, before the IDS software has a chance to examine the packets. This is also referred to as a Berkeley Packet Filter. It makes the IDS more efficient by decreasing the amount of traffic the IDS engine must process.
Now, of course, I've got to get back to filling those staff vacancies.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org, or join the discussion in our forum.