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

[Sentinel-intel] Bad management of updates and non-deletion #3289

Open
Lhorus6 opened this issue Jan 16, 2025 · 1 comment
Open

[Sentinel-intel] Bad management of updates and non-deletion #3289

Lhorus6 opened this issue Jan 16, 2025 · 1 comment
Assignees
Labels
bug use for describing something not working as expected filigran support [optional] use to identify an issue related to feature developed & maintained by Filigran.
Milestone

Comments

@Lhorus6
Copy link
Contributor

Lhorus6 commented Jan 16, 2025

Description

The Sentinel-intel connector allowing to feed Sentinel with IOCs does its role of "creation" but not of "update", nor of "deletion". Here are the problems observed:

  • When updating an element on the OpenCTI side, the existing Indicator on the Sentinel side is not modified. Instead, the connector adds a new entry in the Sentinel table (therefore a duplicate but with the up-to-date values)
  • When deleting, the Sentinel connector seems to do nothing, i.e. the Indicator in question remains in the Sentinel table.

Environment

OCTI 6.4.7

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. Deploy a Sentinel-intel connector
  2. Play with the creation, update and deletion of Indicator and see the behavior on the Sentinel side.

Expected Output

  • When I create an Indicator on OpenCTI -> I create an entry in my Sentinel table.
  • When I update an Indicator on OpenCTI -> I update the existing entry in my Sentinel table.
  • When I delete an Indicator on OpenCTI -> I delete the existing entry in my Sentinel table.

Actual Output

See in the description

@Lhorus6 Lhorus6 added bug use for describing something not working as expected needs triage use to identify issue needing triage from Filigran Product team labels Jan 16, 2025
@romain-filigran romain-filigran added this to the Bugs backlog milestone Jan 16, 2025
@romain-filigran romain-filigran added the filigran support [optional] use to identify an issue related to feature developed & maintained by Filigran. label Jan 16, 2025
@Lhorus6
Copy link
Contributor Author

Lhorus6 commented Jan 16, 2025

Maybe the same root cause : #3177

@helene-nguyen helene-nguyen removed the needs triage use to identify issue needing triage from Filigran Product team label Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug use for describing something not working as expected filigran support [optional] use to identify an issue related to feature developed & maintained by Filigran.
Projects
None yet
Development

No branches or pull requests

4 participants