[Bro] Intel Framework Issues

Josh Liburdi liburdi.joshua at gmail.com
Mon Nov 23 13:03:54 PST 2015

I think you’re right, the default behavior is probably the best for most users. 

There are a few cases where I’d want to see an indicator match regardless of the connection status— for example, if the IP indicator in question is associated with a known command and control server or an attack group who may utilize the server as a C2, then I’d want to see any connection attempt from my network to that IP address. 

It also depends on how users are using intel.log. For example, if a team treats every indicator in intel.log as a traditional alert (that someone then has to triage), then you want to minimize the resource impact that has on your team (e.g., I don’t want my team chasing down indicators that amount to nothing)— in this case, the default behavior works to our favor. If a team uses intel.log as a source of indicator-related information, then you may want to see every IP indicator match regardless of connection status— seeing every IP indicator match increases your chances of catching things like attacker infrastructure changes or infrastructure roll over. 

There’s a lot of granularity that can be worked into how indicators are handled (the intel-ext script is great for that), but it’s very dependent on the objectives of any one particular team. Adding a policy script to enable IP indicator matches for any connection would be a good start, but the default behavior is a great approach!


> On Nov 23, 2015, at 3:48 PM, Seth Hall <seth at icir.org> wrote:
>> On Nov 23, 2015, at 1:47 PM, Josh Liburdi <liburdi.joshua at gmail.com> wrote:
>> I think the most common gotcha for IP addresses is that they will only appear in intel.log when they are a part of a successful TCP connection. Unsuccessful TCP connections and non-TCP connections will not appear in the log.
> Thanks for pointing that out Josh!  I do want to point out the reasoning behind that as a default decision.  My thinking was that spoofed packets could cause false hits and generally non-responded-to probes coming from intelligence hosts aren’t all that interesting.  Is there general agreement that that’s the right approach or should single packets hit on intelligence items by default?
> I think there is a high bar to clear with adding that as default behavior, but I’d like to hear from people actively doing incident response on their thoughts.
> I should also point out that we can certainly include a script that matches on non-complete connections with Bro even if we don’t load it by default.
>  .Seth
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/

More information about the Bro mailing list