Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate Making Relationships First-class Entities #74

Open
ikiril01 opened this issue Jun 18, 2014 · 9 comments
Open

Investigate Making Relationships First-class Entities #74

ikiril01 opened this issue Jun 18, 2014 · 9 comments

Comments

@ikiril01
Copy link
Member

We should investigate making relationships, such as those between Malware Subjects, first-class entities. This would be much cleaner from a data specification perspective, and easily allow for the creation of bi-directional/multi-directional relationships, which at the moment are rather painful to define.

@ikiril01
Copy link
Member Author

A notional example:

<Relationship type="drops" source_id="malware_subject_1" target_id="malware_subject_2">

@ikiril01
Copy link
Member Author

This could also be used for one-way relationships/tagging, e.g.,

<Relationship type="potential indicator" target_id="object_1">

@ikiril01
Copy link
Member Author

One of the open questions is where such relationships should be declared - in the Package, Bundle, or both?

@gtback
Copy link
Contributor

gtback commented Mar 17, 2015

👍

@ikiril01
Copy link
Member Author

As far as one-way relationships - it may make more sense to call these something else, e.g., "Observations", since they're not relating two MAEC entities in the same sense as the "normal" MAEC relationships.

<Observation type="potential indicator" target_id="object_1">

Accordingly - see #8

@ikiril01
Copy link
Member Author

Another open question is whether having the Grouping Relationship still makes sense in the context of first-class relationships, as FC relationships could potentially subsume the capabilities of the Grouping Relationship, at the cost of added verbosity.

E.g., instead of

<Grouping_Relationship>
    <Type>same malware family</Type>
</Grouping_Relationship>

you could have

<Relationship type="same malware family" source_id="malware_subject_1" target_id="malware_subject_2"/>
<Relationship type="same malware family" source_id="malware_subject_2" target_id="malware_subject_3"/>
<Relationship type="same malware family" source_id="malware_subject_1" target_id="malware_subject_3"/>
...

@ikiril01
Copy link
Member Author

Related to the previous post, it may make more sense to add a "scope" property to relationships that can be used to specify Package-level grouping relationships, as well as first-class pair-wise relationships.

E.g.,

<Relationship scope="pair-wise" type="drops" source_id="malware_subject_1" target_id="malware_subject_2"/>
<Relationship scope="global" type="same malware family"/>

Thanks to @dzbeck for the suggestion! I really like this idea, as I think it would allow us to re-use the base relationship structure for grouping relationships, but without the added complexity of a separate “grouping relationship” structure. It also seems that the semantics of scope should be fairly well understood (as long as we have some well-defined terms).

@dzbeck
Copy link
Contributor

dzbeck commented Apr 22, 2015

added Proposal placeholder.

@ikiril01
Copy link
Member Author

Equivalency would also be quite simple to capture through the use of first-class relationships:

<Relationship type="equivalent" source_id="action-1" target_id="action-2"/>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants