Report export to STIX2 brings start_time == stop_time for relations

[andurin]

Description

While finished a report in OCTI I wanted to export the report to JSON(STIX) to import that manually into a MISP Instance.
MISP importer complained about start_time == stop_time values which could be found in the generated relations.

Environment

1. OS (where OpenCTI server runs): Debian 11
2. OpenCTI version: OpenCTI 6.3.3
3. OpenCTI client: None used
4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

1. Browser: /dashboard/analyses/reports
2. Choose a report which already has some relations
3. Export that report:

• Export format: application/json
• Export Type: Full Export

4. Download the report
5. Open in favorite editor
6. Search for "stop_time", find a relation object and compare with start_time

Expected Output

start_time != stop_time

Actual Output

start_time == stop_time

Additional information

Based on this it may be easy to just add an extra second or either microsecond to the stop_time.

OpenCTI-Platform/connectors@a7d6a3a

[nino-filigran]

@andurin indeed, I noticed this behavior but not sure it's an export problem however.
Indeed, by default, start time and stop time are populated with the same values, which then causes the bug when exporting and importing to MISP.

[nino-filigran]

The fix is therefore for us to have at least 1s of difference between two dates on our side, when creating a relation.

[andurin]

Thank you for having a look into this. Yes, it is MISP complaining about this but that's ok since also the Stix Standard says something like "if you propagate start_time and end_time you must ensure that end_time is after start_time." What do you think - can I hope for a fix in the next Version? 03.10.2024 09:29:43 nino-filigran ***@***.***>:

…

@andurin[https://github.com/andurin] indeed, I noticed this behavior but not sure it's an export problem however. Indeed, by default, start time and stop time are populated with the same values, which then causes the bug when exporting and importing to MISP. — Reply to this email directly, view it on GitHub[#8575 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAEEFJDU7VGPEZFOVQ6J55LZZTW6LAVCNFSM6AAAAABPHKQGMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJQG4YTIOBUHE]. You are receiving this because you were mentioned. [Verfolgungsbild][https://github.com/notifications/beacon/AAEEFJEOIPB77D3VBKJTGNTZZTW6LA5CNFSM6AAAAABPHKQGMCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUOP5U6C.gif]

[nino-filigran]

@andurin I'm not sure it will be in the next release: we have quite some high-priority bugs that also require our attention. We'll prioritize this bug in the top part of the bucket, but can't promise anything regarding when it will be fixed.

The "milestone" will be updated once the bug will be fixed, allowing you to know when the fix will be released.

[marieflorescontact]

@nino-filigran : start_time and stop_time have same value because relationship creation form is sent with default values.

We need to decide if the form should be send :

• with differents start_time and stop_time default values
• without default values as it is done in Cases

Check must be added to verify that start_time and stop_time are different

[nino-filigran]

@marieflorescontact I spoke internally with product team and we decided to always have a date at the creation of a relationship. This means the fix should consists in:

• Add a start & stop time when creating a relationship in knowledge views and in investigations to ensure that we have the same behavior accross the platform
• Ensure that the Start time differs from the stop time every time, by making start time =now-1sec and stop time = now