[Dailydave] Longer form questions
Akendo
akendo at akendo.eu
Wed Nov 27 12:52:06 UTC 2019
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 at tenable.com
> <mailto:jlampe at 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 at gmail.com
> <mailto:allen.deryke at 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 at gmail.com <mailto:chris.rohlf at 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 at chuvakin.org <mailto:anton at 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 at gmail.com <mailto:chris.rohlf at 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 at gmail.com <mailto:dave.aitel at 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 at gmail.com
> <mailto:dave.aitel at 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 at lists.immunityinc.com
> <mailto:Dailydave at lists.immunityinc.com>
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> <mailto:Dailydave at 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 at lists.immunityinc.com
> <mailto:Dailydave at lists.immunityinc.com>
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> <mailto:Dailydave at lists.immunityinc.com>
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com <mailto:Dailydave at lists.immunityinc.com>
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
More information about the Dailydave
mailing list