Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the import of reports #688

Closed
rbnor opened this issue May 5, 2020 · 4 comments
Closed

Improve the import of reports #688

rbnor opened this issue May 5, 2020 · 4 comments
Labels
feature use for describing a new feature to develop solved use to identify issue that has been solved (must be linked to the solving PR)
Milestone

Comments

@rbnor
Copy link

rbnor commented May 5, 2020

Please replace every line in curly brackets { like this } with appropriate answers, and remove this line.

Problem to Solve

  1. Importing reports neglects what report the IOCs came from, the actual report is not linked anywhere. This is an issue because meta data needs to be on another platform or flat in the PDF, instead of accessible from the OpenCTI platform. Further more it should be possible to deselect observables before adding them. Not sure its intended to import PDFs like this or if everyone are expected to use misp, and it perhaps would be smoother to link it up with misp. Im not sure how this mapping works with misp, maybe its better to import from there.

  2. There should be a possibility, together with linking the observables to the uploaded report, to add a threat actor for the IOCs in that report, however that should be editable per indicator as well.

  3. Look for the threat actor and synonyms in the processed material.

  4. To make OpenCti a true knowledge database the uploaded PDF should be indexed and searchable, and viewable, as well as, if not the case today, linked to the observables or indicators imported from it. The last part i think already is the case.

  5. import of indicators from pdf should link the original pdf as well, weird to import something and not save and reference the source imo.

It could be that i got this the wrong way around, but importing an observable almost always is as an indicator with a threat actor connected? The author of that information can be both the user and the report.

Current Workaround

None as of now, need to process each observable manually in incidents?

Create stix from the observables, then import?

Proposed Solution

Outlined together with the problem.

Additional Information

@SamuelHassine SamuelHassine added the feature use for describing a new feature to develop label May 7, 2020
@rbnor
Copy link
Author

rbnor commented May 8, 2020

This is taken very well care of by importing from MISP, but i take it not everyone does that perhaps.

@SamuelHassine SamuelHassine added this to the Release 4.1.0 milestone Sep 14, 2020
@SamuelHassine
Copy link
Member

Hi @rbnor,

I'm reviewing this issue and I have a few comments/questions:

  1. If you create a report in OpenCTI and then import a PDF in the "Files" section of this report, all observables extracted are automatically linked to this report.

  2. If you use the "global" import feature, created observables will not be linked to any report because for the moment we are not able to guess with enough quality if the report is already present or not, and creating a new one could lead to duplicates.

What exactly do you need? Can you describe your workflow with precision? Thanks!

@rbnor
Copy link
Author

rbnor commented Jan 26, 2021 via email

@SamuelHassine
Copy link
Member

Hey @rbnor,

I think you should try the new version, stability has been greatly improved :)

Thanks for your answer!

Kind regards,
Samuel

@SamuelHassine SamuelHassine added inactivity solved use to identify issue that has been solved (must be linked to the solving PR) and removed inactivity labels Jan 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature use for describing a new feature to develop solved use to identify issue that has been solved (must be linked to the solving PR)
Projects
None yet
Development

No branches or pull requests

2 participants