In our on-demand webcast, Secrets to using IDS and IPS effectively,
guest speaker Jeff Posluns offers tips for using an IDS/IPS for proactive vulnerability management and to gain insight into the state of a business' security. Here, Jeff answers user-submitted questions from the live broadcast.
Should only one member of an Information Systems Security team receive IDS alerts or should multiple members as well as possibly members of the company's management team?
The answer to your question should be a management decision based on the following:
- A lot of alerts that come from an IDS are false positives.
- A lot of alerts that come from an IDS are not related to urgent issues.
- A lot of alerts that come from an IDS do not require immediate follow up.
- A few of the alerts that come from an IDS should be investigated.
- Very few alerts require immediate action.
Here are my thoughts on the matter. If there is a person on call, or an on-call schedule, only the person on call needs to be notified. If you have spent a lot of time/effort/money tuning your IDS, do not get very many alerts and need to consistently follow up on them, perhaps a ticketing system would be best, in which case the IDS creates a ticket, a member of the security team is paged/alerted, and if the ticket isn't updated in four hours, then a manager is paged. I've seen a few ticketing products that work on this premise.
Aren't IPSes fraught with peril since they can potentially prevent normal traffic?
Historically, IPSes caused more trouble than they solved, but with today's technologies, wrongful blocking does not occur often. Keep in mind that you can't just buy/install an IPS and leave it to do everything on its own. An IPS or IDS needs to be treated like a child; let it learn a lot on its own, but correct it when you can, and try to impart your wisdom to it as you can.
I've seen perhaps 200 IPS implementations, and of them all, I can only recall three where there were problems, and those were all due to abnormal inter-http server communications that were detected as bad traffic. Once that rule was fixed, which is something we do immediately on new implementations now, there is not too much to worry about.
I use Snort and am not very impressed with the quantity of false positives. I really don't respect the system as much as an OTS technology. Am I missing something?
The default Snort rule set does need quite a bit of tuning on most networks. You will most likely see a lot of false positive ICMP alerts and possibly some false positive DNS and/or HTTP alerts as well. If you install the Bleeding Edge rules, you'll see even more.
To have an effective Snort implementation, you'll probably have to spend a few days tuning rules, turning some things off and changing others.
The advantage of Snort is the ease with which you'll get updates, make changes to rules, create your own rules and work with the output. If you're looking for a solution to drop in, commercial software like ISS, NAI, Cisco and others are the way to go. If you are a technical person who wants to spend a few days or even weeks learning, then Snort is a better choice.
I would suggest contacting the guys at SourceFire, who have a commercial variant of Snort, and asking them about false positives and what you can do. I've seen their IDS appliance in action, and it required a lot less tuning than the default open source Snort.
Can an IDS detect port scanning? How?
There are a few ways that an intrusion-detection system can identify port scanning:
- It looks for connection attempts to the same IP on sequential ports (For example, connection attempts to port X, X+1 and X+2 within five seconds).
- It looks for connection attempts to a few specific ports that are not often used or are known to be Trojan ports (For example, connection attempt to port 31337, 12345 and more than two other ports in 10 seconds).
- It looks for more than a specified number of connections from one host to another within a certain time period (For example, more than 10 connection attempts to the same host from the same IP within 10 seconds). This particular method is a reason why DNS servers are often mistaken for port scanning hosts. When your computer uses a DNS server, say ns1.securitysage.com, it will originate connections from random high ports to port 53 on ns1.securitysage.com, and ns1.securitysage.com would always reply from port 53 on the same connection. To an IDS, this can look like ns1.securitysage.com is performing a port scan on another host that made a few queries within a few seconds.
About the author
Jeff Posluns more than a decade of experience in technology management, with technical expertise in the analysis of hacker tools and spamming techniques, intrusion detection, forensics and incident response. He has authored, edited and contributed to a number of books including Snort 2.0 Intrusion Detection and Hack Proofing Your Wireless Networks. Jeff is a trainer for the Certified Information Systems Security Professional curriculum and the founder of Security Sage, a security and privacy services firm.
This was first published in August 2005