The first post in the Fundamentals of the Game series listed a set of skills that characterize successful SOCs, just like the excellence in offensive and defensive fundamental skills characterizes the greatest players in basketball or any other sport. The second article provided details on one of these fundamental skills (established alignment between SOC and business goals). The subject of this new article is another fundamental skill, represented by the design and execution of functional integration of people, processes and technologies. In short: how do we ensure that people, process and technology are aligned inside our security operations program.
We know the "People, Process, Technology" mantra all to well. As information security professionals, we cannot read a blog, book or paper without crossing path with these three nouns. They represent the pillars of any security vendor's offering, or at least that's what their sales presentations say. Popularized in the infosec world at the end of last century by Bruce Schneier, the "People, Process, Technology" trifecta has been at the heart of the ITIL set of practices since their birth in the 1980s, and has its origins linked to Harold Leavitt's Diamond Model theorized in 1965 (with the organization's tasks representing the fourth component). We can probably dissert about what is the most important element of the three and in which percentage we should split our efforts, or budgets, when planning and managing our security program. But we cannot deny that they are all necessary components, and the lack of perfect integration among them most certainly means that our security program is doomed to failure.
When we design and implement incident detection and response capabilities in our SOC, we must keep in mind the following key elements for each of the three components:
- Once the organization has defined the SOC functions, as we have seen in the previous article, it has to find the right human capital to run them. The staff can be internal or external to the organization (e.g. MSSP); what is of paramount importance, however, is that the "ownership" of the program is always kept inside the organization.
- People are then be mapped to SOC roles. Each role must be clearly defined and its definition needs to include, at least, the following information: job description, qualifications, responsibilities, skills and experience, training and career progression paths.
- The type and number of roles is strictly dependent on the organization (i.e. size, structure, mission, budget, vision). As an example, SOC roles needed at different stages of the organization's SOC maturity can be the following: Security Analyst (with different level of expertise/responsibilities, e.g. L1 and L2 Analysts), SOC Manager, Incident Coordinator, Shift Coordinator, Malware Analyst, Forensic Analyst, Content Engineer, Threat Intelligence Analyst, and Platform Engineer.
- Processes are strictly related to the goals that the security program wants to achieve and are therefore related to the SOC functions previously defined. Each SOC function can have one or more associated process.
- Together with the definition of the process, each SOC function needs to be linked to specific roles. This can be done adopting assignment models like, for example, RACI matrix.
- As for the roles, the type and number of processes depends on the organization's needs and the type/number of SOC processes that are to be implemented. As an example, the following processes can be defined and developed: Security Monitoring, Incident Triage, Incident Analysis, Incident Response, Breach Response, Content Management, Forensic Analysis, Malware Analysis, Hunting, Threat Intelligence Management, Security Devices Management, SOC Program Management.
- Technology enhances and supports the SOC Incident Detection and Response capabilities providing visibility on networks and systems, advanced threat detection, incident analysis and investigation capabilities.
- Visibility is ensured by data collection from logs (e.g. operating systems, services, applications, database, security tools, network equipment, etc.), full packet capture collected at selected network pinchpoints (e.g. internet gateways, exchange points among networks with different trust levels), network flows, and endpoint data.
- Advanced threat detection is accomplished through data analytics that leverages collected environmental data (as from the point before) and contextual data in the form of threat intelligence, asset information (criticality above all), and business context.
- Incident analysis and investigation capabilities are guaranteed through a single pane view both into the data triggering threat detection and historical one.
- As the SOC maturity grows, technology can also contribute to process automation both for incident handling (triage, investigation, and remediation) and SOC program management (KPI, reporting, and metrics).
Integrating people, processes and technology may seem hard on paper. But in real life is much, much harder! Unfortunately no silver bullet is available to achieve perfect - or good enough for that matter - integration, no matter what security vendors promise to their customers on their data sheets or at security conference booths. The only recipe I have found effective for reaching this goal goes through hard work by security teams, exactly like in sports where great athletes that want to master the fundamentals of the game train harder and harder every single day of their professional life. Indeed, no shortcut has yet been found for reducing the amount of hard work required to create an effective SOC; at the end of the day we still need to rely on proper design, state of the art implementation, and continuous program management and improvement.
Stay tuned for the next installment of this series in which we will discuss another fundamental of the game: focus on data through visibility and visualization