Hi Alexandre,
thanks for the clarification. I think I have to dig in into MSE/Fame then.
My conclusion at the moment (which as both positive and negative impacts) is that I can
reuse parts of Moose (e.g. FAME) but not the actual Moose UI. This also means that I can
build a model with storage hooks backed in right from the beginning.
Thanks,
Udo
On 29 Dec 2016, at 20:28, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Using Fame has the nice property to be able to save a model as a .mse file, for free.
There are very little documentation about fame unfortunately.
There is this document:
http://scg.unibe.ch/archive/papers/Kuhn08cFame.pdf
Famix is made for programming language. In your case, it looks like you absolutely do not
need Famix (but you probably want to look into it to have example on how to use Fame).
Let us know how it goes.
Cheers,
Alexandre
On Dec 26, 2016, at 1:19 PM, Udo Schneider
<udo.schneider(a)homeaddress.de> wrote:
ok - here we go :-)
First of all the context: I might (90%+) start a new job on January 1st. A big part of
this is cybercrime research/investigation/forensics. The idea is to model different facts
(e.g. hosts, IP addresses, groups, hashes …) and their relation as objects and use Moose
to reason about them. The classical way to implement this in our industry is to use a
Graph/RDF database and describe everything in terms of relations/tuples
(Subject/Predicate/Object).
However taking a look at Moose I’m not 100% sure anymore whether I’d bend Moose to much
for my needs based on it's original design/origin.
Defining the (Meta-)Model: I assume I need to define my own subject model representing
the entities im interested it with Fame (FM3 is just the Fame classes prefix, correct?).
So I’d end up with something like FAMIX just for my problem domain, correct?
Properties for Links/“Predicates”: The predicate linking to objects need to have
properties. E.g. given a tuple hostname/resolves to (DNS)/ip address - the “resolves to”
predicate needs properties like the time/date of resolving and the used DNS server. In
addition multiple predicates might connect the same hostname and ip address - denoting
different points in time the resolve was done.
How would I model such properties for links with Fame?
Actions on subjects: I need to describe actions on subjects. Using the example above
(DNS) I’d need an action on host objects which resolves the host address and creates a
link (denoting the resolve) to the (to be created) ip address.
Is there any hook in Fame to express those actions on subjects?
Continuous import: The model continues to grow (in terms of subjects and links) over
time. This can happen due to actions (see above) or mass import of new data (e.g. DNS zone
files).
Is this kind of “growing” model compatible with Moose or does Moose expect a static
model?
Model in DB/Multiple clients: As you might imagine the model for a forensic case can grow
pretty big very fast. Even for a quick investigation of data we’re easily talking about
10+Gigs of data. In addition we might need to work on the same model (although on
different aspects) with multiple people at the same time. So storing everything “in-image”
is a no-go IMHO. I have pretty good experience with MongoDB/Voyage and assume this could
be made working. Especially because I have to define my own model anyway - thus taking
care of database operations.
Are there any experiences with keeping the model in a DB and working with a local image
“workbench” on it. Esp. with multiple clients?
“Lab Notebook”: This one is a bit fuzzy - sorry if the intention is unclear. During a
case investigation (IMHO an investigation is also part of “the” model) different findings
(e.g. data, visualisations) need to be documented. My impression from Moose is that you
“play” with the data (in inspectors) until you come to an conclusion based on an
assessment. Once you have the result you can decide and tackle the next problem. In my
context I’d need to document not only the result but also the way taken to achieve it.
Maybe something simple like accumulating the research way through all inspector panes
would be enough. I’m not quite sure though.
So how do I document different “results (e.g. data/visualizations) including the “way”
they were achieved?
All in all I’m pretty impressed how Moose might fit on my problem domain. Especially
using it as a “workbench” to explore/investigate the data is something which is much more
pleasure to work with than digging through various SQL/noSQL/Splunk sources with different
tools. Not to mention that the visualizations I get are simply astounding and can be used
1:1 on the reports we generate. However ignoring my first impression I’m not sure whether
the data model I need to work on is “compatible” with the expectations Moose had/was
designed with. Hence the questions.
Thanks,
Udo
On 26 Dec 2016, at 11:39, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Yes
Alexandre
On Dec 26, 2016, at 11:37 AM, Udo Schneider
<Udo.Schneider(a)homeaddress.de> wrote:
All,
I’m dabbling with the idea of using Moose in a totally different questions. However I do
have some questions about using it in my context. Would this ML be the right place to ask
those questions?
CU,
Udo
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev