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

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).

Inputs: logs vs events — and why the distinction matters. A SIEM consumes two categories of telemetry with different characteristics. Logs are structured or semi-structured records written by a system describing what it did: syslog lines from Linux hosts, Windows Event Log entries, web server access logs, audit records from the Linux kernel audit subsystem, IMA measurement events, SELinux AVC denials, firewalld/nftables packet drops, OpenShift API server audit logs (every kubectl API call, with verb, resource, user, namespace, and response code), container runtime logs from CRI-O, SSSD authentication events, and AIDE change reports. Logs are high-volume, append-only, and timestamped but do not inherently carry urgency or severity — they describe facts. Events (or alerts) are pre-processed, semantically enriched signals that something security-relevant may have occurred: a failed authentication threshold exceeded, a KEV-listed CVE detected in a running image, a NetworkPolicy violation, an unexpected privileged container start, or a Falco rule firing on a suspicious execve(). Events are lower-volume, carry a severity and a structured alert schema, and often include correlation context already applied by the source (a CNI plugin, an EDR agent, RHACS, or a cloud-native security platform). The SIEM must handle both — logs require parsing, field extraction, normalisation (mapping vendor-specific field names to a common schema such as ECS, CEF, or LEEF), and indexing before they can be correlated; events arrive pre-normalised but must be deduplicated, enriched with asset context, and correlated with related log evidence. Concretely from a Kubernetes or OpenShift environment, a SIEM receives: logs (OpenShift API audit log via Vector/Fluentd sidecar or the OpenShift Logging Operator forwarding to a SIEM-compatible endpoint; node-level syslog; container stdout/stderr forwarded by the node logging agent; ODF/Ceph audit events; SSSD and PAM authentication logs from the RHCOS node via journald) and events/alerts (RHACS/Stackrox policy violations forwarded via webhook or syslog integration; Falco alerts forwarded to a Fluentd/Fluent Bit aggregator; OPA Gatekeeper policy violation events from the Kubernetes API audit log; image vulnerability findings from an integrated scanner; network flow anomalies from a CNI plugin with flow logging such as Cilium Hubble).

The SIEM’s relationship to the Kubernetes/OpenShift platform is strictly one-directional: the platform pushes telemetry to the SIEM, and the SIEM has no feedback path back to the platform. A SIEM can detect, correlate, alert, and report — but it cannot delete a pod, apply a NetworkPolicy, revoke an RBAC binding, quarantine a node, or trigger a MachineConfig rollout. This is an architectural boundary, not a limitation: the SIEM is an observation and detection system, not a control plane. Actuation — the feedback loop that actually changes the state of the cluster in response to a detected threat — is the role of SOAR. What a SIEM can do on the Kubernetes side is drive the log collection configuration: the OpenShift Logging Operator’s ClusterLogForwarder CRD specifies which log streams are forwarded, to which SIEM endpoint, in which format (syslog, HTTP JSON, Kafka), and with what filtering (namespace selectors, log level thresholds, field inclusion/exclusion). This is the platform-side filtering mechanism: rather than forwarding every container’s stdout at full volume to the SIEM (which would be impractical at scale), the ClusterLogForwarder routes infrastructure logs, audit logs, and application logs to different SIEM indices or pipelines, applies namespace-level filters to exclude high-volume but low-value namespaces (monitoring, logging itself), and can drop DEBUG-level application logs while preserving all audit and security events. The SIEM then applies its own filtering, normalisation, and enrichment on top. Platform-side pre-filtering is not optional at Kubernetes scale: a 100-node OpenShift cluster generating 50,000 log lines per second from all sources would overwhelm most SIEM ingestion pipelines and licensing budgets; structured forwarding of only security-relevant streams — API audit, node auth, security tool alerts, policy violations — is the production-realistic approach.

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.

AIDE (Advanced Intrusion Detection Environment)

Security Linux Integrity Monitoring Rhel Compliance
AIDE (Advanced Intrusion Detection Environment) is a host-based intrusion detection tool that implements file integrity monitoring (FIM): it builds a baseline database capturing cryptographic hashes and metadata for every file it is configured to watch, and on subsequent runs compares the live filesystem against that database, reporting anything that has been added, removed, or changed. Its security premise is detection after the fact: AIDE does not prevent modifications (that is the role of fapolicyd, SELinux, and IMA), but it provides a reliable, auditable record that modifications occurred, when a check was run, and which specific attributes changed. An attacker who compromises a system and modifies a binary, a configuration file, a cron job, or an SSH authorized_keys file will leave a fingerprint in the next AIDE check — provided the database has not also been compromised, which is the central operational concern the tool’s deployment model must address.

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.