Stripped back to its core, a SOC exists primarily to detect and respond to security incidents. Increasingly, however, it can deliver an ever-expanding catalogue of capabilities to protect an organisation’s critical assets against a variety of threats. Identifying which capabilities the SOC should provide is a fundamental element of constructing a successful SOC.
EVOLUTION OF THE SOC
The concept of a SOC has evolved over recent years to mean different things to different people, and in this article, I will try and bring some clarity for enterprises that are looking to build a SOC or considering options for evolving their existing SOC.
Some subscribe to the traditional school of thought that the SOC is solely a security monitoring and detection capability to identify security incidents, which are then handed over to an incident response team – commonly known as a Computer Security Incident Response Team (CSIRT).
Others are in favour of transforming the SOC into a broader, all-encompassing entity that incorporates a conventional SOC with related capabilities – often referred to as a Cyber Defence Centre (CDC). The structure of a CDC will vary between organisations, but can include teams dedicated to incident response, threat intelligence and vulnerability management alongside the SOC team. The split of responsibilities should be clearly defined, but equally skill sets can be shared to perform a range of complementary activities.
As two separate entities, a CSIRT may operate in parallel or above a traditional SOC. Alternatively, a CSIRT may be fused with a SOC and sit within the same group (e.g. a CDC) with access to the same tools. Regardless of the exact organisational alignment, the CSIRT will own the incident response process with a strong interface and political ties to crisis management.
In large global enterprises, the trend of unifying distinct entities, such as a Network Operations Centre (NOC), SOC, CSIRT and other groups (e.g. threat intelligence, fraud investigations and physical security) into a single, coherent unit is gaining traction. This convergence of functions, often referred to as a Fusion Centre, can engender greater collaboration and flexibility.
Merging a SOC team into an umbrella entity responsible for a wider breadth of capabilities supports the vision of many CISOs we speak to, to develop a SOC into a centre of excellence. It also recognises the need for a SOC to closely interface with other teams (both business and technology) to optimise the detection and response to security incidents. The above interpretations of a SOC broadly translate into three approaches for this interaction: coordination, integration and collaboration, as shown in the figure below.
SOC CAPABILITIES
The diverse range of tasks that can fall within the remit of a SOC precludes an exhaustive definition of SOC services and capabilities. As a result, in this article I have focused on five overarching capabilities that embody the essence of what a SOC should provide. In future articles, I will cover each one separately and in depth.
Successful delivery of these capabilities depends on close collaboration and engagement with stakeholders throughout the organisation. A high-level depiction of the five core capabilities is shown in the figure below with brief descriptions provided underneath.
Data collection and correlation: select relevant data to be acquired via logs and other sources and determine how it can be collected and collated effectively.
Key activities: gather, normalise and correlate data from disparate sources. Continually tune and maintain data feeds to ensure the right data at the right level of detail is provided for tools and security analysts to execute tasks quickly and accurately.
How we do it at LMNTRIX: Our data collection is focused on high value data sources that are critical for post breach forensics used for aiding investigations.
Detection: gain actionable insight into abnormal security events and identify malicious or anomalous behaviour.
Key activities: define the threat scenarios to monitor and develop alerts to detect anomalies indicating signs of network intrusion. Establish a mechanism to receive tips and reports of suspicious activity from users and third parties.
How we do it at LMNTRIX: We rely less on logs from existing controls for threat detection and more on our tech stack for detecting threats that bypass existing security controls. We focus our coverage more on Visibility, Detection Capability & Signal Fidelity across different threat vectors. This approach has proven time and time again to be far more effective than the traditional approach of trying to detect threats using logs from existing controls that continue to let threats through.
Monitoring: review generated alerts and conduct initial analysis to ascertain whether an alert constitutes suspicious activity that should be escalated for further investigation or if it is a false positive.
Key activities: perform triage to validate alerts and escalate as appropriate. Provide feedback on false positives for alert development to optimise correlation rules and improve detection of genuine threat activity.
How we do it at LMNTRIX: To scale our team and operation, we make use of bots extensively to automate the initial analysis and incident creation process. Our SOC does not make use of any traditional SIEM or SOAR technologies, and we avoid the associated false positives and analyst alert fatigue. All logs are stored in the cloud using our analytics platform and data ingestion is architected in a high performance pipeline, that performs Data Enrichment when the data gets ingested.
Security investigation: gather additional information and conduct in-depth analysis to understand the full context of an alert.
Key activities: assess whether a potential or actual security incident occurred. If confirmed as a security incident, classify and categorise the incident according to its scale, impact and severity, and recommend response actions.
How we do it at LMNTRIX: Our analysts work out of our incident management system and proprietary XDR platform, which allows for rapid investigations and incident response actions. As eluded to earlier, our bots are nothing more than python code that conducts the first level of alert validation and incident creation before analysts are engaged to conduct a more in-depth investigation.
Incident response: mitigate the business impact of security incidents through remediation and recovery.
Key activities: recommend, coordinate and execute relevant tasks in response to a security incident. Ensure implementation of security controls to address vulnerabilities that were exploited, and apply lessons learned to enhance the SOC’s future performance. Report details of the security incident, including the root cause, evidence collected, and actions taken in response.
How we do it at LMNTRIX: We automate the threat containment process for clients to reduce attackers dwell time, minimise breach impact and stop re-infections. This automation involves the active blocking of IOCs across the client network, endpoint, and cloud controls within minutes of incident validation. These are features built directly into our XDR platform that integrates with all NextGen firewalls, our endpoint security agent, and cloud security vendors (e.g. Zscaler, Netskope, Cisco Umbrella, Exchange Online, and Mimecast).
Each capability encompasses discrete but interrelated operational activities necessary to monitor and analyse security events, and realise the aim of preventing, detecting and responding to security incidents. Depending on the size of the SOC, separate teams may be allocated responsibility for different activities. In a small SOC, multiple activities may be carried out by the same individual.
The figure below (LMNTRIX internal), depicts the end-to-end flow of these SOC activities, starting with the collection and correlation of data to gain visibility of security events, through to detection and monitoring of alerts, conducting security investigations and responding to confirmed security incidents – enabling both remediation and recovery.
Each capability and the corresponding activities I will explain in future articles, with reference to the people, process and technology involved. Organisations should note that:
• “Deploy sensors” involves the onboarding of our own NDR and network forensic sensors, endpoint security agent, mobile security agent, deceptions everywhere, cloud security using API integration together with extensive machine and underground intelligence.
• not all activities shown are performed daily; some are conducted on a periodic basis but are integral to the SOC’s day-to-day success.
• the level of experience and specialist expertise required to carry out each task can vary.
• although automation can improve efficiency in executing certain tasks (annotated where relevant in figure above), automation should only be introduced where there is certainty around a given process
• reporting to the business and executive management may not be part of daily operational processes, but it should be embedded into relevant tasks to demonstrate and communicate the value of the SOC. At LMNTRIX we have developed automated reporting directly into our XDR platform.
• some of the activities represent advanced capabilities (annotated where relevant in the figure above), best suited to organisations that have got the basics right and are seeking to optimise the performance of their SOC.
Stay tuned as I cover the five pillars of security capabilities in more depth in future articles.
