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.
