I think listing all possible actions is a good exercise, then, after brainstorming is over, deciding what is best.  <br><br>For example, for granny, there's blocking/preventing at the browser level, blocking/preventing at the OS,   at her home router, via DNS, via IP, etc. then there's blocking (or null routing, etc) at her ISP,  bringing down the host, contacting the hosting provider, etc...<br>
<br><br><br><br><div class="gmail_quote">On Wed, Oct 22, 2008 at 7:35 PM, Martin Holste <span dir="ltr"><<a href="mailto:mcholste@gmail.com">mcholste@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I like the idea, but are there really that many different actions to be taken, and aren't they going to be org specific?  If I know that an IP is spamming, I don't just want to block them from emailing, I want to block all access from that IP since it is untrustworthy.  But I do think there is a lot of value in developing and distributing better language for describing why the given IP/host is now on the list and other descriptions.  I'm more for giving orgs the most information that we can, and leaving it to them to implement the actual blocking decisions.<br>
<font color="#888888">
<br>--Martin</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Wed, Oct 22, 2008 at 5:35 PM, Blake Hartstein <span dir="ltr"><<a href="mailto:urule99@gmail.com" target="_blank">urule99@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What if we focus on developing and distributing a better language for<br>
communicating actionable events?<br>
The idea is to make all intelligence more valuable and immediate. If I<br>
see this input event, alert, network, ISP, javascript, URL, how does it<br>
impact me, and what do I do about it? Instead of just collecting and<br>
distributing, the goal is to direct the actions for (ISP takedown,<br>
firewall, admin action, more). This enhances all of the prior research<br>
we've already done.<br>
<font color="#888888"><br>
<br>
Blake<br>
</font><div><br>
<br>
<br>
<a href="mailto:robert.jamison@bt.com" target="_blank">robert.jamison@bt.com</a> wrote:<br>
</div><div><div></div><div>> It seems we're a split camp with:<br>
><br>
> [Keynesian CAMP]<br>
> Client Side Product/Service with ability to protect/detect compromise on<br>
> grannyx home user<br>
> *scope most thoroughly represented by Martin's " RFC: Proposal for<br>
> Analysis Framework"<br>
><br>
> [Supply Side CAMP]<br>
> Focus on server side protection for net critical assets<br>
> *Andre/Jack "What is absolutely horrible in its current state is<br>
> IDS/IPS" / "Client side is simply not possible due to political and<br>
> religious issues."<br>
><br>
> Additional notes gathered (I've just caught up on my reading;-)<br>
><br>
> (a) Consideration for re-write defanging capability as inline protection<br>
> (b) Efficiency in stream storage--essentially normalize data inspection<br>
> so it doesn't have to be redone by multiple engines<br>
> (c) XML vs. Binary distribution of verbose alerts vs. instruction<br>
> inferred datapoints<br>
> (d) Consideration for extending existing project Bro<br>
><br>
> Anything I'm missing?<br>
><br>
> Rob<br>
<br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
<br></blockquote></div><br>