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

Cyclic refs in stix-capec.json #34

Open
richard-julien opened this issue Feb 16, 2023 · 0 comments
Open

Cyclic refs in stix-capec.json #34

richard-julien opened this issue Feb 16, 2023 · 0 comments

Comments

@richard-julien
Copy link

Hi, this ticket is to open a discussion about cyclic references in mitre data.

In stix-capec.json, some attack pattern have refs that reference the data in the 2 sides.

The attack pattern 'attack-pattern--9ad2c2eb-9939-4590-9683-2e789692d262' is referencing 'attack-pattern--92cdcd3d-d734-4442-afc3-4599f261498b' through x_capec_can_follow_refs

And The attack pattern 'attack-pattern--92cdcd3d-d734-4442-afc3-4599f261498b' is referencing 'attack-pattern--9ad2c2eb-9939-4590-9683-2e789692d262' through x_capec_can_precede_refs

This situation is complex to handle in a data absorption point of view as its impossible to get the full information with only one round of data ingestion. For example in this case the attack-pattern--9ad2c2eb-9939-4590-9683-2e789692d262 will not be created with the correct x_capec_can_follow_refs as the attack pattern to link will not yet be created. To get all data its mandatory to absorb the file twice to finally get everything but I dont think its a good way to handle that cyclic reference.

So the question is more about "there is a way to remove the cyclic reference?" Maybe using a stix relationship instead of a ref?
That will be something like that ATTACK01 - can-follow -> ATTACK02 that could be easily translated to can-precede when looking on ATTACK02?

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

No branches or pull requests

1 participant