GTI Release 2.0.0

[crestdatasystems]

Contributing to Cortex XSOAR Content

Make sure to register your contribution by filling the contribution registration form

The Pull Request will be reviewed only after the contribution registration form is filled.

Status

• [x] In Progress
• [ ] Ready
• [ ] In Hold - (Reason for hold)

Description

Added following Integrations:

Google Threat Intelligence - ASM Issues

• This integration allows the creation of incidents based on ASM Issues from Google Threat Intelligence.

• Added the following commands:

  • gti-asm-issue-list
  • gti-asm-issue-get
  • gti-asm-issue-status-update

Google Threat Intelligence - DTM Alerts

• This integration allows the creation of incidents based on DTM Alerts from Google Threat Intelligence.

• Added the following commands:

  • gti-dtm-alert-list
  • gti-dtm-alert-get
  • gti-dtm-alert-status-update

Must have

• [x] Tests
• [x] Documentation

[content-bot]

Thank you for your contribution. Your generosity and caring are unrivaled! Make sure to register your contribution by filling the Contribution Registration form, so our content wizard @merit-maita will know the proposed changes are ready to be reviewed. For your convenience, here is a link to the contributions SLAs document.

[content-bot]

Hi @crestdatasystems, thanks for contributing to the XSOAR marketplace. To receive credit for your generous contribution please follow this link.

[crestdatasystems]

Hi @Benimanela @merit-maita,

Please let us know the next steps to move forward with this PR.

[merit-maita]

@Benimanela can you please take a look?

[crestdatasystems]

Hi @Benimanela,

Thanks for reviewing the PR! We’ve implemented the suggested changes, and here’s a summary of the updates:

General

All files have been formatted using demisto-sdk to ensure alignment with XSOAR standards.

Mappers

• Added first_seen and created_at fields to map to the common field Occurred in the incoming mappers for both integrations (ASM Issues and DTM Alerts).
• The severity field continues to be mapped through the integration code.
• For status, we’ve introduced a custom incident field to display the external system’s status in the layout.

Layout

• Severity is populated directly through the integration code.
• Status is managed via the custom incident field, ensuring both DTM Alerts and ASM Issues reflect their respective external statuses correctly.

ASM Issue Layout

---

DTM Alert Layout

Issue Observed in the PR

• A default value has been set for the incident type parameter in both integrations.
• In XSOAR 6.14, everything works as expected. However, in XSOAR 8.9, DTM Alert incidents are being dropped when using the default incident type.
• The same configuration works correctly for ASM Issues, which are fetched successfully with their default type.
• Please share your thoughts on providing a default incident type. Additionally, could you confirm if there might be an issue with the incident type itself or with its definition in the integration YML?

[crestdatasystems]

Hi @Benimanela & @merit-maita,

We’ve shared the demo recording showcasing the updates introduced in the v2.0.0 release via the DFIR Slack. Please let us know if you have any questions or need further clarification on any of the changes.

Regarding the previously reported issue with the default incident type that causes incidents to drop, if there is still no clear cause identified, would you prefer that we remove the default value for now?

Please let us know how you would like us to proceed with this issue. Thanks!

[Benimanela]

u have any questions or need further clarification on any of the changes.

Hi @crestdatasystems, The demo looks great, nice work.

Regarding the incident type issue, can we schedule a short session to figure it out together?

[crestdatasystems]

u have any questions or need further clarification on any of the changes.

Hi @crestdatasystems, The demo looks great, nice work.

Regarding the incident type issue, can we schedule a short session to figure it out together?

Hi @Benimanela,

Thanks for reviewing the PR!

Please feel free to book any available slot on my calendar: https://calendar.app.google/eti5vcQgvpWEZ3jz7

[crestdatasystems]

Hi Team,

We’ve identified the root cause and updated the PR accordingly.

It appears that XSOAR 8 has a bug in the mapper that triggers when a response field contains an empty string. After removing all empty-string fields from the incident JSON, the issue was resolved immediately.

We’ve also observed the same behavior in other integrations where empty-string values cause incidents to be dropped in XSOAR 8. This seems to be a critical bug in the mapper, so ideally it should be addressed for all integrations.

[crestdatasystems]

Hi @merit-maita @Benimanela @DeanArbel,

It has been over two weeks since we resolved the only remaining incident-type issue. We haven’t received any further comments from the reviewers, and no additional actions have been taken.

We kindly request your assistance in progressing this PR, as the Google team is expecting it to be published on the marketplace as soon as possible.

[merit-maita]

Hi @merit-maita @Benimanela @DeanArbel,

It has been over two weeks since we resolved the only remaining incident-type issue. We haven’t received any further comments from the reviewers, and no additional actions have been taken.

We kindly request your assistance in progressing this PR, as the Google team is expecting it to be published on the marketplace as soon as possible.

hi @crestdatasystems sorry for the delay in handling the contribution, im on it today

[merit-maita]

@crestdatasystems switching to complex mapper is not the recommended practice, so i need to take it with our security team, once looked into and approved by them, i'll go ahead with the merging process

[github-actions[bot]]

Thank you for your contribution. Your external PR has been merged and the changes are now included in an internal PR for further review. The internal PR will be merged to the master branch within 3 business days.