Tips for Selecting the Right Tools for Your Security Operations Center
Deciding when to invest in tools and selecting the right ones for the modern SOC is challenging. Can a tool serve multiple purposes or is creating robust processes the answer? Security and risk management leaders should use this research to make pragmatic decisions.
Overview
Key FindingsSecurity operations center (SOC) owners struggle to identify the right technology investments for their security requirements, instead chasing the latest and greatest technologies that may dilute, rather than enhance, the efficacy of their SOC.
Looking at peers with SOCs or trying to benchmark against others in a vertical is of limited use. Each SOC is constructed to meet its own organization’s nuances, security use cases and current and target maturity level.
There is a misconception that technologies powered by artificial intelligence (AI) and machine learning (ML), or any that promise to fully automate your SOC, would magically transform an SOC from low maturity to high maturity overnight. Tools alone won’t solve all SOC challenges.
Security alert triaging is not just a challenge for the security operations center (SOC), but remediating an escalation is an organizational duty.
Your SOC needs trained staff, processes and fine-tuned workflows to use and operate tools that support its goals and capabilities.
RecommendationsPrepare the SOC team and relevant stakeholders for a process-driven evaluation with a “premortem” analysis to reduce the chance of failed projects.
Align the tool selection process according to the target operating model and goals of the SOC, avoiding premature investments in tools perceived as “advanced.”
Make technology investments that match business risk requirements, IT roadmap such as public cloud and SaaS adoption, available staff skill sets and enhance areas of the SOC with operational challenges.
Involve stakeholders beyond the security team when making decisions on security tools. There will be security alerts that will need other areas in the business involved to help rectify the escalations.
Be flexible during organizational and business changes because new workflows and tools to support changes to processes and capabilities might be required.
IntroductionSOCs are like snowflakes because no two are alike. Many have yet to achieve their desired maturity level and target operating model. For those who have achieved their ideal maturity level, they still must react to changes like more evolving threat landscapes; digital business initiatives; and mergers and acquisitions. These factors will influence the current and future technology investments required for a modern SOC (see Note 1).
However, SRM leaders may not consider these factors and instead purchase tools based on short-term needs or as rushed, reactive responses. An example is adding endpoint detection and response (EDR) for a ransomware event, as opposed to investing in security awareness and training to reduce the impact from employees launching malicious attachments sent via phishing emails.
Leaders need to consider how new tools contribute to the SOC’s mission and enhance, rather than complicate, the work performed by SOC staff, given the burdens already placed on these, typically short-staffed, teams (e.g., analysts, engineers, threat hunters and incident responders).
AnalysisTip No. 1: Prepare the SOC Team and Relevant Stakeholders for a Process-Driven Tool Evaluation With a Premortem AnalysisSecurity leaders must educate stakeholders that new detection techniques or technologies do not mean that threat detection will be dramatically better. Many of these new techniques or technologies will be able to improve only a subset of the threat detection use cases required. They will not be able to completely replace the tools that are utilizing more common or traditional approaches (e.g., correlation-based analytics).
Before purchasing tools for the SOC, SRM leaders should understand why, where and how the SOC would benefit from the technology. Understand the organization’s use cases, what threats the business is concerned about and how the tools can help enable protection and additional benefits. Many different security technology tools enable the application of AI through the use cases required (see Infographic: AI Use-Case Prism for Cybersecurity).
Is the SOC using AI to enhance the level of threat detection through specific use cases, whether it is data loss prevention or insider threat?
Will the SOC be using AI to manage a required repeatable task for which resources are limited?
Then, they should perform an honest premortem assessment to determine whether they have the expertise to operate and use these tools over time. Conducting a premortem assessment will assist SRM leaders in identifying any future issues and reflect openly and honestly about any shortcomings in tools with the SOC and specific gaps in process or team structure.
Why do projects fail or not live up to their promises? It may be due to scope; the technology itself (e.g., vendor claims were not confirmed during a proof of concept); the implementation of the tool; or the lack of resources and expertise to run the tool once deployed.
For example, Gartner clients with an existing SOC that has reached an adequate maturity level commonly ask:
Do I upgrade to a modern security information and event management (SIEM) tool?
Should I buy X instead (EDR, NDR, CSPM, XDR)?
Should I build a data lake, create my own ML analytics capability and build my own security orchestration and automation on top of those other two components?
The unhelpful, but always true, answer is, “It depends.” As part of a project to bring tools into the SOC, a solid understanding of the scope, technologies being considered and affected processes is required.
SRM leaders can improve the odds of selecting the right tool for the organization by gaining consensus during a premortem analysis on what could go wrong and which success metrics should apply to a project. The premortem can also serve as an early-stage vehicle for collecting initial use cases and requirements. Those can be further refined as part of the formal project definition and approval cycles.
Types of questions that SRM leaders should be asking as part of the premortem analysis are:
What is the outcome we require for the selection of this security tool?
What are the requirements for planning this project?
Do we have to hire additional resources to complete this project?
Do we have the correct skills internally aligned to the security tool to implement and transition to support?
Are we concerned about the timelines of this project?
Could and how would we miss milestones within this tooling project?
Can we implement any lessons learnt from other tool implementation projects to apply to this?
How are we going to track this project?
What is the operational cost to incorporate a new security product in the program?
Can the adoption of the new security product displace current legacy security products and processes? If yes, what are the potential cost savings?
Tip No. 2: Align the Tool Selection Process According to the Target Operating Model and Goals of the SOC
Every SOC should have a defined target operating model that describes the mission, responsibilities and timelines for achieving various goals and levels of maturity (see Create an SOC Target Operating Model to Drive Success). SRM leaders should use the target operating model as the key reference document as well as the existing technologies, people with expertise, and plays (or processes) in a SOC playbook.
Armed with this, they should ask some key questions to determine which technologies would advance the mission and capabilities of the SOC, including:
What are our top priority concerns (i.e., risks, threats)?
Who will consume the security outcomes we are trying to deliver?
How can we identify known gaps in our SOC (see Table 2 in How to Build and Operate a Modern Security Operations Center)?
What are our SLA goals and what time frames should we set to reach them?
What technologies do we have already?
How well will the new technologies integrate with our existing toolset and processes?
Where is their headroom in the resources and expertise we have available?
Do we have applicable security use cases or processes? Are they well-documented? Are they optimized?
An organization building an SOC should prioritize technology purchases to get real-time monitoring capabilities to better understand what is happening when observing the consequences of the event. This first level of visibility, while potentially limiting the SOC to reactive activities, is necessary.
SIEMs used to be the first tool purchased when tackling a modern SOC journey.
Today, more focused tools, such as EDR or NDR, or alternate platforms, such as XDR, try to compete with SIEM as a first purchase of a nascent SOC. Simultaneously, SIEM technology expands, including capabilities from UEBA, SOAR, Log Management, Threat Hunting and case management products, creating a superset of SOC capabilities available in a single platform.
As the SOC matures and learns, it will build the processes to treat basic incidents, and it will start to differentiate alert treatment based on their impact. Additional tools might help at this stage to speed up initial assessment, with individual alerts being aggregated and augmented with additional context.
More mature organizations may need to strengthen their ability to perform root cause analysis of the incident and elimination of the threat. They want to ensure that when they close an incident, the risk of recurrence is properly handled.
Threat detection, investigation and response (TDIR) is a set of three core capabilities required by operational teams:
Threat detection: real time or near real time
Investigation: ad hoc, threat hunting and forensic
Response: manual and automated
The set of TDIR capabilities increasingly represents the real world requirements for how tools within a SOC should contribute to the SOC mission and strategy providing integration and efficient process execution. An example of how the requirement for TDIR is influencing SOC operations is in the evolution of the SIEM to become all-in-one SOC platforms.
Monitoring and threat detection
-Broad-based visibility and threat detection capabilities (e.g., an SIEM tool with advanced analytics like user and entity behavior analytics)
-Endpoints (e.g., EDR)
-Networks (e.g., network detection and response [NDR])
-Cloud (e.g., security service edge [SSE] and cloud-native application protection platforms [CNAPPs])
Threat Intelligence
Capabilities that deliver evidence-based knowledge about existing or emerging menaces or hazards to the organization’s assets
This information can be obtained by threat intelligence portals, indicators of compromise (IOC) or reporting delivered by the provider
Threat intelligence can also be intertwined with security alerts with other products to provide rich contextual information of the alert
Detection Engineering
-Automation; incident management and response; and threat intelligence (e.g., security orchestration, automation and response [SOAR])
Incident Response and Hunting
-Automated blocking of known threats when risk of false positive is negligible (e.g., extended detection and response [XDR])
Alert aggregation into correlated security incidents (e.g., EDR, SIEM and NDR)
Enriched search engine for in-depth investigation (e.g., SIEM and NDR)
[/list]
Tools for a New SOC or Converting From an Outsourced to Insourced SituationSmaller or newly formed SOCs, or those that were previously outsourced where the technology was given by the provider, often start with SIEM or log management solutions. This is necessary to start seeing what is happening in the organization, leveraging logs from network and endpoint security controls already in place, and possibly from other sources based on criticality to the organization (e.g., domain controllers, cloud infrastructure, critical applications and externally exposed assets). Some cloud-native or cloud-first enterprises may prefer cloud security products such as CNAPP to address the needs (see Emerging Technologies: Future of Cloud-Native Security Operations).
The need to have a common repository of incidents could be addressed within an SIEM tool or within IT’s case management or service desk tool. Using the capabilities of an SOAR tool can be considered if the incident and case management capabilities in the SIEM do not have the correct integrations, or there are security and privacy concerns with using the IT service desk tool. Not every “greenfield” SOC will have the resources (i.e., budget, people and time) to implement a security incident response plan (SIRP) at the beginning. However, it should be strongly considered at the start of instrumenting the SOC, rather than trying to bolt it on later in the SOC building journey.
If security and privacy concerns make the IT service desk tool inappropriate and if the preferred SIEM tool lacks good enough case management capabilities, security leaders will face an early maturity bottleneck. They will have to consider an SIEM tool with more advanced case management capabilities, or leverage an SIRP tool or the SIRP capabilities of an SOAR tool, which would normally be beyond their current maturity level.
Tools for a Maturing SOCAs the SOC organization builds integrated processes for real-time and near-real-time investigations, additional use cases will become more important. Typically, this includes the ability to allocate resources on threat hunting, with the objective of reviewing the entire “kill chain,” find the root cause and avoid repetition of the same incident.
SOC teams face scalability challenges. Too many events and too much time spent on investigating complex incidents drive security leaders to seek tools for improving their SOC productivity. The security orchestration and automation and the threat intelligence platform (TIP) capabilities in SOAR tools can help automate many of the time-consuming activities of SOC and threat intelligence analysts, as well as support threat hunting activities.
Tip No. 3: Make Technology Investments That Align With Security Outcomes
Most organizations start their SOC journey with an evaluation of existing security controls. When they feel the need to purchase a specialized tool, they face a paradox of choices and too many possibilities in the market. Gartner sees many organizations select a tool primarily to solve the most recent security incident because they get a budget right after the event. They have the mandate to “make sure it never happens again,” and pick the shortest path.
However, even if the preferred tool might provide value, it might not be the right time to add more tools, given the current maturity of the SOC. One frequent reason is the lack of available resources and expertise on the team to leverage the tool. It might even affect the budgeting model for the SOC by spending too much in one area while neglecting others.
There are three categories of improvements where an SOC can invest in tools: visibility; analysis; and action, recovery and management. Investments can further be mapped as needed to items like the NIST Cybersecurity Framework.
Identify: The SOC is dependent upon reliable information about the risks, threats and environments being used, and assets of the organization (e.g., identities, employees and devices) to be successful. New tools such as cyber asset attack surface management (CAASM) are emerging (see Hype Cycle for Security Operations, 2022) that can be leveraged by the SOC to have visibility into organizational assets.
Protect: Modern SOCs are focused on performing threat detection and response but should coordinate with their security operations counterparts to help drive protection activities. Developing and then improving security use cases is critical to success.
Detect: This is where a majority of investments are made, regardless of the size, scope and maturity of an SOC. Common tools include SIEM solutions, as well as endpoint protection platform (EPP), EDR, CNAPP and NDR technologies. Capabilities like threat intelligence are one example in which being defensively prepared may require tool investments. Adding or maturing this capability could drive the adoption of TIP tools or SOAR solutions with TIP capabilities.
Respond: There are two components to response. Both are increasingly being addressed by SOAR tools, as well as tools like SIEM, EDR and full packet capture (FPC).
Triage: There is no security monitoring program that can avoid triage challenges when a security event or incident is identified. The SOC’s objective is to have insight into the priority events to investigate. They then need the relevant context for those events to determine the severity of the potential incident and required response.
Incident response: Improvements in incident response overlap with the triage work but quickly become a separate field in larger teams. Larger, better-funded SOCs have new requirements and responsibilities, such as finding the root cause, containing or disrupting a threat, and applicable remediation and recovery processes.
Continuous visibility and verification: While there is no magical tool to predict future attacks, continuous assessment of prevent and detect capabilities is a way to anticipate and quickly identify issues. This is typically the realm of analysts, engineers and responders in the SOC. Breach and attack simulation (BAS) tools can be utilized by the SOC for a variety of purposes, such as validating security controls (for both protection and detection) that are operating appropriately, or continuing test maintenance for content detection.
In the next few years, many SOCs will abandon at least one of the security monitoring tools they currently use due to a lack of resources and expertise to use the tools effectively. To avoid this eventuality, SOC leaders should align their investment with the ability of the tool to provide value over the long term, considering the benefits to the SOC’s mission. They should then evaluate requirements for resources and expertise.
The MITRE ATT&CK framework is being leveraged by vendors, but with increasing adoption by end-user organizations, to demonstrate control coverage and threat detection efficacy. There is also the new MITRE D3FEND matrix that is used for cybersecurity countermeasures (see How to Use MITRE ATT&CK to Improve Threat Detection Capabilities).
Tip No. 4: Involve Stakeholders Beyond the Security TeamAs an organization gets closer to selecting their security tools, or enhancing their existing incumbent, many of the basic principals get thought about last, which are the security alerts and incidents. How will the security alerts and incidents get reported; who will report them and where will they be reported; and how will they be integrated into the organization?
When purchasing new tools, the buyer will need to include other areas of the organization, but why is this? As noted in Tip 3, incident response is incredibly important for investigation, containment and remediation. The perception of adding an additional security tool into the security team is straightforward to the security professional, but without involving the other areas of the business can be a challenge where remediation is concerned.
Involving others within the business is key to a successful tool implementation because the escalation decision will be identified and the correct resolver group communicated with. There are no surprises, and the security team’s process will be adapted with the new tooling and the correct resolver group within the business identified. When incidents are escalated and resolver groups identified in the process, the recording of the security incident is streamlined with the process and the correct business resolver group identified.
Tip No. 5: Be Flexible in Case of Organizational and Business ChangesIf there is one constant in modern organizations, it is that things are changing somewhere. It can be major changes like digital transformation initiatives, where IT is rapidly moving toward use of SaaS and IaaS; mergers and acquisitions; or new regulations. It can be a more minor evolution such as the desire to bring threat detection and response in OT environments into the SOC.
The key idea is to not treat the SOC as a closed system, but one that is vigilant of the changes to the environment outside of the SOC (for example, at the organizational level, the external business environment and sector it operates in). With this understanding, SOC leaders should then embrace change and new opportunities, when presented, to reengineer, or at least enhance and optimize, the SOC. This is similar to what other parts of IT might be doing when the business wants to “digitally transform.”
To treat the SOC like a living entity, there should be processes established to address change such as quarterly reviews that baseline and assess the SOC’s capabilities. Other opportunities may include assessing the required capabilities as new business initiatives and strategies are surfaced to security and risk leaders. These situations provide important opportunities to determine how the SOC can support these changes and whether the SOC will need investments to reduce risk to the business from these changes.
Finally, security leaders must seek out the critical inputs into any changes required in the SOC. These inputs should come from areas such as continuous performance monitoring of the SOC to uncover trends (both good and bad), postmortems from the completion of projects, strategic information from stakeholders across the business and evaluation of the changes in the external threat landscape.
“Achieving depth in defense for the most prevalent threat vectors is the foundational step of maturing the role of the organization’s SOC. Integrate continuous threat exposure management (CTEM) to ensure cross-team collaboration becomes standard.”
SOC leaders must find the balance in improving their detection and blocking capabilities. This should reduce the number of incidents and improve their response capabilities, ultimately to reduce attacker dwell time.
Source: Gartner, Inc.
Original Content: https://shorturl.at/ejQR6
