Transition Architectures: Why Moving Your SOC is Never ‘Just a Migration’
Transition Architectures: Why Moving Your SOC is Never ‘Just a Migration’
Migrating from one IT product to another is nothing new, but moving the core of your security monitoring is in a league of its own. SOC architectures are deeply embedded in your infrastructure, quietly linking systems, data flows, and processes in ways that only become visible when you try to untangle them.
We’ve now reached a point where many SOC products are either being retired, replaced, or left behind. Some have simply been in place too long. Others have been merged into new offerings or were deployed under strategies that no longer exist. And in many cases, valuable new features and capabilities are sitting unused, locked away behind outdated platforms.
For CISOs, the sticking point is clear: transitioning takes time, resources, and money and no one wants to risk weakening their security posture just to make progress. The challenge is finding a clear, structured pathway that delivers improvement without introducing unnecessary risk. That’s where a well-defined, high-level transition process comes in.
Challenges
The CISO presents several challenges when it comes to considering a move from an incumbent technology or provider, not least of which is the return on investment for such a transition.
Key considerations:
- How wedded are they to their existing technology stack, which can be influenced by several factors, such as data retention, customisation, skills and knowledge
- Effect on risk posture both during and post transition. No CISO can realistically present to the board that any investment in security results in a detrimental effect on risk posture.
- Integrations with additional solutions in both the security and wider IT estate.
- Ease of familiarisation and exploitation of new technology post transition to maximise the proposed uplift that such a transition theoretically presents.
It is imperative to present a case that returns a demonstrable improvement in risk posture and that any methodology for transition maintains that risk position throughout, if not incrementally improving whilst in transition.
The CISO must be presented with a confident assertion, backed by technical evidence, that the investment is more than worth it when it comes to making the bold decision to change provider or technology stack.
As such any methodology presented must demonstrate how their current risk posture remains unaffected in any negative way through a comprehensive plan that coherently demonstrates a focus on maintaining, if not improving, risk positions.
A clear differential would be in detailing how, post transition, the richness of new features could be easily explored and industrialised in a continual improvement plan that categorically delivers. This should ideally be backed by contractual metrics that can easily be measured to show said return.
High level migration process
- Assessment and planning
- Forwarding key data sources
- Normalisation
- Refactoring detection rules (do you convert to generic formats such as Sigma and YARA rules)
- Repeat with lower data sources
- Testing greater functionality / modules
- Parallel run
- Switchover (How do you ensure you won’t lose visibility, or lower capability, or drop detection capability, or analyst capability (tool awareness) in the transition)
Assessment and Planning
Architecture and Functionality
- Both incumbent product and target may offer similar architectures and functionalities. However, hopefully the target provides a pathway to more advanced SOC capabilities and services, which can be a significant advantage but also need to be cognizant of any losses
- Often incumbent has significant customisation that need to decide whether has value,
Such as
- Look and feel
- Custom development /scripts for data and processes and processing i.e. regex for the random data source in the corner of the data centre that deprecated 20 yrs ago
- Community based resourcesOSS embedded that may not migrate
Organisational fit
- Does the new product fit with your Data, AI, ITSM, ITOM infrastructure strategies.
- Another agent on the endpoints is not always welcomed even if it’s a straight swap out. The implications of the implementation and possible downtime or risk to service aside
- A Container based strategy may limit your visibility and traceability
- Ephemeral resources have ephemeral or NATed IP addresses hence traceability may be an issue in Incident Management or DFIR processes
- What crossovers between Application logging, Application tracing and Security logging. Where kind you find efficiencies
- Do you still want to move large quantities of data across the cloud (and associated finops implications) or is data lake approach more suitable.
Best practices
Opportunities to align to industry and organisational best practices.
- Bring devops and IaC into your SOC practices
- Bring more automations and low/no code
- Reporting against frameworks and standards such as Mitre ATT&CK, NIST CSF2.0
- Utilisation of AL and ML; MLSecOps
- Risk or contextualised alert
Current Environment Analysis
Evaluate your current xxxxx setup, including endpoint coverage, configurations, and integration points, Key data sources
- Do you need to do any normalisation as you migrate
- Can you need to do any rationalisation as you migrate, removal of low risk or low value data sources
- Can you duplicate data feeds and send to 2 data sources.
- Do you need a transition architecture
- Can you maintain data integrity and non-repudiation requirements
- When do you move integrations
- Do my licenses allow me to take 2 feeds from my Threat intelligence sources. PS don’t reuse API keys 🙂
- What does my identity landscape look like from a user and service principal point of view; new users, roles, MFA, service principals
Requirements Gathering
Identify the security requirements and capabilities needed in xxxxx to match or exceed the current setup.
Stakeholder Involvement
Engage relevant stakeholders, including IT, security teams, and end-users, to ensure alignment on migration goals and timelines.
Data Migration
- do you need to migrate your data; or
- maintain accessibility for regulatory and compliance reasons
- what do you do with your big archive of data that’s locking you into a product
- can it be archived in an accessible and usable manner
- will it even be used?
Expansion of scope
- into your new capability
- Capability mapping – the thing we did in old product is now here
- What new things can we do, impact on processes
Change analyst mindset
It is more than Training there is an opportunity to;
- Reinvigorate Stale staff and get them more engaged
- Break with the mindset “we always do it this way” especially with the old product forefront in analyst minds
- Get the SOC involved in POC and product selection – they are the ones using it, dictating tooling from above needs to be undertaken with caution even if done with the right intentions.
Preparation
Licensing and Subscriptions
Ensure you have the necessary xxxxxx licenses and configure your new xxxxxx environment accordingly.
Training and Documentation
Provide training for your IT and security teams on using xxxxx
- Leverage xxxxxx documentation and resources (professional services, configurations, scripts etc).
Backup and Data Protection
Backup critical data and configurations from xxxxxx to avoid data loss during the migration.
Measurement
- Measure the current state and performance or system and process (MTTR, search times, DFIR processes, playbook runtimes)
Deployment
Deploy
- CI/CD and IaC for the deployments or manual effort?
- Endpoint Agents:
- decide on client deployment methodology (ies) – not a single answer some may be manual some may be automated.
- deploy for client
- Intermediate Server(s) (if required)
- Build VMs
- Harden VMs
Pilot Testing
Start with a pilot deployment on a small subset of endpoints to test compatibility and performance, ensuring to test & tune advanced features selected. Address any issues that arise during this phase.
Configuration and Policies
Configure xxxxx settings, policies, and integrations to match your organisation’s security requirements.
Gradual Rollout
Gradually expand the deployment to all endpoints, ensuring continuous monitoring and support throughout the process.
Reporting and Communication
- The production of the reports may change – faster/slower
- The content of the SOC output may be enriched and more contextual but drive a different narrative with the consumers
- Dashboarding and Access to (Identity and URL of ) may change, which stakeholders need to see the communication.
- Theres is an opportunity to reinvigorate stakeholders, which may be a blessing or problematic.
Use Case changes
- Do UC stay the same, advance/ update, or become deprecated.
- a more advanced agent or SOAR capability may allow for remediation or Quarantine actions that were previously not available.
Cutover
Dual running
- side by side running for xxxxx period of time to gain customer confidence
- double bandwidth consideration
- operational impact to high volume data sources – can the source system handle it, what risks does it introduce
Re-commission
- Validate you can restore feed to incumbent solution. This should be temporary scenario designed to derisk and maintain uptime during migration.
Decommission
- Decommission an endpoint/intermediate
Early Warning Opportunity
- give early warnings to your resolver groups. If you want infrastructure folk to deploy and agent for you talk to the about it. So left hand and right hand are in synch
- refresh approaches and re-establish technical policies and stakeholder relationships.
The unexpected
The shiney new tooling either finds something you didn’t expect or doesn’t find something you did expect it to. Plan your response and RCA.
Validation and Optimisation
Validation Testing
Conduct thorough testing to ensure that xxxxx is functioning correctly and providing the desired security coverage.
Optimisation
Fine-tune configurations and policies based on feedback and performance metrics to optimise the solution for your environment.
Measurement
You’ve put the new tooling place you should measure the improvement over coming days, weeks, months
Reference sources
Palo Alto
– XSIAM 2.0. Continuing to Drive SOC Transformation – Palo Alto Networks. This blog discusses the challenges faced by today’s SOCs and how Palo Alto Networks’ XSIAM 2.0 aims to address these issues by integrating various security tools and data sources to improve threat detection and response times[1].
– Palo Alto Networks Buy IBM’s QRadar Assets in Win for SIEM. This article covers Palo Alto Networks’ acquisition of QRadar assets from IBM and how it introduces QRadar customers to the Cortex XSIAM solutions[2].
Wazuh
– SIEM and Threat Intelligence. Protecting Applications with Wazuh and TheHive. This study explores how Wazuh, along with TheHive, can be used to monitor applications and identify potential security risks[3].
– What SIEM did you choose and why? A Reddit discussion where users share their experiences with different SIEM solutions, including Wazuh[4].
Elastic
– Demystifying SIEM migration. Pitfalls to avoid and tips for ensuring success. This blog by Elastic provides insights into the SIEM migration process, including planning, execution, and operationalisation phases, and offers tips to avoid common pitfalls[5].
– Migrating your SIEM to Elastic Security. A guide that outlines the benefits of migrating to Elastic Security and provides a holistic approach to the migration process[6].
Splunk
– SIEM Migration Services – Splunk. This document details Splunk’s SIEM migration services, designed to help organisations streamline their migration from existing SIEM solutions to Splunk[7].
– SIEM Migration Update. Now Migrate with contextual depth in translations. This article discusses enhancements in the SIEM migration process from Splunk to Microsoft Sentinel, focusing on context-aware translations of detections[8].
CrowdStrike
– Con 2024 – Redefining SecOps with Next-Gen SIEMThis blog highlights CrowdStrike’s innovations in next-gen SIEM technology, including AI and automation capabilities that simplify SIEM migrations[9].
– Future-Proof Your SOCA Migration Guide from Legacy to Next-Gen SIEM with CrowdStrike. This white paper explores how CrowdStrike Professional Services can help organisations migrate to Falcon Next-Gen SIEM[10].
