The problem with network intrusion-detection systems (NIDSes), as any frustrated security manager knows, is they generate a lot of false positives, false alerts, false alarms, etc. It’s hard to separate the wheat from the chaff.<\/p>\n","protected":false},"excerpt":{"rendered":"
Most commercial NIDSes depend on attack signatures to identify malicious or out-of-policy activity. Signature-based NIDS is a very CPU-intensive technology. Before comparing packets against the NIDS database of a thousand or more signatures, the sensors also have to perform a variety of compute-intensive operations such as HTTP normalization, converting URLs in HTTP data streams to a canonical format so that they can be compared against a list of known bad traffic. To keep from losing packets, NIDS signature writers generally only match against the minimum amount of data needed to validate an attack.<\/p>\n
Some IDS vendors are working on making their signature and detection engines smarter, but others are taking a different path: target-based IDS. Take additional information about systems and change the signal-to-noise ratio to increase the signal and decrease the noise. You’d still get an alert for an attack packet, but if the attack were simply noise, the alert would be given a low priority.<\/p>\n
Early entries in this field include Tenable Network Security’s Lightning Console, Cisco Systems’ Cisco Threat Response (CTR) and Internet Security Systems’ Fusion. These products combine traditional network scanning and vulnerability analysis with IDS alerting consoles. They all take in the raw alerts from your IDS consoles, but they “qualify” each alert based on whether your system is actually vulnerable.<\/p>\n
The result: Far fewer alerts and analysis in minutes instead of hours.<\/p>\n
This article takes a look at the nature of the beast these new tools are trying to tame.<\/p>\n
More info: [url=http:\/\/searchsecurity.techtarget.com\/tip\/1,289483,sid14_gci944401,00.html]http:\/\/searchsecurity.techtarget.com\/tip\/1,289483,sid14_gci944401,00.html[\/url]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1282","post","type-post","status-publish","format-standard","hentry","category-product"],"_links":{"self":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1282","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1282"}],"version-history":[{"count":1,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1282\/revisions"}],"predecessor-version":[{"id":3769,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1282\/revisions\/3769"}],"wp:attachment":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1282"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1282"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1282"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}