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

[QRadar Connector : Does not send all hashes in STIX pattern to QRadar] #2631

Closed
vishesh-verma-coder opened this issue Sep 11, 2024 · 0 comments
Assignees
Labels
bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR)
Milestone

Comments

@vishesh-verma-coder
Copy link

Description

During the static review of the code and after testing, it has been identified that newly published QRadar connector does not send all hashes [MD5, SHA1, SHA12....] in the STIX pattern to QRadar.
This is because in the code logic, function returns in the for loop, instead it should use generator (yield) to ensure function loops over all the hashes

Function name : process_indicator

Environment

  1. OS (where OpenCTI server runs): RHEL 8.4 [not related to OS]
  2. OpenCTI version: >5
  3. OpenCTI client: python (connector)
  4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. Create an indicator in Opencti with stix pattern including multiple hashes
  2. Capture the indicator creation event in Live stream [define filters accordingly]
  3. Configure QRadar connector to use the same stream
  4. Qradar stream connector will only send one of the hash and ignore others to QRadar.

Expected Output

  1. All hashes in the STIX pattern should be streamed to QRadar

Actual Output

  1. Only 1 hash value is being streamed.

Additional information

Function name : process_indicator uses return which breaks the iteration in first match of the hash. It should generate the values [using yield] and then response to be handled accordingly for the iterator.

@vishesh-verma-coder vishesh-verma-coder added bug use for describing something not working as expected needs triage use to identify issue needing triage from Filigran Product team labels Sep 11, 2024
@romain-filigran romain-filigran removed the needs triage use to identify issue needing triage from Filigran Product team label Sep 11, 2024
@SamuelHassine SamuelHassine added this to the Release 6.3.0 milestone Sep 13, 2024
@SamuelHassine SamuelHassine added the solved use to identify issue that has been solved (must be linked to the solving PR) label Sep 14, 2024
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 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

3 participants