<div dir="ltr">Yes, yes, and yes. This is the part where a modular, pluggable architecture lets everyone contribute their various scoring mechanisms and checks. There could be a plugin for your SIP/DIP methodology, a plugin for the Google malware domain checker, to Shadowserver.org, etc., etc. But the key is that we don't have to make a web request on a per-packet basis, rather, we update lists for the sniffer periodically, and we only have to check external sources when we are handed an event from the sniffer. If we buffer the data from the sniffer to the event policy engine queue, then we can afford to do lots and lots of scoring, checking, re-checking, and ranking before a human ever has to wonder what's going on without dropping packets. As an added bonus, the source lists can be updated based on the collective decisions, so we get a positive cycle of pruning the source lists.<br>
<br>Thanks for the feedback! I can't wait to all of the cool stuff this group is going to dream up.<br><br>Martin<br><br><div class="gmail_quote">On Fri, Oct 17, 2008 at 4:13 PM, <span dir="ltr"><<a href="mailto:robert.jamison@bt.com">robert.jamison@bt.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;">Great e-mail Martin!<br>
<br>
Disclaimer: My comments and thoughts are coming from an MSSP<br>
perspective, not from a local network security administrator with strong<br>
knowledge of and view into a given environment (this is good and bad, I<br>
suppose...).<br>
<br>
Expanding on Martin's comments:<br>
<div class="Ih2E3d"><br>
" So, while perl would be far<br>
> too slow to do real-time content matching, it is certainly not too<br>
> slow to receive an alert, check to see if this source IP has alerted<br>
> recently, create an incident with some priority, see who needs to be<br>
> notified of the incident, and then send an alert."<br>
<br>
</div>Checking to see if the SIP has alerted recently, and checking for<br>
derogatory information on the DIP gives opportunity to consider<br>
additional evidence outside the context of the observed session. While<br>
a blacklist provides a seed to begin session tracking, it's typically<br>
Boolean and doesn't provide historical or concurrent significance in<br>
establishing an event priority. The common framework is building on<br>
that by more effective session analysis and intelligent classification,<br>
resulting in better incident response--I'm not going to add to this as<br>
my perspective is much more lateral than focused.<br>
<br>
One of the projects I've been working on is the analysis and storage of<br>
firewall logs from functionally and geographically diverse environments.<br>
We are attempting to leverage cross customer firewall accept and deny<br>
data as well as security events from IDS/IPS systems which may or may<br>
not be on the same networks in which the firewalls exist. This could<br>
perhaps be viewed as filling gaps in a protective perimeter by<br>
harnessing detection resources that exist elsewhere. Parallelism vs.<br>
Serialism. This is to build confidence that a customer client is<br>
indeed infected, before reaction policy is even engaged. Even though<br>
SIP or client 'Alpha' may only be seen from a single network (which we,<br>
as a MSSP typically don't have control over) security alerts from<br>
disparate IDS/IPS platforms often implicate the same destination address<br>
as being a control node, or hosting malware. Some of the input we aim<br>
to feed the incident priority algorithm are:<br>
<br>
1) How many other networks have connections to this blacklisted DIP<br>
2) What ports have been accessed<br>
3) What is the historical frequency of access to this DIP from all<br>
monitored environments<br>
4) What are the IDS/IPS signatures which have been tripped<br>
5) Is there a common security classification of those sigs<br>
6) Has any forensic investigation of a client that has been in contact<br>
with this DIP uncovered a rootkit or malware instance<br>
7) What is the historic significance in IP addresses in the DIP's<br>
allocated block (e.g. have other addresses in that block been listed as<br>
DIPs in other security alerts within the same or other attack<br>
classification type?)<br>
<br>
I hope to participate more in this project.<br>
<br>
Thanks,<br>
<br>
<br>
Rob Jamison<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:discussion-bounces@openinfosecfoundation.org">discussion-bounces@openinfosecfoundation.org</a><br>
[mailto:<a href="mailto:discussion-bounces@openinfosecfoundation.org">discussion-bounces@openinfosecfoundation.org</a>] On Behalf Of Matt<br>
Jonkman<br>
Sent: Friday, October 17, 2008 3:58 PM<br>
To: Martin Holste<br>
Cc: <a href="mailto:discussion@openinfosecfoundation.org">discussion@openinfosecfoundation.org</a><br>
Subject: Re: [Discussion] Features and Design Strategy<br>
<br>
Well put Martin. I definitely like the idea. It goes well with one of<br>
the core things we need to do, let everything thread off away from the<br>
flow of packets as possible.<br>
<br>
So to generalize a bit more, we should strive to make anything possible<br>
able to be hooked, or fed out to a side process as possible. Output of<br>
course, but anything else as well. Just leave generic hook points any<br>
process could pull data from fifo style.<br>
<br>
This would likely be where we could let the extracted binaries come out<br>
of the core processes as well.<br>
<br>
Great concept to add, I'll get this into the wiki so we don't lose the<br>
idea.<br>
<br>
What challenges does anyone see in this concept?<br>
<br>
What other advantages might we gain if we plan correctly?<br>
<br>
Matt<br>
<br>
Martin Holste wrote:<br>
> First off, many congrats, Matt!<br>
><br>
> When you look at the threat landscape, it's clear that the most<br>
imminent<br>
> threats are against web-facing clients and servers, so I think we<br>
should<br>
> focus on client-side attacks and attacks against web applications.<br>
> Detecting SMB protocol attacks, etc. is still important, but most<br>
> attacks against non-web protocols need a foothold on the LAN first.<br>
> Most IDS are historically built for defending servers from clients,<br>
and<br>
> I think that idea is becoming a bit antiquated, though certainly far<br>
> from obsolete.<br>
><br>
> My group has had great success doing what John at Berkeley is/will be<br>
> doing with file carving. We've been auto-extracting packed files from<br>
> the network stream and auto-submitting to VirusTotal for over a year<br>
> now. John's point about processing the layer-7 data inside the<br>
streams<br>
> is dead-on. We need to move away from answering "what strings did the<br>
> traffic contain" to answering "what did the host actually do?" We<br>
also<br>
> need to keep in mind that canonically defining what "bad" behavior is<br>
> can be incredibly difficult even if you're just trying to put it in<br>
words.<br>
><br>
> The design strategy that it is important to me is plugin<br>
extensibility.<br>
> One of the reasons I love perl so much is that there is a CPAN module<br>
> for just about anything you could ever dream of needing. The extreme<br>
> ease with which you can incorporate others' code into your own project<br>
> is what has kept it thriving for so long. The differences between<br>
> individual organization's security needs and preferences mandate that<br>
a<br>
> successful project will have a long-term goal of being extremely<br>
> modular, while also having a core functionality that is superb.<br>
><br>
> Since Snort is what I'm familiar with, I will try to make my point by<br>
> comparison: Snort has excellent core functionalilty, but despite<br>
> Marty's best efforts, extending it is not a trivial task because the<br>
> code is in C. When Jason Brevenik posted his SnortUnified.pm module<br>
> which gives perl access to realtime Snort alerts, I realized that<br>
there<br>
> was suddenly an avenue for decoupling the pure network-grepping core<br>
> functionality of Snort with the action component. Moreover, I now had<br>
a<br>
> hook for writing extremely customized and complicated event handling<br>
in<br>
> my programming language of choice instead of trying to debug segfaults<br>
> in preprocessors all day. So, while perl would be far too slow to do<br>
> real-time content matching, it is certainly not too slow to receive an<br>
> alert, check to see if this source IP has alerted recently, create an<br>
> incident with some priority, see who needs to be notified of the<br>
> incident, and then send an alert. So, the point is, we only need the<br>
> really fast component to do a limited number of tasks, and if we<br>
> decouple the real-time, per-packet tasks from the high level "what do<br>
we<br>
> do with this" tasks, anyone is free to trivially write their own hooks<br>
> into how they want things handled, which is the part that varies the<br>
> most from org to org. Marty recognized all of this when he wrote the<br>
> unified output module, but Sourcefire never had a commercial reason<br>
for<br>
> extending it much since it would encroach on their own product<br>
> offerings. OISF has the advantage of not being for-profit, and so we<br>
> can make extensibility a priority.<br>
><br>
> What I would like to see is a brand-new program with functions similar<br>
> to Snort's HTTP preprocessor which has the sole purpose in life of<br>
> sniffing the network and attaching HTTP header fields to the traffic,<br>
> most importantly the host, content-type, and content-length fields.<br>
> This daemon would read a config file which specifies rules more like<br>
> scripts. The rules would have variables populated from a policy<br>
server,<br>
> and it would update these variables very regularly (without a program<br>
> restart of any kind). This would de-couple the work of sniffing from<br>
> the work of policy setting. The policy server would get its variables<br>
> from all kinds of sources, like remote XML files. Armed with this,<br>
very<br>
> simple signatures which identify web applications could be written.<br>
> Here's a pseudo-code example of what I think the configs would look<br>
like:<br>
><br>
> ## On the policy server ##<br>
><br>
> # Declare vars<br>
><br>
> DECLARE $attacked = ARRAY;<br>
><br>
> DECLARE $attackers = ARRAY;<br>
><br>
> DECLARE $bad_hosts = { type=dns,<br>
url=<a href="http://blacklists.example.org/bad_dns.xml" target="_blank">blacklists.example.org/bad_dns.xml</a><br>
> <<a href="http://blacklists.example.org/bad_dns.xml" target="_blank">http://blacklists.example.org/bad_dns.xml</a>>, refresh_list=30 };<br>
><br>
> DECLARE $bad_ips = { type=ip,<br>
> url=<a href="http://more_blacklists.example.org/bad_ips.xml" target="_blank">more_blacklists.example.org/bad_ips.xml</a><br>
> <<a href="http://more_blacklists.example.org/bad_ips.xml" target="_blank">http://more_blacklists.example.org/bad_ips.xml</a>>, refresh_list=30 };<br>
><br>
> DECLARE $our_windows_hosts = { type=ip,<br>
> url=<a href="http://mycompany.example.org/our_windows_hosts.xml" target="_blank">http://mycompany.example.org/our_windows_hosts.xml</a>,<br>
refresh_list=900 };<br>
><br>
> ## On the HTTP sniffer ##<br>
><br>
> # Detect our web apps<br>
><br>
> ID $google AS [http,https ] FROM [ host='*.<a href="http://google.com" target="_blank">google.com</a><br>
> <<a href="http://google.com" target="_blank">http://google.com</a>>' ];<br>
><br>
> ID $google_search_result AS [ $google ] MATCHING [ uri =~ /search/ ];<br>
><br>
> ID $our_web_clients AS [http,https] TO [ $our_windows_hosts ];<br>
><br>
> ID $us_sending_email AS [smtp] FROM [ $our_web_clients ];<br>
><br>
> ID $malware_webapp AS [ http, https ] FROM [ $bad_hosts OR $bad_ips ];<br>
><br>
> # Define our actions<br>
><br>
> # Create an event and record a client as attacked if it is referred to<br>
a<br>
> malware page by a Google search<br>
><br>
> FORWARD EVENT IF { $google_search_result REFERS $malware_webapp } AND<br>
[<br>
> ADD $_CLIENT TO $attacked, ADD $_SERVER TO $attackers ];<br>
><br>
> The important thing is that our daemon doing the HTTP sniffing is<br>
> agnostic in that it has no idea if things are bad or good, it just<br>
lets<br>
> somebody know when a predefined set of criteria has occurred. It is<br>
up<br>
> to an event policy server to receive these events and do something<br>
> intelligent (and highly configurable) with it. So, we've decoupled<br>
any<br>
> decision making from the component that has the most time-sensitive<br>
work<br>
> to do. All of the other components can buffer their work, but the<br>
> network sniffer needs as much work lifted from it as possible so that<br>
it<br>
> can cope with high loads. The policy server components would be the<br>
> only parts that would require much customization, and they would be<br>
> written in a high-level language like perl for maximum extensibility.<br>
><br>
> Let's also not forget the plethora of other apps out there that we can<br>
> leverage. Of particular importance would be SANCP and PADS.<br>
><br>
> SANCP's newest version contains a feature that John Curry added for me<br>
> which writes out an index of the file position within a bulk pcap<br>
where<br>
> a packet starts and stops. This means that you can do instantaenous<br>
> bulk packet retrievals using the index. In my tests, I can pull an<br>
> arbitrary host's traffic from a 30 GB pcap in under 5 seconds. This<br>
> technique could be used for file carving, which would provide the<br>
> ability to send to sandboxes, send to VirusTotal, Symantec, etc.<br>
><br>
> PADS provides a ready-made daemon for identifying the protocols used<br>
> between hosts. If PADS fed a policy server, we could automagically<br>
> update the policy server when new Windows hosts come online, or when<br>
an<br>
> SMTP session starts. Since the HTTP sniffer would be reading from the<br>
> policy server on a regular basis, PADS would be able to keep it<br>
informed<br>
> as to the state of the network. P0f could work as well.<br>
><br>
> So, the main idea would be to have a very lightweight daemon with a<br>
> specific task forward events to an event policy server written in a<br>
> higher level language, and to remove almost all decision making from<br>
the<br>
> sniffer.<br>
><br>
> Comments?<br>
><br>
> Thanks,<br>
><br>
> Martin<br>
><br>
><br>
><br>
------------------------------------------------------------------------<br>
><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>
--<br>
--------------------------------------------<br>
Matthew Jonkman<br>
Emerging Threats<br>
Phone 765-429-0398<br>
Fax 312-264-0205<br>
<a href="http://www.emergingthreats.net" target="_blank">http://www.emergingthreats.net</a><br>
--------------------------------------------<br>
<br>
PGP: <a href="http://www.jonkmans.com/mattjonkman.asc" target="_blank">http://www.jonkmans.com/mattjonkman.asc</a><br>
<br>
<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>
</div></div></blockquote></div><br></div>