Transcription
Splunk SOAR Validated ArchitecturesVersion 2.0Product Best PracticesVersion 2 on June 3, 2021SSVAs - 1 – v2.0
SSVAs - 2 – v2.0
Table of ContentsSplunk SOAR Validated Architectures Version 2.01Introduction1.1Pillars of Splunk SOAR Validated Architectures1.2What to Expect from Splunk SOAR Validated Architectures1.3Roles and Responsibilities1.4Overview of the Splunk SOAR Validated Architectures Selection Process1.5Step 1: Define Your Requirements for s to Keep Under ConsiderationTopology CategoriesDefine Your Requirements for AutomationQuestionnaire 1: Define your requirements for integrations:How to Determine Your Topology Category Code88912121.6Step 2: Choose a Topology for Automation131.6.11.6.21.6.3Using Your Topology Category CodeNon-clustered deployment optionsClustered deployment options1314241.7Step 3: Apply Design Principles and Best Practices291.7.11.7.21.7.3Deployment and Integrations Architectural DiagramsAligning Your Topology with Best PracticesBest Practices: Tier-Specific Recommendations295050Summary & Next Steps1.8Next Steps1.9Appendix "A": SSVA Pillars Explained1.10Appendix "B": Topology Components52525455SSVAs - 3 – v2.0
IntroductionSplunk SOAR Validated Architectures (SSVAs) are proven reference architectures for stable, efficient, andrepeatable Splunk SOAR deployments. Many of Splunk's existing customers have experienced rapid adoptionand expansion, leading to certain challenges as they attempt to scale. New Splunk SOAR customers areincreasingly looking for guidelines and certified architectures to ensure that their initial deployment is built on asolid foundation. SSVAs have been developed to help our customers with these growing needs.Whether you are a new or existing Splunk SOAR customer, SSVAs will help you build an environment that iseasier to maintain and simpler to troubleshoot. SSVAs are designed to provide you with the best possible resultswhile minimizing your total cost of ownership. Additionally, your entire Splunk SOAR foundation will be based on arepeatable architecture which will allow you to scale your deployment as your needs evolve over time.SSVAs offer topology options that consider a wide array of organizational requirements, so you can easilyunderstand and find a topology that is right for your requirements. The Splunk SOAR Validated Architecturesselection process will help you match your specific requirements to the topology that best meets yourorganization's needs. If you are new to Splunk SOAR, we recommend implementing a Validated Architecture foryour initial deployment. If you are an existing customer, we recommend that you explore the option of aligningwith a Validated Architecture topology. Unless you have unique requirements that make it necessary to build acustom architecture, it is very likely that a Validated Architecture will fulfill your requirements while remaining costeffective.This white paper will provide you with an overview of SSVAs. Within this whitepaper, you will find the resourcesyou need to go through the SSVA selection process, including the requirements questionnaire, deploymenttopology diagrams, design principles, and general guidelines.If you need assistance implementing a Splunk SOAR Validated Architecture, contact Splunk ProfessionalServices (https://www.splunk.com/en ment StructureSSVAs are broken into three major content areas:1. Automation and Case Management TierAutomation and Case Management covers the architecture tier that provides the Splunk SOAR functionality –front-end interface, playbook automation, and data storage.2. Integrations TierThe Integrations Tier section guides you in choosing the right integrations to meet your requirements.3. Design Principles and Best PracticesDesign Principles and Best Practices apply to your architecture as a whole and will help you make the correctchoices when working out the details of your deployment.SSVAs - 4 – v2.0
Reasons to Use Splunk SOAR Validated ArchitecturesImplementing a Validated Architecture will empower you to design and deploy Splunk SOAR more confidently.SSVAs will help you solve some of the most common challenges that organizations face, including:Performance Organizations want to see improvements in performance and stability.Complexity Organizations sometimes run into the pitfalls of custom-built deployments, especially when they have growntoo rapidly or organically. In such cases, unnecessary complexity may have been introduced into theenvironment. This complexity can become a serious barrier when attempting to scale.Efficiency To derive the maximum benefits from the Splunk deployment, organizations must improve the efficiency ofoperations and accelerate time to value.Cost Organizations are seeking ways to reduce total cost of ownership (TCO), while fulfilling all of theirrequirements.Agility Organizations will need to adapt to change as they scale and grow.Maintenance Optimization of the environment is often necessary in order to reduce maintenance efforts.Scalability Organizations must have the ability to scale efficiently and seamlessly.Verification Stakeholders within the organization want the assurance that their Splunk deployment is built on bestpractices.1.1 Pillars of Splunk SOAR Validated ArchitecturesSplunk SOAR Validated Architectures are built on the following foundational pillars. For more information on thesedesign pillars, refer to Appendix "A" NAGEABILITYThe system meetscustomercontinuityrequirements isable to recoverfrom planned andunplanned outagesor disruptions.The system canmaintain anoptimal level ofservice undervarying usagepatterns.The system isdesigned to scaleon all tiers,allowing you tohandle increasedworkloadseffectively.The system isdesigned toprotect data,configurations,and assets whilecontinuing todeliver value.The system iscentrally operableand manageableacross all tiers.These pillars are in direct support of the Platform Management & Support Service in the Splunk Center ofExcellence model.1.2 What to Expect from Splunk SOAR Validated ArchitecturesPlease note that SSVAs do not include deployment technologies or deployment sizing. The reasoning for this isas follows:SSVAs - 5 – v2.0
Deployment technologies, such as operating systems and server hardware, are considered implementationchoices in the context of SSVAs. Different customers will have different choices, so a generalization is noteasily possible. Deployment sizing requires an evaluation of data ingest volume, data types, file volumes, and playbook usecases, which tend to be very customer-specific and generally have no bearing on the fundamentaldeployment architecture itself. Customer should engage with Professional Services to ensure that proper sizing and adequate loading isconfigured. Currently, there is no formal sizing guides for Splunk SOAR. There is a recommended singleinstance sizing for productions systems located here for on premise tom/latest/Install/ProdRequirementsSSVAs will provide:SSVAs do not provide:Clustered and non-clustereddeployment options.Diagrams of the referencearchitecture.Guidelines to help you selectthe architecture that is right for youTier-specific recommendations.Best practices for building outyour Splunk SOAR deploymentImplementation choices (OS, bare metal vs. virtual vs. Cloud etc.).Deployment sizing.A prescriptive approval of your architecture. Note: SSVAs providerecommendations and guidelines, so you can ultimately make the rightdecision for your organization.A topology suggestion for every possible deployment scenario. Insome cases, unique factors may require a custom architecture to bedeveloped. Splunk experts are available to help with any customsolutions you need. If you are an existing customer, reach out to yourSplunk Account Team. If you are new to Splunk, you can reach us here(https://www.splunk.com/en us/talk-to-sales.html).1.3 Roles and ResponsibilitiesSplunk SOAR Validated Architectures are highly relevant to the concerns of decision makers and administrators.Architects, consultants, Splunk SOAR administrators, and managed service providers should all be involved in theSSVA selection process. You will find a description of each of these roles below:RoleDescriptionArchitectsResponsible for architecting Splunk deployments to meet enterprise needs.ConsultantsResponsible for providing services for Splunk architecture, design, and implementation.Splunk SOARSpecialistsResponsible for managing the Splunk SOAR product lifecycle.Managed ServiceProvidersEntities that deploy and run Splunk as a service for customers.SSVAs - 6 – v2.0
1.4 Overview of the Splunk SOAR Validated Architectures SelectionProcessThe Splunk SOAR Validated Architectures selection process will help you identify the simplest and moststreamlined architecture that meets all of your organization's needs.Steps in the SelectionProcessGoalsConsiderationsStep 1: Define Requirementsfor:Definerequirements. Decision-makers, stakeholders, and adminsshould collaborate to identify and define yourorganization's requirements. If you already have a deployment in place, youcan evaluate your current architecture to seewhat it would take to move to a validated model.a) Automation and CaseManagementb) Integration NeedsFor a questionnaire that will help you define yourrequirements, refer to Step 1.5 below.Step 2: Choose a Topologyfor:Automation and CaseManagementChoose atopology thatmeetsidentifiedrequirements. You'll choose a topology that best meets yourrequirements. Keep things simple and in accordance with theSSVA, so you can appreciate the easier path toscalability.For diagrams and descriptions of topology options,refer to Step 2 below.Step 3: Apply DesignPrinciples and BestPracticesPrioritize yourdesignprinciples andreview tierspecificimplementationbest practices. Each design principle reinforces one or more ofthe pillars of Splunk SOAR Validatedarchitectures. You'll prioritize design principles in accordancewith the needs of your organization. Tier-specific recommendations will guide yourtopology implementation.For a breakdown of design principles, refer to Step3 below.1.5 Step 1: Define Your Requirements for AutomationTo select the appropriate deployment topology, you will need to do a deep dive into your requirements. Once youhave defined your requirements you will be able to choose the simplest, most cost-effective way to deploy SplunkSOAR. Below you will find a questionnaire that will help you define key requirements areas for the indexing andsearch tiers of your deployment.SSVAs - 7 – v2.0
The requirements questionnaire focuses on areas that will have a direct impact on your deployment topology.Therefore, we highly recommend that you record your answers to the questions below before choosing a topologyin the next step.1.5.1 Things to Keep Under ConsiderationReview your use casesHeadless operation is considered only for design and playbook execution and very minimal if any customerinteraction other than design and administrative operations. Case Management operation is considered full-usefunctionality of the platform and is measured by the number of concurrent customers using the platform. As youdefine your requirements, you should think about the intended usage of Splunk SOAR. For example, the topologyfor a "headless" deployment of Splunk SOAR acting as an automation backend will require far fewer interactiveusers than a deployment in which Splunk SOAR will be the case management system of record. You should fullyconsider use cases involving: Headless vs Case management operations Reporting Availability Disaster Recovery Requirements Other use case scenarios specific to your organizationDepending on your use case scenarios, your deployment may need to provide additional architecturalcharacteristics.Think about future growthYou will need to think about your immediate needs in order to define your requirements. However, you shouldalso consider future growth and scalability. Scaling your deployment may require expenditures, additional staffing,or other resources you may want to start planning for today. We have started this plan for the average use for acustomer to able to last at least 1 year of operations before modification should be considered. This willdependent on the usage, volume, playbook and asset configurations. Since these vary greatly betweencustomers, please understand that this planning varies between customers and is an estimate.1.5.2 Topology CategoriesThe following is a key to SSVA topology categories. These categories are used in the questionnaire below. Youwill also find references to these categories in the next steps of the SSVA selection process.Platform Topology CategoriesCategoryCodeExplanationSCategory "S" indicates a single-server Splunk SOAR deploymentXCategory “X” indicates an externalized single-instance Splunk SOAR deployment withexternalized shared services (e.g., file share, database)DCategory "D" indicates a distributed Splunk SOAR deployment across two sites configured inWarm Standby Mode. Warm Standby is not supported with externalized shared services.CCategory "C" indicates the need for a clustered automation and case management tier (datareplication and high capacity for automation is required). Clustered SOAR deployments alwaysrequire externalized shared services.SSVAs - 8 – v2.0
Instance Requirements CategoriesCategoryNumberExplanation0Category "0" indicates a Software as a Service model and no physical hardware is required.1Category "1" indicates a single or up to 3 hardware/virtual instances* will meet requirements2Category "2" indicates the need for multiple hardware/virtual instances minimum of 3 and up to 8separate hardware instances per site* Instance is defined as a single-instance appliance (virtual or on physical hardware), single-instance with externalshared components, a SaaS tenant, or a single SOAR clusterIntegration Tier CategoriesCategoryCodeExplanationECategory “E” indicates that SOAR will leverage an external Splunk instance for custom reportingcapabilityE Category “E ” indicates that SOAR will leverage one or all of the optional customer provided loadbalancers, NFS, or utilize AWS ServicesCECategory “CE” indicates that SOAR will leverage an external Splunk Cloud Enterprise instancefor custom reporting capability or ingestion source.CE Category “CE ” indicates that SOAR will leverage an external Splunk Cloud Enterprise instancefor custom reporting capability and AWS Services1.5.2.1 Define Your Requirements for Automation See the key above for an explanation of topology category codes. If you answer "yes" to multiple questions, usethe topology category code for the highest numbered question.SSVAs - 9 – v2.0
#12QuestionConsiderationsImpact on TopologyAre you wantinga solution thatreduces yourinfrastructure &maintenancecosts?Consideration for casemanagement or cloudbased automation.Candidate for SaaSsolution that providesreduced maintenancecosts and managedinfrastructure.Is your expecteddaily data ingestup to 500forwardedevents/hour?These areforwardedevents to SOARand not ES orSplunk EPScalculations34High volume 750events per hour andHigh-performancetransactions is nts0Certain on-premisescapabilities are notpresent.Supports up to 20concurrent usersConstrained to regionaldeploymentsConsidered short-termgrowth in the dailyingest ( 6-12 month)Candidate for a singleserver deployment,depending on answersto availability-relatedquestionsS1Candidate forexternalizing sharedservices like file anddatabase to increaseperformance and localredundancy.X1Requires two SOARinstances deployed in awarm standbyconfiguration to supportcontinuous ingest andautomationD1These are forwardedevents to SOAR and notES or Splunk EPScalculationAre youingesting up to500events/hourand using casemanagementwith less than10 personnelcontinuously?Need to consider longterm growth of databaseand file collections ( 612 month)Do you requireDisasterRecovery fordata ingestion orautomation?If you are planning onusing SOAR for dataenrichment only and/orbatched automationjobs, an interruption ofservice may beacceptable.If you have your ownsite replicationcapabilities like VMwareSite Recovery Manageror in AWS region anddon't require multiregional supportThis is the mostcommon customer useconfiguration. It providesActive/Passive WarmStandby services.SSVAs - 10 – v2.0
#5QuestionConsiderationsImpact on TopologyIs your expecteddaily data ingestgreater than 500 forwardedevents/hour?Automated playbookdevelopment greatlyaffects event ingestion.Default build can handleingestion of 10,000events a day.Requires a HighCapacity ClusteredAutomation and CaseManagement tier withexternalized sharedservices.These areforwardedevents to SOARand not ES orSplunk mentsC1D/C1D/M2C1This configuration isconsidered high volumeand high availability. It isa horizontally scalabledeployment.If your continuous usercount is above 10 usersa day, you shouldconsider a clustereddeployment678Assuming anavailable SplunkSOAR instance:Does your dataneed to ensureactive/activeavailability forautomationexecution?If your use case isswiftly, responding to,and remediating issuesfrom ingested alerts,automated blocking orremoval and local sitedown time is notacceptable.Requires a HighCapacity ClusteredAutomation and CaseManagement tier or aDistributed system withCustomer providedequipment.Do you operatemultiple datacenters andrequire recoveryof your SplunkSOARenvironment incase of a datacenter outage?Disaster recoveryrequirements maydictate continuousprescribe RTO/RPOgoals for manualdisaster recoveryFailover will require twoSOARplatforms operating in inwarm standby mode.Do you need tosupport manyconcurrentusers?Requirements for morethan 10 concurrentusers typically requirehorizontal scaling of theAutomation and CaseManagement TierD is TCO is less than CTCO. With D customerneeds to provideadequate applicationlevel load balancers andmust script the processto fail over.Use "D" if SOAR isbeing used for casemanagementUse "M" if SOAR is notbeing used for casemanagementRequires a clusteredAutomation and CaseManagement tier withexternalized sharedservices.SSVAs - 11 – v2.0
1.5.2.2 Questionnaire 1: Define your requirements for integrations:#Question1Do you require SOARclustering (see abovequestionnaire)?2Do you require theability to create customdashboards and reportsfor SOAR metrics?ConsiderationsStandard reports &metrics can beproduced without anyexternal reportingcomponents orresources.Impact on TopologyIntegrationRequirementsClustering requires theexternalization ofSplunk to act as theSOAR Reporting TierECustom reporting anddashboards require anexternal SplunkEnterprise instance toact as the SOARReporting TierEIndicate a yes here, ifyou have custommetrics you want tomeasure or detailedreporting requirements.3Do you want to provideyour own externalinfrastructure or utilizecloud infrastructuresIf the customer wants toprovide separate fileservices or databaseservices.Reduced cost ofownershipE 4Do you require theability to integrateSplunk CloudInfrastructure withcustomer providedinfrastructure (onpremise)If you are using SplunkCloud or Cloud ES andyet want SOAR onpremises only.Requires the use ofSplunk SOAR in theDMZ or VPCconnections to providecloud to premiseconnectivity.CE5Do you require theability to integrateSplunk CloudInfrastructure withcustomer provided orother CloudinfrastructureIf the customer wants toprovide separate fileservices or databaseservices.Custom reporting anddashboards require anexternal Splunkinstance to act as theSOAR Reporting TierCE If you are using SplunkCloud or Cloud ES andyet want to integrateSOAR1.5.3 How to Determine Your Topology Category CodeBased on your answers to the requirements questionnaire above, you will end up with a combined topologycategory indicator that will allow you to identify the best topology for your needs. Instructions and examples areprovided below.Instructions1. Write down the questions to which you answered "yes".2. If you answered "yes" to multiple questions, follow the topology recommendation for the highest numberedquestion. If you see multiple topology options (for example, "S/C"), look at the previous questions todetermine which option is best suited for you.3. Your reporting tier code will be the letter representing the question(s) to which you answered yes. If youranswer results are yes, then use E for your reporting tier code.SSVAs - 12 – v2.0
Example #1Let's say you answered "yes" to questions #4, #5 and #7, and you need custom reporting requirements (1b.Question #2). You will end up with a topology category of "C1E", indicating the need for a clustered indexing tierwith an external reporting server.Example #1Let's say you answered "yes" to questions #4, #5 and #7, and you need custom reporting requirements (1b.Question #2). You will end up with a topology category of "C1E", indicating the need for a clustered indexing tierwith an external reporting server(s).1.6 Step 2: Choose a Topology for AutomationTopologies are generally split into non-clustered and clustered deployments. Non-clustered deployments requirethe least number of distinct components and have excellent scalability characteristics.Remember: The primary goal of the SSVA selection process is to allow you to build what you need withoutintroducing unnecessary components.NoteWhile you may choose to implement a topology that provides additional benefits beyond your immediateneeds, keep in mind that this will likely result in unnecessary costs. Moreover, the introduction of additionalcomplexity is often counter-productive to operational efficiency.Important Note about topology diagramsThe icons in the topology diagrams represent functional Splunk roles and do not imply dedicatedinfrastructure to run them. Please see the Appendix for guidance as to which Splunk roles can be collocated onthe same infrastructure/server.1.6.1 Using Your Topology Category CodeBefore selecting a topology option, it is highly recommended that you complete the requirements questionnaire todetermine your topology category code. If you have not yet done this, please go back and complete the previousstep above. Once you have your topology category code you will be able to identify the deployment option that isthe best fit for your stated requirements. These Automation tier topologies have been matched and aligned toyour recommended Splunk Index and Search topologies.SSVAs - 13 – v2.0
1.6.2 Non-clustered deployment optionsBelow you will find the following the available topology options:Type of DeploymentTopology Category Code(s)Single Tenant Deployment using Software as a Service withSplunk managed infrastructureS0Single Tenant Deployment using Software as a Service withSplunk managed infrastructure with on premise integrationS0ESingle Tenant Deployment using Software as a Service withSplunk managed infrastructure with hybrid cloud solutionS0E Single Tenant Deployment using Software as a Service withSplunk managed infrastructure with Splunk Cloud IntegrationS0CESingle Server Deployment using embedded Splunk integration Single siteS1Single Server Deployment using Splunk Enterprise Integration Single siteS1ESingle Server Deployment using external Shared Services withembedded SplunkX1Single Server Deployment using external Shared Services withSplunk Enterprise IntegrationX1EDistributed Warm Standby Deployment using embedded Splunkintegration - Multiple siteD2Distributed Warm Standby Deployment using embedded Splunkwith customer provided infrastructure – Multiple siteD2EDistributed Warm Standby Deployment using embedded Splunkwith customer provided infrastructure – Multiple siteD2E Distributed Warm Standby Deployment with Splunk CloudIntegration - Multiple siteD2CEDistributed Warm Standby Deployment with Splunk CloudIntegration - Multiple siteD2CE High Capacity Clustered Deployment - Single SiteC1High Capacity Clustered Deployment - Single SiteC1EHigh Capacity Clustered Deployment with AWS Integrations orcustomer provided infrastructure – Single SiteC1E High Capacity Clustered Deployment with Splunk Cloud – SingleSiteC1CEHigh Capacity Clustered Deployment with Splunk Cloud andAWS Integrations – Single SiteC1CE High Capacity Clustered Deployment - Multiple SiteM2EHigh Capacity Clustered Deployment with Splunk Cloud Multiple SiteM2CEHigh Capacity Clustered Deployment with Splunk Cloud andAWS Integrations - Multiple SiteM2CE SSVAs - 14 – v2.0
1.6.2.1Single Server Deployment (S0)Automation & Case Management TierSOARAutomation BrokerFor an explanation of topology components, refer to Appendix "B" below.Description of the Single Server Deployment (S0)LimitationsThis deployment topology provides you with a very cost-effectivesolution if your environment meets all the following criteria: Scalability provided by Splunkmanaged infrastructurea) you have requirements to provide high-availability or automaticdisaster recovery for your Splunk SOAR Deployment, Constrained to regionaldeploymentsb) your daily event ingestion is 750 events per day, and Limited to Internet accessibleintegrations or AutomationBroker integrationsc) you have approximately 20 concurrent users in your environmentd) suitable for a production environmentThe primary benefits of this topology include easy manageability, goodsearch performance for smaller ingest and concurrent user count.This topology is commonly used in production environments and theprimary benefits of this topology include easy manageability and afixed TCO.SSVAs - 15 – v2.0
1.6.2.2Single Server Deployment (S0E)Automation & Case Management TierSOARReporting TierAutomation BrokerSplunkFor an explanation of topology components, refer to Appendix "B" below.Description of the Single Server Deployment (S0E)LimitationsThis deployment topology provides you with a very cost-effectivesolution if your environment meets all the following criteria: Scalability provided by Splunkmanaged infrastructurea) you have requirements to provide high-availability or automaticdisaster recovery for your Splunk SOAR Deployment, Ingestion and reporting aremostly provided by SplunkIntegrations Splunk forwarding will needaccess to the public internet Constrained to regionaldeploymentsb) your daily event ingestion is 750 events per day, andc) you have approximately 20 concurrent users in your environmentd) suitable for a production environmentThe primary benefits of this topology include easy manageability, goodsearch performance for smaller ingest and concurrent user count.Common integration with SaaS and hybrid cloud integrationsThis topology is commonly used in production environments and theprimary benefits of this topology include easy manageability and afixed TCO.SSVAs - 16 – v2.0
1.6.2.3Single Server Deployment (S0E )Automation & Case Management TierSOARReporting TierAutomation BrokerSplunkFor an explanation of topology components, refer to Appendix "B" below.Description of the Single Server Deployment (S0E )LimitationsThis deployment topology provides you with a very cost-effectivesolution if your environment meets all the following criteria: Scalability provided by Splunkmanaged infrastructurea) you have requirements to provide high-availability or automaticdisaster recovery for your Splunk SOAR Deployment, Ingestion and reporting aremostly provided by SplunkIntegrations Splunk forwarding will needaccess to the public internet Constrained to regionaldeploymentsb) your daily event ingestion is 750 events per day, andc) you have approximately 20 concurrent users in your environmentd) suitable for a production environmentThe primary benefits of this topology include easy manageability, goodsearch performance for smaller ingest and concurrent user count.Common integration with SaaS and hybrid cloud integrationsThis topology is commonly used in production environments and theprimary benefits of this topology include easy manageability and afixed TCO.SSVAs - 17 – v2.0
1.6.2.4Single Server Deployment (S0CE)Automation & Case Management TierSOARReporting TierAutomation BrokerSplunkFor an explanation of topology components, refer to Appendix "B" below.Description of the Single Server Deployment (S0CE)LimitationsThis deployment topology provides you with a very cost-effectivesolution if your environment meets all the following criteria: Scalability provided by Splunkmanaged infrastructurea) you have requirements to provide high-availability or automaticdisaster recovery for your Splunk SOAR Deployment, Ingestion and reporting aremostly provided by SplunkCloud Integrations Constrained to regionaldeploymentsb) your daily event ingestion is 750 events per day, andc) you have approximately 20 concurrent users in your environmentd) suitable for a production environmentThe primary benefits of this topology include easy manageability, goodsearch performance for smaller ingest and concurrent user count.Common integration for SaaS to SaaS Splunk ComponentsThis topology is commonly used in production environments and theprimary benefits of this topology include easy manageability and afixed TCO.SSVAs - 18 – v2.0
1.6.2.5Single Server Deployment (S1)Automation & Case Management TierSplunkSOARReportinggFSDBShared ServicesFor an explanation of topology components, refer to Appendix "B" below.Description of the Single Server Deployment (S1)LimitationsThis deployment topology provides you with a very cost-effectivesolution if your environment meets all the following criteria: No High Availability Scalability limited by hardwarecapacity Reporting limited to standardSOAR reports and/or API usagea) you do not have any requirements to provide high-availability orautomatic disaster recovery for y
1. Automation and Case Management Tier Automation and Case Management covers the architecture tier that provides the Splunk SOAR functionality - front-end interface, playbook automation, and data storage. 2. Integrations Tier The Integrations Tier section guides you in choosing the right integrations to meet your requirements. 3.
