

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Risposta agli incidenti di sicurezza in AMS
<a name="security-incident-response"></a>

La sicurezza è la massima priorità di AWS Managed Services (AMS). AMS distribuisce risorse e controlli nei tuoi account per gestirli. AWS ha un modello di responsabilità AWS condivisa: gestisce la sicurezza del cloud e tu sei responsabile della sicurezza nel cloud. AMS protegge i tuoi dati e le tue risorse e aiuta a mantenere la tua AWS infrastruttura sicura utilizzando controlli di sicurezza e il monitoraggio attivo dei problemi di sicurezza. Queste funzionalità ti aiutano a stabilire una base di sicurezza per le applicazioni in esecuzione nel AWS cloud. AMS collabora con voi tramite Security Incident Response per valutare l'effetto e quindi effettuare misure di contenimento e correzione sulla base delle raccomandazioni delle migliori pratiche.

Quando si verifica una deviazione dalla linea di base, ad esempio a causa di un'errata configurazione o di un cambiamento di fattori esterni, è necessario rispondere e indagare. Per farlo con successo, è necessario comprendere i concetti di base di Security Incident Response all'interno del proprio ambiente AMS. È inoltre necessario comprendere i requisiti per preparare, istruire e formare i team cloud prima che si verifichino problemi di sicurezza. È importante conoscere i controlli e le funzionalità che è possibile utilizzare, preparare piani di risposta per problemi di sicurezza comuni, come la compromissione di un account utente o l'uso improprio di account privilegiati, e identificare metodi di riparazione che utilizzano l'automazione per migliorare la velocità e la coerenza di risposta. Inoltre, è necessario comprendere i requisiti normativi e di conformità relativi alla creazione di un programma di Security Incident Response per soddisfare tali requisiti.

Security Incident Response può essere complesso, ma implementando un approccio iterativo è possibile semplificare il processo e consentire al team di risposta agli incidenti di soddisfare le parti interessate delle risorse fornendo un rilevamento e una risposta tempestivi e continui. In questa guida, ti forniamo la metodologia utilizzata da AMS per la risposta agli incidenti, la matrice di responsabilità AMS (RACI), come prepararti per un evento di sicurezza, come coinvolgere AMS durante gli incidenti di sicurezza e alcuni dei runbook di risposta agli incidenti utilizzati da AMS.

# Come funziona AMS Security Incident Response
<a name="sir-how-works"></a>

AWS Managed Services si allinea alla [Guida alla gestione degli incidenti di sicurezza informatica NIST 800-61 per la risposta agli incidenti di sicurezza](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final). Allineandoci a questo standard di settore, forniamo un approccio coerente alla gestione degli eventi di sicurezza e aderiamo alle migliori pratiche per proteggere e rispondere agli incidenti di sicurezza nel tuo cloud.

