La sicurezza operativa parte da un vocabolario preciso. Prima di parlare di tool e alert, un analista SOC deve saper collocare ogni evento nel modello concettuale corretto: cosa stiamo proteggendo, da cosa, e con quali controlli stratificati.
La CIA triad
La CIA triad definisce i tre obiettivi fondamentali di qualsiasi programma di sicurezza:
| Proprietà | Cosa garantisce | Esempio di violazione |
|---|---|---|
| Confidentiality | L’informazione è accessibile solo a chi è autorizzato | Data exfiltration, sniffing di traffico in chiaro |
| Integrity | Il dato non è stato alterato in modo non autorizzato | Tampering di un record, defacement, man-in-the-middle che modifica il payload |
| Availability | Il servizio/dato è raggiungibile quando serve | DoS/DDoS, ransomware che cifra i file, guasto hardware |
Controlli tipici: la confidentiality si difende con encryption (IPsec, TLS) e access control; l’integrity con hashing, digital signature e file integrity monitoring; l’availability con ridondanza, load balancing e protezione anti-DDoS.
Punto chiave d’esame: un attacco può colpire una o più proprietà contemporaneamente, ma nello scenario devi identificare quella primariamente impattata. Un ransomware che cifra i dati senza esfiltrarli colpisce l’availability (i dati esistono ma sono inaccessibili), non necessariamente confidentiality.
Threat, vulnerability e risk
Sono tre concetti distinti che l’esame ama confondere:
- Vulnerability: una debolezza (una versione software non patchata, una password debole, una porta aperta).
- Threat: un potenziale evento o attore che può sfruttare la vulnerability (un attaccante, un malware, un insider).
- Risk: la probabilità che una threat sfrutti una vulnerability, moltiplicata per l’impatto. In forma concettuale: Risk = Threat × Vulnerability × Impact.
Un exploit è lo strumento concreto che trasforma la vulnerability in compromissione. Se non esiste vulnerability, la threat non genera risk.
Defense-in-depth
Il modello defense-in-depth applica controlli di sicurezza multipli e stratificati, in modo che il fallimento di un singolo layer non comprometta l’intero sistema. I layer tipici:
- Physical (badge, videosorveglianza)
- Network (firewall, segmentazione VLAN, IPS/Firepower)
- Endpoint (AMP, antivirus, host firewall)
- Application (input validation, WAF)
- Data (encryption, DLP)
- Policy e awareness (formazione, procedure)
Il principio guida è che nessun controllo è infallibile: la ridondanza dei layer aumenta il costo e il tempo necessari all’attaccante, migliorando la capacità di detection.
Security deployment models: perimeter vs zero trust
Il modello perimeter-based assume una netta separazione tra “dentro” (trusted) e “fuori” (untrusted), con il firewall come guardiano. Il limite è evidente: una volta superato il perimetro (phishing, credenziali rubate), l’attaccante si muove lateralmente con pochi ostacoli.
Il modello zero trust ribalta l’assunto: “never trust, always verify”. Nessun utente, dispositivo o flusso è affidabile per posizione di rete. Ogni accesso viene autenticato, autorizzato e valutato continuamente in base a identità, postura del dispositivo e contesto. Si appoggia a micro-segmentation, autenticazione forte (MFA) e policy dinamiche — in ambito Cisco tipicamente Cisco ISE per identity/posture e TrustSec/SGT per la segmentazione.
Least privilege e separation of duties
Due controlli chiave che riducono il risk:
- Principle of least privilege: ogni soggetto riceve solo i permessi strettamente necessari al proprio compito, per il tempo necessario. Limita il blast radius di un account compromesso.
- Separation of duties: nessun singolo individuo controlla l’intero ciclo di un’operazione critica (es. chi crea un pagamento non è chi lo approva). Riduce frode interna ed errori. Concetto correlato: dual control e job rotation.
Insieme, questi controlli sono pilastri sia del zero trust sia di un solido programma di access control.
Trappole tipiche d’esame
Ragiona come un analista SOC in fase di triage: davanti a un alert la domanda non è “cosa è successo” ma “quale proprietà CIA è primariamente impattata” e “quale controllo architetturale è stato aggirato”.
- Alert IDS: grande volume di traffico DNS anomalo in uscita verso un dominio sconosciuto (DNS tunneling) → la proprietà primariamente colpita è la confidentiality (data exfiltration attraverso un covert channel). L’availability resta intatta: i servizi rispondono, ma il dato sta lasciando il perimetro.
- Alert FIM: modifica non autorizzata al file di configurazione di un web server, senza downtime → integrity. La trappola è rispondere “availability” perché è un server: il servizio è up e raggiungibile, ma il contenuto non è più affidabile finché non lo si valida contro un hash noto.
- Caso di lateral movement: da una workstation compromessa l’attaccante raggiunge un file server usando credenziali valide, senza incontrare alcuna nuova autenticazione → il modello fallito è il perimeter-based (fiducia implicita “dentro” la rete). La contromisura che avrebbe fermato il movimento è zero trust con micro-segmentation e ri-autenticazione per-flusso: la posizione in rete non deve conferire fiducia. Se lo scenario enfatizza “verifica continua per ogni accesso interno”, la risposta è zero trust, non un firewall perimetrale più stretto.
- Caso insider/frode: lo stesso analista che riceve e chiude l’alert di un pagamento anomalo è anche l’utente che aveva creato e approvato quel pagamento → principio violato: separation of duties (non least privilege). Un singolo soggetto controlla l’intero ciclo dell’operazione critica; la mitigazione è dual control e la separazione dei ruoli di creazione, approvazione e revisione.
- Triage di un account che, oltre alle sue mansioni, può disabilitare i log di audit del SIEM → la combinazione da segnalare è duplice: violazione di least privilege (permesso non necessario al ruolo) con impatto sulla integrity della pista di audit. La trappola è fermarsi al solo least privilege senza notare che la capacità di alterare i log mina l’affidabilità delle evidenze di indagine.