-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
A notional example: <Relationship type="drops" source_id="malware_subject_1" target_id="malware_subject_2"> |
This could also be used for one-way relationships/tagging, e.g., <Relationship type="potential indicator" target_id="object_1"> |
One of the open questions is where such relationships should be declared - in the Package, Bundle, or both? |
👍 |
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 |
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"/>
... |
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). |
added Proposal placeholder. |
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"/> |
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.
The text was updated successfully, but these errors were encountered: