Licensed for Distribution
FOUNDATIONAL
Refreshed 9 July 2021, Published 15 January 2020 - ID G00464051
By John Collins
Security and risk management leaders often struggle to maintain effective security operations centers without defined operating models. SRM leaders who need to protect an organization according to the internal/external threat landscape should build and run an SOC using an SOC target operating model.
Overview
Key Challenges
Security and risk management leaders often struggle to convey the business value of their security operations centers to non-security leaders, resulting in reduced investment, poor collaboration and eroding support.
Without operational alignment and defined agreements for an SOC, SRM leaders face resistance and avoidance from other business units, increasing the risk of security incidents with direct fiscal impact on the business.
SRM leaders are failing to identify and understand relevant threats and risks to the organization, which increases the chances of devastating security incidents. Lack of initial and continuous threat modeling affects all components of the SOC target operating model, resulting in increased risk and reduced efficacy of SOC operations.
Recommendations
SRM leaders responsible for SOCs should:
Leverage the Gartner SOCTOM framework to define the current and future state, the mission, and the roadmap, as well as align with business initiatives.
Engage with leaders enterprise-wide to assess their requirements and the needs of the SOC now and in the future.
Improve communication with non-security leaders by translating security metrics into business-enabling terms that show a demonstrable effect on risk to the organization.
Continuously assess threats and risks to the business by developing a formal threat-modeling program and leverage the results to drive risk mitigation efficacy.
Introduction
The core mission of any security operations center (SOC) is to defend an organization against the internal and external threat landscape, while accounting for the risk tolerance of the organization. However, security and risk management (SRM) leaders have been in a continuous state of conflict since the concept of the SOC was born. SRM leaders are often plagued with questions and doubts:
What does the SOC do? Business leaders are not seeing a return on investment (ROI) in the SOC in the form of reduced risk exposure to the business. Why?
Why are my business unit peers confrontational, and why do they continuously oppose my team’s requests and recommendations?
Why can’t the SOC compete for investment, compared with peers inside and outside security?
Why can’t we make agile adjustments to deal with threats?
After spending so much on security tools, why are we continuously getting breached?
This line of questioning on a continuous basis could introduce unfocused noise and distract from the efficiency of the SOC. Unfortunately, these issues with SOC operations and valuation are common across every industry. In 2019, the SANS Institute conducted an SOC survey, Common and Best Practices for Security Operations Centers. The top challenges respondents reported were a lack of skilled staff (57%), with too many tools not integrated (43%), and a lack of processes (36%) that contribute to the issues that centralized SOCs face. (1)
Various business units inside an organization will use a target operating model (TOM) to define the requirements, dependencies, current operating model (COM) and roadmap for the future state. The concept of a TOM in security is not innovative.
The Gartner form of this, the Gartner Information Security Function Operating Model (GISFOM; see “Introducing the Gartner Information Security Function Operating Model”), guides an organization’s overall security program development. The Gartner SOCTOM model (see Figure 1) closely follows both the information and technology (I&T) operating model framework (see “What Is an I&T Operating Model, and How Do You Accelerate Its Design Process?”) and the GISFOM framework. The key difference is the related high-level components of align, invest and measure (AIM).
Figure 1. SOCTOM Framework
Defining an SOCTOM will address problems organizations face with SOC efficacy, efficiency and ROI. An SOCTOM is universally applicable and valuable, regardless of whether the organization has recently made the decision to build an SOC, or if they have been operating one for a certain length of time. The SOCTOM applies the same GISFOM concepts at a granular level to guide SRM leaders in defining a current and a future state for an SOC.
Analysis
Define the SOC's Current State, Future State and Roadmap, and Establish Internal and External Alignment with the SOCTOM Framework
Defining a roadmap requires an understanding of the current state and is essential for SOC creation, function and maturation. A COM is always a work in progress — it is “current” as of today, and it’s different from the COM yesterday or tomorrow. Perform continuous COM assessments against the SOCTOM to determine whether the SOC is on track toward real, intended goals and maturity. Business goals and strategy will change based on various inputs, that will affect the long-term SOC roadmap (see “SOC Development Roadmap”). For example, an organization may implement a hybrid SOC operation model using a managed security/detection and response service provider for Level 1 (L1) alert triage and round-the-clock monitoring of on-premises environments.
A leadership change may push the organization to migrate to the cloud; however, the security provider may not have the ability to deliver the same coverage in a cloud environment. Business and organizational decisions have a ripple effect on security components, such as the SOC and security providers. SRM leaders will experience greater operational success by having strong integration and communication with the business and their organizational peers to stay aware of potentially impactful decisions.
The Gartner SOCTOM framework provides an interlinked component structure SRM leaders need to comprehend for successful implementation. Table 1 provides definition of each component and how AIM works here.
Table 1: Gartner SOCTOM Framework Components
Component | AIM Definition/Functionality |
Align | |
Organization | The primary driver here is to ensure a clear understanding of roles, responsibilities, expectations and dependencies between the SOC and the organizational units. Determine what the defined business objectives and risks are and ensure that the SOC mission will support them. |
Compliance and Framework | Determine requirements for compliance and/or industry security frameworks and how they will affect the SOC development and roadmap. This requires alignment with IT, integrated risk management (IRM) and legal to ensure that the SOC is meeting regulatory or industry requirements. |
Partners | Identify partners and ensure there is strong communication around bidirectional change regarding material changes to agreements, architecture and delivery of services. |
Invest | |
People | Invest in people to operate the SOC and invest equally in their development. It is critical to give SOC personnel a sense of ownership in the operations and security program. Ensure there is a dedicated budget for recruitment, retention and training of security expertise. |
Process | Implement process that fits with the SOC model and business objectives, to include other organization components. |
Technology | Use a pragmatic and realistic selection process for SOC tool spending, based on thereat modeling and identified business risks. Layering multiple overlapping tools will hit a barrier of diminishing returns as it relates to risk reduced per dollar spent. |
Measure | |
Efficacy | Risk reduction is the key metric to convey value to leadership and validate investment in the SOC. |
Threat | Threat modeling and continuously measuring threat exposure drive risk identification, talent needs, process improvement and pertinent tool selection. |
State | Continuously assess and understand the COM to determine where the SOC is on the roadmap journey. This component measures all the components above at any given time to determine the success of risk mitigation to the organization and to assess investments in people, processes, and technology (PPT), as the SOC matures against the roadmap. |
Source: Gartner (January 2020)
Communicating and aligning with business leaders, organizational peers, compliance requirements and partners will enable SRM leaders to reduce friction and increase operational effectiveness earlier in the SOC development cycle.
The invest components are the legacy core of an SOC. According to 2019 industry survey results, PPT is the core issue of SOC failure. This also includes lack of budget. (2) SRM leaders must create a plan for personnel success by defining goals and deciding on the level of internal talent required for a particular SOC.
Creating an SOCTOM when planning, running or improving an SOC will deliver marked improvement for SRM leaders to communicate effectively, collaborate internally and externally, and conceive understanding of the present and future SOC.
Engage With Leaders Enterprise-wide to Understand Their Requirements and the Needs of the SOC
SRM leaders must align with organizational peers from business units affected by SOC operations. IT, HR and legal are common SOC alliances that must be involved in the decisions on SOC development and operations. The IT organization will be married to the SOC and the relationship is critical for success. According to a 2019 Ponemon survey, the top barrier to SOC success is lack of visibility into the environment, with 69% of respondents stating that a lack of network visibility is the top reason for ineffectiveness. (3) There is no good reason for the SOC and IT to have a “turf war” over access to assets or to argue over responsibilities. Lack of communication and emotional intelligence are common root causes of IT-versus-SOC disputes and introduce unnecessary risk to the organization. Figure 2 provides guidance on how to overcome the differences and introduce appreciation for one another.
Figure 2. Organizational Alignment and Agreement
SRM leaders need to reach out to non-IT business units to consult their needs and explain SOC’s operational capabilities and how it could support their mission. For example, a critical discussion must occur with legal regarding security incidents and data breaches. “Build Your Security Incident Crisis Communications Plan” provides excellent guidance on the organizations required for incident planning, with the SOC an essential player. The SOC and HR teams can collaborate on ways the SOC can support the HR mission via security monitoring and evidence collection in HR cases. Defining process and explaining SOC capabilities during an active HR investigation or data breach is not ideal timing.
Figure 3 is an example of an SOCTOM plan that uses color coding to depict what is insourced, outsourced and co-sourced. This example illustrates requirements internally and externally to set expectations with stakeholders outside the SOC. For example, co-sourced security engineering could involve the IT operations team in maintaining hardware hosting security solutions, and a managed security service provider (MSSP) will provide continuous security use-case updates. This example logical diagram of an SOCTOM is based on Gartner Consulting efforts. There are multiple permutations to the SOCTOM, driven largely by the SOC model from which an organization can choose. This represents a hybrid model, with portions outsourced to a provider, and it depicts partner groups in the organization.
Figure 3. SOCTOM Example Planning Design
Translate Security Metrics into Business-Enabling Terms to Improve Communication with Non-Security Leaders
Develop risk indicators and security metrics that convey value and influence non-IT leadership decision making (see “Develop Key Risk Indicators and Security Metrics That Influence Business Decision Making”). Security metric value will vary based on an organization’s identified business risks, threats and security maturity. Gartner provides a significant amount of guidance on security metric development. When developing metrics for communication in an SOCTOM (see “Developing Metrics for Security Operational Performance”), implement Gartner’s approach of a five-step taxonomy:
Business-aligned
Controllable
Quantitative
Easy to assemble
Can form a trend
Determine what is of value to the audience using the taxonomy above in relation to the groupings depicted in Figure 4. Don’t waste time on irrelevant metrics, just because data is available.
Figure 4. Metrics and Reporting Hierarchy
Collaboration with the C-suite is the most important strategic direct interaction SRM leaders need to have continuously. This relationship is the opportunity for SRM leaders to communicate the value of the SOC, using the guidance provided above. It is how the SOC will learn about evolving strategic business plans. SRM leaders can leverage a simple, yet effective, interpretation of the Observe, Orient, Decide and Act (OODA) Loop (4) model, developed by Colonel John R. Boyd, USAF (Ret.) to interpret evolving business objectives and requirements. Figure 5 provides a map of how this can work for an SOCTOM to remain relevant to changing business needs.
Figure 5. OODA Loop Process to Update SOCTOM Based on Business Change
Understanding business needs is not the end of this collaboration with C-suite leadership. The leadership team must interpret the ongoing value the SOC is providing to the business. The CISO role is often the designated liaison between the security program and the executive leadership team, but who communicates is irrelevant. The data communicated is critical, and how it is communicated is even more vital to SOC reputation and validation. This is not just an SOC issue, but an overall security program problem that Gartner has addressed in numerous research undertakings to assist SRM leaders.
The three key concepts to leverage in security value communication (see “Want to Improve Your Business and Security Relationship? Fix the Way You Communicate”) are:
Communicate in business language. Cut down technical jargon to build business partner interest and to understand risk. Progressive information security leaders use informal conversations with business partners (see “Information Risk Understanding Exercise Questionnaire”) to conduct information risk understanding exercises.
Add context to risk guidance. Provide advice on the risks business partners are likely to face. Scenario-based discussions (see “Information Security Engagement Scenarios”) help highlight clear action steps at relevant decision points.
Adopt an open-door policy. Use informal conversations to help business partners understand how to be secure inside and outside the work environment. Make business partners feel comfortable approaching security with risk-related queries. This helps position security as an advisor on security-related concerns and build business’s trust in security (see “Business Engagement Training — Become the Trusted Advisor”).
Each SOC partner will have different requirements; however, the OODA Loop framework and the Gartner security value communication guidance are still applicable. Explaining dynamic link library (DLL) sideloading, Remote Desktop Protocol (RDP) chaining and exfiltration of data through SSH File Transfer Protocol (SFTP) is unlikely to translate well to anyone outside the SOC.
Develop a Formal Threat-Modeling Program to Assess Threats and Risks to the Business
Threat modeling is arguably the most underutilized tool of SOC operations, and it is virtually free. Threat modeling is often associated with software development and system architecture design. However, in the Gartner’s SOCTOM framework, threat modeling focuses on the identification of likely threats against an organization (see Figure 6). SRM leaders should leverage a formal framework to identify threats, such as ISO 27005:2018, CBEST Threat Modelling or Mitre Threat Susceptibility Analysis. Regardless of the threat-modeling framework or method used, the goal is to answer the question, “What threats is the organization up against?” Measuring threats to understand their nature has a direct impact on the invest components (e.g., people, processes and tools).
According to 2019 survey results, only 37% of organizations say their SOC has high interoperability with intelligence tools. (5) This means nearly two-thirds of organizations are not effectively using the intelligence products for which they’ve paid.
Figure 6. Threat Modeling for SOCTOM Development
Gartner recommends that every organization define its top threats, at a minimum, by associated business risks, industry and geopolitical applicability, before adopting a “boil the ocean” approach. Here’s an example using the retail industry:
Business Risks — Attacks against point of sale (POS) systems are affecting the confidentiality of card data, and the availability of processing systems will be devastating to brand reputation and revenue.
Industry — GlitchPoS is applicable to card brands, payment processors, POS manufacturers and retailers. Industries that do not leverage POS systems should eliminate POS threats from their models.
Geopolitical — Determine targeting of GlitchPoS and other POS-related malware. If it’s targeting regions in which the business has no operations, the criticality is lowered, but not eliminated. Perhaps the POS malware targets a particular POS vendor, model and/or a version of software that is not applicable to the business.
Using multiple inputs in their threat-modeling decisions, SRM leaders will be able to build a unique threat model for the organization to identify threats to the organization and changes to the SOCTOM to mitigate identified threats.
Evidence
1 Crowley & Pescatore, 2019
2 Ponemon Institute, 2019
3 Osinga, 2006
4 Osinga, 2006
5 Ponemon Institute, 2019
6 Ponemon Institute, 2019
© 2022 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. and its affiliates.
Bình luận