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?).

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.

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.

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).

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.

“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.

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