Amazon SCS-C02: Rilevamento delle minacce e avvisi — Guida allo studio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Centralizzazione di GuardDuty in un’organizzazione

Amazon GuardDuty è un servizio di rilevamento continuo delle minacce che analizza gli eventi di gestione e i dati di CloudTrail, i VPC Flow Logs, i log delle query DNS, i log di audit di EKS, l’attività di login di RDS e la telemetria di runtime. Produce dei risultati (finding) classificati per scopo della minaccia (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) e per tipo di risorsa (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).

Gestire GuardDuty account per account non è una soluzione scalabile. L’architettura corretta in un ambiente AWS Organizations consiste nel designare un amministratore delegato — tipicamente l’account dedicato alla sicurezza o all’audit — utilizzando l’account di gestione di Organizations. Dall’amministratore delegato, si abilita GuardDuty a livello di organizzazione e si attiva l’abilitazione automatica (auto-enable) in modo che i nuovi account membri e le nuove Regioni siano protetti automaticamente non appena vengono creati. Senza l’abilitazione automatica, un account appena creato rimane “cieco” finché un operatore non abilita manualmente il rilevamento, che è esattamente la lacuna che gli aggressori sfruttano durante la fase di onboarding.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial gestisce un ambiente AWS multi-account che comprende 28 account per produzione, sviluppo e servizi condivisi. Il loro account di gestione governa gli altri account tramite AWS Organizations, con logging centralizzato di CloudTrail e S3, ma gli avvisi di sicurezza e i dati di indagine sono dispersi tra gli account membri, rendendo il triage degli incidenti lento e incoerente.

Sfida: Un recente rilevamento di movimento laterale in un account ha prodotto risultati di GuardDuty che non sono stati visibili abbastanza rapidamente agli strumenti centrali del SOC, ritardando il contenimento e l’indagine forense.

Approccio Raccomandato:

Designare un amministratore delegato di GuardDuty nell’account di gestione e abilitare GuardDuty in tutta l’organizzazione tramite AWS Organizations, in modo che tutti gli account membri inoltrino i risultati a un rilevatore centrale.
Attivare AWS Security Hub in modo centralizzato nell’account di gestione come aggregatore e abilitare Security Hub per tutti gli account e le regioni per normalizzare i risultati di GuardDuty insieme ad altri standard di sicurezza.
Configurare regole Amazon EventBridge nell’account di gestione per catturare i risultati di GuardDuty e Security Hub e instradarli verso destinazioni centralizzate come Amazon SNS per l’invio di avvisi, Amazon Kinesis Data Firehose verso S3 per l’archiviazione, o la consegna diretta al proprio SIEM.
Implementare dei responder Lambda attivati da EventBridge per azioni di contenimento automatizzate (ad esempio, isolare un’istanza EC2 tramite l’API di EC2 e creare un incidente in AWS Systems Manager) e contrassegnare i risultati per l’indagine.
Integrare Amazon Detective per l’indagine centralizzata e inoltrare i risultati archiviati in S3 al proprio sistema di analisi/SIEM per la correlazione e il reporting a lungo termine.

Motivazione: L’utilizzo di un amministratore delegato di GuardDuty con Security Hub ed EventBridge centralizza il rilevamento, normalizza gli avvisi e abilita risposte automatizzate e auditabili, in linea con le best practice di AWS per il rilevamento delle minacce a livello di organizzazione e una risposta tempestiva agli incidenti.

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty è un servizio Regionale, quindi la relazione di amministratore delegato e le impostazioni di abilitazione automatica devono essere stabilite in ogni Regione in cui si opera. Questa è una fonte frequente di punti ciechi: un team abilita GuardDuty in us-east-1 e presume di avere una copertura globale.

Protezioni Specifiche per Servizio

La versione base di GuardDuty copre le fonti di dati fondamentali, ma diversi piani di protezione devono essere abilitati esplicitamente perché comportano costi aggiuntivi e l’ingestione di telemetria supplementare:

RDS Protection: profila l’attività di login per i motori Aurora MySQL/PostgreSQL e RDS, generando risultati come CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin quando utenti sconosciuti si autenticano a un endpoint di un DB. Questa è la fonte corretta per rilevare accessi sospetti al database — non create filtri di metriche CloudWatch personalizzati sui log di audit del DB quando RDS Protection emette già il risultato in modo nativo.
EKS Protection: acquisisce i log di audit di Kubernetes per rilevare accessi anomali all’API, creazione di pod con privilegi elevati e l’uso di dashboard esposte.
Runtime Monitoring: installa un agente leggero basato su eBPF su EC2, ECS/Fargate o EKS per far emergere eventi di processo, file e rete — necessario per rilevare malware fileless o reverse shell in fase di esecuzione.
Malware Protection: esegue scansioni di snapshot dei volumi EBS collegati a istanze segnalate da altri risultati, o scansioni on-demand di oggetti S3 al momento del caricamento.
Lambda Protection e S3 Protection: coprono rispettivamente i pattern di invocazione delle funzioni e l’accesso al data plane di S3.

Abilitare solo il servizio di base e aspettarsi che compaiano anomalie di login al DB è una configurazione errata comune — i tipi di risultato semplicemente non vengono prodotti finché la funzionalità corrispondente non viene attivata.

