There is a limited number of relationships that are ‘valid’ within STIX. This can limit the ability of objects to directly show their association with another. As an example an Indicator cannot currently be directly related to a Threat Actor, but instead MUST go through either a TTP object, or a Campaign. Similarly neither a Campaign nor Incident can be directly associated with an ExploitTarget. Yet there may be times that this is exactly what a user wants to reflect.
A supplied example as to why this is not helpful.
“Say badguy1 uses CVE-10. Right now, I have to link that via a ttp. There are two possible scenarios here. The first is that I might not know the ttp being used to exploit CVE-10 The problem with that is obvious, no link can be created currently. The second case is if I do know the ttp. This represents a linkage that can be created, but at a loss of clarity/specificity. So let’s say badguy1 uses CVE-10 via spearphishing. So I link badguy1 to spearphishing and link spearphishing to CVE-10. BUT, I also have 20 other CVEs linked to spearphishing, and 100 other threat actors linked to spearphishing. At that point I have no way to tell which bad guy uses spearphishing to exploit which CVE.”
POTENTIAL ANSWER
If we could remove the constraints around relationships that they follow the current STIX Model then we could allow any STIX top-level Object to be associated with any other STIX Object. This flexibility would make it easier for anything to relate to anything, and allow the model to reflect reality (or the producer’s assertion of reality) without constraint.
We would be effectively providing the basic building blocks that end-users would be able to use to construct the content that reflects their reality. We won’t be imposing our interpretation of how things are structured, but instead allowing users to model the relationships where they exist. Please note this still will require further research and planning, as we will need to add to the relationship vocabulary to provide an ‘agreed list’ of the types of relationships one can describe. This will take some time to fully populate.
PROBLEM
There is a limited number of relationships that are ‘valid’ within STIX. This can limit the ability of objects to directly show their association with another. As an example an Indicator cannot currently be directly related to a Threat Actor, but instead MUST go through either a TTP object, or a Campaign. Similarly neither a Campaign nor Incident can be directly associated with an ExploitTarget. Yet there may be times that this is exactly what a user wants to reflect.
A supplied example as to why this is not helpful.
“Say badguy1 uses CVE-10. Right now, I have to link that via a ttp. There are two possible scenarios here. The first is that I might not know the ttp being used to exploit CVE-10 The problem with that is obvious, no link can be created currently. The second case is if I do know the ttp. This represents a linkage that can be created, but at a loss of clarity/specificity. So let’s say badguy1 uses CVE-10 via spearphishing. So I link badguy1 to spearphishing and link spearphishing to CVE-10. BUT, I also have 20 other CVEs linked to spearphishing, and 100 other threat actors linked to spearphishing. At that point I have no way to tell which bad guy uses spearphishing to exploit which CVE.”
POTENTIAL ANSWER
If we could remove the constraints around relationships that they follow the current STIX Model then we could allow any STIX top-level Object to be associated with any other STIX Object. This flexibility would make it easier for anything to relate to anything, and allow the model to reflect reality (or the producer’s assertion of reality) without constraint. We would be effectively providing the basic building blocks that end-users would be able to use to construct the content that reflects their reality. We won’t be imposing our interpretation of how things are structured, but instead allowing users to model the relationships where they exist. Please note this still will require further research and planning, as we will need to add to the relationship vocabulary to provide an ‘agreed list’ of the types of relationships one can describe. This will take some time to fully populate.