<div dir="ltr">Happens all the time, we call it shiny object syndrome.<div>Some sexy new concept emerges claiming to be a silver bullet and the whole industry shifts. I hear about people wanting to get access to threat intel w/o even being able to do basic logging/patching/firewall management. In reality, the majority of the work is setting up your environments to data collectors with appropriate sources. Most people go down the road of trying to shoehorn in some product that's going to solve all of your problems and I think that is the fork in the road Dave was referring to: do they lock the threat feeds into their products and force customers into long purchase cycles or do they merely sell or trade the feeds and allow customers to make their own choices about what to do with that data.</div><div><br></div><div>If you can't tell, I'm a fan of the latter approach as I think everybody wins (aside from the product vendors' margins). It opens up the freedom to use feeds from one vendor with the tech from another. What about small shops that don't have a software product and only sell feeds? Will they get locked out when Bit9 replaces AV? Will they support 3rd party feeds?</div><div><br></div><div>I love the idea of TAXI exchanges though I think the STIX format is lacking though I know they are working hard to improve it. I've been tossing the idea around of having collectors that pub/sub things to internal TAXI exchanges that get fed through your event handling frameworks so that we can constantly add different IoCs and anomaly models on the fly. Communication models and KFF databases should ideally be built automatically as code is promoted from load test / QA into production. Unfortunately, most people aren't ready for that because they claim they can't afford to have true test environments but I would imagine the reality is that they could spend far less on security if you were to have adequate test environments to build their baselines for much better behavioral analysis rather than a signature based model which economics dictate will inevitably fail.</div><div><br></div><div>Z</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 15, 2014 at 5:45 PM, al bell <span dir="ltr"><<a href="mailto:ab4250@gmail.com" target="_blank">ab4250@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I wonder how many organizations go down the (expensive and time consuming) road of consuming external threat feeds before they have fully instrumented their own internal high fidelity threat feeds. <span class="HOEnZb"><font color="#888888"><div><br><div><br></div><div>Al</div></div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Oct 15, 2014 at 11:53 AM, Zack <span dir="ltr"><<a href="mailto:zpayton@gmail.com" target="_blank">zpayton@gmail.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let me start with the statement that I have mad love for Dave. While I loved the article Dave and mostly agree with you, I wanted to note a few things. To be completely fair, your article was written by someone selling something that competes for budget dollars with av products and this email post is written by someone who consumes consumes data feeds from an array of 'sensors' whether those sensors are vuln reports written by offensive security teams, AV logs, or threat intelligence feeds from various groups (IRC channels of actors / private TAXI exchanges).<br>
<br>
In your article you state that threat intel is sold on a per host basis and requires an agent. While this is true in some cases (I'm looking at you carbon black / bit9), I really see them more as an agent that sources indicators aggregated from private and public sources. The point, dear reader, is don't misconstrue threat intel from products. Threat intel is a data stream (though the feed itself can be a product) of information valuable to your Situational Awareness. If some vendor wants to include the automata that acts on that data stream well that's another fucking product.<br>
<br>
Ultimately, data relevant to your environment is valuable and as Dave hinted at, some of the best threat intelligence comes from your own data sources: DNS queries, process hashes, netflow data, authentication/authorization audit logs, proxy logs. Those are all high value threat feeds because they 100% apply to you. Threat intel coming from external parties can be valuable as well but is more noisy: how many of those 100,000,000 known C2 domains are you really gonna see on your network?<br>
<br>
No data stream is gonna be complete and correlating multiple streams together based on what's available and valuable to your environment is key. Personally I find that modeling your normal usage patterns and alerting based on anomaly to be less noisy but I also find value in lists of known bad domains / ip / whatever.<br>
<br>
In the end, using these feeds to ply your SA impacts judgment (automated or manual) and everything else in your ecosystem is just a data stream you use to augment your perception. I advocate mastering your least noisy streams first and try to see each intel feed / data stream as just another input. The value of data streams coming from AV is rapidly diminishing if not already so noisy as to be useless.<br>
<br>
I saw a talk in Vegas about measuring the IQ of your threat feeds and while the talk wasn't that groundbreaking it did leave some interesting food for thought: mainly diffing various intel feeds to get a fuzzy feeling of unique content. Running through the mental exercise I realized that your internal data feeds are going to have a lot more unique content that is directly applicable to you meanwhile more than 99% of data from most external sources were never applicable.<br>
<br>
Z<br>
<div><div><br>
> On Oct 15, 2014, at 8:59 AM, Dave Aitel <<a href="mailto:dave@immunityinc.com" target="_blank">dave@immunityinc.com</a>> wrote:<br>
><br>
> <a href="http://www.fierceitsecurity.com/story/threat-intelligence-problem/2014-10-13" target="_blank">http://www.fierceitsecurity.com/story/threat-intelligence-problem/2014-10-13</a><br>
><br>
> In this article I go over "Threat Intelligence". And I'm a little hard<br>
> on it because I think it has to make a choice, and soon. In one hand, is<br>
> a pill that takes it down the road to AV-like financial success, but<br>
> strategic failure. And in the other hand, the current models are only<br>
> stepping stones towards offerings that provide true strategic<br>
> situational awareness to their clients, so their clients can build<br>
> customized incident response programs that really work.<br>
><br>
> Honestly, I think because of the way VC-funded firms work, we may end up<br>
> taking the blue pill, which is unfortunately for companies, but good for<br>
> those of us doing offense.<br>
><br>
> -dave<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Dailydave mailing list<br>
> <a href="mailto:Dailydave@lists.immunityinc.com" target="_blank">Dailydave@lists.immunityinc.com</a><br>
> <a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a><br>
_______________________________________________<br>
Dailydave mailing list<br>
<a href="mailto:Dailydave@lists.immunityinc.com" target="_blank">Dailydave@lists.immunityinc.com</a><br>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a><br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>