I am trying to pull CWE data into OpenCTI using the API. To simplify what is going wrong, I will describe it using a bundle upload to OpenCTI directly because it results in the same problems.
The bundle also contains Grouping, Weakness, and Extension Definition (for Weakness definition) objects.
So why are they not being ingested?
So firstly, if I did this again, I would represent CWEs as Vulnerabilities. We did this originally to make a clear distinction between CVEs and CWEs in Vulmatch . In hindsight, that was a bad decision, but we’re very wedded to it now
Now, to answer your question…
These are present in the import (check the Containers tab)
OpenCTI currently has limited support for custom STIX objects, and Extension Definitions.
Check out the Figma diagram on this page
In short no custom objects, unless hardcoded into OpenCTI (e.g. crytocurrency-wallet) are supported, hence why you don’t see them.
Support for Extension Definitions seems to be the same. Unless they are declared in the OCTI code, they will be ignored.
Looking at these two stale tickets, I don’t think support is coming in OCTI any time soon.
opened 09:22AM - 31 Oct 23 UTC
feature
ingestion
## Description
In OpenCTI, extension fields (e.g. "x-opencti-...) exist. Othe… r platforms with the ability to export in STIX format also have custom fields.
When importing a STIX bundle from this other platform, with custom fields, the import connector does not recognize the objects (i.e. I have nothing in my workbench).
If I delete the custom fields from the other platform and leave the rest of the file as it is, the connector detects all the objects (my workbench is complete).
Shouldn't the import connector just ignore the unknown fields and still find the objects contained in the bundle?
Without this, it is impossible to import STIX bundles from other platforms (by "other" I mean, other than OpenCTI).
## Environment
OpenCTI 5.11.12
opened 06:35PM - 29 May 24 UTC
feature
needs triage
Hi folks,
I use OpenCTI to keep track of relevant IOCs and other data that co… mes from various internal/external sources in the form of STIX bundles, but am unable to make full use of OpenCTI due to the seeming lack of support for extra information/fields in STIX objects.
This is an issue for me because the items we track must be associated with state information that's produced/consumed by an internal service, which cannot easily be represented by the existing domain objects and relationships. Since OpenCTI should be the canonical place for storing STIX IOCs/observables/etc, we need our internal service to push items to OpenCTI (in the form of STIX JSON bundles) and be able to create, update, and read this OOB information (serialized/deserialized in a string format).
Currently I'm just testing with the manual bundle import feature, but none of my attempts to include an extra field have worked. I've tried including extra fields (`x_internalservice_metadata`) and also STIX extensions (both custom ones and the existing special-case ones described here https://blog.filigran.io/opencti-data-sharing-capabilities-upgrade-a1235827a521, exactly as shown in the example).
I've been completely unable to get any sort of extra field containing a string value to be associated with an SDO. If it does import successfully, the extra data is silently dropped, and not present when the object is exported as a bundle.
Is there plan to add support for anything like extensions or custom fields? Or if it can be done, is this documented?
I think this could be an important feature of OpenCTI as it would facilitate better interoperability with STIX consumers/producers that track information which is not understood by OpenCTI.
Are there any recommended workarounds for this at the moment?
(I'm using OpenCTI 6.0.10 Community in standalone mode)
I’ve seen some people implement data connectors to provide a transform step to convert custom objects/properties into those supported by OCTI.
e.g. take weakness and convert to a vulnerability then import.
We will do something like this for our Vulmatch and CTI Butler OCTI connectors soon.
