Dailydave mailing list archives
Re: Longer form questions
From: Akendo <akendo () akendo eu>
Date: Wed, 27 Nov 2019 13:52:06 +0100
Hey guys, thanks for this intriguing discussion! I try to get into it and hope that I got it correctly, I'm going to answer a bit out of the blue here. So please be nice to the rookie here! However, I was wondering what the bottom line here is. NIDS is dead and how does this annoy Rob? (References are welcomed). Should we throw out any NIDS now and jump onto the metadata train? I try to get into the discussion here by taking the opposite side. Should the point not be that a NIDS can protect against off-the-shell exploits? Sure, some are too complicated to have reasonable signatures to be detected, but that's what most adversaries are going to utilise, at least when it's Team D. This might not be necessarily true, because their certainty smarter person than me who can figure out how to write a proper signature for such stuff. Somehow I feel like that you all put the burden exceptional high, in that sense that the NIDS detects everything or nothing. But the way I see a NIDS, it's an additional sensor to your environment. Just like any other monitoring, it adds visibility. Sure with it, you increase the attack vector, but when it does increase the chances of detecting an attack does this not add value? so far, akendo On 06.09.19 23:18, Andre Gironda wrote:u I feel like that you set the burden very exepnioanl hihg. asd
Daemonlogger + Zeek Intelligence Framework for sightings. Doesn't need TLS secrets. Doesn't need high availability or to run inline. The sensors tell you what they see and where and when they saw it. No need to block. No need to "detect". No signatures at all (just a living watchlist). No AI/ML. No modification of traffic. No huge concern if an APT, skiddie, or admin crashes it (it's receive-only on the Daemonlogger interfaces, right?). You don't even need to save any pcap or flow/sess data or metadata! For SMTP/ESMTP/Submission services try emailrelay.sf.net <http://emailrelay.sf.net> and run Yara across the headers. ReversingLabs and some trustgroups maintain/share rules especially checking rfc2822 content-type and message-id. NSM, NIDS, NIPS, NFA, and Network Forensics are dead but Sighting and Gating concepts are not. For cloud, there's always Prisma Cloud and/or CRFT.app. For containers: eBPF, Sysdig, Capsule8, et al. On Fri, Sep 6, 2019, 12:15 PM John Lampe <jlampe () tenable com <mailto:jlampe () tenable com>> wrote: I think Dave nailed it when he said "anomaly detection algorithm". There is still value in being able to take netflow data, ip intel, protocol hashing and enumeration (even encrypted ones), client fingerprinting, and a lot of other things and bringing that all together. Call it a NIDS, passive scanner, whatever...it's still an integral part of security. oh, and the places where those tools live is prime real estate. If you're doing IR or hunting, you'll be wanting access to those tree stands. John On Fri, Sep 6, 2019 at 1:30 PM Allen DeRyke <allen.deryke () gmail com <mailto:allen.deryke () gmail com>> wrote: Network security monitoring is alive and well; netflow, bro, zeek, and packet capture are incredibly valuable data sources for DFIR and "threat hunting" purposes; however signature-based IDS as a primary detection mechanism has always been a bit of a story that vendors sell blue teams to sleep better at night. The metadata tools do raise the bar for your adversaries opsec, and the ugly reality is that these tools help us "get lucky" with detection. This audience is well aware that there will always be an environmental niche for the ruthlessly opportunistic species be it blue, red, or salesy. This isn't to say there isn't a place for a "good IDS analyst" closely managing a "well-designed" sensor rollout and a "tailored" signature set, but the ROI of getting all three things right in 2019 is rarely comparable to alternative investments; We know what's going on though... Somebody out there needs to continue funding expeditions for the lost golden city of El Dorado and when they find it the joke will be on all of us for not purchasing more supplies from the superior outfitter that's obviously enabled them to be such good treasure hunters. -- Allen Deryke On Fri, Sep 6, 2019 at 7:18 AM Chris Rohlf <chris.rohlf () gmail com <mailto:chris.rohlf () gmail com>> wrote: I think netflows have a lot of value in production and corp environments. But if the question is ‘can NIDS, now or in the future, detect client side remotes against scriptable targets’ then the answer is a resounding no. NIDS in server environments simply can’t scale up enough or model the complex tech stacks they sit in front of. Sure you can write a signature to match a single exploit instance but its easily bypassed, and requires reducing the security of TLS everywhere to that of an unmanaged, and likely unpatched, linux box that stores your private keys at the same privilege level of the program that parses complex file and protocol structures from untrusted sources. We haven’t even gotten into how badly this weakens good service mesh architectures with mutual TLS. Any good security leadership wants metrics but its risk calculations like this that almost always go unnoticed. Chris On Thu, Sep 5, 2019 at 7:15 PM Anton Chuvakin <anton () chuvakin org <mailto:anton () chuvakin org>> wrote: Wow, indeed, so 2007, this brings back memories .... But on a more serious note: do you guys truly think that network security monitoring (whether NIDS, network forensics / capture, "NTA / NDR", Bro / Zeek and such) is "dead dead"? And there no hope for any zombie-apocalypse-style revival? :-) On Thu, Sep 5, 2019 at 2:41 PM Chris Rohlf <chris.rohlf () gmail com <mailto:chris.rohlf () gmail com>> wrote: I’ve been happily ignoring Twitter the last few weeks so when I saw a DD post come in I got excited and felt nostalgic for 2007, which coincidentally this thread reminds me of. Not just because Dave is trolling Rob but also because I thought the idea of network based protocol and file parsers died around that time. How many HTTP implementation quirks does the Snort engine implement these days? Back then it was almost none. But what about now? Trick question, it doesn’t matter. Theres not enough memory or cpu in your average NIDS (or whatever they’re called now) to possibly keep state while monitoring the traffic volume in any real production deployment. I suppose theres only one RDP implementation whose quirks are worth reimplementing, but what are the chances they did it better than Microsoft? Does the MITM have as many mitigations as a modern Msft server OS? And are you willing to trust it with all those private keys? Does the MITM box have 2fa auth? Role based acl’s? What other disk did that key touch after your team exported it? If you’re a CISO who is losing sleep over these exploits but are not asking the questions above then you may not have your priorities straight. Chris On Thu, Sep 5, 2019 at 11:03 AM Dave Aitel <dave.aitel () gmail com <mailto:dave.aitel () gmail com>> wrote: https://blog.talosintelligence.com/2019/09/the-latest-on-bluekeep-and-dejablue.html Ok, so as someone pointed out in private email, they have a blog that goes through a 20 step process to exporting your private key from your RDP server to the MITM box that is parsing the protocol. I think this is an unlikely configuration, but in theory it IS possible. An anomaly detection algorithm might be a better option for real world detection, even though it is not specific to the bug. In other words, just to annoy Rob Graham, maybe network defenses can't really find every bug they want to - not just because they should not be edge-devices with vast repositories of every private key on your network, but because parsing requires state and state requires memory and you don't have infinite memory. https://vimeo.com/357848836 <---also watch the INFILTRATE teaser! :) ALSO: I'm headed to Tel Aviv next week if there's any infosec stuff happening there and anyone wants to say hi! -dave On Wed, Sep 4, 2019 at 12:57 PM Dave Aitel <dave.aitel () gmail com <mailto:dave.aitel () gmail com>> wrote: So I like the BLUEKEEP marketing train because it's a very hard bug to detect authoritatively for either endpoint protection or for network-based defenses. So when companies make claims about it, it's worth asking how they did that. Twitter is a terrible place for that, but since I know everyone in the industry who does this kind of thing is on this list I figured I'd ask here... -dave https://twitter.com/daveaitel/status/1169265348669005825 image.png _______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com <mailto:Dailydave () lists immunityinc com> https://lists.immunityinc.com/mailman/listinfo/dailydave _______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com <mailto:Dailydave () lists immunityinc com> https://lists.immunityinc.com/mailman/listinfo/dailydave -- Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin Blog: https://blogs.gartner.com/anton-chuvakin/ _______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com <mailto:Dailydave () lists immunityinc com> https://lists.immunityinc.com/mailman/listinfo/dailydave _______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com <mailto:Dailydave () lists immunityinc com> https://lists.immunityinc.com/mailman/listinfo/dailydave _______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com <mailto:Dailydave () lists immunityinc com> https://lists.immunityinc.com/mailman/listinfo/dailydave _______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave
_______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave
Current thread:
- Re: Longer form questions Akendo (Dec 02)