Webmaster 003 wrote: > I think the easiest way would be to buy a device with a consulting > company doing the backend stuff. Then the "user" can stay fat and > happy, with a set monthly cost. This is going to be far more expensive > than learning how to actually configure, update and monitor their own > box. This might well be an area where a niche consultancy could make > something. Lazy users are not an endangered species. In my experience, > most people want security devices and software that work like > refrigerators, which is to say, every 15 years or so, you have to get > something fixed or adjusted, or you have to upgrade the size (more beer > and sprouts). Since refrigerators are so simple, the main choice users > make is "does it match my decor." I have had very good experience with > respectable software firewalls on my windows boxes, and Snort, running > to let me know what sort of silly traffic actually gets through. My > high-risk users have been migrated to Linux boxes, and the number of > alerts in the network are way, way down. IPS/IDS is not a magic > bullet. Changing user behavior has been higher-yield than asdding more > software.
The novelty of an asymmetric environment where you're trying to support fat lazy users on one side and avoid smart economically motivated attackers on the other side had kind of worn off. The best you can probably hope for under those circumstances is to pick off enough of the low hanging fruit that the stupid one's are kept at bay. If you're a consultant winning on the low bid you don't exactly have the luxury of the billable hours or capex to do more than that. Speaking to the roi, someone already observed that in at least one environment it was concluded that patch management was addressing an overlapping set of low hanging fruit and that therefore the ips was no longer earning it's keep. It is plausible that the approach used simply comes down to style, and that the real measure of success is time and dollars spent on compromise mitigation which is likely much easier to quantify in some evironments than others. joel > On Mon, 02 Mar 2009 14:21:39 -0500, Stefano Zanero > <[email protected]> wrote: > >> Jeremy Bennett wrote: >> >>> This is a problem with the products, not the customers. The problem >>> being that there is still too much IDS thinking inside the IPS. >> >> Funny, since an IPS is nothing more than an IDS that can drop traffic ;-) >> >> Yes, I'm being humorous here, but really there is not that much >> difference in the two things, except for the marketing and the extremely >> different defensive posture: an IDS hunts for higher detection rates >> even at the cost of some false positives, whereas IPS aim at extremely >> low false positive rates. >> >> However: >> >>> So, I *should* be able to purchase an IPS, read the manual, configure it >>> according to my own risk profile, and then leave it alone. High-risk >>> activity should be blocked. Benign traffic should be let through. >> >> And then villains should be brought over to justice, and the greater >> good should prevail. >> >> However, getting back to the real world, doesn't work. You cannot >> configure "your risk profile" because there's no way on Earth to express >> that sensibly in a single clicky and yummy web interface. You can >> configure the system, activating and deactivating specific signatures, >> and - sorry - you WILL need to know damn well what you are doing. >> >> It is not just a problem with the products (and boy they are faulty), it >> IS a problem with the customers. A huge one. >> >>> Questionable traffic should be logged for later policy reviews. >> >> What would "questionable" mean ? >> >>> If I do >>> not have the ability to continuously monitor the device then I should >>> not have to do that. The device should regularly download updates and >>> apply them based on my configuration. >> >> Pray tell, how, exactly ? I think it's high time to stop thinking that >> somehow an "expensive enough" box will be able to do our homework for >> us. An IPS is a tool for applying specific signatures to traffic and >> block specific forms of attacks. Relating that with policies and >> weighing risks is a job for a human, and a skilled one, not for an >> algorithm. >> >> SZ >> >> > > >
