Runtime Security: Monitoraggio in Tempo Reale
La runtime security e l'ultima linea di difesa nel paradigma DevSecOps: proteggere le applicazioni mentre sono in esecuzione in produzione. SAST, DAST e SCA trovano vulnerabilità prima del deploy, ma la runtime security rileva e risponde a minacce attive, comportamenti anomali e attacchi in corso.
In questo articolo esploreremo Falco per il threat detection basato su syscall, eBPF per il monitoraggio a basso overhead, tecniche di anomaly detection e l'integrazione con sistemi SIEM per una visibilità completa.
Cosa Imparerai
- Come funziona il runtime threat detection
- Falco: regole, configurazione e deploy in Kubernetes
- eBPF: monitoraggio kernel ad alte prestazioni
- Anomaly detection e behavioral analysis
- Incident response automatizzato
- Integrazione con SIEM (Splunk, ELK, Datadog)
Falco: Runtime Threat Detection
Falco e il progetto CNCF di riferimento per il runtime security. Monitora le syscall del kernel Linux in tempo reale e genera alert quando rileva comportamenti che violano le regole di sicurezza definite. Falco può rilevare shell spawn nei container, accesso a file sensibili, connessioni di rete sospette e privilege escalation.
Installazione in Kubernetes con Helm
# Aggiungere il repository Helm di Falco
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
# Installare Falco con il driver eBPF
helm install falco falcosecurity/falco \
--namespace falco --create-namespace \
--set driver.kind=ebpf \
--set falcosidekick.enabled=true \
--set falcosidekick.webui.enabled=true
# Verificare l'installazione
kubectl get pods -n falco
kubectl logs -n falco -l app.kubernetes.io/name=falco
Regole Falco Custom
Falco include centinaia di regole predefinite, ma per adattarle al proprio ambiente e fondamentale creare regole custom:
# falco-custom-rules.yaml
customRules:
custom-rules.yaml: |-
# Rileva shell in container di produzione
- rule: Shell in Production Container
desc: Detect shell execution in production namespace
condition: >
spawned_process and container and
proc.name in (bash, sh, zsh, dash) and
k8s.ns.name = "production"
output: >
Shell spawned in production container
(user=%user.name command=%proc.cmdline
container=%container.name namespace=%k8s.ns.name
pod=%k8s.pod.name image=%container.image.repository)
priority: CRITICAL
tags: [container, shell, production]
# Rileva accesso a file di credenziali
- rule: Read Sensitive Credential Files
desc: Detect access to credential files
condition: >
open_read and container and
(fd.name startswith /etc/shadow or
fd.name startswith /root/.ssh or
fd.name startswith /run/secrets)
output: >
Sensitive file read in container
(file=%fd.name user=%user.name
container=%container.name command=%proc.cmdline)
priority: WARNING
tags: [container, filesystem, credentials]
# Rileva connessioni di rete inattese
- rule: Unexpected Outbound Connection
desc: Detect outbound connections from containers that should not have network
condition: >
outbound and container and
k8s.pod.label.network-restricted = "true"
output: >
Unexpected outbound connection from restricted pod
(connection=%fd.name pod=%k8s.pod.name
namespace=%k8s.ns.name image=%container.image.repository)
priority: ERROR
tags: [container, network]
eBPF: Monitoraggio Kernel ad Alte Prestazioni
eBPF (extended Berkeley Packet Filter) e una tecnologia del kernel Linux che permette di eseguire programmi sandbox nel kernel senza modificarlo. eBPF e la tecnologia sottostante che Falco, Tetragon e altri strumenti utilizzano per il monitoraggio a basso overhead delle syscall.
L'overhead di eBPF e tipicamente inferiore all'1-2% di CPU, rendendo praticabile il monitoraggio continuo anche in ambienti ad alte prestazioni.
Tetragon: eBPF Security Observability
Tetragon di Isovalent (ora Cisco) e un tool eBPF-based che va oltre il semplice monitoring: può bloccare attivamente i comportamenti sospetti a livello kernel, come l'esecuzione di processi non autorizzati o connessioni di rete non previste.
# tetragon-policy.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: block-privilege-escalation
spec:
kprobes:
- call: "__x64_sys_setuid"
syscall: true
args:
- index: 0
type: int
selectors:
- matchArgs:
- index: 0
operator: Equal
values:
- "0" # UID 0 = root
matchNamespaces:
- namespace: production
operator: In
matchActions:
- action: Sigkill # Termina il processo
Anomaly Detection
L'anomaly detection utilizza baseline comportamentali per identificare deviazioni dal comportamento normale. Invece di cercare pattern di attacco noti, rileva qualsiasi comportamento insolito che potrebbe indicare una compromissione.
- Network baseline: monitorare il traffico di rete tipico e rilevare connessioni inattese
- Process baseline: registrare i processi normali e allertare per processi sconosciuti
- File access patterns: monitorare l'accesso ai file e rilevare letture anomale
- Resource usage: picchi di CPU/memoria possono indicare cryptomining o DoS
Indicatori di Compromissione (IoC) Comuni
| Indicatore | Possibile Attacco | Strumento |
|---|---|---|
| Shell spawn in container | RCE, backdoor | Falco |
| Connessione a IP noto malevolo | C2 communication | Network monitoring |
| Picco CPU improvviso | Cryptomining | Metrics/Prometheus |
| Lettura /etc/shadow | Credential theft | Falco, Tetragon |
| Processo curl/wget in container | Data exfiltration | Falco |
Incident Response Automatizzato
La velocità di risposta e critica durante un incidente di sicurezza. L'incident response automatizzato permette di reagire in secondi invece che in ore:
# Falcosidekick: risposte automatiche agli alert
# values.yaml per Helm
falcosidekick:
config:
# Notifica Slack per alert WARNING+
slack:
webhookurl: "https://hooks.slack.com/services/xxx"
minimumpriority: "warning"
# Esegui azione Kubernetes per alert CRITICAL
kubernetesCR:
enabled: true
minimumpriority: "critical"
# Pagerduty per on-call
pagerduty:
routingkey: "xxx"
minimumpriority: "critical"
# Azioni automatiche
customActions:
# Isola il pod compromesso (rimuovi label di network policy)
- name: isolate-pod
priority: critical
action: kubernetes
parameters:
namespace: "production"
action: "label"
value: "quarantine=true"
Integrazione con SIEM
Gli alert di runtime security devono confluire in un sistema centralizzato (SIEM) per correlazione, analisi e retention a lungo termine. I SIEM più comuni nell'ecosistema DevSecOps sono:
Integrazione SIEM
- ELK Stack (Elasticsearch, Logstash, Kibana): open source, flessibile, ottimo per log analysis
- Splunk: enterprise, potenti query, buono per compliance
- Datadog Security Monitoring: SaaS, integrazione nativa con cloud e container
- Grafana + Loki: leggero, ottimo per ambienti Kubernetes
Best Practice per Runtime Security
- Deploy Falco su ogni cluster: monitoraggio runtime deve coprire il 100% dei workload
- Custom rules per il contesto: adattare le regole Falco al proprio ambiente applicativo
- Automazione incident response: isolamento automatico dei pod compromessi
- Baseline comportamentale: stabilire una baseline prima di attivare alert di anomaly
- Retention dei log: mantenere i log di sicurezza per almeno 90 giorni (meglio 1 anno)
- Runbook documentati: procedura per ogni tipo di alert con passi di investigazione
Conclusioni
La runtime security chiude il cerchio della protezione DevSecOps. Mentre gli strumenti pre-deploy (SAST, DAST, SCA, IaC scanning) prevengono le vulnerabilità, la runtime security rileva e risponde a minacce attive in produzione. Con Falco, eBPF e incident response automatizzato, le organizzazioni possono reagire in tempo reale.
Nel prossimo articolo esploreremo Compliance Framework, analizzando come mappare i controlli DevSecOps ai requisiti GDPR, SOC2 e ISO27001 e automatizzare la conformità con compliance-as-code.