Snort mailing list archives
Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9
From: Martin Holste <mcholste () gmail com>
Date: Thu, 3 Feb 2011 10:31:40 -0600
Again I am not advocating completely ignoring malware or the CnC, but it only works if the assets connects to a segment being monitored by an IDS. In an organization where the majority of user assets are mobile, a stationary monitoring solution is not adequate. We have sales folks that might connect to the corporate network via VPN 2-3 times a month. I can't just write them off as lost. I have to aggressively protect them and my network IDS isn't going to be able to do that.
Your responses are certainly valid for your organization's case (mostly off-network devices). My point is that an IDS is not a defensive tool, it is a scorekeeper. It's not there to prevent infections, it's there to let you know when the defenses have failed.
If we are talking plausible hypotheticals then I'd say... neither. I'd take HIPS, Firewall, AV, and content filtering on a host built from a standardized image with limited user rights and white-listed executables with integrity checking and all managed under a comprehensive vulnerability management program. I'm not saying that is what I have, but if we are wishing that is what I'd want. That combination will out protect any IDS you can buy with any ruleset you can buy. And that will be true today and a year from now.
We have all of that and do all of that. We still had over a thousand infections last year. Again, IDS is not protecting anything. It's the canary in the mine that's dying to tell you when protections fail.
I don't disagree with the first part of this, but I'm also not ready to throw in the towel for "defense" and allocate those resources to just cleaning up the mess created from a "resistance is futile" mindset.
Re-imaging takes resources, so any preventative efforts that can be made have a linear return on investment. We simply can't afford to throw in the towel and resort to clean-up, because that's too expensive for re-imaging alone. What I'm saying is that expect to do some clean-up, regardless of how many defenses you erect. However, in order to find the hosts that need cleaning, you're going to need an effective IDS. So, when you're allocating resources to erecting defenses, don't forget that you need to allocate resources to your scorekeeper.
That is why writing to the vulnerability is preferred over writing to the exploit. That mindset switch was made back around the 6000-7000 SID time frame.
This used to be a true statement. Unfortunately, you cannot "write to the vulnerability" on the network anymore. This is the same as writing to the exploit because it will be encrypted and/or encoded. The shift that has still not occurred is the understanding that all of the actual exploiting of vulnerabilities is done on the host, not the network, because the network is only transporting the encoded exploit to the host where it is then unpacked and executed in a client-side app. This is why I'm not telling people to stop installing AV/HIPS and I'm still saying that patching is important. This is why I AM very skeptical about IPS effectiveness for blocking exploits.
I agree, but again your area of coverage is very small when compared to everywhere that asset can go. If we limit our view to our network, then there is still a better way to catch this stuff than traditional IDS. You touched on it a bit. Correlation. Take those two pieces of information, combined with log and flow data from the hosts and a good baseline traffic profile. You'll catch far more than just malware. You'll catch insider abuse and data theft/loss as well. And for no extra cost you'll find misconfigured systems/network gear too.
I'm including flow analysis/correlation under the umbrella of "network IDS," so I agree with you here. I will add that flow anomalies are even more false-positive prone than content signature anomalies, so it's a formidable task to do effectively in a large org. That said, go grab the Zeus IP list off of abuse.ch and run your flows against it. It takes little effort and you won't be sorry!
1) Is that JAR on the white-list? No? I'm not overly worried about it then.
That sounds nice. I wish I had that, but I can't for reasons you touch on below (whitelists are hard to maintain and a burden on the enterprise):
2) Oh how I wish I could just write areas of the globe off. In 10 seconds can think of 5 countries I would outright block at the edge if I could. The problem is in a multi-billion dollar company with a global sales presence you can't do that. Of those 5 countries I'd write off, we have an office in 2 of them, so not everyone is afforded the luxury of geographic blocking. I run all the IP based known/possible bad host rules from the ET set. Most of the lists are pretty good indicators of something that needs to be looked at, but 90'ish% of the hits we get from the RBN lists are for legitimate business traffic.
True true true. That's why we can't block--only monitor. I am certainly against xenophobic block lists. But if a host doesn't usually go to a certain country for exe files, then it probably warrants a quick follow-up (*cough* StreamDB *cough*).
Yup that was my point. The host protecting its self is the PRIMARY defense. Not IDS. Host based Content filtering, firewall, HIPS, AV ... then network IDS. That puts IDS as the 5th level of protection. And it only works when connected to the protected network.
99% agree. The 1% difference is that I need you to put a "P" where your "D" is in "IDS." IPS is definitely 5th best as an effective preventative tool. What I would add, though, is that IDS is the only thing on the list as a scorekeeper, and since 1st-4th place are at best 50% effective, I'd put the scorekeeper at the top of the list.
That is interesting. I have not read either of those, but I definitely will. Thanks.
Unbelievable reports. Stop whatever you're doing and read them! Also note that they are extremely scientific in their methodology and numbers, and these are all first-hand investigations. Verizon worked both with and without the US Secret Service on hundreds of these last year alone.
Thanks for the response, Wally
Thanks for the discussion! I really like to hear other viewpoints, especially from orgs that are setup differently than mine. ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9, (continued)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Matthew Jonkman (Jan 31)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Jason Wallace (Feb 01)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Matthew Jonkman (Feb 02)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Martin Holste (Feb 02)
- Re: was--Matt Jonkman in the new Hakin9--now detecting infections John York (Feb 03)
- Re: was--Matt Jonkman in the new Hakin9--now detecting infections Matthew Jonkman (Feb 03)
- Re: was--Matt Jonkman in the new Hakin9--now detecting infections Marshall Bartoszek (Feb 04)
- Re: was--Matt Jonkman in the new Hakin9--now detecting infections Jefferson, Shawn (Feb 03)
- Re: was--Matt Jonkman in the new Hakin9--now detecting infections John York (Feb 03)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Jason Wallace (Feb 03)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Martin Holste (Feb 03)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Will Metcalf (Feb 04)
- Re: [Emerging-Sigs] Matt Jonkman in the new Hakin9 Matthew Jonkman (Feb 04)