A SOC (Security Operations Centre) is the organisational function responsible for defending an infrastructure against security threats through continuous monitoring, alert triage, incident investigation, and coordinated response. It is not a single product: it is the combination of people (security analysts operating in tiered roles), processes (runbooks, escalation paths, incident classification, post-incident review), and technology (primarily a SIEM for detection and visibility, a SOAR platform for orchestration and actuation, EDR agents, vulnerability scanners, threat intelligence feeds, and ticketing or case management systems). The SOC’s purpose is to close the loop between something going wrong in the infrastructure and someone doing something about it — with enough structure that the response is consistent, attributable, and auditable regardless of which analyst is on shift. Operating models range from a fully internal 24×7 team, through a virtual SOC (vSOC) sharing analysts across business units, to an outsourced MDR (Managed Detection and Response) or MSSP engagement where a third party operates the SIEM and initial triage on the organisation’s behalf; the technology stack is largely the same across models, but the boundary of who performs each tier of work changes. Analyst tiers are conventionally structured as L1 (alert triage, false-positive filtering, initial enrichment, escalation decisions), L2 (deeper investigation, correlation across data sources, containment recommendations), and L3 (threat hunting, malware reverse engineering, incident lead, playbook authoring, purple-team exercises) — with escalation governed by severity classification (P1–P4 or equivalent), SLA targets for MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond), and documented runbooks that define what each tier may do autonomously versus what requires approval.
The SOC’s technology architecture follows a clear division of labour that maps directly to the glossary entries for its component platforms. The SIEM is the SOC’s eyes: it ingests logs and events from across the estate, correlates them, and produces alerts — but, as established in the SIEM entry, it has no actuation capability and no feedback path to the infrastructure it monitors. The SOAR platform is the SOC’s hands: it receives enriched alerts from the SIEM (or directly from EDR, CSPM, or container security tools), executes investigation and containment playbooks, and issues remediation commands to connected systems. Between them sits the analyst workflow: an alert fires in the SIEM, an L1 analyst validates it is not a false positive, a case is opened in the SOAR or case management system, enrichment queries pull context from threat intelligence (IOC reputation, KEV status of any CVEs in the affected asset), asset inventory, and identity systems (LDAP/AD, SSSD), and the playbook or analyst decides on containment. Break-glass account activations, bastion session anomalies, and privileged access events are high-priority SOC alert categories because they represent direct access to the administrative plane. Threat intelligence integration is not optional at SOC scale: correlating an alert against the KEV catalog, STIX/TAXII feeds, and ISAC sharing communities transforms a generic “suspicious outbound connection” into a prioritised incident with known actor attribution and documented remediation guidance. Compliance reporting — PCI DSS log review, NIST SP 800-53 AU controls, ISO 27001 incident management — is a secondary but operationally significant SOC output, typically generated from SIEM retention and reporting modules rather than from analyst manual effort.
In a Kubernetes or OpenShift environment, the SOC inherits a telemetry landscape that is both richer and more complex than a traditional VM estate. The primary detection inputs are the same streams described in the SIEM entry: OpenShift API audit logs (every kubectl and API server call), node-level authentication events via journald (SSSD, PAM), container runtime logs, RHACS/StackRox policy violations, Falco syscall alerts, OPA Gatekeeper admission denials, image vulnerability findings correlated against KEV and SBOM data, and NetworkPolicy or CNI flow anomalies. The SOC analyst’s investigation workflow for a Kubernetes alert differs from a host-based alert in one critical respect: the unit of compromise is often a pod or service account, not a host — containment means namespace isolation via NetworkPolicy, RBAC revocation of an over-privileged RoleBinding, pod quarantine or deletion, node cordoning, and image digest blocklisting via RHACS, not simply isolating an IP on a firewall. These actuation steps are executed by SOAR playbooks against the Kubernetes API, with the tiered automation model described in the SOAR entry: low-risk enrichment runs automatically, medium-risk network isolation runs automatically with analyst notification, and high-risk actions (ClusterRoleBinding deletion, node drain) require explicit human approval. The SOC’s relationship to platform-side log filtering is also worth stating explicitly: the OpenShift Logging Operator’s ClusterLogForwarder CRD is configured by platform engineers to route security-relevant streams to the SIEM endpoint, but the SOC defines which streams are security-relevant, at what volume, and with what retention — making the SOC a stakeholder in platform logging architecture, not merely a consumer of whatever the platform team happens to forward. A mature Kubernetes SOC also maintains runbooks for platform-specific scenarios: a compromised service account with cluster-admin, a privileged container breakout detected by Falco, a KEV-listed CVE in a running image on a production namespace, and a break-glass kubeconfig activation — each with defined escalation paths, pre-approved SOAR playbook triggers, and post-incident review requirements.