[Security Solution] When duplicating a prebuilt rule, 'Related Integrations' and 'Required Fields' values are not inherited from the original rule

[pborgonovi]

Describe the bug:
When duplicating a prebuilt rule, 'Related Integrations' and 'Required Fields' values are not inherited from the original rule

Kibana/Elasticsearch Stack version:
8.15

Server OS version:

Browser and Browser OS versions:

Elastic Endpoint version:

Original install method (e.g. download page, yum, from source, etc.):

Functional Area (e.g. Endpoint management, timelines, resolver, etc.):

Steps to reproduce:

1. Duplicate a prebuilt rule containing related integrations and required fields
2. Open the duplicated rule and validate the fields

Current behavior:
'Related Integrations' and 'Required Fields' values are not inherited from the original rule

Expected behavior:
'Related Integrations' and 'Required Fields' values should be inherited from the original rule as explicitly specified as requirement of:
#173595
#173594

Screenshots (if relevant):

Screen.Recording.2024-08-15.at.8.58.38.AM.mov

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

{
    "id": "94c7ce40-4be5-4c80-a899-ca433d48ba60",
    "updated_at": "2024-08-15T15:59:25.696Z",
    "updated_by": "19276298",
    "created_at": "2024-08-15T15:59:25.055Z",
    "created_by": "19276298",
    "name": "Endpoint Security [Duplicate]",
    "tags": [
        "Data Source: Elastic Defend"
    ],
    "interval": "5m",
    "enabled": false,
    "revision": 0,
    "description": "Generates a detection alert each time an Elastic Endpoint Security alert is received. Enabling this rule allows you to immediately begin investigating your Endpoint alerts.",
    "risk_score": 47,
    "severity": "medium",
    "license": "Elastic License v2",
    "output_index": "",
    "rule_name_override": "message",
    "timestamp_override": "event.ingested",
    "author": [
        "Elastic"
    ],
    "false_positives": [],
    "from": "now-10m",
    "rule_id": "00887f99-2fe8-4a9f-986f-a3abbc612db7",
    "max_signals": 10000,
    "risk_score_mapping": [
        {
            "field": "event.risk_score",
            "operator": "equals",
            "value": ""
        }
    ],
    "severity_mapping": [
        {
            "field": "event.severity",
            "operator": "equals",
            "severity": "low",
            "value": "21"
        },
        {
            "field": "event.severity",
            "operator": "equals",
            "severity": "medium",
            "value": "47"
        },
        {
            "field": "event.severity",
            "operator": "equals",
            "severity": "high",
            "value": "73"
        },
        {
            "field": "event.severity",
            "operator": "equals",
            "severity": "critical",
            "value": "99"
        }
    ],
    "threat": [],
    "to": "now",
    "references": [],
    "version": 103,
    "exceptions_list": [],
    "immutable": false,
    "rule_source": {
        "type": "internal"
    },
    "related_integrations": [],
    "required_fields": [],
    "setup": "## Setup\n\nThis rule is configured to generate more **Max alerts per run** than the default 1000 alerts per run set for all rules. This is to ensure that it captures as many alerts as possible.\n\n**IMPORTANT:** The rule's **Max alerts per run** setting can be superseded by the `xpack.alerting.rules.run.alerts.max` Kibana config setting, which determines the maximum alerts generated by _any_ rule in the Kibana alerting framework. For example, if `xpack.alerting.rules.run.alerts.max` is set to 1000, this rule will still generate no more than 1000 alerts even if its own **Max alerts per run** is set higher.\n\nTo make sure this rule can generate as many alerts as it's configured in its own **Max alerts per run** setting, increase the `xpack.alerting.rules.run.alerts.max` system setting accordingly.\n\n**NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.",
    "type": "query",
    "language": "kuery",
    "index": [
        "logs-endpoint.alerts-*"
    ],
    "query": "event.kind:alert and event.module:(endpoint and not endgame)\n",
    "actions": []
}

Any additional context (logs, chat logs, magical formulas, etc.):

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[banderror]

@pborgonovi Fantastic catch, appreciate it a lot! This PR will fix this bug: #191065

It's a shame that we missed this during the implementation, then code review, and finally acceptance and exploratory testing for #173595 and #173594 - two very similar features in a row. While acceptance testing is not focused on finding bugs, all the rest of the stages of this process require comprehensive testing with checking all the edge cases, especially when they are listed in the Acceptance Criteria. Fortunately, the bug's impact is not high and we can backport it to a patch version.

cc @nikitaindik @maximpn

[banderror]

@pborgonovi The bug has been fixed in #191065 and I'm waiting for the backport to get merged to 8.15. I hope it will be merged soon and the fix will make it to v8.15.1.

[pborgonovi]

Retest

8.16 SNAPSHOT - Passed ✅

Screen.Recording.2024-08-29.at.8.32.25.AM.mov

8.15.1 SNAPSHOT - Passed ✅

Screen.Recording.2024-08-29.at.9.39.43.AM.mov