↓ Skip to main content
Le Site de François
  1. Index/

SOAR (Security Orchestration, Automation and Response)

Security Operations Automation Orchestration Incident-Response Kubernetes Soc

SOAR (Security Orchestration, Automation and Response) is the actuation complement to a SIEM: where the SIEM detects and alerts, SOAR responds and acts. It receives alerts — primarily from the SIEM, but also directly from EDR platforms, vulnerability scanners, cloud security posture tools, and CNI/container security platforms — and executes structured response playbooks: predefined, branching workflows that enrich the alert with additional context from connected systems, make automated or human-gated decisions based on that context, and issue remediation actions across the organisation’s security tooling. The three pillars of SOAR are orchestration (connecting disparate security tools into a unified, API-driven workflow so they exchange data and coordinate actions without human clipboard-copying), automation (executing repeatable investigation and containment steps at machine speed, consistently and without analyst fatigue), and case management (tracking the full lifecycle of a security incident — detection, triage, investigation, containment, eradication, recovery, and post-incident review — in a structured, auditable record). Leading platforms include Splunk SOAR (formerly Phantom), IBM QRadar SOAR (formerly Resilient), Palo Alto XSOAR (formerly Demisto), Microsoft Sentinel with Playbooks (Logic Apps), and open-source options such as TheHive with Cortex.

Inputs and enrichment. A SOAR platform’s primary input is a structured alert from the SIEM — a normalised, correlated event with severity, source entities (IP, user, pod, namespace, container image), and the raw evidence that triggered it. On top of this, SOAR orchestrates enrichment queries to a constellation of connected systems before the playbook makes any response decision: threat intelligence platforms (MISP, VirusTotal, Recorded Future) for IOC reputation; asset databases and CMDBs for context on the affected host or workload; LDAP/AD and SSSD for user identity and group membership of the authenticating principal; vulnerability scanners for CVE data on the affected image; and the Kubernetes/OpenShift API directly for the current state of the pod, namespace, service account, RBAC bindings, and NetworkPolicy associated with the affected workload. This enrichment transforms a raw “suspicious process execution in pod X” alert into a fully contextualised case: the pod is in the payments namespace, owned by service account payments-processor, which has a ClusterRoleBinding granting it cluster-admin (unexpected and policy-violating), the node it runs on is a worker with no other high-risk workloads, and the image has a KEV-listed CVE in the process that executed. With that context, the playbook can make a proportionate automated decision rather than binary block-or-ignore.

Feedback to Kubernetes/OpenShift — the critical difference from SIEM. Unlike a SIEM, a SOAR platform has bidirectional integration with connected platforms: it does not just receive telemetry, it issues commands. For Kubernetes and OpenShift, SOAR playbooks can execute the following response actions via the Kubernetes API or platform-specific APIs: Network isolation — applying a deny-all NetworkPolicy to the affected namespace or a specific pod label selector, cutting the workload’s network access while leaving it running for forensic evidence collection; Pod quarantine or deletion — calling kubectl delete pod or annotating the pod with a quarantine label that a custom controller or RHACS policy enforces; RBAC revocation — deleting or patching the offending RoleBinding or ClusterRoleBinding that granted excessive permissions to the compromised service account; Node cordoning — issuing kubectl cordon <node> to prevent new pod scheduling on a potentially compromised node, followed by kubectl drain if evacuation is safe; Image admission blocking — calling the RHACS API to add the compromised image digest to a denylist policy, preventing it from being scheduled anywhere else in the cluster; Secret rotation trigger — calling Vault or ESO APIs to revoke and re-issue credentials associated with the compromised service account; and MachineConfig escalation — creating a support ticket or paging the node team to apply a remediation MachineConfig to affected RHCOS nodes, since direct node modification is not done through SOAR but through the MCO. The key operational discipline is playbook blast-radius calibration: automated actuation against a production cluster without a human approval gate carries the risk that a false positive detection triggers an automated network isolation of a critical payment processing pod during peak traffic. SOAR playbooks in Kubernetes contexts typically use a tiered automation model: low-risk enrichment and notification steps execute fully automatically; medium-risk actions (applying a NetworkPolicy) execute automatically but with immediate SOC notification and a rollback playbook on standby; high-risk or irreversible actions (pod deletion, ClusterRoleBinding revocation) require explicit analyst approval via a Teams/Slack approval button or a case management approval gate before execution. SOAR’s feedback to the SIEM closes the loop: once response actions are taken, the SOAR platform updates the SIEM incident record (closing the QRadar offense, updating the Splunk notable event, or annotating the Sentinel incident) with the actions taken, the timeline, and the analyst decisions — creating a complete, auditable chain from detection to containment in a single record.

Related

SOC (Security Operations Centre)

Security Operations Monitoring Incident-Response Detection Soc
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.

SIEM (Security Information and Event Management)

Security Operations Monitoring Logging Detection Compliance Soc
SIEM (Security Information and Event Management) is a platform that aggregates security telemetry from across an organisation’s infrastructure, normalises it into a common schema, applies correlation rules and behavioural analytics to detect threats, and retains the data for investigation and compliance reporting. The name combines two earlier disciplines: SIM (Security Information Management) — long-term log retention, compliance reporting, and forensic search — and SEM (Security Event Management) — real-time alert correlation and incident detection. Modern SIEMs do both simultaneously, serving as the primary visibility layer for a Security Operations Centre (SOC). Leading platforms include Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel, Elastic Security, Exabeam, and LogRhythm; all share the same fundamental architecture despite differing in query language (SPL for Splunk, KQL for Sentinel, EQL/KQL for Elastic, AQL for QRadar), correlation engine design (search-based vs dedicated CEP engine), and deployment model (on-premises, SaaS, or hybrid).

cert-manager

Kubernetes Security Tls Pki Certificates Cncf Automation
cert-manager is a CNCF graduated project that brings PKI lifecycle management into Kubernetes as a first-class controller, eliminating the manual processes — CSR generation, CA submission, secret rotation, renewal tracking — that cause certificate-related outages in clusters that manage TLS manually. Its premise is that X.509 certificates should be declared as Kubernetes resources with the same GitOps-friendly, reconciliation-driven lifecycle as any other workload configuration: an operator declares the desired certificate, cert-manager continuously ensures that a valid, non-expired certificate matching that declaration exists and is stored in a Kubernetes Secret, and renews it automatically before expiry. The default renewal threshold is two-thirds of the certificate’s validity period, so a certificate with a 90-day lifetime is renewed at 60 days without operator intervention.