Ninety-Day SIEM Cutover: Sequencing a Cortex XSIAM Migration Without a Detection Gap
A 6,000-employee enterprise runs an on-premises SIEM ingesting 950 GB/day, a separate SOAR, and an EDR console. The SIEM contract expires in 90 days and the board has approved Cortex XSIAM. The estate carries 1,100 correlation rules; 380 have not fired in 18 months. There are 210 playbooks, 90 of which call a ticketing system that was decommissioned two years ago. Three sources - perimeter firewall, secure web gateway, and EDR - account for 71% of daily volume. Four sources (two mainframes, an OT historian, and a custom appliance) cannot send CEF or syslog over TLS and currently forward through a legacy collector. Compliance requires 12 months of searchable retention for authentication and firewall data. Twenty-two analysts know the old rule names by heart and have built their runbooks around them. The CISO's single non-negotiable requirement is no detection gap during cutover.
1. Propose a 90-day sequence with the parallel-run strategy, and justify why a lift-and-shift of all 1,100 rules is the wrong starting point.
Read the worked answer
Why not lift-and-shift: rules written for another SIEM encode that platform's parsing quirks and field names, not just detection logic. Porting 1,100 of them carries forward 380 dormant rules, duplicate coverage, and a large volume of tuning debt into a new platform, and burns the entire 90 days on syntax translation. Worse, it makes parity unmeasurable: you cannot tell whether a missing alert is a parsing defect or a rule you should not have ported.
Sequence
- Days 0-30 - data and context. Onboard the three high-volume sources first (they drive volume, cost, and most detections) and confirm normalization, timestamps, and field completeness. Stand up broker VMs for the four non-standard sources, keeping the legacy collector in the path initially rather than re-engineering OT collection under deadline. Land identity and asset context; without it, detections cannot be scoped to an owner.
- Days 30-60 - detection parity on the top use cases. Rank the active rule set by use case, not by rule name, and rebuild the top 30-40 in native content. Run legacy and XSIAM in parallel by dual-forwarding the same sources, so both produce alerts on identical input. Build a rule-name mapping table so analyst runbooks stay valid.
- Days 60-80 - automation. Rebuild or replace the 90 orphaned playbooks; delete rather than port automation whose ticketing target no longer exists.
- Days 80-90 - cutover and hold. Disable legacy alerting, keep its storage until the retention obligation is met elsewhere, and keep parallel forwarding for 30 days.
Trade-off to state explicitly: the 380 dormant rules get audited, not ported. Some are dormant because logging broke - which is why the audit happens against raw data.
2. Define the criteria you would use to rationalize the 1,100 correlation rules, and explain the risk in using firing history alone.
Read the worked answer
The trap: "has not fired in 18 months" is often read as "no value." It can equally mean the rule's data source stopped sending, the rule was silently broken by a schema change, or it is a low-and-slow detection that is correct to stay quiet. Deleting on firing history alone can retire a compensating control.
Criteria, applied in order
- Is there a governing requirement? Compliance mandates, contractual obligations, and regulatory reporting requirements survive any efficiency argument. Flag these first and exclude them from volume-driven culling.
- Is the data source actually healthy? For each dormant rule, check whether its source is still forwarding and parsing. A dormant rule whose source is dead is an invisible gap, not a candidate for deletion. Sample raw logs to confirm the activity the rule targets still exists.
- Does it map to a use case already covered? Collapse duplicates at the use-case level. Three rules detecting the same lateral-movement technique become one well-tuned detection plus correlation.
- What is its operating cost? False-positive volume and analyst time. A rule generating 40 dismissals a week for two true positives a year may still be worth keeping if the technique is high impact - cost alone does not decide it.
- Can it be expressed at all in the new platform? Rules depending on a data source you are not migrating must be either retired with a documented risk acceptance or replaced with a compensating control.
Output: four buckets - migrate as-is, rebuild/tune, retire with sign-off, and investigate (dormant with suspicious data health). The fourth bucket is usually the most valuable finding in the whole migration, and it is the one a firing-history-only approach silently discards.
3. How would you prove detection parity before switching off the legacy SIEM, and what does the rollback actually look like?
Read the worked answer
Parity must be defined per use case, not as an aggregate alert count. Matching total alert volume is meaningless - you can match the number while missing every high-severity detection and adding noise.
Evidence to assemble
- Twin-source comparison. With both platforms receiving identical forwarded data, compare alerts per use case over a defined window (two weeks minimum), normalizing for rule-name mapping. Investigate every legacy alert with no XSIAM counterpart; each is either a parsing gap or a deliberate retirement.
- Synthetic event injection. Generate known-bad activity on endpoints and in log streams - controlled test commands, authentication failures, test payloads from an isolated host - and confirm both platforms alert on the same event. This is the only way to test detections that have not naturally fired.
- Data-quality gates. Parsing error rate, field completeness on the fields your detections actually use, timestamp and timezone correctness, and end-to-end latency measured from event time to alert time.
- Retention and search verification. Confirm the 12-month searchable retention obligation for authentication and firewall data is satisfied by the new platform before any data is deleted - and that searches return the same results as the legacy system on a known query.
- Analyst validation. Have the on-duty analysts work a full shift against XSIAM only, in parallel with legacy, and log every case where they could not complete a runbook step.
Rollback: keep the legacy license and its storage intact through the hold period, keep dual-forwarding live, and write a one-page flip procedure with a named decision owner and a deadline for the go/no-go. Rollback must be executable within a shift by someone who did not design the migration - otherwise it is a plan on paper, not a control.