Change problematic verbiage of black/white – replace with block/allow

[ali-sawyer]

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)

Related Issues

n/a

Description

Replaces the offensive wording of "blacklist" and "whitelist" with the accepted industry standard terms of "blocklist" and "allowlist". As we are pushing this pack to more customers, it is important to update this verbiage to align with our values.

References:

• https://www.ciisec.org/wp-content/uploads/2023/10/DEI-Guide-to-Inclusive-Language-in-Cybersecurity.pdf
• https://www.splunk.com/en_us/blog/learn/blacklist-whitelist-inclusivity.html

Must have

• Tests
• 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 @rshunim 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 @ali-sawyer, thanks for contributing to the XSOAR marketplace. To receive credit for your generous contribution please follow this link.

[rshunim]

Hi @ali-sawyer, Thanks for your fixes.
The PR is approved by me.
@tomer-pan I'd appreciate your review too.
Regarding the RN file . Please fix the file so the validation passes

[rshunim]

Hi @ShirleyDenkberg, there are small changes here in the documentation, please review it too

[ShirleyDenkberg]

@rshunim @tomer-pan Doc review completed.

[tomer-pan]

@ali-sawyer
Changing incident type id and name will affect all other places using this object.
For example, in the playbook "TIM - Process AWS indicators" (FeedAWS pack) - there's a task named "Create Process Indicators Manually incident" which creates a new incident from that type. There are others as well.
If we change the id+name of this incident type, we should iterate through all of the other places which uses this incident type and change them as well to use the new name/id so they won't break.

[tomer-pan]

@ali-sawyer @rshunim
For all the places where the description is changed - that's not an issue.
BUT when changing IDs of objects, it will affect other objects using it.
For example other playbooks that count on the old name or even customers' custom playbooks or other objects which use the current layout or incident type IDs - we can potentially break those.
So, we should make sure to address all of the other OOTB content which uses the old IDs and maybe even show a breaking change note for this release which states that all custom content that relies on the layout or incident type might break and appropriate changes should be done to this custom content.

[ali-sawyer]

@tomer-pan that makes sense. I updated the references in the other feed packs that use the content that was renamed. Lmk if I should add a breaking change note.

[tomer-pan]

@ali-sawyer Thanks, now all looks good.
And yes, please add a breaking change note.