[Marking restriction] Two markings with the same order do not restrict access

[Lhorus6]

Description

Here's how marking works:

For markings with the same type (e.g. TLP), the "order" plays a hierarchical role. This means that if I have access to a marking of order X, I can access all markings of order < X (of the same type, of course). For example:

• TLP:CLEAR is of order 0 and TLP:GREEN is of order 1
• TLP:GREEN is an “allowed” marking for me, but TLP:CLEAR is not. -> I can still see TLP:CLEAR because it's lower down in the hierarchy.

The problem arises when the order is equal -> you can see them all. So in the current configuration of TLPs on the platform (see screenshot below), a person with access to TLP:AMBER, will be able to see TLP:AMBER+STRICT even if he hasn't been given access.

Changing the value of TLP:AMBER+STRICT would solve the problem for TLPs but would still block a set of use cases. For example, if I have custom markings for my internal teams and apply them to restrict access to a particular team:

• if I don't put them in order (all equal), they're useless,
• if I set an order, higher orders will be able to see lower (which is not expected).

Environment

OCTI 6.0.10

Reproducible Steps

Steps to create the smallest reproducible scenario:

1. Create UserA without "bypass all" capabilities
2. Play with the "type" of marking and the "order" and attribute differente "allowed marking" to the UserA (this is configured at Group level) -> Check the behavior

Expected Output

Markings of the same order should not give access to other

[richard-julien]

That's the expected behavior, this bug must be closed as wont fix.

[Lhorus6]

Why did we make this choice? This reduces the possibilities of using markings.

At a minimum, we must change the "order" of the TLPs so that "AMBER" does not allow access to "AMBER+STRICT"

[richard-julien]

This doest not reduce anything. If you want to make amber less important that amber+strict, you can change the rank

[Lhorus6]

For "reduce possibilities":

For example, if I have custom markings for my internal teams and apply them to restrict access to a particular team:

• if I don't put them in order (all equal), they're useless,
• if I set an order, higher orders will be able to see lower (which is not expected).

A workaround is to put different type, but it would be cleaner to have the same.

For TLP:

Yes you can still change it manually. But given that it is present in the platform by default, I expect it to be configured correctly.

[richard-julien]

For reduce possibilities: the concept is to use a different type.

For TLP, you can discuss that with @SamuelHassine and @Jipegien has it was configured like this on purpose.

[Jipegien]

Initially, marking definition is a feature to implement specific marking on data to restrict dissemination (filtering output feeds). A lot of users extended this usage to other type of limitations, like internal access restriction, but it has limits.

For non hierarchical access restriction system, you will have to leverage multiple TLP types (Team1access, Team2access, etc.) or wait for the arrival of advanced RBAC.

Regarding the rank of AMBER and AMBER+STRICT, changing the default config now will imply impact for every users and can modify expected dissemination workflow. If a particular user want to modify this, it is very simply done in Settings.

[Lhorus6]

• Isn't the "order" of the TLPs managed when the platform is deployed? If we change them, will everyone (existing platform) be updated?
• In your opinion, is it normal/not a problem for TLP:AMBER to give access to TLP:AMBER+STRICT? It's easy to change, I agree, but you still need to know that TLP:AMBER gives access to AMBER+STRICT. On my side, I've just discovered this now. It could be that many people aren't aware of this and are sharing more data than expected with certain people.

[richard-julien]

Isn't the "order" of the TLPs managed when the platform is deployed? If we change them, will everyone (existing platform) be updated?

Depends of what we decide, we can migrate or not if needed.

In your opinion, is it normal/not a problem for TLP:AMBER to give access to TLP:AMBER+STRICT? Yes, it was decided like this. It can be changed if we have a global agreement to change it.

If people are not aware we need to improve the documentation

[Jipegien]

Not everyone is using the TLP v2 protocol and a lot are using only AMBER. Again, TLP is not an access restriction system, but an indication of how data should be disseminate by recipient. It is a matter of platform administration to set the marking definition adequately for users usages regarding dissemination and access restriction, so for me it should be reviewed and handled specifically by admins.

That being said, if we have a way to not impact existing platforms with the change of orders and only apply it to new platforms, I am ok with it. We can send a message in the Slack channel to inform the community about the change and let existing platforms' administrators make the change manually if needed. @Lhorus6 can you see with platform people for the feasibility? I will handle the Slack channel communication if we implement the change. Let me know.

[Lhorus6]

If I understand well, we just need to modify the line 131 and 137 : https://github.com/OpenCTI-Platform/opencti/blob/9c10a5b6e18867131e3284b0a33ebbdf2dca82f2/opencti-platform/opencti-graphql/src/database/data-initialization.js#L131 Don't know if it should be done by Platform or R&D