Hoxhunt integration v2

[tomaskukk]

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

• In Progress
• Ready
• In Hold - (Reason for hold)

Description

New version of Hoxhunt integration. Changed support from community from to partner.t

Includes

• Deprecation of old integration
• New integration
• Default playbook
• Incident types
• Incident fields
• Classifier, mapper incoming & outgoing
• Default layout
• Mirroring

Must have

• Tests
• Documentation

[CLAassistant]

All committers have signed the CLA.

[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 @yaakovpraisler 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 @tomaskukk, thanks for contributing to the XSOAR marketplace. To receive credit for your generous contribution please follow this link.

[yaakovpraisler]

Hey @tomaskukk Thank you for your contribution and sorry for the delay with the review.
Overall it looks good, please see my comments below.

@idovandijk You can start reviewing the non-integration content.

[pennane]

All current suggestions considered and code updated accordingly.

[idovandijk]

Thank you @tomaskukk for your patience, I will send my review in the upcoming days.

[yaakovpraisler]

Hey @tomaskukk, Let's wait for @idovandijk's review for the incident types, fields etc. then we'll set a call for a demo.

[yaakovpraisler]

Suggested change

	def __init__(self, base_url: str, headers: dict, proxy: bool = False, verify: bool = False):
	super().__init__(base_url=base_url, headers=headers, proxy=proxy, verify=verify)

When init is not defined, the super.init will be run

[yaakovpraisler]

Suggested change

<~XSOAR> (Available from Cortex XSOAR 6.10.0).</~XSOAR>

Sorry, I missed this in my previous comment here, I would do it by my self but I don't have permissions.
Please do it for all the RN entries.

[idovandijk]

Do we need this to be searchable?

[tomaskukk]

No, I can add unsearchable: true, good catch!

[idovandijk]

Looks good! I have a few comments regarding the fields:

1. There are many new fields in this PR. While some fields are Hoxhunt specific, there are some fields that could potentially be replaced with existing fields in the marketplace.

Please take a look at the existing incident fields in the CommonTypes pack in the Marketplace.
If you find a suitable replacement field, you can associate it to your Hoxhunt incident types by adding your incident types under both the associatedTypes and under the systemAssociatedTypes properties of the field in its JSON file.

If the new field you want to use is a content pack other than CommonTypes, you can decide to keep your existing field, or to use the existing one and add a dependency in your pack to the destination pack. Since using fields from packs other than CommonTypes (which is preinstalled) will introduce a new dependency for your pack, I leave this to you to decide. CommonTypes however, is a Core pack, which means XSOAR users get those fields preinstalled anyway, so it's worth using them.

The advantage to using existing fields rather than adding new ones is that they are shared across different vendors and can be used in widgets, dashboards, etc. For example, if I want to filter all incidents by the "Email To" fields, I won't be seeing incidents where the "Hoxhunt Email To" field is populated.

2. In addition to my previous point regarding fields, there is an additional check I'd like to ask from your side. As the Hoxhunt pack is also available in XSIAM, we can use Field Aliases instead of adding those new alert fields into XSIAM (we will only add them to XSOAR). Please go over the CoreAlertFields pack, and see whether any fields from there can be utilized for your use-case.

For example, let's say the Email Recipient field in the CoreAlertFields pack fulfills our need for our Hox FT Email To field. We will do the following:
A. Add the name of the field Hox FT Email To under the Aliases property in the field Email Recipient from the CoreAlertFields pack like so:

B. Edit the Hox FT Email To field and add the following property, to make sure this field is added only to XSOAR (because XSIAM will use the alias);

"marketplaces": [
"xsoar"
]

3. Please rename the fields to have spaces between words in Title Case.

Regarding the playbook: Before using rasterize add a task with the IsIntegrationAvailable automation to check if Rasterize is available prior to using it.

Once you're able to introduce the changes, I would be happy to see the playbook in action, the mapper and classifier, and the layout :)

If you have any questions please don't hesitate to let me know. Looking forward to get this merged 😎

[tomaskukk]

Hey @idovandijk. Thank you for the thorough review.

There are many new fields in this PR. While some fields are Hoxhunt specific, there are some fields that could potentially be replaced with existing fields in the marketplace.

We also had this chat with @edik24, the reason we wanted to use custom fields is to keep the fields isReadOnly: true. These fields should never be edited by the user, as they are kept up to date within our server. User should have no control over them. The suitable replacements that I checked, were isReadOnly: false.

There are a couple of fields that are isReadOnly: false, but we didn't find suitable built-in system fields for them.

In addition to my previous point regarding fields, there is an additional check I'd like to ask from your side. As the Hoxhunt pack is also available in XSIAM, we can use Field Aliases instead of adding those new alert fields into XSIAM (we will only add them to XSOAR). Please go over the CoreAlertFields pack, and see whether any fields from there can be utilized for your use-case.

Honestly I'm not that familiar with XSIAM. I trust your guidance, but does it have implications such as mentioned above in the first comment reply (readonly fields)?

Please rename the fields to have spaces between words in Title Case.

Will do!

[idovandijk]

We also had this chat with @edik24, the reason we wanted to use custom fields is to keep the fields isReadOnly: true. These fields should never be edited by the user, as they are kept up to date within our server. User should have no control over them. The suitable replacements that I checked, were isReadOnly: false.

There are a couple of fields that are isReadOnly: false, but we didn't find suitable built-in system fields for them.

Thank you for bringing this to my attention. In that case, it makes sense to keep your fields.

Honestly I'm not that familiar with XSIAM. I trust your guidance, but does it have implications such as mentioned above in the first comment reply (readonly fields)?

Let me get back to you this. As I don't want you to have to make changes and then revert them, please ignore this point for now until I can update with how it will behave.

One more thing, as you make changes to the field names, be aware that these changes will require also updating the mapper and layout to reflect the new names.