[Security Solution] Upgrading a prebuilt rule with exceptions succeeds on the 2nd attempt

[pborgonovi]

Describe the bug:

When updating a prebuilt rule that has an exception added, the system initially shows a message stating “1 rule failed to update,” even though no errors are logged. Subsequently, upon clicking “Update rule” again, the rule is successfully updated with a confirmation message, “1 rule updated successfully.”

Kibana/Elasticsearch Stack version:

8.17

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

Prebuilt Rules Update

Pre requisites:

1. Prebuilt rules are installed
2. Rule updates are available

Steps to reproduce:

1. Navigate to the Rules Management page and locate a prebuilt rule.
2. Add a rule exception to the rule.
3. Go to the Updates tab in the Rule Management table.
4. Click Update rule for the rule with an available update.
5. Observe the message “1 rule failed to update.”
6. Click the Update again.

Current behavior:

• The system initially shows the message: “1 rule failed to update.”
• No corresponding error is observed in the logs.
• Click Update Rule again, the rule is successfully updated, and the message changes to: “1 rule updated successfully.”

Expected behavior:

If no errors occur during the update process, the rule should update successfully on the first attempt, with the message: “1 rule updated successfully.”

Screenshots (if relevant):

prebuiltRulesCustomizationEnabled flag ON:

Screen.Recording.2024-12-04.at.12.00.13.PM.mp4

prebuiltRulesCustomizationEnabled flag OFF:

Screen.Recording.2024-12-04.at.12.25.25.PM.mov

[elasticmachine]

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

[elasticmachine]

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

[elasticmachine]

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

[banderror]

@pborgonovi I believe there is an error returned from the upgrade/_perform API endpoint, and the rule is being upgraded successfully only from the second attempt.

Could you please record a HAR file and attach it to the description? It should include rule editing and both attempts to upgrade the rule.

[pborgonovi]

@banderror please find the HAR file attached. I had to rename the file adding .txt extension because it's not possible to attach HAR files.

Let me know if it works

update_rule_exception.har.txt

[banderror]

Thank you @pborgonovi, it works.

Indeed, the rule upgrade fails on the 1st attempt and succeeds on the 2nd one.

First call to /internal/detection_engine/prebuilt_rules/upgrade/_perform:

{"mode":"SPECIFIC_RULES","rules":[{"rule_id":"000047bb-b27a-47ec-8b62-ef1a5d2c9e19","version":310,"revision":0,"fields":{"references":{"pick_version":"RESOLVED","resolved_value":["https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm","https://developer.okta.com/docs/reference/api/system-log/","https://developer.okta.com/docs/reference/api/event-types/","https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy","https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security","https://www.elastic.co/security-labs/starter-guide-to-understanding-okta"]},"related_integrations":{"pick_version":"RESOLVED","resolved_value":[{"package":"okta","version":"^3.0.0"}]}}}],"pick_version":"MERGED"}

{
    "summary": {
        "total": 1,
        "skipped": 0,
        "succeeded": 0,
        "failed": 1
    },
    "results": {
        "updated": [],
        "skipped": []
    },
    "errors": [
        {
            "message": "Revision mismatch for rule_id 000047bb-b27a-47ec-8b62-ef1a5d2c9e19: expected 1, got 0",
            "rules": [
                {
                    "rule_id": "000047bb-b27a-47ec-8b62-ef1a5d2c9e19"
                }
            ]
        }
    ]
}

Second call to /internal/detection_engine/prebuilt_rules/upgrade/_perform:

{"mode":"SPECIFIC_RULES","rules":[{"rule_id":"000047bb-b27a-47ec-8b62-ef1a5d2c9e19","version":310,"revision":1,"fields":{"references":{"pick_version":"RESOLVED","resolved_value":["https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm","https://developer.okta.com/docs/reference/api/system-log/","https://developer.okta.com/docs/reference/api/event-types/","https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy","https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security","https://www.elastic.co/security-labs/starter-guide-to-understanding-okta"]},"related_integrations":{"pick_version":"RESOLVED","resolved_value":[{"package":"okta","version":"^3.0.0"}]}}}],"pick_version":"MERGED"}

{
    "summary": {
        "total": 1,
        "skipped": 0,
        "succeeded": 1,
        "failed": 0
    },
    "results": {
        "updated": [
            {
                "name": "Attempt to Modify an Okta Policy Rule",
                "description": "Detects attempts to modify a rule within an Okta policy. An adversary may attempt to modify an Okta policy rule in order to weaken an organization's security controls.",
                "risk_score": 21,
                "severity": "low",
                "timestamp_override": "event.ingested",
                "timestamp_override_fallback_disabled": false,
                "license": "Elastic License v2",
                "note": "## Triage and analysis\n\n### Investigating Attempt to Modify an Okta Policy Rule\n\nThe modification of an Okta policy rule can be an indication of malicious activity as it may aim to weaken an organization's security controls.\n\n#### Possible investigation steps:\n\n- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert.\n- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor.\n- Examine the `okta.outcome.reason` field for additional context around the modification attempt.\n- Check the `okta.outcome.result` field to confirm the rule modification attempt.\n- Check if there are multiple rule modification attempts from the same actor or IP address (`okta.client.ip`).\n- Check for successful logins immediately following the modification attempt.\n- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the modification attempt.\n\n### False positive analysis:\n\n- Check if there were issues with the Okta system at the time of the modification attempt. This could indicate a system error rather than a genuine threat activity.\n- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the modification attempt. If these match the actor's normal behavior, it might be a false positive.\n- Verify the actor's administrative rights to ensure they are correctly configured.\n\n### Response and remediation:\n\n- If unauthorized modification is confirmed, initiate the incident response process.\n- Immediately lock the affected actor account and require a password change.\n- Consider resetting MFA tokens for the actor and require re-enrollment.\n- Check if the compromised account was used to access or alter any sensitive data or systems.\n- If a specific modification technique was used, ensure your systems are patched or configured to prevent such techniques.\n- Assess the criticality of affected services and servers.\n- Work with your IT team to minimize the impact on users and maintain business continuity.\n- If multiple accounts are affected, consider a broader reset or audit of MFA tokens.\n- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).",
                "output_index": "",
                "version": 310,
                "tags": [
                    "Use Case: Identity and Access Audit",
                    "Tactic: Defense Evasion",
                    "Data Source: Okta"
                ],
                "enabled": false,
                "risk_score_mapping": [],
                "severity_mapping": [],
                "interval": "5m",
                "from": "now-60s",
                "to": "now",
                "actions": [],
                "exceptions_list": [
                    {
                        "id": "82679834-e475-499c-a873-2bc20692221e",
                        "list_id": "6e519c12-80ab-4e69-894f-e5cec55be127",
                        "type": "rule_default",
                        "namespace_type": "single"
                    }
                ],
                "author": [
                    "Elastic"
                ],
                "false_positives": [
                    "Consider adding exceptions to this rule to filter false positives if Okta MFA rules are regularly modified in your organization."
                ],
                "references": [
                    "https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm",
                    "https://developer.okta.com/docs/reference/api/system-log/",
                    "https://developer.okta.com/docs/reference/api/event-types/",
                    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
                    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
                    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta"
                ],
                "max_signals": 100,
                "threat": [
                    {
                        "framework": "MITRE ATT&CK",
                        "tactic": {
                            "id": "TA0005",
                            "name": "Defense Evasion",
                            "reference": "https://attack.mitre.org/tactics/TA0005/"
                        },
                        "technique": [
                            {
                                "id": "T1562",
                                "name": "Impair Defenses",
                                "reference": "https://attack.mitre.org/techniques/T1562/",
                                "subtechnique": [
                                    {
                                        "id": "T1562.007",
                                        "name": "Disable or Modify Cloud Firewall",
                                        "reference": "https://attack.mitre.org/techniques/T1562/007/"
                                    }
                                ]
                            }
                        ]
                    }
                ],
                "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.",
                "related_integrations": [
                    {
                        "package": "okta",
                        "version": "^3.0.0"
                    }
                ],
                "required_fields": [
                    {
                        "name": "event.action",
                        "type": "keyword",
                        "ecs": true
                    },
                    {
                        "name": "event.dataset",
                        "type": "keyword",
                        "ecs": true
                    }
                ],
                "id": "561cb5f3-6c26-4547-8959-681ac9b83e2b",
                "rule_id": "000047bb-b27a-47ec-8b62-ef1a5d2c9e19",
                "immutable": true,
                "rule_source": {
                    "type": "external",
                    "is_customized": true
                },
                "updated_at": "2024-12-06T16:51:18.436Z",
                "updated_by": "elastic",
                "created_at": "2024-12-04T19:45:40.284Z",
                "created_by": "elastic",
                "revision": 2,
                "type": "query",
                "index": [
                    "filebeat-*",
                    "logs-okta*"
                ],
                "filters": [],
                "query": "event.dataset:okta.system and event.action:policy.rule.update\n",
                "language": "kuery"
            }
        ],
        "skipped": []
    },
    "errors": []
}