Bug: PDF Reports are being created as File and Artifact objects

[SYNchroACK]

MISP-STIX usage

No response

Expected behavior

https://docs.oasis-open.org/cti/stix/v2.1/csprd01/stix-v2.1-csprd01.html#_Toc16070588

I believe the correct approach is to handle external analysis:attachment as an external reference with a link.

Actual behavior

File and Artifact objects are created to represent a PDF Report.

Steps to reproduce

Parse an event with an external analysis:attachment attribute.

Version

2.4.168

Python version

3.10

Relevant log output

No response

Extra attachments

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[SYNchroACK]

@chrisr3d any update on this? Again, I believe File and Artifact objects are not meant to store intelligence PDF reports.

1.2.3 STIX Cyber-observable Objects
STIX defines a set of STIX Cyber-observable Objects (SCOs) for characterizing host-based and network-based information. SCOs are used by various STIX Domain Objects (SDOs) to provide supporting context. The Observed Data SDO, for example, indicates that the raw data was observed at a particular time.

STIX Cyber-observable Objects (SCOs) document the facts concerning what happened on a network or host, and do not capture the who, when, or why. By associating SCOs with STIX Domain Objects (SDOs), it is possible to convey a higher-level understanding of the threat landscape, and to potentially provide insight as to the who and the why particular intelligence may be relevant to an organization. For example, information about a file that existed, a process that was observed running, or that network traffic occurred between two IPs can all be captured as SCOs.

I believe we should create an external reference on the Report object.
See here: https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_xzbicbtscatx:~:text=section%207.2.3).-,external_references,-list%20of%20type

The link to the external reference would be the direct link to the attachment on misp instance. In case the external reference attribute is a link instead of the attachment, then the report external reference should be that exact link.

External Reference: https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_72bcfr3t79jx

[iglocska]

Hey there! I agree, the current implementation is not ideal, however, this is a trade-off when dealing with an export format that is doesn't fully cover all aspects of the initial format. Our options are basically to altogether lose this information, or accomodate it the best we can (I'd always vouch for the second option being the most prudent).

Using external references is basically a no-go for the following reasons:

• It won't allow us to actually store the file itself
• Cross referencing a url for a file hosted on MISP is not a good idea for the following reasons:
  • Secrecy: MISP instances should not always be publicly identified and STIX output can / may be re-used in other contexts / reshared further (if the distribution and TLP allow us to do so)
  • Not all MISP instances are available, often data gets produced on internal instances rather than on publicly accessible ones. Also, the STIX data should be usable in a vaccum, even without internet connectivity.

Therefore, I'd be happy to promote the idea of moving reports and supporting files at large to external references, once STIX starts providing a better home for such files. Perhaps the best course of action would be to take this up with the STIX TC?