![\[Ciclo di vita della risposta agli incidenti\]](http://docs.aws.amazon.com/it_it/managedservices/latest/userguide/images/sec-inc-response-1.png)


**Ciclo di vita della risposta agli incidenti**

Quando il rilevamento identifica e genera un avviso di sicurezza o richiedi assistenza per la sicurezza, il team di AWS Managed Services Operations si assicura che venga condotta un'indagine tempestiva, esegue automazioni per eseguire la raccolta, il triage e l'analisi dei dati, ti informa dell'analisi, esegue indagini e qualsiasi attività di contenimento e quindi pubblica l'analisi degli eventi.

Le attività di raccolta, triage, analisi e contenimento dei dati eseguite durante la risposta all'incidente variano a seconda del tipo di evento di sicurezza oggetto di indagine. Alla fine di questo documento sono riportati esempi di flussi di lavoro di Security Incident Response per scenari selezionati.

Durante gli incidenti, AMS determina dinamicamente la linea d'azione corretta, il che potrebbe comportare il riordino o l'aggiramento appropriato delle fasi documentate per garantire che si verifichi il risultato giusto.

# Preparazione
<a name="preparation-phase"></a>

Con l'evolversi del panorama delle minacce, AMS continua a espandere le capacità di rilevamento e risposta. Man mano che vengono aggiunti nuovi rilevamenti, AMS incorpora gli avvisi di questi nuovi rilevamenti nella piattaforma di rilevamento e risposta. I soccorritori di sicurezza AMS sono formati per indagare e collaborare con voi durante tutto il ciclo di vita del Security Incident Response.

Grazie a questo approccio basato sulla partnership, è importante che i team addetti alla sicurezza e alle applicazioni siano preparati a collaborare con AMS per gestire gli eventi di sicurezza man mano che si verificano tali eventi. Questa documentazione spiega cosa aspettarsi durante un evento di sicurezza e aiuta a prepararsi per una risposta rapida quando si verifica un incidente di sicurezza.

Questa documentazione utilizza la definizione NIST 800-61 di **evento come qualsiasi evento** osservabile in un sistema o in una rete e un **incidente** come violazione o minaccia imminente di violazione delle politiche, delle politiche di utilizzo accettabile o delle pratiche di sicurezza standard.

## Lista di controllo per la preparazione
<a name="sir-cklist"></a>

 Completa la seguente lista di controllo con il tuo AMS cloud solution delivery manager (CSDM) e l'architetto cloud AMS (CA):
+ Scopri quali carichi di lavoro vengono eseguiti in quali account.
+ Scopri quali team interni sono responsabili dei vari carichi di lavoro e etichettali in modo appropriato nei carichi di lavoro.
+ Gestisci internamente i dati di contatto di altri team che potrebbero essere necessari durante un'indagine su un evento di sicurezza e per le decisioni di contenimento.
+ Verifica che i contatti di sicurezza siano aggiornati e aggiunti a tutti gli account gestiti AWS . I contatti vengono gestiti per account.
+ Scopri come segnalare un incidente di sicurezza ad AMS e conosci la gravità e i tempi di risposta previsti.
+ Assicurati che, quando le notifiche di sicurezza vengono ricevute, vengano indirizzate alle persone e ai sistemi appropriati, come i cercapersone o il centro operativo di sicurezza.
+ Scopri quali fonti di registro sono disponibili, dove sono archiviate nei tuoi account e chi può accedervi.
+ Scopri come utilizzare CloudWatch Insights to Query Logs durante le indagini.
+ Comprendi le opzioni di contenimento disponibili per risorsa (IAMEC2, S3 e così via) e le conseguenze sulla disponibilità del carico di lavoro durante il contenimento.

# Rilevamento
<a name="sir-detect"></a>

Durante la gestione degli AWS account, AMS monitora eventuali anomalie nel comportamento degli utenti, nelle attività degli account e nei potenziali eventi di sicurezza utilizzando i dati raccolti da fonti e controlli di rilevamento, tra cui, a titolo esemplificativo ma non esaustivo, CloudWatch Amazon, GuardDuty VPC Flow Logs, Amazon Macie AWS Config e i feed interni di Amazon Threat Intelligence.

AMS utilizza sia AWS servizi nativi che altre tecnologie di rilevamento per rispondere agli eventi di sicurezza creati da:
+ Tipi di ricerca della conformità di Config
+ GuardDuty Tipi di ricerca
+ Tipi di ricerca di Macie
+ Eventi del firewall DNS di Amazon Route 53 Resolver
+ Eventi di sicurezza AMS (allarmi cloud watch)

Ulteriori risultati vengono aggiunti man mano che i servizi, i prodotti e gli ecosistemi di minacce si evolvono. 

## Segnala gli eventi di sicurezza ad AMS
<a name="sir-report"></a>

Segnala un incidente tramite l'AMS Support Portal o Supporto Center per notificare ad AMS un incidente di sicurezza o per richiedere indagini.

# Analizzare
<a name="sir-analyze"></a>

Dopo aver identificato e segnalato un evento di sicurezza, il passaggio successivo consiste nell'analizzare se l'evento segnalato è un falso positivo o un incidente reale. AMS utilizza l'automazione e le tecniche investigative manuali per gestire gli eventi di sicurezza. L'analisi include l'analisi dei log provenienti da diverse fonti di rilevamento, come i registri del traffico di rete, i registri degli host, CloudTrail gli eventi, i registri dei AWS servizi e così via. L'analisi cerca anche modelli che mostrano un comportamento anomalo per correlazione.

La collaborazione è necessaria per comprendere il contesto specifico dell'ambiente dell'account e stabilire ciò che è normale per l'account e i carichi di lavoro. Ciò consente ad AMS di identificare un'anomalia più rapidamente e di accelerare la risposta agli incidenti.

## Gestisci le comunicazioni di AMS relative agli eventi di sicurezza
<a name="sir-comms-from-ams"></a>

AMS ti tiene informato durante le indagini contattando i tuoi contatti di sicurezza tramite una segnalazione in caso di incidente. Il vostro AMS cloud service delivery manager (CSDM) e l'architetto cloud AMS (CA) sono i punti di contatto a cui rivolgervi per qualsiasi comunicazione durante un'indagine di sicurezza attiva.

La comunicazione include la notifica automatica quando viene generato un avviso di sicurezza, l'analisi della comunicazione dopo l'evento, la creazione di call bridge e la consegna continua di elementi quali file di registro, istantanee delle risorse infette e la trasmissione dei risultati delle indagini all'utente durante l'evento di sicurezza.

I campi standard inclusi nelle notifiche di avviso di sicurezza AMS sono elencati di seguito. Questi campi forniscono informazioni che consentono di indirizzare gli eventi ai team appropriati all'interno dell'organizzazione per la correzione.
+ Tipo di ricerca
+ Identificatore del ritrovamento (se pertinente)
+ Individuazione della gravità
+ Descrizione del ritrovamento
+ Individuazione della data e dell'ora di creazione
+ AWS ID dell'account
+ Regione (se pertinente)
+ AWS Risorse (IAM user/role/policy EC2, S3, EKS)

Vengono forniti campi aggiuntivi a seconda del tipo di risultato, ad esempio EKS Findings include i dettagli di Pod, Container e Cluster.

# Contenere
<a name="sir-contain"></a>

L'approccio di AMS al contenimento si basa sulla collaborazione con te. Conosci la tua attività e gli impatti sul carico di lavoro che potrebbero derivare dalle attività di contenimento, come l'isolamento della rete, il de-provisioning di utenti o ruoli IAM, la ricostruzione delle istanze e così via.

Una parte essenziale del contenimento è il processo decisionale. Ad esempio, spegnere un sistema, isolare una risorsa dalla rete o disattivare l'accesso o terminare le sessioni. Queste decisioni sono più facili da prendere se esistono strategie e procedure predeterminate per contenere l'incidente. AMS fornisce la strategia di contenimento e quindi implementa la soluzione dopo aver considerato il rischio associato all'implementazione delle azioni di contenimento.

Esistono diverse opzioni di contenimento a seconda delle risorse oggetto di analisi. AMS prevede che durante un'indagine su un incidente vengano implementati contemporaneamente più tipi di contenimento. Alcuni di questi esempi includono:
+ Applica regole di protezione per bloccare il traffico non autorizzato (gruppo di sicurezza, NACL, regole WAF, regole SCP, Deny listing, impostazione dell'azione di firma in quarantena o blocco)
+ Isolamento delle risorse
+ Isolamento di rete
+ Disabilitazione degli utenti, dei ruoli e delle politiche IAM
+ Modifica/riduzione dei privilegi di utente e ruolo IAM
+ Interruzione, sospensione, eliminazione delle risorse di calcolo
+ Limitazione dell'accesso pubblico alla risorsa interessata
+ Chiavi di accesso, chiavi API e password a rotazione
+ Eliminazione delle credenziali divulgate e delle informazioni sensibili

AMS vi incoraggia a prendere in considerazione il tipo di strategie di contenimento per ogni tipo di incidente grave che rientra nella vostra propensione al rischio, con criteri chiaramente documentati per facilitare il processo decisionale in caso di incidente. I criteri per determinare la strategia appropriata includono:
+ Potenziali danni alle risorse
+ Conservazione delle prove
+ Indisponibilità del servizio (ad esempio, connettività di rete, servizi forniti a parti esterne)
+ Tempo e risorse necessari per implementare la strategia
+ Efficacia della strategia (ad esempio, contenimento parziale, contenimento totale)
+ Permanenza della soluzione (ad esempio, decisioni relative a porte unidirezionali o porte bidirezionali)
+ Durata della soluzione (ad esempio, soluzione alternativa di emergenza da rimuovere in quattro ore, soluzione temporanea da rimuovere in due settimane, soluzione permanente).
+ Applica controlli di sicurezza attivabili per ridurre il rischio e concedi il tempo necessario per definire e implementare un contenimento più efficace. 

La velocità di contenimento è fondamentale, AMS consiglia un approccio graduale per ottenere un contenimento efficiente ed efficace attraverso strategie a breve e lungo termine.

Utilizzate questa guida per prendere in considerazione la vostra strategia di contenimento che prevede diverse tecniche in base al tipo di risorsa.
+ Strategia di contenimento
  + AMS può identificare la portata dell'incidente di sicurezza?
    + In caso affermativo, identifica tutte le risorse (utenti, sistemi, risorse).
    + In caso negativo, esaminate parallelamente all'esecuzione del passaggio successivo sulle risorse identificate.
  + La risorsa può essere isolata?
    + In caso affermativo, procedi a isolare le risorse interessate.
    + In caso negativo, collabora con i proprietari e i gestori del sistema per determinare le ulteriori azioni necessarie per contenere il problema.
  + Tutte le risorse interessate sono isolate dalle risorse non interessate?
    + In caso affermativo, procedi con il passaggio successivo.
    + In caso negativo, continuate a isolare le risorse interessate fino a raggiungere un contenimento a breve termine per evitare che l'incidente si aggravi ulteriormente.
+ Backup del sistema
  + Sono state create copie di backup dei sistemi interessati per ulteriori analisi?
  + Le copie forensi sono crittografate e archiviate in un luogo sicuro?
    + In caso affermativo, procedi con il passaggio successivo.
    + In caso negativo, crittografa le immagini forensi, quindi conservale in un luogo sicuro per evitare utilizzi accidentali, danni e manomissioni.

# Sradicare
<a name="sir-eradicate"></a>

Dopo aver contenuto un incidente, potrebbe essere necessario eliminarlo per eliminare del tutto le fonti di minaccia e proteggere il sistema prima di procedere alla fase di ripristino successiva. Le misure di eradicazione potrebbero includere l'eliminazione del malware e la rimozione degli account utente compromessi, nonché l'identificazione e la mitigazione di tutte le vulnerabilità sfruttate. Durante l'eliminazione, è importante identificare tutti gli account, le risorse e le istanze interessati all'interno dell'ambiente in modo che possano essere corretti. 

È buona norma che l'eradicazione e il ripristino avvengano secondo un approccio graduale, in modo da dare priorità alle fasi di riparazione. Per gli incidenti su larga scala, il ripristino potrebbe richiedere mesi. L'intento delle fasi iniziali deve essere quello di aumentare la sicurezza complessiva con modifiche di valore relativamente rapide (da giorni a settimane) per prevenire incidenti futuri. Le fasi successive devono concentrarsi sui cambiamenti a lungo termine (ad esempio, modifiche all'infrastruttura) e sul lavoro continuo per mantenere l'azienda il più sicura possibile.

Per alcuni incidenti, l'eradicazione non è necessaria o viene eseguita durante il recupero. 

Considera i seguenti aspetti:
+ È possibile modificare l'immagine del sistema e quindi rafforzarlo con patch o altre contromisure per prevenire o ridurre il rischio di attacchi?
+ Tutti i malware e gli altri artefatti lasciati dagli aggressori sono stati rimossi e i sistemi interessati sono protetti da ulteriori attacchi?

# Ripristino
<a name="sir-recover"></a>

AMS collabora con te per ripristinare il normale funzionamento dei sistemi, confermare che funzionino normalmente e (se applicabile) correggere le vulnerabilità per prevenire incidenti simili.

 Considera i seguenti aspetti:
+ I sistemi interessati sono aggiornati e rafforzati contro l'attacco recente e i possibili attacchi futuri?
+ In che giorno e a che ora è possibile ripristinare la produzione dei sistemi interessati?
+ Quali strumenti utilizzerete per testare, monitorare e verificare che i sistemi ripristinati in produzione non siano vulnerabili alle tecniche di attacco iniziali?

# Segnalazione post incidente
<a name="sir-post-report"></a>

Dopo l'evento, AMS esegue un processo di revisione delle indagini per tutti gli incidenti di sicurezza. Inoltre, AMS avvia un processo di correzione dell'errore (COE) per risolvere gli incidenti di sicurezza causati da un errore di sistema o procedurale che plausibilmente ha margini di miglioramento. AMS collabora con te per migliorare continuamente l'esperienza delle indagini sulla sicurezza. Il processo COE aiuta AMS a identificare i fattori che contribuiscono agli eventi che influiscono sui clienti e collega tali cause alle azioni successive, elementi che possono impedire il ripetersi di eventi simili o contribuire a mitigare la durata o il livello di impatto.

 Il processo di revisione delle indagini sugli incidenti di sicurezza affronta i seguenti elementi per identificare le opportunità di miglioramento:
+ Qual è stato il tempo trascorso dall'inizio dell'incidente alla scoperta dell'incidente, alla valutazione iniziale dell'impatto e a ciascuna fase del processo di gestione dell'incidente (ad esempio, contenimento, ripristino)?
+ Quanto tempo ha impiegato il team di risposta all'incidente per rispondere alla segnalazione iniziale dell'incidente?
+ Quanto tempo è stato necessario per eseguire un'analisi d'impatto iniziale?
+ Era evitabile e in che modo? Esiste uno strumento o un processo che avrebbe potuto impedirlo?
+ Avremmo potuto rilevarlo prima e in che modo?
+ Cosa avrebbe potuto velocizzare le indagini?
+ Sono state seguite le procedure documentate di risposta agli incidenti? Erano adeguate?
+ La condivisione delle informazioni con altre parti interessate è stata effettuata in modo tempestivo? Come potrebbe essere migliorata?
+ La collaborazione con altri team (addetti AWS alla sicurezza, agli account, al team di AWS sviluppo e al team di sicurezza dei clienti) è stata efficace? In caso contrario, cosa potrebbe essere migliorato?
+ Quali fasi preparatorie mancavano che avrebbero potuto essere utili, le matrici di escalation, i RACI, i modelli di responsabilità condivisa e così via? È necessario aggiornare qualche Runbook?
+ Qual era la differenza tra la valutazione d'impatto iniziale e la valutazione d'impatto finale? Cosa possiamo fare per migliorare l'accuratezza delle valutazioni nelle fasi iniziali della risposta all'incidente?
+ Quali sono gli elementi d'azione tratti dalle lezioni apprese?

# Runbook di risposta agli incidenti di sicurezza in AMS
<a name="sir-runbooks"></a>

Questa sezione contiene due runbook:
+ [Risposta all'attività dell'utente root](sir-root-user.md)
+ [Risposta agli eventi di malware](sir-malware.md)

# Risposta all'attività dell'utente root
<a name="sir-root-user"></a>

L'[utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) è il superutente del tuo AWS account. Tieni presente che AMS monitora l'utilizzo dei root. È consigliabile utilizzare l'utente root solo per le poche attività che lo richiedono, ad esempio modificare le impostazioni dell'account, attivare l'accesso AWS Identity and Access Management (IAM) alla fatturazione e alla gestione dei costi, modificare la password root e attivare l'autenticazione a più fattori (MFA). Per ulteriori informazioni, consulta [Attività che richiedono credenziali utente root](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).

Per ulteriori informazioni su come informare AMS dell'utilizzo root pianificato, consulta [Quando e come utilizzare l'account root in AMS](https://docs.aws.amazon.com/managedservices/latest/userguide/how-when-to-use-root.html).

Quando viene rilevata un'attività dell'utente root, sia che si tratti di tentativi falliti di accesso, che potrebbero indicare un attacco di forza bruta, sia di attività nell'account dopo un accesso riuscito, viene generato un evento e viene inviato un incidente ai contatti di sicurezza definiti.

AWS Managed Services Operations analizza le attività non pianificate degli utenti root, esegue la raccolta, il triage e l'analisi dei dati ed esegue attività di contenimento secondo le tue indicazioni, seguite dall'analisi post-evento.

Se utilizzi il modello operativo AMS Advanced, ricevi comunicazioni aggiuntive dagli ingegneri di AMS CSDM e AMS Ops che confermano l'attività non pianificata dell'utente root, dovuta alla responsabilità di AMS di proteggere le credenziali degli utenti root. AMS analizza l'attività dell'utente root fino a quando non viene confermato un percorso da seguire.

## Preparazione
<a name="sir-prepare-root"></a>

Informate AMS di qualsiasi utilizzo pianificato dell'utente root inviando una richiesta di servizio AMS con i dati e gli orari dell'evento pianificato per evitare attività di risposta agli incidenti non necessarie.

Rivolgiti periodicamente GameDays ad AMS per verificare che i processi di risposta agli incidenti dei clienti di AMS siano aggiornati, le persone e i sistemi e costruisci una memoria muscolare con le persone responsabili per ottenere una risposta più rapida agli incidenti.

## Fase A: rilevamento
<a name="sir-detect-root"></a>

AMS monitora l'attività principale negli account attraverso fonti di rilevamento, tra cui GuardDuty il monitoraggio AMS.

Se disponi di AMS Accelerate, il modello operativo risponde all'incidente richiedendo un'indagine per eventuali attività impreviste dell'utente root. Quando ciò si verifica, AMS Operations avvia il Compromised Account runbook.

Se disponi di AMS Advanced, il modello operativo risponde all'incidente o informa il CSDM di qualsiasi attività pianificata dell'utente root per chiudere un'indagine attiva sulla compromissione dell'account.

## Fase B: analisi
<a name="sir-analyze-root"></a>

AMS esegue un'indagine approfondita sugli eventi degli utenti root quando determina che l'attività non è autorizzata. Utilizzando sia le automazioni che il team di risposta alla sicurezza AMS, i log e gli eventi vengono analizzati alla ricerca di anomalie e comportamenti imprevisti per gli utenti root. I log vengono forniti per aiutare a determinare se l'attività è sconosciuta, se si tratta di un evento utente root autorizzato o se richiede ulteriori indagini.

Alcuni esempi delle informazioni fornite durante l'indagine a supporto dei controlli interni includono:
+ Informazioni sull'account: su quale account è stato utilizzato l'account root?
+ Indirizzo e-mail per l'utente root: ogni utente root è associato a un indirizzo e-mail dell'organizzazione
+ Dettagli di autenticazione: da dove e quando l'utente root ha avuto accesso al vostro ambiente?
+ Record di attività: cosa ha fatto l'utente dopo aver effettuato l'accesso come root? Questi record sono sotto forma di CloudWatch eventi. Capire come leggere questi registri aiuta nelle indagini.

È consigliabile essere pronti a ricevere le informazioni di analisi e disporre di un piano per contattare i punti di contatto autorizzati per gli account all'interno dell'organizzazione. Poiché gli utenti root non vengono nominati come individui, determinare chi ha accesso all'indirizzo di posta elettronica principale utilizzato per l'account all'interno dell'organizzazione aiuta a indirizzare rapidamente le domande all'interno dell'organizzazione. 

## Fase C: contenimento ed eliminazione
<a name="sir-eradicate-root"></a>

AMS collabora con i tuoi team di sicurezza per eseguire il contenimento seguendo le indicazioni dei tuoi contatti autorizzati per la Customer Security. Le opzioni di contenimento includono: 
+ Rotazione delle credenziali e delle chiavi appropriate.
+ Interruzione delle sessioni attive su account e risorse.
+ Eliminazione delle risorse create.

Durante le attività di contenimento, AMS collabora a stretto contatto con il vostro team di sicurezza per garantire che eventuali interruzioni dei carichi di lavoro siano ridotte al minimo e che le credenziali root siano protette in modo adeguato.

Una volta completato il piano di contenimento, collaborerai con il team operativo di AMS per tutte le azioni di ripristino necessarie.

## Rapporto successivo all'incidente
<a name="sir-post-root"></a>

Se necessario, AMS avvia il processo di revisione delle indagini per identificare le lezioni apprese. Come parte del completamento di un COE, AMS comunica tutti i risultati pertinenti ai clienti interessati per aiutarli a migliorare il processo di risposta agli incidenti.

AMS documenta tutti i dettagli finali dell'indagine, raccoglie le metriche appropriate e quindi segnala l'incidente a tutti i team interni di AMS che richiedono informazioni, compresi il CSDM e la CA assegnati.

# Risposta agli eventi di malware
<a name="sir-malware"></a>

Le EC2 istanze Amazon vengono utilizzate per ospitare una varietà di carichi di lavoro, tra cui software di terze parti e software sviluppato su misura distribuito dai team applicativi all'interno delle organizzazioni. AMS fornisce e ti incoraggia a distribuire i tuoi carichi di lavoro su immagini che vengono patchate e gestite su base continuativa da AMS.

Durante il funzionamento delle istanze, AMS monitora le anomalie nel comportamento o nell'attività attraverso una serie di controlli di rilevamento della sicurezza, tra cui Amazon, Endpoint Protection GuardDuty, Network Traffic e feed interni di Amazon sulle minacce.

I clienti AMS con il modello operativo AMS Advanced installano automaticamente il client di monitoraggio della sicurezza degli endpoint (EPS) sulle risorse assegnate. Ciò garantisce che le risorse siano monitorate e supportate 24 ore su 24, 7 giorni su 7, inclusa la creazione di un incidente di sicurezza quando viene rilevato un evento.

AMS monitora anche Malware GuardDuty Findings. Questi sono disponibili sia su AMS Advanced che su AMS Accelerate, se abilitati. Per ulteriori informazioni, consulta GuardDuty la sezione [Protezione da malware in Amazon](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection.html).

**Nota**  
Se hai optato per [Bring Your Own EPS](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-byoeps.html), la procedura di risposta agli incidenti è diversa da quella descritta in questa pagina. Per ulteriori informazioni, consulta la documentazione di riferimento.

Quando viene rilevato un malware, viene creato un incidente e l'utente riceve una notifica dell'evento. Questa notifica è seguita da tutte le attività di riparazione che si sono verificate. AMS Operations indaga, esegue la raccolta, il triage e l'analisi dei dati, quindi esegue attività di contenimento secondo le indicazioni del cliente, seguite dall'analisi post-evento.

## Fase A: Rilevamento
<a name="sir-malware-detect"></a>

AMS monitora gli eventi sulle istanze con il monitoraggio di una soluzione GuardDuty di sicurezza degli endpoint. AMS determina le attività di arricchimento e valutazione appropriate per aiutarvi a prendere decisioni di contenimento o di accettazione del rischio in base al tipo di scoperta o di avviso.

La raccolta dei dati viene eseguita in base al tipo di risultato. La raccolta dei dati prevede l'interrogazione di più fonti di dati sia all'interno che all'esterno dell'account interessato per creare un quadro dell'attività osservata o delle configurazioni che destano preoccupazione.

AMS esegue la correlazione dei risultati con altri allarmi e avvisi o telemetria provenienti da qualsiasi account interessato o piattaforma AMS di intelligence sulle minacce.

## Fase B: analisi
<a name="sir-malware-analyze"></a>

Una volta raccolti, i dati vengono analizzati per identificare eventuali attività o indicatori di preoccupazione. Durante questa fase dell'indagine, AMS collabora con voi per integrare le conoscenze aziendali e di settore relative alle istanze e ai carichi di lavoro, al fine di aiutarvi a capire cosa ci si aspetta da ciò che è fuori dall'ordinario.

Alcuni esempi delle informazioni fornite durante l'indagine a supporto dei controlli interni includono:
+ Informazioni sull'account: su quale account è stata osservata l'attività del malware?
+ Dettagli sull'istanza: Quali istanze sono implicate negli eventi relativi al malware?
+ Timestamp dell'evento: quando è scattato l'avviso?
+ Informazioni sul carico di lavoro: cosa è in esecuzione sull'istanza? 
+ Dettagli sul malware, se pertinenti: famiglie di malware e informazioni open source sul malware.
+ Dettagli sugli utenti o sui ruoli: quali utenti o ruoli sono interessati e coinvolti nell'attività?
+ Record delle attività: quali attività vengono registrate sull'istanza? Questi sono sotto forma di CloudWatch eventi ed eventi di sistema generati dall'istanza. Capire come leggere questi registri ti aiuterà nelle indagini
+ Attività di rete: quali endpoint si connettono all'istanza, a cosa si connette l'istanza e cos'è l'analisi del traffico?

È consigliabile essere pronti a ricevere informazioni sulle indagini e predisporre un piano su come contattare i punti di contatto appropriati per account, istanze e carichi di lavoro all'interno dell'organizzazione. Comprendere la topologia di rete e la connessione prevista può aiutare ad accelerare l'analisi dell'impatto. Anche la conoscenza dei test di penetrazione pianificati nell'ambiente e delle recenti implementazioni eseguite dai proprietari delle applicazioni può accelerare le indagini.

Se si determina che l'attività è pianificata e autorizzata, l'incidente viene aggiornato e l'indagine termina. Se il compromesso viene confermato, tu e AMS stabilite il piano di contenimento appropriato.

## Fase C: Contenere ed eliminare
<a name="sir-malware-eradicate"></a>

AMS collabora con te per determinare le attività di contenimento appropriate sulla base dei dati raccolti e delle informazioni note. Le opzioni di contenimento includono, a titolo esemplificativo ma non esaustivo:
+ Conservazione dei dati tramite istantanee
+ Modifica delle regole di rete per limitare il traffico in entrata o in uscita dalle istanze
+ Modifica delle policy relative agli utenti e ai ruoli di SCP, IAM per limitare l'accesso
+ Chiusura, sospensione o disattivazione delle istanze
+ Interruzione di qualsiasi connessione persistente
+ Rotazione delle credenziali/chiavi appropriate

Se scegli di eseguire l'attività di eradicazione sull'istanza, AMS ti aiuta a raggiungere tale obiettivo. Le opzioni includono, a titolo esemplificativo ma non esaustivo:
+ Rimozione di qualsiasi software indesiderato
+ Ricostruzione dell'istanza da un'immagine pulita e completamente patchata e ridistribuzione delle applicazioni e della configurazione
+ Ripristino dell'istanza da un backup precedente
+ Distribuzione di applicazioni e servizi su un'altra istanza all'interno dell'account che potrebbe essere adatta a ospitare i carichi di lavoro.

È importante determinare in che modo il malware è stato distribuito ed eseguito sull'istanza prima del ripristino del servizio per assicurarsi che vengano applicati eventuali controlli aggiuntivi per prevenire la ricomparsa del malware sull'istanza. AMS fornisce approfondimenti o informazioni aggiuntivi ai tuoi partner o team forensi, se necessario per supportare l'analisi forense.

A questo punto, collabori con AMS Operations per le attività di ripristino. AMS collabora a stretto contatto con te per ridurre al minimo le interruzioni dei carichi di lavoro e proteggere le istanze.

## Rapporto successivo all'incidente
<a name="sir-malware-post-event"></a>

Se necessario, AMS avvia il processo di revisione delle indagini per identificare le lezioni apprese. Nell'ambito del completamento di un COE, AMS vi comunica i risultati pertinenti per aiutarvi a migliorare il processo di risposta agli incidenti.

AMS documenta i dettagli finali dell'indagine, raccoglie i parametri appropriati e segnala l'incidente ai team interni di AMS che richiedono informazioni, compresi il CSDM e la CA assegnati.