Comment on Draft NIST Publications
Thanks to SANS I read this FCW story about new NIST draft publications, specifically Draft Special Publication 800-94, Guide to Intrusion Detection and Prevention (IDP) Systems (.pdf). I am worried about this document because it seems to imply that detection and prevention are equivalent functions. Recent Dark Reading stories like IDS/IPS: Too Many Holes? and IPS Technology: Ready for Overhaul have been critical of both technologies, but especially IPS.
Despite some vendor claims to the contrary, customers realize that the same inspection logic used to "detect intrusions" is supposed to be applied to the "prevent intrusions" problem. Since so-called "intrusion prevention" products were sold as devices that overcame "false positive" problems, many customers are disappointed are end up running their "IPS" in detect only mode. From this perspective, it makes sense for NIST to lump IDS and IPS in the same category.
From an operational and consequences-based perspective, IDS and IPS are completely different. Management generally permits an IDS team with passive sensors to do just about anything it wants, shy of using RST tricks to deny traffic. Management does not take the same approach with IPS, since an IPS is just a smarter firewall. One bad IPS rule and business traffic is interrupted.
While on this subject, I consider it unfortunate that the terms IDS and IPS even exist. Neither describes the actual function of either device. IDS as used by the vast majority of people seldom "detects intrusions." Rather, the technology is an Attack Indication System.
IPS is even more poorly named. An IPS is just a layer 7 firewall, so I would just as soon call an IPS a smarter firewall.
Finally, I read this press release:
[McAfee] announced that it has been selected to be deployed as the standard network intrusion prevention solution for the U.S. Air Force. The Air Force will use McAfee® IntruShield Network Intrusion Prevention System (IPS) and McAfee IntruShield Security Manager appliances to provide comprehensive and proactive protection for its worldwide non-classified and classified networks. The task order was awarded by the Air Force's Combat Information Transport System (CITS) program office to prime contractor Booz Allen Hamilton under the U.S. Air Force NETCENTS contract.
I'm guessing this is the end of ASIM?
Despite some vendor claims to the contrary, customers realize that the same inspection logic used to "detect intrusions" is supposed to be applied to the "prevent intrusions" problem. Since so-called "intrusion prevention" products were sold as devices that overcame "false positive" problems, many customers are disappointed are end up running their "IPS" in detect only mode. From this perspective, it makes sense for NIST to lump IDS and IPS in the same category.
From an operational and consequences-based perspective, IDS and IPS are completely different. Management generally permits an IDS team with passive sensors to do just about anything it wants, shy of using RST tricks to deny traffic. Management does not take the same approach with IPS, since an IPS is just a smarter firewall. One bad IPS rule and business traffic is interrupted.
While on this subject, I consider it unfortunate that the terms IDS and IPS even exist. Neither describes the actual function of either device. IDS as used by the vast majority of people seldom "detects intrusions." Rather, the technology is an Attack Indication System.
IPS is even more poorly named. An IPS is just a layer 7 firewall, so I would just as soon call an IPS a smarter firewall.
Finally, I read this press release:
[McAfee] announced that it has been selected to be deployed as the standard network intrusion prevention solution for the U.S. Air Force. The Air Force will use McAfee® IntruShield Network Intrusion Prevention System (IPS) and McAfee IntruShield Security Manager appliances to provide comprehensive and proactive protection for its worldwide non-classified and classified networks. The task order was awarded by the Air Force's Combat Information Transport System (CITS) program office to prime contractor Booz Allen Hamilton under the U.S. Air Force NETCENTS contract.
I'm guessing this is the end of ASIM?
Comments
I have no idea why we/they went with McAfee, as it is possibly one of the worst IPS's on the market, however, someone in the DoD must be in bed with them, because I heard that Army is looking at McAfee too.
Many of the services are looking at McAfee as their sole ids/ips/xxx for their entire service, kindof scary, next thing you know they will all use the same OS...........;)
"IPS is just a smarter firewall. One bad IPS rule and business traffic is interrupted."
I dont buy that. If anything, the inline IPS setups I've seen are done as dumb firewalls since they dont tend to be done in a source-destination orientation. Every install I've seen to date is basically set to stomp on any traffic that is percieved as "bad", regardless of where it came from or where its going. At best I've seen source/destination used as exceptions to cut down on false positives.
"An IPS is just a layer 7 firewall"
You are kidding right? I mean I see that you could use such a box that way, but IPS just isnt designed for that kind of usage at all.
As with the quote before, the problem remains that I've yet to see IPS done in a way that aligns the business needs with the realities of the network.
You probably want to check out how "IPS" is actually designed. Sourcefire uses IPTables as it's 'blocking' mechanism. Last time I checked, IPTables was a packet filtering firewall. How else does an appliance 'block' network traffic? There are other implementations, but they are even more dangerous..imagine actively manipulating router ACLs...yikes.
Oversimplified but true. By that logic, ACLs on routers are "enough". Lets not be silly though. Otherwise I think you agree with me that default deny is the better position.
Anonymous: yes I know how Sourcefire does it. I've seen good ol' TCP RST more often than not and more than a few shun source IP implementations.
IDS (by any other name) is still a great tool for detecting anomalous traffic, however, even inline, its a very poor substitute for a correct firewall archetecture. NB that whenever possible I try to build out a firewall with a combination of layer 3 and layer 7 inspection tools appropriate to the protocols involved.
Bottom line: look at the effect the technology has on the traffic, now the way it operates. I've been differentiating between passive devices (sensors) and active devices (firewalls).