Re: Longer form questions

[Andre Gironda <andre () operations net>]

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 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> 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>
> 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> 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>
> > > 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>
> > > > 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>
> > > > > 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>
> > > > > > 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: image.png]
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > 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
> > > >
> > > >
> > > > --
> > > > 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
> > > 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
_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave