Content Pack Update Breaks One Tenant's Custom Phishing Playbook
Your organization is consolidating three security teams onto one Cortex XSOAR multi-tenant deployment. Business unit A (retail, 900 endpoints) maintains a heavily customized copy of a Marketplace phishing playbook plus 14 local scripts. Business unit B (manufacturing, 4,200 endpoints including OT) must never send email from the platform and needs analysts restricted to their own incidents. Business unit C is an MSSP customer with a contractual EU data-residency clause. Each BU has its own analysts but all sit under one parent tenant. During the pilot, immediately after an automatic content pack update, six tasks in BU-A's playbook return 'no result', and a custom script that used to populate a context key now returns null. Playbook runs still report success. BU-B analysts report they can see BU-A incidents in global search results. The SOC has three weeks before a quarterly audit and no budget for additional engines.
1. Explain the most likely cause of the BU-A failures and list the controls you would put in place so that a content pack update cannot silently break custom automation again.
Read the worked answer
Most likely cause: the pack update changed shared content. Marketplace pack content and local custom content resolve in the same namespace, so a pack that adds a script, an integration command, or a task output with a name matching a local customization can shadow it. The symptoms fit the hypothesis: only the tenant with heavy customization broke, the break appeared right after the update, tasks returned 'no result' (typically a task whose output filter no longer matches), and a null return suggests duplicate name resolution or a renamed context key. Confirm by diffing the pack version, running the script directly from the war room, and comparing task inputs before and after the update.
Controls: (1) never edit Marketplace content in place - export local changes into a namespaced custom pack with a prefix; (2) pin pack versions and schedule updates, testing them in a dev tenant first; (3) maintain a regression pack with fixed inputs and asserted outputs for each critical playbook; (4) add task-level error handling and fallback values so a null result cannot pass silently; (5) read release notes for renamed commands and context keys before approving an update.
2. BU-B analysts can see BU-A incidents. Diagnose the cause and propose the tenant and role model you would put in place, including what is needed for BU-C's residency requirement.
Read the worked answer
This is an RBAC problem, not evidence that multi-tenancy is unsuitable. Permissions are typically the union of roles assigned at parent and child level, and global search returns any investigation the user's role can view. If BU-B analysts see BU-A incidents, either they hold a parent-level role with investigation or evidence read, or both BUs were placed under a shared parent default role that was never overridden. Fix by assigning roles at the child tenant only, removing parent-level analyst roles, and verifying with a test account per BU. Also confirm what global search actually spans in your version, since admin roles may search across tenants by design.
For BU-C, RBAC cannot satisfy data residency. Use a separate tenant in the required region and inventory every integration that moves data off-platform: threat intel lookups, sandbox detonation, email notifications, chat connectors, and any playbook calling an external API. Disable or repoint them to EU endpoints and document it for the auditor. In three weeks, prioritize the role cleanup and the data-flow inventory; those are the items an auditor will actually test.
3. What would you monitor in the first 72 hours after the RBAC and pack changes go live, and what would make you roll back?
Read the worked answer
Watch three things. First, authentication and authorization signals: failed logins per tenant, 403s from playbook service accounts, and any role assignment change events. A silent over-restriction often shows up as playbooks failing to read incident fields rather than as a login error. Second, playbook execution health per tenant: success rate, average run time, and count of tasks returning no result, compared with the pre-change baseline. Third, search behavior: audit which users run cross-tenant searches and whether results shrink to zero for legitimate admins.
Roll back if any BU's analysts lose access to their own incidents, if a critical playbook's success rate drops more than a few points against baseline, or if service accounts start hitting 403s. Do not roll back merely because global search returns fewer rows - that is the intended effect. Keep the previous pack version pinned and the old role definitions exported so rollback is a configuration change, not a rebuild.