Manidant connector defaults to create all new entities with TLP:AMBER+STRICT

[animedbz16]

Description

Mandiant is by default creating new Stix Objects with the TLP:AMBER+STRICT marking which is problematic when there may be race conditions with other connectors such as when a new CVE Vulnerability is created by a connector, where if Mandiant creates this first it gets flagged with an improperly high TLP:AMBER+STRICT marking, while if connector-cve creates the CVE Vulnerability first then it will be marked appropriately with TLP:CLEAR.

Having these objects having improper TLP markings poses issues when factoring in how on creation of these objects other connectors may then auto-enrich them with various data, but are then being blocked because of these improper TLP markings that Mandiant is creating.

Environment

1. OS (where OpenCTI server runs): Docker
2. OpenCTI version: 6.4.10
3. OpenCTI client: Docker
4. Other environment details: Docker

Reproducible Steps

Steps to create the smallest reproducible scenario:

1. Stand up OpenCTI and Mandiant connector with default settings
2. Mandiant will create new objects into the system with its default TLP:AMBER+STRICT

Expected Output

Mandiant connector should not likely be creating new CVE objects with a TLP:AMBER+STRICT because these CVEs are made public and should be TLP:CLEAR, such as how connector-cve is importing CVEs.

Actual Output

Mandiant connector will create new CVE Vulnerabilities and other types of objects with the TLP:AMBER+STRICT marking

Additional information

While it seems expected that Mandiant should import / create many objects with the TLP:AMBER+STRICT, such as for the Mandiant specific reports that require a paid license to obtain and that this information is not allowed to be shared.

However, other types of objects, such as CVE Vulnerability objects, which are essentially public information, should not be being created by the Manidant connector with a default TLP:AMBER+STRICT

The issue presents itself where by having multiple connectors such as connector-cve, connector-mitre, connector-cisa-known-expoited-vulnerabilites, and connector-mandiant, when a brand new CVE Vulnerability is being created, it becomes a race condition to which connector will become the first to actually create the object.

If Mandiant is first, then it is defaulting all of the objects it creates with the TLP:AMBER+STRICT, which poses issues where many other connectors for enrichment will no longer work on a CVE Vulnerablity because the object has now been flagged with this marking, such as attempting to have connector-first-epss enrich CVE objects with the First EPSS scores.

It seems that the Mandiant connector should likely be updated so that it is not in appropriately creating various objects with higher TLP than they should likely have.

Note: While I have focused on Vulnerability objects, this race condition issue will occur for any type of object that Mandiant is creating where another is also importing this data.

Screenshots (optional)

[animedbz16]

Similar issues with Mandiant creating IPv4-Addr objects.

When Mandiant creates IPv4 observable because there is a Mandiant report that may be associated / related to it. If the IP Address is not already in OpenCTI, then Mandiant connector creates it and marks that IPv4 Object as TLP:AMBER+STRICT.

This poses an issue where other connectors such as GreyNoise will enrich IPv4 Objects but they have a max marking of TLP:CLEAR so then if you attempt to enrich the IPv4 address it will fail to do so.

It is not clear why Mandiant is creating these objects that seemingly are not propitiatory to Mandiant to be creating / marking those objects as TLP:AMBER+STRICT