<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
look at mynetwatchman.. it was an early attempt do do both.<br>
<br>
<br>
<br>
Andre Ludwig wrote:
<blockquote cite="mid:4908AF02.2000701@packetspy.com" type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
What is being discussed on this list in regards to technology and
requirements for data rentetion and access just dont mesh well with
current "standard RDBMS". I would suggest looking at distributed file
systems and some of the databases that sit on top of them (hypertable,
hbase, etc come to mind).
Andre Ludwig
Matt Jonkman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Agreed. I don't want to get deep into the schema itself. Just want to
explore the idea of not being tied to one schema.
A question for the sql guru's though: Is there a large enough difference
in how you'd structure a scheme for large scale vs small/speedy to
justify thinking about this?
Matt
Martin Holste wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think that schema discussions are extremely premature since we still
haven't decided what we're even recording.
--Martin
On Tue, Oct 28, 2008 at 11:54 AM, Matt Jonkman <<a class="moz-txt-link-abbreviated" href="mailto:jonkman@jonkmans.com">jonkman@jonkmans.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:jonkman@jonkmans.com"><mailto:jonkman@jonkmans.com></a>> wrote:
I wonder if we ought to build several db schema's for different goals.
I'm not a deep-down sql expert (we'll get one involved when we get
here), but I suspect if your goal is different a different schema will
do best.
For instance, if you intend to keep every alert ever generated for
historical comparison you need one schema to keep it snappy. If you
intend to have a smaller number of alerts but a massive number of
sensors inserting frequently then you may need a different structure.
So perhaps we should build several schemas and let you choose at setup.
Then the engine just reads the version tag and inserts in that form.
Any sql guru's that could speak more to this?
Matt
James McQuaid wrote:
> I'm *still* listening... please continue.
>
> Message: 3
> Frank Knobbe wrote:
>> No, that's a bad idea (at least if you talk about Snort). If you
create
>> new/different message texts, Snort will create a new entry in the
>> signature table (unique to msg+gid+sid+rev). Also, you would not
get the
>> same text with barnyard or in barnyard (and probably flop) based
>> installs since BY only reports the sid (the msg is pulled from the
>> sid-msg.map file).
>
> We are not talking snort. This is totally different.
>
> And we'll definitely not use a db schema with this issue.
>
> Matt
>
>> While you could of course fork barnyard, my concern would be the
bloat
>> of the signature table due to unique msg texts.
>>
>
> No forking here, all new.
>
> Everything from the pattern matcher on up. :)
>
> Matt
>
>
> --
> --------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Phone 765-429-0398
> Fax 312-264-0205
> <a class="moz-txt-link-freetext" href="http://www.emergingthreats.net">http://www.emergingthreats.net</a>
>
>
> --------------------------------------------
>
> PGP: <a class="moz-txt-link-freetext" href="http://www.jonkmans.com/mattjonkman.asc">http://www.jonkmans.com/mattjonkman.asc</a>
>
>
>
>
>
--
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
<a class="moz-txt-link-freetext" href="http://www.emergingthreats.net">http://www.emergingthreats.net</a>
--------------------------------------------
PGP: <a class="moz-txt-link-freetext" href="http://www.jonkmans.com/mattjonkman.asc">http://www.jonkmans.com/mattjonkman.asc</a>
_______________________________________________
Discussion mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Discussion@openinfosecfoundation.org"><mailto:Discussion@openinfosecfoundation.org></a>
<a class="moz-txt-link-freetext" href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.9.0 (Build 397)
Charset: ISO-8859-1
wsBVAwUBSQivBcjAfVnRK9hXAQjszAgAuo00m4GoBrroLxj6zcRjpEyiNP/S831u
TWPwiF5YjEoDMpGDBlVqJiOowJ2LvO2bAJCPvR9dXnQPK7pOVgRy1ODt0cdeAV5a
18ALVe6P9SNCQXpt3Qnay8sSHC7fNcUxvLpyVwlRXm+2OnC/UKEjtGtBlrbXn0eO
Aapm8i4IH53QysFuuWAEFq3tPH6T1XbrnAHEdXrUiC972gqFFy2G8i2UqxN92076
KX0OhdeWS7QPJOTXiBRBftK9ZLvLQ42zXUtW/I7/Cmh2+hMT6/ime+QblCwX3k9q
9+8YOLiVTG1/KRtXSJakZ/2f4h7dK55j7az4UoD3hdzbgzLUNUagZQ==
=6IAU
-----END PGP SIGNATURE-----
_______________________________________________
Discussion mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Michael Scheidell, CTO<br>
Phone: 561-999-5000, x 1259<br>
<font color="#999999">></font><font color="#cc0000"> <b>| </b></font>SECNAP
Network Security Corporation
<style type="text/css">
<!--
.unnamed1 {
margin: 1em;
padding: 1px;
} -->
</style>
<ul class="unnamed1">
<li>Certified SNORT Integrator</li>
<li>King of Spam Filters, SC Magazine 2008</li>
<li>Information Security Award 2008, Info Security Products Guide</li>
<li>CRN Magazine Top 40 Emerging Security Vendors</li>
</ul>
</div>
<br>
<div id="disclaimer.secnap.com"><hr>
<p>This email has been scanned and certified safe by SpammerTrap®.
<br />For Information please see
<a href="http://www.spammertrap.com">www.spammertrap.com</a></p>
<hr></div>
<br>
</body>
</html>