opencti
opencti copied to clipboard
OpenCTI-Platform
Deletion leaves some orphans
Description
When deleting an entity that has some relations with other entities, the relations are also deleted. Problem: if such relation has a higher marking than allowed to this user, the relation will not be deleted. Furthermore it will still be visible in the platform, and one side will be marked as "restricted" which is the default display behavior when a user can't see an object.
We should prevent deletion if:
- at least one of the items in the cluster to delete (the object + all relationships) does have a higher marking/confidence level than your user
Checkout userFilterStoreElements function, that checks if a user has access to a given element checking markings, granted refs
But this function does not check the confidence.
@nino-filigran in our PR we chose to treat merge operations like deletion, because ultimately some entities are indeed deleted.
This means we cannot merge 2 entities if we do not have access to all the relationships of all entities. Are you ok with this ?
@labo-flg not sure to understand why it's treated the same: a merge is not a deletion. Why do say "ltimately some entities are indeed deleted"? Do you mean if for instance:
- I have 2 entities, FRA and France. Both of them are linked to the same intrusion set: APT28.
- If I merge FRA and France, utlimately, one relation will be deleted, since the relations are the same?
To clarify, example:
- entity FRA + Malware X
targetsFRA - entity France + Malware Y
targetsFrance
-> Merge FRA into France ; expected result:
- entity France with alias FRA + Malware X
targetsFrance + Malware YtargetsFrance - entity FRA is deleted from the platform
If the user doing the merge has not sufficient ACL to see the relationship Malware X targets FRA, we would have :
- entity France with alias FRA + Malware Y
targetsFrance - entity FRA is deleted from the platform
- orphan relationship Malware X
targetsdeleted , appearing as Malware Xtargetsrestricted because that's how display works
To prevent that, we would now fail to execute the merge because user does not have sufficient ACL on all relationships impacted.
That's one case yes. But there is an other case where I'm not sure what the intended behavior is:
- You have FRA and France. FRA is linked to APT28 with a TLP:RED relation
- User with TLP:GREEN marking wants to merge FRA to France
What do we want to happen? Do we want to refuse the merge since the user can't see the FRA -> APT28 relation, or do we accept the merge and move the relation to the merged entity even if the user doesn't have access to the relation?
In your case @JeremyCloarec, user will not see the relation in the first place. Therefore, the user will try to merge thinking everyhting is alright. Given that the relation would be updated (indeed, FRA -> APT28 would become FRANCE (alias FRA) -> APT 28) I'm in favor of preventing the user from merging. Indeed, user has insufficient ACLs to perform an "update".
Access check in deletion and in merging has been split in 2 PRs #6811 and #6989
#6811 contains changes related to deletion, and is safe to merge
#6989 contains changes related to merge, and needs more discussion to decide if we go for it or not. Adding access check during merging could impact two core processes:
- when data is ingested, the upsert process can sometimes lead to a merge (hard for me to describe the cases where a merge is done during upsert, code can be found in
middleware.jscreateEntityRaw). If connectors are not configured to access all dependencies during a merge, this could lead to some upsert failing and to knowledge data loss - when a platform is synced, merge events are processed on the target platform by the worker. If worker configuration doesn't have access to all data, this could also lead to some merge events failing
Please take also a look to https://github.com/OpenCTI-Platform/opencti/issues/7015