Security Hub come Piano di Aggregazione

Security Hub acquisisce i risultati (finding) da GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health e prodotti ISV di terze parti, normalizzandoli nel formato AWS Security Finding Format (ASFF). Esegue anche i propri standard di conformità (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).

Per centralizzare i dati in un’Organization:

Abilita Security Hub come servizio in Organizations e designa un amministratore delegato (solitamente lo stesso account di sicurezza di GuardDuty).
Attiva l’abilitazione automatica per i nuovi account (auto-enable new accounts) in modo che i membri vengano registrati automaticamente.
Configura una Regione di aggregazione dei risultati (finding aggregation Region), chiamata anche Regione home, e collega tutte le altre Regioni ad essa. Senza l’aggregazione tra Regioni, ogni Regione mantiene un’istanza di Security Hub indipendente e gli analisti devono passare da una console all’altra.

Il pattern per un rollout globale a livello di organizzazione richiede quindi due impostazioni coordinate: il collegamento della Regione di aggregazione e l’attivazione dell’abilitazione automatica a livello di organizzazione. Abilitare l’una senza l’altra lascia i nuovi account senza copertura o le nuove Regioni isolate (siloed).

Una limitazione importante: Security Hub aggrega e assegna priorità, ma non esegue la remediation. Trattarlo come una piattaforma di remediation è un errore concettuale: la remediation avviene a valle, tramite EventBridge.

EventBridge come Tessuto di Automazione

Sia GuardDuty che Security Hub pubblicano i risultati (finding) sul bus di eventi predefinito. aws.guardduty emette eventi GuardDuty Finding, e aws.securityhub emette eventi Security Hub Findings - Imported (creati/aggiornati da Hub) e Security Hub Findings - Custom Action (attivati dall’operatore).

Regole troppo generiche come {"source": ["aws.securityhub"]} invocano i target ad ogni aggiornamento di un risultato da qualsiasi provider, inondando rapidamente i topic SNS e allertando gli ingegneri di turno (on-call) con rumore informativo. L’approccio corretto è filtrare in base ai valori di severity.Label, ProductArn, Types o Title specifici:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }],
    "type": [{ "prefix": "CredentialAccess:RDS/" }]
  }
}

Per un pattern incentrato su Security Hub che si attivi solo per i risultati di GuardDuty ad alta severità, ignorando i prodotti ISV di terze parti che generano rumore:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

I target comuni includono un topic SNS per notifiche via email/SMS/Slack, una funzione Lambda che isola un’istanza sostituendone il security group, un runbook di SSM Automation o una state machine di Step Functions che orchestra una risposta multi-step. Per il caso d’uso dell’anomalia di login su Aurora, il percorso con il minimo sforzo è: GuardDuty RDS Protection → regola EventBridge filtrata per il tipo di risultato RDS → topic SNS con sottoscrizione email. Non sono richiesti polling personalizzati, né Lambda, né SIEM di terze parti.

Azioni Personalizzate di Security Hub

Le azioni personalizzate (custom actions) sono trigger attivati da un operatore. Nella console di Security Hub, un analista seleziona uno o più risultati e sceglie un’azione personalizzata (ad esempio, “Metti in quarantena EC2”). Security Hub emette un evento Security Hub Findings - Custom Action che trasporta gli ARN dei risultati selezionati; una regola di EventBridge effettua il match sull’ARN dell’azione personalizzata e invoca una Lambda che esegue la risposta. Questo fornisce un pulsante per l’intervento umano (human-in-the-loop) senza dover costruire un’interfaccia utente su misura:

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

L’ARN risultante (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) diventa il valore di match nel campo resources della regola di EventBridge.

Soppressione e Gestione del Segnale

La gestione del rumore è una disciplina, non un filtro da applicare una tantum. Utilizza le regole di automazione di Security Hub (automation rules) o le regole di soppressione (suppression rules) di GuardDuty per archiviare automaticamente i risultati noti come benigni (ad esempio, un risultato Recon:EC2/Portscan previsto da uno strumento di penetration testing). Filtra le regole di EventBridge per ProductArn per silenziare un’integrazione di terze parti “chiacchierona” (chatty) senza disabilitarla completamente. Combina Severity.Label con Workflow.Status = NEW in modo che i risultati riaperti o già notificati non generino nuovi alert. L’obiettivo è che ogni alert che raggiunge un essere umano rappresenti un evento su cui agire (actionable) e ad alta confidenza; qualsiasi altra cosa erode la prontezza di risposta.

Pivot Investigativo

Quando si attiva un risultato ad alta severità — ad esempio, Backdoor:EC2/C&CActivity.B!DNS — il percorso investigativo più rapido non è scrivere manualmente query Athena su CloudTrail e Flow Logs. Amazon Detective, se abilitato insieme a GuardDuty, pre-costruisce grafi di entità a partire da CloudTrail, VPC Flow Logs e dai risultati di GuardDuty. Passare (pivoting) direttamente dal risultato al ruolo IAM o al profilo dell’istanza EC2 in Detective fa emergere l’attività API, i peer di rete e i conteggi delle connessioni riuscite e fallite nell’intervallo di tempo pertinente, senza alcun lavoro di query personalizzata.

← Gestione dell’identità e degli accessi · Tutti i domini · Registrazione →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →