CompTIA SY0-701: Operazioni di Sicurezza, Monitoraggio e Rilevamento — Guida allo studio
Fa parte della CompTIA Security+ SY0-701 — Guida allo studio. Esercitati con risposte verificate nel centro esami CompTIA, oppure fai test cronometrati su ExamRoll.io.
Le moderne operazioni di sicurezza dipendono dalla capacità di osservare, correlare e agire sui segnali provenienti da ogni angolo dell’azienda: endpoint, dispositivi di rete, provider di identità, workload cloud e applicazioni. Un programma di rilevamento maturo non è un singolo prodotto, ma un ecosistema di pipeline di telemetria, motori di analisi, analisti umani e flussi di lavoro di risposta automatizzata, progettato per ridurre il tempo che intercorre tra la compromissione e il contenimento.
SIEM e Aggregazione Centralizzata dei Log
Una piattaforma di Security Information and Event Management (SIEM) è il tessuto connettivo del centro operativo di sicurezza (SOC). Ingerisce log da fonti eterogenee — Windows Event Logs, syslog di Linux, dati di flusso dei firewall, resolver DNS, Active Directory, agent degli endpoint, tracce di audit SaaS — li normalizza in uno schema comune e applica regole di correlazione attraverso il flusso aggregato. Il valore non risiede semplicemente nell’archiviazione; risiede nella capacità di correlare un’autenticazione VPN fallita in una fonte di log con un accesso privilegiato riuscito e un accesso SMB laterale in un’altra, producendo un singolo allarme ad alta fedeltà dove tre eventi isolati sarebbero stati solo rumore di fondo.
Piattaforme comuni includono Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security e Chronicle. In ambienti cloud, strumenti nativi come AWS CloudTrail combinato con CloudWatch e GuardDuty, o Azure Monitor con spazi di lavoro Log Analytics, fungono da spina dorsale per il logging e spesso alimentano a monte un SIEM.
Una tipica ricerca di correlazione Splunk che illustra la logica cross-source:
index=wineventlog EventCode=4625
| stats count by src_ip, user
| where count > 10
| join user [search index=vpn action=success]
| table _time, user, src_ip, count
Il tranello qui è sottile: un’organizzazione può implementare un SIEM, ingerire terabyte di dati e comunque mancare le intrusioni perché mancano fonti di log critiche. Se gli eventi di creazione di processi degli endpoint (Windows Event ID 4688 o Sysmon Event ID 1) non vengono inoltrati, o i log di “deny” del firewall vengono troncati, intere fasi dell’attacco diventano invisibili. La copertura delle fonti di log — mappata esplicitamente su un framework come MITRE ATT&CK — è un prerequisito per un rilevamento significativo.
Endpoint Detection and Response (EDR)
L’EDR estende la visibilità all’host, dove alla fine si manifesta la maggior parte dell’attività degli aggressori. A differenza degli antivirus tradizionali, che si basano sulla corrispondenza di hash di file e firme, le piattaforme EDR come CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint e Carbon Black registrano una telemetria continua: alberi dei processi, argomenti della riga di comando, modifiche al registro, connessioni di rete e caricamenti di DLL. Questi dati consentono sia il rilevamento comportamentale in tempo reale sia la caccia alle minacce (threat hunting) retrospettiva.
Un malinteso comune è trattare l’EDR come un controllo preventivo equivalente a un firewall. L’EDR principalmente rileva e assiste nella risposta: può bloccare comportamenti malevoli noti, ma il suo valore maggiore risiede nel fornire la traccia forense che permette a un analista di determinare cosa ha fatto un processo compromesso, a quali credenziali ha avuto accesso e dove si è spostato lateralmente. Le azioni di risposta come l’isolamento dell’host, la terminazione del processo e la quarantena dei file sono tipicamente avviate da un analista o da un playbook SOAR, non dal solo EDR.
IDS/IPS, Firme e Applicazione di Baseline
I sistemi di rilevamento e prevenzione delle intrusioni basati sulla rete (IDS/IPS) ispezionano il traffico confrontandolo con firme e modelli comportamentali. Un IDS (come Snort o Suricata in modalità di monitoraggio) genera allarmi su pattern sospetti; un IPS si posiziona “in-line” e blocca il traffico corrispondente. Una regola Snort per rilevare un pattern di exploit specifico dimostra la logica basata su firma:
alert tcp any any -> $HOME_NET 445 (
msg:"SMB Exploit Attempt";
content:"|ff|SMB"; offset:4; depth:4;
content:"|72 00|"; distance:0;
sid:9000001; rev:1;
)
Il rilevamento basato su anomalie stabilisce una baseline comportamentale e genera allarmi in caso di deviazioni: una workstation che improvvisamente inizia a fare query DNS a una velocità 10 volte superiore alla norma, o un server che apre per la prima volta connessioni in uscita sulla porta 4444, entrambi giustificano un’indagine indipendentemente dalla corrispondenza con una firma.
Threat Intelligence e Gestione degli Indicatori
La Threat Intelligence trasforma i dati grezzi in conoscenza attuabile sulle tattiche, tecniche e procedure (TTP) degli avversari. STIX (Structured Threat Information eXpression) è il formato standard per rappresentare gli oggetti di threat intelligence — indicatori, campagne, attori di minaccia, modelli di attacco — mentre TAXII (Trusted Automated eXchange of Indicator Information) è il protocollo di trasporto per condividerli. I feed commerciali e open-source (VirusTotal, AlienVault OTX, MISP, Recorded Future) forniscono reputazione IP, blocklist di domini, hash di file e regole YARA che possono essere ingeriti direttamente nelle piattaforme SIEM e firewall.
Gli Indicatori di Compromissione (IoC) — indirizzi IP malevoli, hash di file, nomi di dominio, chiavi di registro — sono l’intelligence più immediatamente utilizzabile ma anche la più effimera; gli aggressori cambiano rapidamente la loro infrastruttura. Gli Indicatori di Attacco (IoA) si concentrano sui comportamenti piuttosto che sugli artefatti: un processo che genera una shell figlia, un comando PowerShell codificato o un servizio creato con un nome casuale. Il rilevamento basato su IoA è più difficile da eludere perché prende di mira la tecnica, non lo strumento specifico.
Scenario Pratico: Lacuna di Rilevamento per Mancanza di Fonti di Log
Un’azienda di servizi finanziari ha implementato un SIEM e ha ingerito i log dei firewall perimetrali, i log degli eventi di sicurezza di Windows e i log del gateway di posta elettronica. Durante un’esercitazione di red team, il team ha ottenuto l’accesso iniziale tramite un’email di phishing (rilevata), ma ha poi utilizzato WMI per il movimento laterale e PowerShell remoting per l’esecuzione di comandi — nessuno dei due ha generato eventi di sicurezza di Windows nella configurazione predefinita. Il red team ha raggiunto la workstation della tesoreria e ha esfiltrato un file di bonifico simulato senza attivare un singolo allarme del SIEM dopo il rilevamento iniziale del phishing. La lacuna: Sysmon non era stato implementato, il logging dei blocchi di script PowerShell non era abilitato e il logging dell’attività WMI richiedeva una configurazione aggiuntiva. L’esercitazione ha dimostrato che la copertura del SIEM è valida solo quanto le fonti di log che lo alimentano — una lezione che deve essere convalidata attraverso esercitazioni di purple team, non data per scontata dalla documentazione del fornitore.
← Sicurezza e Architettura di Rete · Tutti i domini · Risposta agli Incidenti →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →