Analisi e risposta alle minacce

Questo argomento offre indicazioni informali per aiutarti a esaminare e rispondere alle minacce, nonché a utilizzare risorse aggiuntive per aggiungere contesto ai risultati di Security Command Center. Seguire questi passaggi ti aiuta a capire cosa è successo durante un potenziale attacco e a sviluppare possibili risposte per le risorse interessate.

Non è garantito che le tecniche illustrate in questa pagina siano efficaci contro eventuali minacce precedenti, attuali o future che devi affrontare. Consulta Correzione delle minacce per capire perché Security Command Center non fornisce indicazioni ufficiali per la correzione delle minacce.

Prima di iniziare

Devi disporre di ruoli Identity and Access Management (IAM) adeguati per visualizzare o modificare risultati e log, nonché per modificare le risorse Google Cloud. Se si verificano errori di accesso in Security Command Center, chiedi assistenza all'amministratore e consulta Controllo dell'accesso per scoprire di più sui ruoli. Per risolvere gli errori delle risorse, leggi la documentazione dei prodotti interessati.

Comprensione dei risultati delle minacce

Event Threat Detection produce risultati sulla sicurezza abbinando gli eventi nei flussi dei log di Cloud Logging a indicatori di compromissione noti (IoC). Gli IoC, sviluppati da fonti di sicurezza interne di Google, identificano potenziali vulnerabilità e attacchi. Event Threat Detection rileva anche le minacce identificando tattiche, tecniche e procedure note avversarie nel flusso di logging e rilevando deviazioni dal comportamento passato della tua organizzazione o del tuo progetto. Se attivi il livello Premium di Security Command Center a livello di organizzazione, Event Threat Detection può anche analizzare i log di Google Workspace.

Container Threat Detection genera risultati raccogliendo e analizzando i comportamenti osservati di basso livello nel kernel guest dei container.

I risultati vengono scritti in Security Command Center. Se attivi il livello Premium di Security Command Center a livello di organizzazione, puoi anche configurare i risultati per la scrittura in Cloud Logging.

Esame dei risultati

Per esaminare i risultati delle minacce nella console Google Cloud, segui questi passaggi:

1. Nella console Google Cloud, vai alla pagina Risultati di Security Command Center.

   Vai a Risultati

2. Se necessario, seleziona il progetto, la cartella o l'organizzazione Google Cloud.

   

3. Nella sezione Filtri rapidi, fai clic su un filtro appropriato per visualizzare il risultato necessario nella tabella Risultati della query dei risultati. Ad esempio, se selezioni Event Threat Detection o Container Threat Detection nella sottosezione Nome visualizzato dell'origine, verranno visualizzati nei risultati solo i risultati del servizio selezionato.

   La tabella viene compilata con i risultati per l'origine selezionata.

4. Per visualizzare i dettagli di un risultato specifico, fai clic sul nome del risultato sotto Category. Il riquadro dei dettagli del risultato si espande per mostrare un riepilogo dei dettagli del risultato.

5. Per visualizzare la definizione JSON del risultato, fai clic sulla scheda JSON.

I risultati forniscono i nomi e gli identificatori numerici delle risorse coinvolte in un incidente, insieme alle variabili di ambiente e alle proprietà degli asset. Puoi utilizzare queste informazioni per isolare rapidamente le risorse interessate e determinare l'ambito potenziale di un evento.

Per facilitare l'indagine, i risultati delle minacce contengono anche link alle seguenti risorse esterne:

• voci framework MITRE ATT&CK. Il framework spiega le tecniche di attacco contro le risorse cloud e fornisce indicazioni di correzione.
• VirusTotal, un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Le sezioni seguenti descrivono le potenziali risposte alle minacce rilevate.

Disattivazione dei risultati delle minacce

Una volta risolto un problema che ha attivato il rilevamento di una minaccia, Security Command Center non imposta automaticamente lo stato del risultato su INACTIVE. Lo stato di una minaccia rilevata rimane ACTIVE, a meno che non imposti manualmente la proprietà state su INACTIVE.

In caso di falso positivo, valuta la possibilità di lasciare lo stato del risultato su ACTIVE e invece di disattivare il risultato.

Per falsi positivi persistenti o ricorrenti, crea una regola di disattivazione. L'impostazione di una regola di disattivazione può ridurre il numero di risultati da gestire, il che semplifica l'identificazione di una vera minaccia quando si verifica.

Se si tratta di una minaccia reale, prima di impostare lo stato del risultato su INACTIVE, elimina la minaccia e completa un'indagine approfondita della minaccia rilevata, della portata dell'intrusione ed eventuali altri problemi e risultati correlati.

Per disattivare un risultato o modificarne lo stato, consulta i seguenti argomenti:

• Disattiva i risultati.
• Modificare lo stato di un risultato

Risposte di Event Threat Detection

Per saperne di più su Event Threat Detection, consulta Come funziona Event Threat Detection.

Questa sezione non contiene risposte per i risultati generati dai moduli personalizzati per Event Threat Detection, perché la tua organizzazione definisce le azioni consigliate per questi rilevatori.

Evasion: Access from Anonymizing Proxy

L'accesso anomalo da un proxy anonimo viene rilevato esaminando Cloud Audit Logs per le modifiche del servizio Google Cloud che hanno avuto origine da indirizzi IP proxy anonimi, come gli indirizzi IP di Tor.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Evasion: Access from Anonymizing Proxy, come indicato in Analisi dei risultati. Si apre il riquadro dei dettagli del risultato, con la scheda Riepilogo.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche (un account potenzialmente compromesso).
     • IP: l'indirizzo IP proxy da cui vengono eseguite le modifiche.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Se vuoi, fai clic sulla scheda JSON per visualizzare altri campi dei risultati.

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Proxy: Multi-hop Proxy.
2. Contatta il proprietario dell'account nel campo principalEmail. Verifica se l'azione è stata svolta dal legittimo proprietario.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Defense Evasion: Breakglass Workload Deployment Created

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Breakglass Workload Deployment Created viene rilevato esaminando Cloud Audit Logs per vedere se esistono deployment nei carichi di lavoro che utilizzano il flag del deployment di emergenza per eseguire l'override dei controlli di Autorizzazione binaria.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Defense Evasion: Breakglass Workload Deployment Created, come indicato in Analisi dei risultati. Si apre il riquadro dei dettagli di ricerca, con la scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha eseguito la modifica.
     • Method name (Nome metodo): il metodo chiamato.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui si è verificato il deployment.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta specifica di firma del certificato.

3. Controlla le altre azioni eseguite dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore che hai annotato nel campo Nome visualizzato della risorsa nei dettagli del risultato.

   • PRINCIPAL_EMAIL: il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Defense Evasion: Breakglass Workload Deployment.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Defense Evasion: Breakglass Workload Deployment Updated

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Breakglass Workload Deployment Updated viene rilevato esaminando Cloud Audit Logs per verificare se sono presenti aggiornamenti ai carichi di lavoro che utilizzano il flag di deployment di emergenza per eseguire l'override dei controlli di Autorizzazione binaria.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Defense Evasion: Breakglass Workload Deployment Updated, come indicato in Analisi dei risultati. Si apre il riquadro dei dettagli di ricerca, con la scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha eseguito la modifica.
     • Method name (Nome metodo): il metodo chiamato.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui si è verificato l'aggiornamento.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta specifica di firma del certificato.

3. Controlla le altre azioni eseguite dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore che hai annotato nel campo Nome visualizzato della risorsa nei dettagli del risultato.

   • PRINCIPAL_EMAIL: il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Defense Evasion: Breakglass Workload Deployment.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Defense Evasion: Modify VPC Service Control

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Gli audit log vengono esaminati per rilevare modifiche ai perimetri Controlli di servizio VPC che comporterebbero una riduzione della protezione offerta da tale perimetro. Ecco alcuni esempi:

• Un progetto viene rimosso da un perimetro
• Un criterio di livello di accesso viene aggiunto a un perimetro esistente
• Uno o più servizi vengono aggiunti all'elenco dei servizi accessibili

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Defense Evasion: Modify VPC Service Control, come indicato in Analisi dei risultati. Si apre il riquadro dei dettagli del risultato, con la scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare il seguente campo:
     • Email principale: l'account che ha eseguito la modifica.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome completo risorsa: il nome del perimetro dei Controlli di servizio VPC che è stato modificato.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel file JSON, nota i seguenti campi.

   • sourceProperties
     • properties
       • name: il nome del perimetro dei Controlli di servizio VPC che è stato modificato
       • policyLink: il link al criterio di accesso che controlla il perimetro
       • delta: le modifiche, REMOVE o ADD, a un perimetro che ne ha ridotto la protezione
       • restricted_resources: i progetti che seguono le restrizioni di questo perimetro. La protezione viene ridotta se rimuovi un progetto
       • restricted_services: i servizi la cui esecuzione è vietata in base alle limitazioni di questo perimetro. La protezione viene ridotta se si rimuove un servizio limitato
       • allowed_services: i servizi autorizzati a essere eseguiti nelle restrizioni di questo perimetro. La protezione viene ridotta se si aggiunge un servizio consentito
       • access_levels: i livelli di accesso configurati per consentire l'accesso alle risorse all'interno del perimetro. La protezione viene ridotta se aggiungi altri livelli di accesso

Passaggio 2: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Trova i log delle attività di amministrazione relativi alle modifiche ai Controlli di servizio VPC utilizzando i seguenti filtri:
   • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
   • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Defense Evasion: Edit Authentication Process.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del criterio e del perimetro dei Controlli di servizio VPC.
• Valuta la possibilità di ripristinare le modifiche del perimetro fino al completamento dell'indagine.
• Valuta la possibilità di revocare i ruoli di Gestore contesto accesso per l'entità che ha modificato il perimetro fino al completamento dell'indagine.
• Esamina come sono state utilizzate le protezioni ridotte. Ad esempio, se "API BigQuery Data Transfer Service" è abilitata o aggiunta come servizio consentito, controlla chi ha iniziato a utilizzare il servizio e cosa sta trasferendo.

Discovery: Can get sensitive Kubernetes object check

Un utente potenzialmente malintenzionato ha tentato di determinare per quali oggetti sensibili in GKE può eseguire query utilizzando il comando kubectl auth can-i get. Nello specifico, l'attore ha eseguito uno dei seguenti comandi:

• kubectl auth can-i get '*'
• kubectl auth can-i get secrets
• kubectl auth can-i get clusterroles/cluster-admin

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Discovery: Can get sensitive Kubernetes object check come diretto in Controllo dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi:

   • In Che cosa è stato rilevato:
     • Revisioni degli accessi a Kubernetes: le informazioni sulla revisione degli accessi richieste, in base alla risorsa k8s SelfSubjectAccessReview.
     • Email principale: l'account che ha effettuato la chiamata.
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Nella sezione Link correlati:
     • URI Cloud Logging: link alle voci di Logging.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Nella pagina caricata, verifica se esistono altre azioni eseguite dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore che hai annotato nel campo Nome visualizzato della risorsa nei dettagli del risultato.

   • PRINCIPAL_EMAIL: il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Discovery.
2. Conferma la sensibilità dell'oggetto oggetto della query e determina se nei log sono presenti altri segni di attività dannosa dell'entità.

3. Se l'account che hai indicato nella riga Email principale dei dettagli di individuazione non è un account di servizio, contatta il proprietario dell'account per verificare se il proprietario legittimo abbia svolto l'azione.

   Se l'email principale è un account di servizio (IAM o Kubernetes), identifica l'origine della revisione dell'accesso per stabilirne la legittimità.

4. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Exfiltration: BigQuery Data Exfiltration

I risultati restituiti da Exfiltration: BigQuery Data Exfiltration contengono una delle due possibili regole secondarie. Ogni regola secondaria ha una gravità diversa:

• Regola secondaria exfil_to_external_table con gravità = HIGH:
  • Una risorsa è stata salvata al di fuori della tua organizzazione o del tuo progetto.
• Regola secondaria vpc_perimeter_violation con gravità = LOW:
  • I Controlli di servizio VPC hanno bloccato un'operazione di copia o un tentativo di accesso alle risorse BigQuery.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Exfiltration: BigQuery Data Exfiltration, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli dei risultati, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato:
     • Gravità: la gravità è HIGH per la regola secondaria exfil_to_external_table o LOW per la regola secondaria vpc_perimeter_violation.
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui sono stati esfiltrati i dati.
     • Destinazioni di esfiltrazione: dettagli sulle tabelle in cui sono stati archiviati i dati esfiltrati.
   • Risorsa interessata:
     • Nome completo risorsa: il nome completo della risorsa del progetto, della cartella o dell'organizzazione da cui sono stati esfiltrati i dati.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
     • Chronicle: link a Chronicle.

3. Fai clic sulla scheda Proprietà sorgente ed esamina i campi visualizzati, in particolare:

   • detectionCategory:
     • subRuleName: exfil_to_external_table o vpc_perimeter_violation.
   • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • properties
     • dataExfiltrationAttempt
       • jobLink: il link al job BigQuery che ha esfiltrato i dati.
       • query: la query SQL viene eseguita sul set di dati BigQuery.

4. Se vuoi, fai clic sulla scheda JSON per visualizzare l'elenco completo delle proprietà JSON del risultato.

Passaggio 2: indaga in Chronicle

Puoi utilizzare Chronicle per analizzare questa scoperta. Chronicle è un servizio Google Cloud che ti consente di analizzare le minacce ed esplorare le entità correlate in una cronologia unificata. Chronicle arricchisce i dati dei risultati, consentendoti di identificare gli indicatori di interesse e semplificare le indagini.

Puoi utilizzare Chronicle solo se attivi Security Command Center a livello di organizzazione.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato di origine, seleziona Event Threat Detection.

   La tabella viene compilata con i risultati di Event Threat Detection.

4. Nella tabella, sotto category, fai clic su un risultato Exfiltration: BigQuery Data Exfiltration. Si apre il riquadro dei dettagli del risultato.

5. Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Indaga in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Chronicle.

Utilizza le seguenti guide per condurre indagini in Chronicle:

• Esaminare un utente
• Esaminare una risorsa

Passaggio 3: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina IAM .

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel codice JSON trovato.

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato in Email principale e controlla quali autorizzazioni sono assegnate all'account.

Passaggio 4: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Trova i log delle attività di amministrazione relativi ai job BigQuery utilizzando i seguenti filtri:

   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 5: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per userEmail fino al termine dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati (exfiltration.sources e exfiltration.targets).
• Per analizzare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare dati di Sensitive Data Protection a Security Command Center. A seconda della quantità di informazioni, i costi di Sensitive Data Protection possono essere significativi. Segui le best practice per mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Exfiltration: BigQuery Data Extraction

L'esfiltrazione di dati da BigQuery viene rilevata esaminando gli audit log per due scenari:

• Una risorsa viene salvata in un bucket Cloud Storage all'esterno della tua organizzazione.
• Una risorsa viene salvata in un bucket Cloud Storage accessibile pubblicamente di proprietà della tua organizzazione.

Per le attivazioni del livello Premium di Security Command Center a livello di progetto, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: BigQuery Data Extraction, come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo del riquadro dei dettagli dei risultati, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui sono stati esfiltrati i dati.
     • Destinazioni di esfiltrazione: dettagli sulle tabelle in cui sono stati archiviati i dati esfiltrati.
   • Risorsa interessata:
     • Nome completo risorsa: il nome della risorsa BigQuery i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Nel riquadro dei dettagli del risultato, fai clic sulla scheda JSON.

4. Nel file JSON, nota i seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
     • properties:
       • extractionAttempt:
       • jobLink: il link al job BigQuery che ha esfiltrato i dati

Passaggio 2: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina IAM .

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel codice JSON trovato (nel passaggio 1).

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato in Email principale (dal Passaggio 1) e controlla quali autorizzazioni sono assegnate all'account.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Trova i log delle attività di amministrazione relativi ai job BigQuery utilizzando i seguenti filtri:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati nella scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per l'entità elencata nella riga Email principale della scheda Riepilogo dei dettagli del risultato fino al completamento dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati identificati nel campo Origini di esfiltrazione della scheda Riepilogo dei dettagli di ricerca.
• Per analizzare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare dati di Sensitive Data Protection a Security Command Center. A seconda della quantità di informazioni, i costi di Sensitive Data Protection possono essere significativi. Segui le best practice per mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Se sei il proprietario del bucket, valuta la possibilità di revocare le autorizzazioni di accesso pubblico.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Exfiltration: BigQuery Data to Google Drive

L'esfiltrazione di dati da BigQuery viene rilevata esaminando gli audit log per il seguente scenario:

• Una risorsa viene salvata in una cartella di Google Drive.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: BigQuery Data to Google Drive, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, tra cui:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulla tabella BigQuery da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli della destinazione in Google Drive.
   • Risorsa interessata, tra cui:
     • Nome completo risorsa: il nome della risorsa BigQuery i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • Link correlati, tra cui:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Per ulteriori informazioni, fai clic sulla scheda JSON.

4. Nel file JSON, nota i seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
     • properties:
       • extractionAttempt:
       • jobLink: il link al job BigQuery che ha esfiltrato i dati

Passaggio 2: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina IAM .

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel codice JSON trovato (nel passaggio 1).

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato in access.principalEmail (dal Passaggio 1) e controlla quali autorizzazioni sono assegnate all'account.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Trova i log delle attività di amministrazione relativi ai job BigQuery utilizzando i seguenti filtri:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per l'entità nel campo access.principalEmail fino al completamento dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati (exfiltration.sources).
• Per analizzare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare dati di Sensitive Data Protection a Security Command Center. A seconda della quantità di informazioni, i costi di Sensitive Data Protection possono essere significativi. Segui le best practice per mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Exfiltration: Cloud SQL Data Exfiltration

L'esfiltrazione di dati da Cloud SQL viene rilevata esaminando gli audit log per due scenari:

• Dati dell'istanza live esportati in un bucket Cloud Storage esterno all'organizzazione.
• Dati dell'istanza live esportati in un bucket Cloud Storage di proprietà dell'organizzazione e accessibili pubblicamente.

Sono supportati tutti i tipi di istanza Cloud SQL.

Per le attivazioni del livello Premium di Security Command Center a livello di progetto, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: Cloud SQL Data Exfiltration, come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale : l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sull'istanza Cloud SQL i cui dati sono stati esfiltrati.
     • Destinazioni di esfiltrazione: dettagli sul bucket Cloud Storage in cui sono stati esportati i dati.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa Cloud SQL di cui sono stati esfiltrati i dati.
     • Nome completo del progetto: il progetto Google Cloud che contiene i dati di Cloud SQL di origine.
   • Link correlati, tra cui:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel JSON del risultato, nota i seguenti campi:

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene l'istanza Cloud SQL di origine.
     • properties
     • bucketAccess: se il bucket Cloud Storage è accessibile pubblicamente o esterno all'organizzazione
     • exportScope: quantità di dati esportati, ad esempio l'intera istanza, uno o più database, una o più tabelle o un sottoinsieme specificato da una query)

Passaggio 2: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina IAM .

   Vai a IAM

2. Se necessario, seleziona il progetto dell'istanza elencato nel campo projectId nel codice JSON del risultato (nel passaggio 1).

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato nella riga Email principale nella scheda Riepilogo dei dettagli del risultato (dal Passaggio 1). Controlla quali autorizzazioni sono assegnate all'account.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging (dal passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza Cloud SQL pertinente.

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati descritto nel Passaggio 1. I risultati correlati hanno lo stesso tipo di risultato nella stessa istanza Cloud SQL.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per access.principalEmail fino al termine dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi alle istanze Cloud SQL interessate.
  • MySQL
  • PostgreSQL
  • SQL Server
• Per limitare l'accesso e l'esportazione dall'API Cloud SQL Admin, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Exfiltration: Cloud SQL Restore Backup to External Organization

L'esfiltrazione di dati da un backup di Cloud SQL viene rilevata esaminando gli audit log per determinare se i dati del backup sono stati ripristinati in un'istanza Cloud SQL esterna all'organizzazione o al progetto. Sono supportati tutti i tipi di istanze e backup di Cloud SQL.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: Cloud SQL Restore Backup to External Organization, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sull'istanza Cloud SQL da cui è stato creato il backup.
     • Destinazioni di esfiltrazione: dettagli sull'istanza Cloud SQL in cui sono stati ripristinati i dati di backup.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa del backup che è stato ripristinato.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL da cui è stato creato il backup.

3. Link correlati, in particolare i seguenti campi:

   • URI Cloud Logging: link alle voci di Logging.
   • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
   • Risultati correlati: link ai risultati correlati.

4. Fai clic sulla scheda JSON.

5. Nel file JSON, nota i seguenti campi.

   • resource:
     • parent_name: nome risorsa dell'istanza Cloud SQL da cui è stato creato il backup
   • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • properties:
     • restoreToExternalInstance:
       • backupId: l'ID dell'esecuzione del backup ripristinata

Passaggio 2: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina IAM .

   Vai a IAM

2. Se necessario, seleziona il progetto dell'istanza elencato nel campo projectId nel codice JSON del risultato (dal Passaggio 1).

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato in Email principale (dal Passaggio 1) e controlla quali autorizzazioni sono assegnate all'account.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nell'URI di Cloud Logging (dal passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza Cloud SQL pertinente.

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati. (dal Passaggio 1). I risultati correlati hanno lo stesso tipo di risultato sulla stessa istanza Cloud SQL.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con dati esfiltrati.
• Potresti revocare le autorizzazioni per l'entità elencata nella riga Email principale della scheda Riepilogo dei dettagli del risultato fino al completamento dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi alle istanze Cloud SQL interessate.
  • MySQL
  • PostgreSQL
  • SQL Server
• Per limitare l'accesso all'API Cloud SQL Admin, utilizza i Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Exfiltration: Cloud SQL Over-Privileged Grant

Rileva quando tutti i privilegi su un database PostgreSQL (o tutte le funzioni o le procedure in un database) vengono concessi a uno o più utenti del database.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Exfiltration: Cloud SQL Over-Privileged Grant, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza PostgreSQL di Cloud SQL interessata.
     • Nome utente database: l'utente PostgreSQL che ha concesso privilegi in eccesso.
     • Query di database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari del database: i beneficiari dei privilegi overbroad.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza Cloud SQL PostgreSQL interessata.
     • Nome completo padre: il nome della risorsa dell'istanza PostgreSQL di Cloud SQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza PostgreSQL di Cloud SQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: rivedi i privilegi del database

1. Connettiti al database PostgreSQL.
2. Elenca e mostra i privilegi di accesso per:
   • Database. Utilizza il metacomando \l o \list e controlla quali privilegi vengono assegnati per il database elencato in Nome visualizzato del database (dal passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e verifica quali privilegi vengono assegnati per le funzioni o le procedure nel database elencato in Nome visualizzato del database (dal Passaggio 1).

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nell'URI di Cloud Logging (dal passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. In Esplora log, controlla i log pgaudit di PostgreSQL, che registrano le query eseguite nel database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario dell'istanza con concessioni con privilegi in eccesso.
• Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari del database fino al completamento dell'indagine.
• Per limitare l'accesso al database (da Nome visualizzato del database del Passaggio 1, revoke le autorizzazioni non necessarie dei beneficiari (dai Beneficiari del database del Passaggio 1).

Initial Access: Database Superuser Writes to User Tables

Rileva quando l'account super user del database Cloud SQL (postgres per PostgreSQL e root per MySQL) scrive nelle tabelle utente. In genere, il super user (un ruolo con accesso molto ampio) non deve essere utilizzato per scrivere nelle tabelle utente. Per la normale attività quotidiana, si deve usare un account utente con accesso più limitato. Quando un super user scrive in una tabella utente, ciò potrebbe indicare che un utente malintenzionato ha aumentato i privilegi o ha compromesso l'utente predefinito del database e sta modificando i dati. Potrebbe indicare anche pratiche normali ma non sicure.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Initial Access: Database Superuser Writes to User Tables, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza Cloud SQL PostgreSQL o MySQL interessata.
     • Nome utente del database: il super user.
     • Query di database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza Cloud SQL interessata.
     • Nome completo padre: il nome della risorsa dell'istanza Cloud SQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in cloudLoggingQueryURI (dal passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. Controlla i log per gli audit log PostgreSQL o gli audit log di Cloud SQL per MySQL, che contengono le query eseguite dal super user, utilizzando i seguenti filtri:
   • protoPayload.request.user="SUPERUSER"

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Controlla gli utenti autorizzati a connettersi al database.

  • Per PostgreSQL, consulta Creazione e gestione degli utenti
  • Per MySQL, consulta Gestire gli utenti con l'autenticazione integrata

• Valuta la possibilità di cambiare la password dell'utente avanzato.

  • Per PostgreSQL, consulta Impostare la password per l'utente predefinito
  • Per MySQL, consulta Impostare la password per l'utente predefinito

• Valuta la possibilità di creare un nuovo utente con accesso limitato per i diversi tipi di query utilizzati nell'istanza.

  • Concedi al nuovo utente solo le autorizzazioni necessarie per eseguire le sue query.

    • Per PostgreSQL, consulta Concedi (comando)
    • Per MySQL, consulta Controllo dell'accesso e gestione dell'account

  • Aggiorna le credenziali per i client che si connettono all'istanza Cloud SQL

Initial Access: Anonymous GKE resource created from the internet

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando un aggressore potenzialmente dannoso ha utilizzato uno dei seguenti utenti o gruppi di utenti predefiniti di Kubernetes per creare una nuova risorsa Kubernetes nel cluster:

• system:anonymous
• system:authenticated
• system:unauthenticated

Questi utenti e gruppi sono effettivamente anonimi. Un'associazione di controllo dell'accesso basato su ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione per creare le risorse nel cluster.

Esamina la risorsa creata e l'associazione RBAC associata per assicurarti che l'associazione sia necessaria. Se l'associazione non è necessaria, rimuovila. Per ulteriori dettagli, vedi il messaggio di log relativo a questo risultato.

Per limitare questo problema, vedi Evitare ruoli e gruppi predefiniti.

Initial Access: GKE resource modified anonymously from the internet

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando un utente potenzialmente dannoso ha utilizzato uno dei seguenti utenti o gruppi di utenti Kubernetes predefiniti per modificare una risorsa Kubernetes nel cluster:

• system:anonymous
• system:authenticated
• system:unauthenticated

Questi utenti e gruppi sono effettivamente anonimi. Un'associazione di controllo dell'accesso basato su ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione per modificare le risorse nel cluster.

Esamina la risorsa modificata e l'associazione RBAC associata per assicurarti che l'associazione sia necessaria. Se l'associazione non è necessaria, rimuovila. Per ulteriori dettagli, vedi il messaggio di log relativo a questo risultato.

Per limitare questo problema, vedi Evitare ruoli e gruppi predefiniti.

Initial Access: Dormant Service Account Action

Rileva gli eventi in cui un account di servizio gestito dall'utente inattivo ha attivato un'azione. In questo contesto, un account di servizio viene considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Initial Access: Dormant Service Account Action, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'account di servizio inattivo che ha eseguito l'azione.
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui ha eseguito l'accesso dall'account di servizio.
   • Method name (Nome metodo): il metodo chiamato

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Utilizza gli strumenti per l'account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza dovrebbe identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Initial Access: Dormant Service Account Key Created

Rileva gli eventi in cui viene creata una chiave dormiente dell'account di servizio gestito dall'utente. In questo contesto, un account di servizio viene considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Initial Access: Dormant Service Account Key Created, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha creato la chiave dell'account di servizio.

   In Risorsa interessata:

   • Nome visualizzato della risorsa: la chiave dell'account di servizio inattivo appena creata
   • Nome completo del progetto: il progetto in cui si trova l'account di servizio inattivo

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Utilizza gli strumenti per l'account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'Email principale se è stata compromessa.
• Annulla la chiave dell'account di servizio appena creata nella pagina Account di servizio.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza dovrebbe identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Initial Access: Leaked Service Account Key Used

Rileva gli eventi in cui una chiave dell'account di servizio divulgata viene utilizzata per autenticare l'azione. In questo contesto, una chiave dell'account di servizio divulgata è una chiave che è stata pubblicata sulla rete internet pubblica. Ad esempio, le chiavi degli account di servizio vengono spesso pubblicate per errore nel repository GitHub pubblico.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Initial Access: Leaked Service Account Key Used, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'account di servizio utilizzato in questa azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui ha eseguito l'accesso dall'account di servizio.
   • Method name (Nome del metodo): il nome del metodo dell'azione.
   • Nome chiave account di servizio: la chiave dell'account di servizio divulgata utilizzata per autenticare questa azione
   • Descrizione: la descrizione di ciò che è stato rilevato, inclusa la posizione sulla rete internet pubblica in cui è possibile trovare la chiave dell'account di servizio

   In Risorsa interessata:

   • Nome visualizzato della risorsa: la risorsa interessata nell'azione.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto o l'organizzazione.

3. Nella pagina caricata, trova i log correlati utilizzando il seguente filtro:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"

   Sostituisci PRINCIPAL_EMAIL con il valore che hai annotato nel campo Email principale nei dettagli del risultato. Sostituisci SERVICE_ACCOUNT_KEY_NAME con il valore che hai annotato nel campo Nome chiave dell'account di servizio nei dettagli del risultato.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Revoca subito la chiave dell'account di servizio nella pagina Account di servizio.
• Rimuovi la pagina web o il repository GitHub in cui è pubblicata la chiave dell'account di servizio.
• Valuta la possibilità di eliminare l'account di servizio compromesso.
• Ruota ed elimina tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima dell'eliminazione, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.

Initial Access: Excessive Permission Denied Actions

Rileva gli eventi in cui un'entità attiva ripetutamente errori di autorizzazione negata in più metodi e servizi.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Initial Access: Excessive Permission Denied Actions, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'entità che ha attivato più errori di autorizzazione negata.
   • Nome servizio: il nome API del servizio Google Cloud su cui si è verificato l'ultimo errore di autorizzazione negata
   • Nome metodo: il metodo richiamato quando si è verificato l'ultimo errore di autorizzazione negata

3. Nei dettagli del risultato, nella scheda Proprietà sorgente, prendi nota dei valori dei seguenti campi nel codice JSON:

   • properties.failedActions: gli errori relativi all'autorizzazione negata che si sono verificati. Per ogni voce, i dettagli includono il nome del servizio, il nome del metodo, il numero di tentativi non riusciti e l'ora dell'ultimo errore. Sono visualizzate al massimo 10 voci.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella barra degli strumenti della console Google Cloud, seleziona il tuo progetto.

3. Nella pagina caricata, trova i log correlati utilizzando il seguente filtro:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.status.code=7

   Sostituisci PRINCIPAL_EMAIL con il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario dell'account nel campo Email principale. Verificare se l'azione sia stata eseguita dal legittimo proprietario.
• Elimina le risorse del progetto create da quell'account, ad esempio istanze di Compute Engine non familiari, snapshot, account di servizio, utenti IAM e così via.
• Contatta il proprietario del progetto con l'account e potresti eliminare o disabilitare l'account.

Brute Force: SSH

Rilevamento della forza bruta di SSH su un host riuscito. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Brute Force: SSH, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • IP chiamante: l'indirizzo IP che ha lanciato l'attacco.
     • Nome utente: l'account che ha eseguito l'accesso.

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
     • Chronicle: link a Chronicle.

3. Fai clic sulla scheda JSON.

4. Nel file JSON, nota i seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId: ID progetto e timestamp per identificare la voce di log
       • projectId: il progetto che contiene il risultato
     • properties:
       • attempts:
       • Attempts: il numero di tentativi di accesso.
         • username: l'account che ha eseguito l'accesso
         • vmName: il nome della macchina virtuale
         • authResult: risultato dell'autenticazione SSH

Passaggio 2: indaga in Chronicle

Puoi utilizzare Chronicle per analizzare questa scoperta. Chronicle è un servizio Google Cloud che ti consente di analizzare le minacce ed esplorare le entità correlate in una cronologia facile da usare. Chronicle arricchisce i dati dei risultati, consentendoti di identificare gli indicatori di interesse e semplificare le indagini.

Puoi utilizzare Chronicle solo se attivi Security Command Center a livello di organizzazione.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato di origine, seleziona Event Threat Detection.

   La tabella viene compilata con i risultati per il tipo di origine selezionato.

4. Nella tabella, sotto category, fai clic su un risultato Brute Force: SSH. Si apre il riquadro dei dettagli del risultato.

5. Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Indaga in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Chronicle.

Utilizza le seguenti guide per condurre indagini in Chronicle:

• Esaminare un utente
• Esaminare un indirizzo IP
• Esaminare una risorsa

Passaggio 3: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla Dashboard.

   Vai alla dashboard

2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, seleziona il progetto elencato in projectId.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM che corrisponde al nome e alla zona in vmName. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disabilita le regole firewall eccessivamente permissive sulla porta 22.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella pagina caricata, trova i log di flusso VPC relativi all'indirizzo IP elencato nella riga Email principale nella scheda Riepilogo dei dettagli del risultato utilizzando il seguente filtro:
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Passaggio 5: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Account validi: Account locali.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il tentativo di forza bruta riuscito.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e disattivazione degli endpoint.
• Valuta la possibilità di disabilitare l'accesso SSH alla VM. Per informazioni sulla disattivazione delle chiavi SSH, consulta Limitazione delle chiavi SSH dalle VM. Questo passaggio potrebbe interrompere l'accesso autorizzato alla VM, quindi considera le esigenze della tua organizzazione prima di procedere.
• Utilizza solo l'autenticazione SSH con chiavi autorizzate.
• Blocca gli indirizzi IP dannosi aggiornando le regole firewall o utilizzando Google Cloud Armor. Puoi abilitare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda della quantità di informazioni, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.

Credential Access: External Member Added To Privileged Group

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Rileva quando un membro esterno viene aggiunto a un gruppo Google con privilegi (un gruppo a cui sono stati concessi ruoli o autorizzazioni sensibili). Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato di Credential Access: External Member Added To Privileged Group, come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Nel riquadro dei dettagli, fai clic sulla scheda JSON.

4. Nel file JSON, nota i seguenti campi.

   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • externalMember: il membro esterno appena aggiunto
   • sensitiveRoles: i ruoli sensibili associati a questo gruppo

Passaggio 2: esamina i membri del gruppo

1. Vai a Google Gruppi.

   Vai a Google Gruppi

2. Fai clic sul nome del gruppo da esaminare.

3. Nel menu di navigazione, fai clic su Membri.

4. Se il membro esterno appena aggiunto non deve far parte di questo gruppo, fai clic sulla casella di controllo accanto al nome del membro, quindi seleziona Rimuovi membro o Escludi membro.

   Per rimuovere membri o rimuovere membri, devi essere un amministratore di Google Workspace o devi disporre del ruolo Proprietario o Gestore nel gruppo Google. Per maggiori informazioni, vedi Assegnare ruoli ai membri di un gruppo.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Se necessario, seleziona il tuo progetto.

   

3. Nella pagina visualizzata, controlla i log per le modifiche relative all'appartenenza ai gruppi Google utilizzando i seguenti filtri:

   • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati dell'indagine con la ricerca MITRE.

Credential Access: Privileged Group Opened To Public

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Rileva quando un gruppo Google con privilegi (ovvero un gruppo a cui sono stati concessi ruoli o autorizzazioni sensibili) viene modificato per essere accessibile al pubblico. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato di Credential Access: Privileged Group Opened To Public, come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche, che potrebbe essere compromesso.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel file JSON, nota i seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • sensitiveRoles: i ruoli sensibili associati a questo gruppo
   • whoCanJoin: l'impostazione di partecipazione del gruppo

Passaggio 2: esamina le impostazioni di accesso del gruppo

1. Vai alla Console di amministrazione per Google Gruppi. Devi essere un amministratore di Google Workspace per accedere alla console.

   Vai alla Console di amministrazione

2. Nel riquadro di navigazione, fai clic su Directory e seleziona Gruppi.

3. Fai clic sul nome del gruppo da esaminare.

4. Fai clic su Impostazioni di accesso e, in Chi può iscriversi al gruppo, esamina l'impostazione di partecipazione al gruppo.

5. Nel menu a discesa, se necessario, modifica l'impostazione relativa alla partecipazione.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Se necessario, seleziona il tuo progetto.

   

3. Nella pagina visualizzata, controlla i log relativi alle modifiche alle impostazioni di Google Gruppi utilizzando i seguenti filtri:

   • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati dell'indagine con la ricerca MITRE.

Credential Access: Secrets Accessed in Kubernetes Namespace

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando l'defaultaccount di servizio Kubernetes di un pod è stato utilizzato per accedere agli oggetti Secret nel cluster. L'account di servizio Kubernetes default non dovrebbe avere accesso agli oggetti Secret, a meno che tu non l'abbia concesso esplicitamente con un oggetto Role o un oggetto ClusterRole.

Credential Access: Sensitive Role Granted To Hybrid Group

Rileva quando vengono concessi ruoli o autorizzazioni sensibili a un gruppo Google con membri esterni. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato di Credential Access: Sensitive Role Granted To Hybrid Group, come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche, che potrebbe essere compromesso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: la risorsa in cui è stato concesso il nuovo ruolo.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel file JSON, nota i seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • bindingDeltas: i ruoli sensibili appena concessi a questo gruppo.

Passaggio 2: esamina le autorizzazioni del gruppo

1. Vai alla pagina IAM nella console Google Cloud.

   Vai a IAM

2. Nel campo Filtro, inserisci il nome dell'account indicato in groupName.

3. Esamina i ruoli sensibili concessi al gruppo.

4. Se il ruolo sensibile appena aggiunto non è necessario, revocalo.

   Devi disporre di autorizzazioni specifiche per gestire i ruoli nella tua organizzazione o nel tuo progetto. Per ulteriori informazioni, consulta la sezione Autorizzazioni richieste.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Se necessario, seleziona il tuo progetto.

   

3. Nella pagina visualizzata, controlla i log relativi alle modifiche alle impostazioni di Google Gruppi utilizzando i seguenti filtri:

   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati dell'indagine con la ricerca MITRE.

Malware: Cryptomining Bad IP

Il malware viene rilevato esaminando i log di flusso VPC e Cloud DNS per le connessioni a indirizzi IP e domini di comando e controllo noti. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Malware: Cryptomining Bad IP, come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • IP di origine: l'indirizzo IP di cryptomining sospetto.
     • Porta di origine: la porta di origine della connessione, se disponibile.
     • IP di destinazione: l'indirizzo IP di destinazione.
     • Porta di destinazione: la porta di destinazione della connessione, se disponibile.
     • Protocollo: il protocollo IANA associato alla connessione.
   • Risorsa interessata
   • Link correlati, tra cui i seguenti campi:
     • URI di Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda Proprietà sorgente.

4. Espandi le proprietà e annota i valori di progetto e istanza nel seguente campo:

   • instanceDetails: prendi nota sia dell'ID progetto sia del nome dell'istanza Compute Engine. L'ID progetto e il nome dell'istanza vengono visualizzati come mostrato nell'esempio seguente:

     /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

5. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina Dashboard.

   Vai alla dashboard

2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, seleziona il progetto elencato in properties_project_id.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM che corrisponde a properties_sourceInstance. Indaga sull'istanza potenzialmente compromessa alla ricerca di malware.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disabilita le regole firewall eccessivamente permissive.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il tuo progetto.

3. Nella pagina visualizzata, trova i log di flusso VPC relativi a Properties_ip_0 utilizzando il seguente filtro:

   • logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
   • (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Compromissione delle risorse.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto contenente malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole firewall o utilizzando Google Cloud Armor. Puoi abilitare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda del volume dei dati, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.

Initial Access: Log4j Compromise Attempt

Questo risultato viene generato quando vengono rilevate lookups Java Naming and Directory Interface (JNDI) all'interno delle intestazioni o dei parametri URL. Queste ricerche potrebbero indicare tentativi di sfruttamento di Log4Shell. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Initial Access: Log4j Compromise Attempt, come indicato in Esaminare i dettagli del risultato. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
   • Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.

   • Nel file JSON, nota i seguenti campi.

   • properties

     • loadBalancerName: nome del bilanciatore del carico che ha ricevuto la ricerca JNDI
     • requestUrl: l'URL della richiesta HTTP. Se presente, contiene una ricerca JNDI.
     • requestUserAgent: lo user agent che ha inviato la richiesta HTTP. Se presente, contiene una ricerca JNDI.
     • refererUrl: l'URL della pagina che ha inviato la richiesta HTTP. Se presente, contiene una ricerca JNDI.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging del passaggio 1.

2. Nella pagina caricata, controlla i campi httpRequest per verificare la presenza di token stringa come ${jndi:ldap:// che potrebbero indicare possibili tentativi di sfruttamento.

   Consulta CVE-2021-44228: rilevare l'exploit di Log4Shell nella documentazione di Logging per visualizzare le stringhe di esempio in cui cercare e per una query di esempio.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exploit Public-Facing Application.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Esegui l'upgrade alla versione più recente di Log4j2.
• Segui i suggerimenti di Google Cloud per analizzare e rispondere alla vulnerabilità "Apache Log4j 2" {: target="blog" track-type="tasks" track-name="blogLink"}
• Implementa le tecniche di mitigazione consigliate nelle vulnerabilità di sicurezza di Apache Log4j
• Se utilizzi Google Cloud Armor, esegui il deployment di cve-canary rule in un criterio di sicurezza di Google Cloud Armor nuovo o esistente. Per maggiori informazioni, consulta Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j

Active Scan: Log4j Vulnerable to RCE

Gli scanner di vulnerabilità Log4j supportati inseriscono ricerche JNDI offuscate in parametri HTTP, URL e campi di testo con callback ai domini controllati dagli scanner. Questo risultato viene generato quando vengono trovate query DNS per i domini non offuscati. Queste query vengono eseguite solo se una ricerca JNDI ha avuto esito positivo, indicando una vulnerabilità di Log4j attiva. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Active Scan: Log4j Vulnerable to RCE, come indicato nella sezione Esaminare i dettagli del risultato. Il riquadro dei dettagli del risultato si apre sulla scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato
   • Risorsa interessata, in particolare il seguente campo:
     • Nome completo risorsa: il nome completo della risorsa dell'istanza Compute Engine vulnerabile a Log4j RCE.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.

4. Nel file JSON, nota i seguenti campi.

   • properties
     • scannerDomain: il dominio utilizzato dallo scanner nell'ambito della ricerca JNDI. Indica quale scanner ha identificato la vulnerabilità.
     • sourceIp: l'indirizzo IP utilizzato per creare la query DNS
     • vpcName: il nome della rete nell'istanza in cui è stata eseguita la query DNS.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging del passaggio 1.

2. Nella pagina caricata, controlla i campi httpRequest per verificare la presenza di token stringa come ${jndi:ldap:// che potrebbero indicare possibili tentativi di sfruttamento.

   Consulta CVE-2021-44228: rilevare l'exploit di Log4Shell nella documentazione di Logging per visualizzare le stringhe di esempio in cui cercare e per una query di esempio.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Exploitation of Remote Services.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Esegui l'upgrade alla versione più recente di Log4j2.
• Segui i suggerimenti di Google Cloud per analizzare e rispondere alla vulnerabilità "Apache Log4j 2" {: target="blog" track-type="tasks" track-name="blogLink"}
• Implementa le tecniche di mitigazione consigliate nelle vulnerabilità di sicurezza di Apache Log4j
• Se utilizzi Google Cloud Armor, esegui il deployment di cve-canary rule in un criterio di sicurezza di Google Cloud Armor nuovo o esistente. Per maggiori informazioni, consulta Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j

Leaked credentials

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Questo risultato viene generato quando le credenziali dell'account di servizio Google Cloud vengono divulgate online o compromesse accidentalmente. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato account_has_leaked_credentials, come indicato nella sezione Esaminare i dettagli del risultato. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

• Che cosa è stato rilevato
• Risorsa interessata

1. Fai clic sulla scheda Proprietà sorgente e prendi nota dei seguenti campi:

   • Compromised_account: l'account di servizio potenzialmente compromesso
   • Project_identifier: il progetto contenente le credenziali dell'account potenzialmente divulgate
   • URL: il link al repository GitHub

2. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: rivedi le autorizzazioni del progetto e dell'account di servizio

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato in Project_identifier.

3. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato in Compromised_account e seleziona le autorizzazioni assegnate.

4. Nella console Google Cloud, vai alla pagina Account di servizio.

   Vai ad Account di servizio

5. Nella pagina visualizzata, inserisci nella casella Filtro il nome dell'account di servizio compromesso e controlla le chiavi e le date di creazione della chiave dell'account di servizio.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il tuo progetto.

3. Nella pagina caricata, controlla i log per verificare le attività delle risorse IAM nuove o aggiornate utilizzando i seguenti filtri:

   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
   • protoPayload.methodName="InsertProjectOwnershipInvite"
   • protoPayload.authenticationInfo.principalEmail="Compromised_account"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Account validi: account cloud.
2. Esamina i risultati correlati facendo clic sul link in relatedFindingURI. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con le credenziali divulgate.
• Valuta la possibilità di eliminare l'account di servizio compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team per la sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere alle notifiche dell'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.
• Apri il link URL ed elimina le credenziali divulgate. Raccogli ulteriori informazioni sull'account compromesso e contatta il proprietario.

Malware

Il malware viene rilevato esaminando i log di flusso VPC e i log di Cloud DNS per le connessioni a domini di comando e controllo e indirizzi IP noti. Attualmente, Event Threat Detection offre funzioni di rilevamento di malware generico (Malware: Bad IP e Malware: Bad Domain) e rilevatori in particolare di malware correlati a Log4j (Log4j Malware: Bad IP e Log4j Malware: Bad Domain).

I passaggi seguenti descrivono come esaminare e rispondere ai risultati basati sull'IP. I passaggi di correzione sono simili per i risultati basati sul dominio.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di malware pertinente. I passaggi seguenti utilizzano il risultato di Malware: Bad IP, come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Dominio indicatore: per Bad domain risultati, il dominio che ha attivato il risultato.
     • IP indicatore: per i risultati Bad IP, l'indirizzo IP che ha attivato il risultato.
     • IP di origine: per i risultati Bad IP, un indirizzo IP di controllo e comando del malware noto.
     • Porta di origine: per i risultati Bad IP, la porta di origine della connessione.
     • IP di destinazione: per i risultati Bad IP, l'indirizzo IP di destinazione del malware.
     • Porta di destinazione: per i risultati Bad IP, la porta di destinazione della connessione.
     • Protocollo: per i risultati Bad IP, il numero di protocollo IANA associato alla connessione.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa dell'istanza di Compute Engine interessata.
     • Nome completo del progetto: il nome completo della risorsa del progetto che contiene il risultato.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
     • Chronicle: link a Chronicle.
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

   1. Fai clic sulla scheda JSON e prendi nota del seguente campo:

      • evidence:
      • sourceLogId:
        • projectID: l'ID del progetto in cui è stato rilevato il problema.
      • properties:
      • InstanceDetails: l'indirizzo della risorsa per l'istanza di Compute Engine.

Passaggio 2: indaga in Chronicle

Puoi utilizzare Chronicle per analizzare questa scoperta. Chronicle è un servizio Google Cloud che ti consente di analizzare le minacce ed esplorare le entità correlate in una cronologia facile da usare. Chronicle arricchisce i dati dei risultati, consentendoti di identificare gli indicatori di interesse e semplificare le indagini.

Puoi utilizzare Chronicle solo se attivi Security Command Center a livello di organizzazione.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato di origine, seleziona Event Threat Detection.

   La tabella viene compilata con i risultati per il tipo di origine selezionato.

4. Nella tabella, sotto category, fai clic sul risultato Malware: Bad IP. Si apre il riquadro dei dettagli del risultato.

5. Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Indaga in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Chronicle.

Utilizza le seguenti guide per condurre indagini in Chronicle:

• Esaminare un indirizzo IP
• Esaminare una risorsa

Passaggio 3: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina Dashboard.

   Vai alla dashboard

2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, nel campo Cerca progetti e cartelle inserisci il numero del progetto riportato nella riga Nome completo del progetto della scheda Riepilogo.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM che corrisponde al nome e alla zona in Nome completo risorsa. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disabilita le regole firewall eccessivamente permissive.

Passaggio 4: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Nella pagina caricata, trova i log di flusso VPC relativi all'indirizzo IP in IP di origine utilizzando il seguente filtro:

   • logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")

     Sostituisci quanto segue:

     • PROJECT_ID con l'opzione Seleziona il progetto elencato in projectId.
     • SOURCE_IP con l'indirizzo IP elencato nella riga IP di origine nella scheda Riepilogo dei dettagli del risultato.

Passaggio 5: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Dynamic Resolution (Risoluzione dinamica) e Command and Control.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Controlla gli URL e i domini segnalati su VirusTotal facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
4. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto contenente malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Per tenere traccia delle attività e delle vulnerabilità che hanno consentito l'inserimento di malware, controlla gli audit log e i syslog associati all'istanza compromessa.
• Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole firewall o utilizzando Google Cloud Armor. Puoi abilitare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. I costi di Google Cloud Armor possono essere significativi a seconda del volume dei dati. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.
• Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza il criterio IAM Shielded VM e Trusted Immagini.

Malware: Outgoing DoS

Event Threat Detection rileva l'utilizzo potenziale di un'istanza per lanciare un attacco denial of service (DoS) analizzando i log di flusso VPC. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Malware: Outgoing DoS come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato
     • IP di origine: l'indirizzo IP di origine dell'attività DoS.
     • Porta di origine: la porta di origine della connessione.
     • IP di destinazione: l'indirizzo IP di destinazione dell'attività DoS.
     • Porta di destinazione: la porta di destinazione della connessione.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
   1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   2. Nel file JSON, nota i seguenti campi.
   • sourceInstanceDetails: l'istanza VM di Compute Engine interessata

Passaggio 2: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina Dashboard.

   Vai alla dashboard

2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, seleziona l'ID progetto elencato in sourceInstanceDetails.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM che corrisponde al nome e alla zona dell'istanza in sourceInstanceDetails. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disabilita le regole firewall eccessivamente permissive.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Nella pagina caricata, trova i log di flusso VPC relativi all'indirizzo IP in srcIP utilizzando il seguente filtro:

   • logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="srcIP" OR jsonPayload.connection.dest_ip="destIP")

     Sostituisci quanto segue:

     • PROJECT_ID con l'ID del progetto in cui è stato rilevato il problema.
     • SOURCE_IP con l'indirizzo IP elencato nel campo srcIP nel codice JSON del risultato.
     • DESTINATION_IP con l'indirizzo IP elencato nel campo destIp nel codice JSON del risultato.

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Network Denial of Service.
2. Esamina i risultati correlati facendo clic sul link su Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto che presenta traffico DoS in uscita.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Per tenere traccia delle attività e delle vulnerabilità che hanno consentito l'inserimento di malware, controlla gli audit log e i syslog associati all'istanza compromessa.
• Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole firewall o utilizzando Google Cloud Armor. Puoi abilitare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda del volume dei dati, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.
• Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza il criterio IAM Shielded VM e Trusted Immagini.

Persistence: IAM Anomalous Grant

Gli audit log vengono esaminati per rilevare l'aggiunta di concessioni di ruoli IAM (IAM) che potrebbero essere considerate sospette.

Di seguito sono riportati alcuni esempi di concessioni anomale:

• Invitare un utente esterno, ad esempio un utente gmail.com, come proprietario del progetto dalla console Google Cloud
• Un account di servizio che concede autorizzazioni sensibili
• Un ruolo personalizzato che concede autorizzazioni sensibili
• Un account di servizio aggiunto dall'esterno dell'organizzazione o del progetto

Il risultato IAM Anomalous Grant è univoco in quanto include regole secondarie che forniscono informazioni più specifiche su ogni istanza del risultato. La classificazione della gravità di questo risultato dipende dalla regola secondaria. Ogni regola secondaria potrebbe richiedere una risposta diversa.

Il seguente elenco mostra tutte le possibili regole secondarie e le relative gravità:

• external_service_account_added_to_policy:
  • HIGH, se è stato concesso un ruolo altamente sensibile o se è stato concesso un ruolo di sensibilità media a livello di organizzazione. Per ulteriori informazioni, consulta Ruoli altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo di sensibilità media. Per ulteriori informazioni, consulta la sezione Ruoli a sensibilità media.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, se è stato concesso un ruolo altamente sensibile o se è stato concesso un ruolo di sensibilità media a livello di organizzazione. Per ulteriori informazioni, consulta Ruoli altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo di sensibilità media. Per ulteriori informazioni, consulta la sezione Ruoli a sensibilità media.
• custom_role_given_sensitive_permissions: MEDIUM
• service_account_granted_sensitive_role_to_member: HIGH
• policy_modified_by_default_compute_service_account: HIGH

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Persistence: IAM Anomalous Grant come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: indirizzo email dell'account utente o di servizio che ha assegnato il ruolo.

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: link a Chronicle.

3. Fai clic sulla scheda JSON. Viene visualizzato il JSON completo del risultato.

4. Nel JSON del risultato, nota i seguenti campi:

   • detectionCategory:
     • subRuleName: informazioni più specifiche sul tipo di concessione anomala verificata. La regola secondaria determina la classificazione della gravità di questo risultato.
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il risultato.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: l'azione intrapresa dall'utente.
       • Role: il ruolo assegnato all'utente.
       • member: l'indirizzo email dell'utente che ha ricevuto il ruolo.

Passaggio 2: indaga in Chronicle

Puoi utilizzare Chronicle per analizzare questa scoperta. Chronicle è un servizio Google Cloud che ti consente di analizzare le minacce ed esplorare le entità correlate in una cronologia facile da usare. Chronicle arricchisce i dati dei risultati, consentendoti di identificare gli indicatori di interesse e semplificare le indagini.

Non puoi esaminare i risultati di Security Command Center in Chronicle se attivi Security Command Center a livello di progetto.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato di origine, seleziona Event Threat Detection.

   La tabella viene compilata con i risultati per il tipo di origine selezionato.

4. Nella tabella, sotto category, fai clic su un risultato Persistence: IAM Anomalous Grant. Si apre il riquadro dei dettagli per trovare le informazioni.

5. Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Indaga in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Chronicle.

Utilizza le seguenti guide per condurre indagini in Chronicle:

• Esaminare un utente
• Esaminare una risorsa

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Nella pagina visualizzata, cerca le risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account Cloud.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati nella scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con l'account compromesso.
• Elimina l'account di servizio compromesso, ruota ed elimina tutte le chiavi di accesso degli account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze di Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare l'aggiunta di utenti di gmail.com, utilizza il Criterio dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Persistence: Impersonation Role Granted for Dormant Service Account

Rileva gli eventi in cui viene concesso un ruolo di rappresentazione a un'entità che consente di impersonare un account di servizio gestito dall'utente inattivo. In questo risultato, l'account di servizio inattivo corrisponde alla risorsa interessata e un account di servizio viene considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Persistence: Impersonation Role Granted for Dormant Service Account, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione.
   • Nome concessione accesso in violazione: l'entità a cui è stato concesso il ruolo di rappresentazione

   In Risorsa interessata:

   • Nome visualizzato della risorsa: l'account di servizio inattivo come risorsa
   • Nome completo del progetto: il progetto in cui si trova l'account di servizio inattivo

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Utilizza gli strumenti per l'account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, nella sezione Link correlati, fai clic sul link URI Cloud Logging per aprire Esplora log.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'Email principale se è stata compromessa.
• Rimuovi il ruolo di rappresentazione appena concesso dal membro di destinazione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza dovrebbe identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Persistence: Unmanaged Account Granted Sensitive Role

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva gli eventi in cui viene concesso un ruolo sensibile a un account non gestito Gli account non gestiti non possono essere controllati dagli amministratori di sistema. Ad esempio, quando il dipendente corrispondente ha lasciato l'azienda, l'amministratore non può eliminare l'account. Pertanto, la concessione di ruoli sensibili agli account non gestiti crea un potenziale rischio per la sicurezza per l'organizzazione.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Persistence: Unmanaged Account Granted Sensitive Role, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione.
   • Nome concessione accesso in violazione: l'account non gestito che riceve la concessione
   • Concessione di accesso in violazione.Ruolo concesso: il ruolo sensibile concesso

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Contatta il proprietario del campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Verifica con il proprietario del campo Nome della concessione di accesso in violazione per conoscere l'origine dell'account non gestito.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, nella sezione Link correlati, fai clic sul link URI Cloud Logging per aprire Esplora log.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'Email principale se è stata compromessa.
• Rimuovi il ruolo sensibile appena concesso dall'account non gestito.
• Puoi convertire l'account non gestito in account gestito utilizzando lo strumento di trasferimento e trasferire questo account sotto il controllo degli amministratori di sistema.

Persistence: New API Method

È stata rilevata un'attività di amministrazione anomala di un utente potenzialmente malintenzionato in un'organizzazione, una cartella o un progetto. L'attività anomala può essere una delle seguenti:

• Nuova attività di un'entità in un'organizzazione, una cartella o un progetto
• Attività che non viene rilevata da un po' di tempo da un'entità in un'organizzazione, una cartella o un progetto

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Persistence: New API Method come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi:

   • In Che cosa è stato rilevato:
     • Email principale: l'account che ha effettuato la chiamata
     • Nome servizio: il nome dell'API del servizio Google Cloud utilizzato nell'azione
     • Method name (Nome metodo): il metodo chiamato
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il nome della risorsa interessata, che può essere uguale al nome dell'organizzazione, della cartella o del progetto
     • Percorso risorsa: la posizione nella gerarchia delle risorse in cui si è svolta l'attività

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Persistence.
2. Verifica se l'azione è giustificata nell'organizzazione, nella cartella o nel progetto e se l'azione è stata intrapresa dal legittimo proprietario dell'account. L'organizzazione, la cartella o il progetto vengono visualizzati nella riga Percorso risorsa, mentre l'account viene visualizzato nella riga Email principale.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Persistence: New Geography

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Un account utente o di servizio IAM accede a Google Cloud da una posizione anomala, in base alla geolocalizzazione dell'indirizzo IP richiedente.

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Persistence: New Geography, come indicato nella sezione Esaminare i dettagli dei risultati in precedenza in questa pagina. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

• Che cosa è stato rilevato, in particolare i seguenti campi:
  • Email principale: l'account utente potenzialmente compromesso.
• Risorsa interessata, in particolare i seguenti campi:
  • Nome completo del progetto: il progetto che contiene l'account utente potenzialmente compromesso.
• Link correlati, in particolare i seguenti campi:
  • URI Cloud Logging: link alle voci di Logging.
  • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
  • Risultati correlati: link ai risultati correlati.

1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.

2. Nel file JSON, nota i seguenti campi sourceProperties:

   • affectedResources:
     • gcpResourceName: la risorsa interessata
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il risultato.
   • properties:
     • anomalousLocation:
     • anomalousLocation: la posizione attuale stimata dell'utente.
     • callerIp: l'indirizzo IP esterno.
     • notSeenInLast: il periodo di tempo utilizzato per stabilire un riferimento per il normale comportamento.
     • typicalGeolocations: le località in cui l'utente solitamente accede alle risorse Google Cloud.

Passaggio 2: esamina le autorizzazioni del progetto e dell'account

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectID nel codice JSON trovato.

3. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato in Email principale e seleziona i ruoli concessi.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il tuo progetto.
3. Nella pagina visualizzata, controlla i log per verificare le attività delle risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Valid Accounts: Cloud Accounts.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con l'account compromesso.
• Esamina i campi anomalousLocation, typicalGeolocations e notSeenInLast per verificare se l'accesso è anomalo e se l'account è stato compromesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze di Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitazione delle località delle risorse.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Persistence: New User Agent

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Un account di servizio IAM accede a Google Cloud utilizzando software sospetto, come indicato da uno user agent anomalo.

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Persistence: New User Agent, come indicato nella sezione Esaminare i dettagli dei risultati in precedenza in questa pagina. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account di servizio potenzialmente compromesso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo del progetto: il progetto che contiene l'account di servizio potenzialmente compromesso.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
   1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   2. Nel file JSON, nota i seguenti campi.
   • projectId: il progetto che contiene l'account di servizio potenzialmente compromesso.
   • callerUserAgent: lo user agent anomalo.
   • anomalousSoftwareClassification: il tipo di software.
   • notSeenInLast: il periodo di tempo utilizzato per stabilire un riferimento per il comportamento normale.

Passaggio 2: esamina le autorizzazioni del progetto e dell'account

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato in projectId.

3. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato nella riga Email principale nella scheda Riepilogo dei dettagli del risultato e seleziona i ruoli concessi.

4. Nella console Google Cloud, vai alla pagina Account di servizio.

   Vai ad Account di servizio

5. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato nella riga Email principale della scheda Riepilogo dei dettagli del risultato.

6. Controlla le chiavi e le date di creazione delle chiavi dell'account di servizio.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il tuo progetto.
3. Nella pagina visualizzata, controlla i log per verificare le attività delle risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con l'account compromesso.
• Esamina i campi anomalousSoftwareClassification, callerUserAgent e behaviorPeriod per verificare se l'accesso è anomalo e se l'account è stato compromesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze di Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitazione delle località delle risorse.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Per aumentare i privilegi, un utente potenzialmente malintenzionato ha tentato di modificare un oggetto ClusterRole o ClusterRoleBinding di controllo dell'accesso basato sui ruoli (RBAC) del ruolo sensibile cluster-admin utilizzando una richiesta PUT o PATCH.

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Privilege Escalation: Changes to sensitive Kubernetes RBAC objects come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Method name (Nome metodo): il metodo chiamato.
     • Associazioni Kubernetes: l'associazione sensibile Kubernetes o ClusterRoleBinding che è stata modificata.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Nella sezione Cosa è stato rilevato, fai clic sul nome dell'associazione nella riga Associazioni Kubernetes. Vengono visualizzati i dettagli dell'associazione.

4. Nell'associazione visualizzata, prendi nota dei dettagli dell'associazione.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging.

2. Se il valore in Nome metodo era un metodo PATCH, controlla il corpo della richiesta per sapere quali proprietà sono state modificate.

   Nelle chiamate update (PUT), nella richiesta viene inviato l'intero oggetto, quindi le modifiche non sono chiare.

3. Controlla le altre azioni eseguite dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore che hai annotato nel campo Nome visualizzato della risorsa nei dettagli del risultato.

   • PRINCIPAL_EMAIL: il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Conferma la sensibilità dell'oggetto sottoposto a query e se la modifica è giustificata.
3. Per le associazioni, puoi controllare l'oggetto e verificare se l'oggetto ha bisogno del ruolo a cui è associato.
4. Determinare se nei log sono presenti altri segni di attività dannosa da parte dell'entità.

5. Se l'indirizzo email dell'entità non è un account di servizio, contatta il proprietario dell'account per verificare che l'azione sia stata eseguita dal proprietario legittimo.

   Se l'email principale è un account di servizio (IAM o Kubernetes), identifica l'origine della modifica per stabilirne la legittimità.

6. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Per riassegnare i privilegi, un utente potenzialmente malintenzionato ha creato una richiesta di firma del certificato (CSR) master Kubernetes, che gli consente di accedere a cluster-admin.

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Privilege Escalation: Create Kubernetes CSR for master cert come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Method name (Nome metodo): il metodo chiamato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta specifica di firma del certificato.

3. Controlla le altre azioni eseguite dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore che hai annotato nel campo Nome visualizzato della risorsa nei dettagli del risultato.

   • PRINCIPAL_EMAIL: il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Verifica se l'autorizzazione a concedere l'accesso a cluster-admin è giustificata.

3. Se l'indirizzo email dell'entità non è un account di servizio, contatta il proprietario dell'account per verificare che l'azione sia stata eseguita dal proprietario legittimo.

   Se l'email principale è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per stabilirne la legittimità.

4. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Per aumentare i privilegi, un utente potenzialmente malintenzionato ha tentato di creare un nuovo oggetto RoleBinding o ClusterRoleBinding per il ruolo cluster-admin.

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Privilege Escalation: Creation of sensitive Kubernetes bindings come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Associazioni Kubernetes: l'associazione sensibile Kubernetes o ClusterRoleBinding creato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging.

2. Controlla le altre azioni eseguite dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore che hai annotato nel campo Nome visualizzato della risorsa nei dettagli del risultato.

   • PRINCIPAL_EMAIL: il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Conferma la sensibilità dell'associazione creata e se i ruoli sono necessari per i soggetti.
3. Per le associazioni, puoi controllare l'oggetto e verificare se l'oggetto ha bisogno del ruolo a cui è associato.
4. Determinare se nei log sono presenti altri segni di attività dannosa da parte dell'entità.

5. Se l'indirizzo email dell'entità non è un account di servizio, contatta il proprietario dell'account per verificare che l'azione sia stata eseguita dal proprietario legittimo.

   Se l'email principale è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per stabilirne la legittimità.

6. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Per aumentare i privilegi, un utente potenzialmente malintenzionato ha eseguito una query per una richiesta di firma del certificato (CSR), con il comando kubectl, utilizzando le credenziali di bootstrap compromesse.

Di seguito è riportato un esempio di comando rilevato da questa regola:

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Method name (Nome metodo): il metodo chiamato.
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: controlla i log

Se il nome del metodo, che hai annotato nel campo Nome del metodo nei dettagli dei risultati, è un metodo GET, procedi nel seguente modo:

1. Nella scheda Riepilogo dei dettagli del risultato nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta specifica di firma del certificato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Se il CSR specifico è disponibile nella voce di log, esamina la sensibilità del certificato e verifica se l'azione è giustificata.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

Un aggressore potenzialmente dannoso ha creato un pod che contiene container o container con privilegi e capacità di escalation dei privilegi.

Il campo privileged di un contenitore con privilegi è impostato su true. Un container con funzionalità di escalation dei privilegi ha il campo allowPrivilegeEscalation impostato su true. Per ulteriori informazioni, consulta il riferimento dell'API SecurityContext v1 core nella documentazione di Kubernetes.

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Privilege Escalation: Launch of privileged Kubernetes container come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Pod Kubernetes: il pod appena creato con container con privilegi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

3. Nella scheda JSON, prendi nota dei valori dei campi dei risultati:

   • findings.kubernetes.pods[].containers: il container con privilegi attivato nel pod.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI di Cloud Logging.

2. Controlla le altre azioni eseguite dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore che hai annotato nel campo Nome visualizzato della risorsa nei dettagli del risultato.

   • PRINCIPAL_EMAIL: il valore che hai annotato nel campo Email principale nei dettagli del risultato.

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Verifica che il container creato richieda l'accesso alle risorse host e alle funzionalità del kernel.
3. Determinare se nei log sono presenti altri segni di attività dannosa da parte dell'entità.

4. Se l'indirizzo email principale non è un account di servizio, contatta il proprietario dell'account per verificare se l'azione sia stata eseguita dal proprietario legittimo.

   Se l'email principale è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per stabilirne la legittimità.

5. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Rileva gli eventi in cui viene concesso un ruolo IAM sensibile a un account di servizio gestito dall'utente inattivo. In questo contesto, un account di servizio viene considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Privilege Escalation: Dormant Service Account Granted Sensitive Role, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione.
   • Nome concessione accesso in questione: l'account di servizio inattivo che ha ricevuto il ruolo sensibile
   • Concessione di accesso in violazione.Ruolo concesso: il ruolo IAM sensibile assegnato

   In Risorsa interessata:

   • Nome visualizzato della risorsa: l'organizzazione, la cartella o il progetto in cui il ruolo IAM sensibile è stato concesso all'account di servizio inattivo.

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Utilizza gli strumenti per l'account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, nella sezione Link correlati, fai clic sul link URI Cloud Logging per aprire Esplora log.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'Email principale se è stata compromessa.
• Rimuovi il ruolo IAM sensibile appena assegnato dall'account di servizio inattivo.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team per la sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

Il furto dell'identità anomala dell'account di servizio viene rilevato esaminando gli audit log delle attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di furto d'identità dell'account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account di servizio finale nella richiesta di rappresentazione utilizzata per accedere a Google Cloud.
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Method name (Nome metodo): il metodo chiamato.
     • Informazioni sulla delega dell'account di servizio: dettagli degli account di servizio nella catena di delega; l'entità in fondo all'elenco è il chiamante della richiesta di rappresentazione.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se la richiesta è anomala e se un account è stato compromesso.
3. Contatta il proprietario del chiamante per il furto d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica che l'azione sia stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team per la sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation viene rilevato esaminando gli audit log delle attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di furto d'identità dell'account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account di servizio finale nella richiesta di rappresentazione utilizzata per accedere a Google Cloud.
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Method name (Nome metodo): il metodo chiamato.
     • Informazioni sulla delega dell'account di servizio: dettagli degli account di servizio nella catena di delega; l'entità in fondo all'elenco è il chiamante della richiesta di rappresentazione.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se la richiesta è anomala e se un account è stato compromesso.
3. Contatta il proprietario del chiamante per il furto d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica che l'azione sia stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team per la sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation viene rilevato esaminando gli audit log di accesso ai dati per verificare se si è verificata un'anomalia in una richiesta di furto d'identità di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account di servizio finale nella richiesta di rappresentazione utilizzata per accedere a Google Cloud
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Method name (Nome metodo): il metodo chiamato
     • Informazioni sulla delega dell'account di servizio: dettagli degli account di servizio nella catena di delega; l'entità in fondo all'elenco è il chiamante della richiesta di rappresentazione
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se la richiesta è anomala e se un account è stato compromesso.
3. Contatta il proprietario del chiamante per il furto d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica che l'azione sia stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team per la sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator viene rilevato esaminando gli audit log delle attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di furto d'identità di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • Email principale: l'account di servizio finale nella richiesta di rappresentazione utilizzata per accedere a Google Cloud
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Method name (Nome metodo): il metodo chiamato
     • Informazioni sulla delega dell'account di servizio: dettagli degli account di servizio nella catena di delega; l'entità in fondo all'elenco è il chiamante della richiesta di rappresentazione

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se la richiesta è anomala e se un account è stato compromesso.
3. Contatta il proprietario del chiamante per il furto d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica che l'azione sia stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team per la sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Il rilevamento anomalo dell'identità dell'account di servizio viene rilevato esaminando gli audit log di accesso ai dati per verificare se si è verificata un'anomalia in una richiesta di rappresentazione dell'account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Privilege Escalation: Anomalous Service Account Impersonator for Data Access, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'account di servizio finale nella richiesta di rappresentazione utilizzata per accedere a Google Cloud
   • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
   • Method name (Nome metodo): il metodo chiamato
   • Informazioni sulla delega dell'account di servizio: dettagli degli account di servizio nella catena di delega; l'entità in fondo all'elenco è il chiamante della richiesta di rappresentazione

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se la richiesta è anomala e se un account è stato compromesso.
3. Contatta il proprietario del chiamante per il furto d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica che l'azione sia stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team per la sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Service account self-investigation

Le credenziali di un account di servizio vengono utilizzate per esaminare i ruoli e le autorizzazioni associati allo stesso account di servizio. Questo risultato indica che le credenziali dell'account di servizio potrebbero essere state compromesse e che è necessario intervenire immediatamente.

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Discovery: Service Account Self-Investigation, come indicato nella sezione Esaminare i dettagli dei risultati in precedenza in questa pagina. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Gravità: il livello di rischio assegnato all'esito. La gravità è HIGH se la chiamata API che ha attivato questo risultato non è autorizzata: l'account di servizio non è autorizzato a eseguire query sulle proprie autorizzazioni IAM con l'API projects.getIamPolicy.
     • Email principale: l'account di servizio potenzialmente compromesso.
     • IP chiamante: l'indirizzo IP interno o esterno
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa:
     • Nome completo del progetto: il progetto che contiene le credenziali dell'account potenzialmente divulgate.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
   1. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: rivedi le autorizzazioni del progetto e dell'account di servizio

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectID del codice JSON del risultato.

3. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato in Email principale e seleziona le autorizzazioni assegnate.

4. Nella console Google Cloud, vai alla pagina Account di servizio.

   Vai ad Account di servizio

5. Nella pagina visualizzata, inserisci nella casella Filtro il nome dell'account di servizio compromesso e controlla le chiavi e le date di creazione della chiave dell'account di servizio.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il tuo progetto.
3. Nella pagina visualizzata, controlla i log per verificare le attività delle risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Permission Groups Discovery: Cloud Groups.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con l'account compromesso.
• Elimina l'account di servizio compromesso, ruota ed elimina tutte le chiavi di accesso degli account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso.
• Elimina le risorse del progetto create dall'account compromesso, ad esempio istanze di Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection esamina gli audit log per rilevare l'eliminazione degli host che eseguono applicazioni protette dal servizio di backup e RE. Dopo l'eliminazione di un host, non è possibile eseguire il backup delle applicazioni associate all'host.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Inhibit System Recovery: Deleted Google Cloud Backup and DR host, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome applicazione: il nome di un database o di una VM connessa a backup e RE
     • Nome host: il nome di un host connesso a backup e RE
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato l'host
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte nella tua indagine per determinare il modo migliore per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Verifica che l'host eliminato non sia più incluso nell'elenco degli host di backup e RE.
3. Seleziona l'opzione Add Host (Aggiungi host) per aggiungere di nuovo l'host eliminato.

Inhibit System Recovery: Google Cloud Backup and DR remove plan

Security Command Center esamina gli audit log per rilevare l'eliminazione anomala di un piano di backup del servizio di backup e RE utilizzato per applicare criteri di backup a un'applicazione.

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Inhibit System Recovery: Google Cloud Backup and DR remove plan, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre sulla scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome applicazione: il nome di un database o di una VM connessa a backup e RE
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza del backup, la pianificazione e il tempo di conservazione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il piano
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte nella tua indagine per determinare il modo migliore per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestione app, trova le applicazioni interessate che non sono più protette e controlla i criteri di backup per ciascuna.

Inhibit System Recovery: Google Cloud Backup and DR delete template

Security Command Center esamina gli audit log per rilevare l'eliminazione anomala di un modello. Un modello è una configurazione di base per i backup che può essere applicata a più applicazioni.

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Inhibit System Recovery: Google Cloud Backup and DR delete template, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre sulla scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza del backup, la pianificazione e il tempo di conservazione
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il modello
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte nella tua indagine per determinare il modo migliore per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestione app, trova le applicazioni interessate che non sono più protette e controlla i criteri di backup per ciascuna.
3. Per aggiungere di nuovo un modello, vai alla scheda Piani di backup, seleziona Modelli, quindi l'opzione Crea modello.

Inhibit System Recovery: Google Cloud Backup and DR delete policy

Gli audit log vengono esaminati per rilevare l'eliminazione di un criterio. Un criterio definisce la modalità di esecuzione di un backup e la relativa posizione di archiviazione.

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Inhibit System Recovery: Google Cloud Backup and DR delete policy, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre sulla scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza, la pianificazione e il tempo di conservazione del backup
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il criterio
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestione app, seleziona l'applicazione interessata e controlla le impostazioni Norme applicate.

Inhibit System Recovery: Google Cloud Backup and DR delete profile

Gli audit log vengono esaminati per rilevare l'eliminazione di un profilo. Un profilo definisce quali pool di archiviazione vengono utilizzati per archiviare i backup.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete profile, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il profilo
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Piani di backup, seleziona Profili per un elenco di tutti i profili. 3. Esamina i profili per verificare che tutti i profili obbligatori siano presenti. 4. Se il profilo eliminato è stato rimosso per errore, seleziona Crea profilo per definire i target di archiviazione per le appliance di backup e RE.

Inhibit System Recovery: Google Cloud Backup and DR delete storage pool

Gli audit log vengono esaminati per rilevare l'eliminazione di un pool di archiviazione. Un pool di archiviazione associa un bucket Cloud Storage a backup e RE.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome pool di archiviazione: il nome dei bucket di archiviazione in cui sono archiviati i backup
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il pool di archiviazione
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestisci, seleziona Pool di archiviazione per visualizzare un elenco di tutti i pool di archiviazione. 3. Esamina le associazioni dei pool di archiviazione con le appliance di backup. 4. Se a un'appliance attiva non è associato un pool di archiviazione, seleziona Aggiungi pool OnVault per aggiungerla di nuovo.

Data Destruction: Google Cloud Backup and DR expire image

Un utente potenzialmente malintenzionato ha richiesto di eliminare un'immagine di backup.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR expire image, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza del backup, la pianificazione e il tempo di conservazione
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza del backup, la pianificazione e il tempo di conservazione
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'immagine di backup
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitoraggio e seleziona Job per esaminare lo stato del job di eliminazione di backup. 3. Se un job di eliminazione non è autorizzato, vai alle autorizzazioni IAM per esaminare gli utenti con accesso ai dati di backup.

Data Destruction: Google Cloud Backup and DR expire all images

Un utente potenzialmente malintenzionato ha richiesto di eliminare tutte le immagini di backup associate a un'applicazione.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR expire all images, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza del backup, la pianificazione e il tempo di conservazione
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza del backup, la pianificazione e il tempo di conservazione
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui sono state eliminate le immagini di backup
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitoraggio e seleziona Job per esaminare lo stato del job di eliminazione di backup. 3. Se un job di eliminazione non è autorizzato, vai alle autorizzazioni IAM per esaminare gli utenti con accesso ai dati di backup.

Data Destruction: Google Cloud Backup and DR remove appliance

Gli audit log vengono esaminati per rilevare la rimozione di un'appliance di backup e ripristino. Un'appliance di backup e ripristino è un componente fondamentale per le operazioni di backup.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR remove appliance, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome appliance: il nome di un database o di una VM connessa a backup e RE
     • Oggetto dell'entità: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'appliance
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestione app, trova le applicazioni interessate che non sono più protette e controlla i criteri di backup per ciascuna. 3. Per creare una nuova appliance e riapplicare le protezioni alle app non protette, vai a Backup e RE nella console Google Cloud e seleziona l'opzione Esegui il deployment di un'altra appliance di backup o di ripristino. 4. Nel menu Archiviazione, configura ogni nuova appliance con un target di archiviazione. Dopo aver configurato un'appliance, questa viene visualizzata come opzione quando crei un profilo per le applicazioni.

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection esamina gli audit log per rilevare se la data di scadenza di un backup su un'appliance di servizio di backup e RE è stata ridotta.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Impact: Google Cloud Backup and DR reduced backup expiration, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre sulla scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Descrizione: informazioni sul rilevamento
     • Oggetto dell'entità: un account utente o di servizio che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata ridotta la scadenza del backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Oggetto entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte nella tua indagine per determinare il modo migliore per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda App Manager, trova l'applicazione interessata per la quale è stata ridotta la scadenza del backup e verifica che la scadenza fosse prevista dall'entità.
3. Per avviare un nuovo backup dell'applicazione, seleziona Gestisci configurazioni di backup per creare un backup on demand o per pianificare un nuovo backup.

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection esamina gli audit log per rilevare se il piano di backup è stato modificato in modo da ridurre la frequenza dei backup.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri la sezione Impact: Google Cloud Backup and DR reduced backup frequency, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre sulla scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni riportate nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Descrizione: informazioni sul rilevamento
     • Oggetto dell'entità: un account utente o di servizio che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata ridotta la frequenza di backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca sui metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Oggetto entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Valuta attentamente le informazioni raccolte nella tua indagine per determinare il modo migliore per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda App Manager, trova l'applicazione interessata per cui è stata ridotta la frequenza di backup e verifica che la modifica sia stata intenzionale dall'entità.
3. Per avviare un nuovo backup dell'applicazione, seleziona Gestisci configurazioni di backup per creare un backup on demand o per pianificare un nuovo backup.

Lateral Movement: Modified Boot Disk Attached to Instance

Gli audit log vengono esaminati per rilevare movimenti sospetti del disco tra le risorse delle istanze Compute Engine. A Compute Engine è stato collegato un disco di avvio potenzialmente modificato.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Lateral Movement: Modify Boot Disk Attaching to Instance, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'account di servizio che ha eseguito l'azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui ha eseguito l'accesso dall'account di servizio.
   • Method name (Nome metodo): il metodo chiamato

Passaggio 2: ricerca sui metodi di attacco e di risposta

1. Utilizza gli strumenti dell'account di servizio come Activity Analyzer per esaminare l'attività dell'account di servizio associato.
2. Contatta il proprietario dell'account di servizio nel campo Email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di utilizzare l'avvio protetto per Compute Engine
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, nonché ruotare ed eliminare tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza dovrebbe identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare risorse sconosciute, tra cui istanze, snapshot, account di servizio e utenti IAM di Compute Engine. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza Google Cloud.

Privilege Escalation: AlloyDB Over-Privileged Grant

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando tutti i privilegi su un database AlloyDB per PostgreSQL (o tutte le funzioni o le procedure in un database) vengono concessi a uno o più utenti del database.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato di Privilege Escalation: AlloyDB Over-Privileged Grant, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza AlloyDB per PostgreSQL interessato.
     • Nome utente database: l'utente PostgreSQL che ha concesso privilegi in eccesso.
     • Query di database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari del database: i beneficiari dei privilegi overbroad.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza AlloyDB per PostgreSQL interessata.
     • Nome completo padre: il nome della risorsa dell'istanza AlloyDB per PostgreSQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza AlloyDB per PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.

3. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: rivedi i privilegi del database

1. Connettiti all'istanza AlloyDB per PostgreSQL.
2. Elenca e mostra i privilegi di accesso per:
   • Database. Utilizza il metacomando \l o \list e controlla quali privilegi vengono assegnati per il database elencato in Nome visualizzato del database (dal passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e verifica quali privilegi vengono assegnati per le funzioni o le procedure nel database elencato in Nome visualizzato del database (dal Passaggio 1).

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nell'URI di Cloud Logging (dal passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. In Esplora log, controlla i log pgaudit di PostgreSQL, che registrano le query eseguite nel database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario dell'istanza con concessioni con privilegi in eccesso.
• Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari del database fino al completamento dell'indagine.
• Per limitare l'accesso al database (da Nome visualizzato del database del Passaggio 1, revoke le autorizzazioni non necessarie dei beneficiari (dai Beneficiari del database del Passaggio 1).

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando l'account super user del database AlloyDB per PostgreSQL (postgres) scrive nelle tabelle utente. In genere non si deve usare il super user (un ruolo con accesso molto ampio) per scrivere nelle tabelle utente. Dovresti usare un account utente con accesso più limitato per la normale attività quotidiana. Un super user scrive in una tabella utente potrebbe indicare che un utente malintenzionato ha aumentato i privilegi o ha compromesso l'utente del database predefinito e sta modificando i dati. Potrebbe anche indicare pratiche normali ma non sicure.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Privilege Escalation: AlloyDB Database Superuser Writes to User Tables, come indicato in Analisi dei risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza AlloyDB per PostgreSQL interessato.
     • Nome utente del database: il super user.
     • Query di database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza AlloyDB per PostgreSQL interessata.
     • Nome completo padre: il nome della risorsa dell'istanza AlloyDB per PostgreSQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza AlloyDB per PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.

3. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in cloudLoggingQueryURI (dal passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza AlloyDB per PostgreSQL pertinente.
2. Controlla i log dei log pgaudit di PostgreSQL, che contengono le query eseguite dal super user, utilizzando i seguenti filtri:
   • protoPayload.request.user="postgres"

Passaggio 3: ricerca sui metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Esamina gli utenti autorizzati a connettersi al database.
• Valuta la possibilità di cambiare la password dell'utente avanzato.
• Prendi in considerazione la creazione di un nuovo utente con accesso limitato per i diversi tipi di query utilizzati nell'istanza.
  • Concedi al nuovo utente solo le autorizzazioni necessarie per eseguire le sue query.
  • Aggiorna le credenziali per i client che si connettono all'istanza AlloyDB per PostgreSQL

Rilevamenti dei metadati amministratore di Compute Engine

Persistence: GCE Admin Added SSH Key

Descrizione	Azioni
La chiave dei metadati dell'istanza Compute Engine ssh-keys è stata modificata su un'istanza stabilita.	La chiave dei metadati dell'istanza di Compute Engine ssh-keys è stata modificata in un'istanza creata più di sette giorni fa. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un utente malintenzionato per introdurre un nuovo accesso alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" (protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" ) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: INSTANCE_ID: gceInstanceId elencato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1098/004/

Persistence: GCE Admin Added Startup Script

Descrizione	Azioni
La chiave dei metadati dell'istanza Compute Engine startup-script o startup-script-url è stata modificata su un'istanza stabilita.	La chiave dei metadati dell'istanza di Compute Engine startup-script o startup-script-url è stata modificata in un'istanza creata più di sette giorni fa. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un utente malintenzionato per introdurre un nuovo accesso alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" ((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" ) OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" )) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: INSTANCE_ID: gceInstanceId elencato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1098/004/

Rilevamenti dei log di Google Workspace

Se condividi i log di Google Workspace con Cloud Logging, Event Threat Detection genera risultati per diverse minacce di Google Workspace. Poiché i log di Google Workspace sono a livello di organizzazione, Event Threat Detection può analizzarli solo se attivi Security Command Center a livello di organizzazione.

Event Threat Detection arricchisce gli eventi dei log e scrive i risultati in Security Command Center. La seguente tabella contiene le minacce di Google Workspace, le voci pertinenti del framework MITRE ATT&CK e i dettagli sugli eventi che attivano i risultati. Puoi anche controllare i log utilizzando filtri specifici e combinare tutte le informazioni per rispondere alle minacce di Google Workspace.

Initial Access: Disabled Password Leak

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
L'account di un membro è stato disattivato perché è stata rilevata una fuga di password.	Reimposta le password degli account interessati e consiglia ai membri di utilizzare password efficaci e univoche per gli account aziendali.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli evento di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabilitato_password_leak

Initial Access: Suspicious Login Blocked

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
È stato rilevato e bloccato un accesso sospetto all'account di un membro.	Questo account potrebbe essere preso di mira da avversari. Assicurati che l'account utente rispetti le linee guida di sicurezza della tua organizzazione per l'uso di password efficaci e l'autenticazione a più fattori.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli evento di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

Initial Access: Account Disabled Hijacked

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
L'account di un membro è stato sospeso a causa di attività sospetta.	Questo account è stato compromesso. Reimposta la password dell'account e incoraggia gli utenti a creare password efficaci e univoche per gli account aziendali.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabilitato_redirected

Impair Defenses: Two Step Verification Disabled

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
Un membro ha disattivato la verifica in due passaggi.	Verifica se l'utente ha intenzione di disattivare la verifica in due passaggi. Se la tua organizzazione richiede la verifica in due passaggi, assicurati che l'utente la attivi tempestivamente.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1562/ Dettagli evento Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

Initial Access: Government Based Attack

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
Alcuni hacker sostenuti da un governo potrebbero aver tentato di compromettere un account o un computer di un membro.	Questo account potrebbe essere preso di mira da avversari. Assicurati che l'account utente rispetti le linee guida di sicurezza della tua organizzazione per l'uso di password efficaci e l'autenticazione a più fattori.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli evento Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

Persistence: SSO Enablement Toggle

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
L'impostazione Abilita SSO (Single Sign-On) nell'account amministratore è stata disattivata.	Le impostazioni SSO per la tua organizzazione sono state modificate. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un utente malintenzionato per introdurre un nuovo accesso alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: DOMAIN_NAME: domainName elencato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1098/ Dettagli evento di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

Persistence: SSO Settings Changed

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
Le impostazioni SSO per l'account amministratore sono state modificate.	Le impostazioni SSO per la tua organizzazione sono state modificate. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un utente malintenzionato per introdurre un nuovo accesso alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: DOMAIN_NAME: domainName elencato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1098/ Dettagli evento di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

Impair Defenses: Strong Authentication Disabled

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
La verifica in due passaggi è stata disattivata per l'organizzazione.	La verifica in due passaggi non è più obbligatoria per la tua organizzazione. Scopri se si tratta di una modifica intenzionale alle norme da parte di un amministratore o se si tratta di un tentativo di un utente malintenzionato di semplificare la compromissione dell'account.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="admin.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci ORGANIZATION_ID con l'ID organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1562/ Dettagli evento di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_MANY_AUTHENTICATION

Rispondere alle minacce di Google Workspace

I risultati per Google Workspace sono disponibili solo per le attivazioni a livello di organizzazione di Security Command Center. Non è possibile analizzare i log di Google Workspace per attivazioni a livello di progetto.

Se sei un amministratore di Google Workspace, puoi utilizzare gli strumenti di sicurezza del servizio per risolvere queste minacce:

• Centro avvisi di Google Workspace
• Centro sicurezza di Google Workspace

Questi strumenti includono avvisi, una dashboard per la sicurezza, suggerimenti per la sicurezza e possono aiutarti a esaminare le minacce e a porvi rimedio.

Se non sei un amministratore di Google Workspace:

• Se hai ancora accesso al tuo account, modifica o reimposta la password e attiva la verifica in due passaggi.
• Contatta l'amministratore di Google Workspace o il team della tua azienda che gestisce il tuo account Google Workspace. Utilizza questi risultati come un'indicazione che un account potrebbe essere stato compromesso.

Rilevamenti delle minacce Cloud IDS

Cloud IDS: THREAT_ID

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

I risultati di Cloud IDS sono generati da Cloud IDS, un servizio di sicurezza che monitora il traffico da e verso le tue risorse Google Cloud per rilevare eventuali minacce. Quando Cloud IDS rileva una minaccia, invia a Event Threat Detection informazioni sulla minaccia, come indirizzo IP di origine, indirizzo di destinazione e numero di porta, che quindi invia una minaccia.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Cloud IDS: THREAT_ID, come indicato in Analisi dei risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Protocollo: il protocollo di rete utilizzato
     • Ora evento: quando si è verificato l'evento.
     • Descrizione: ulteriori informazioni sul risultato
     • Gravità: il livello di gravità dell'avviso.
     • IP di destinazione: l'IP di destinazione del traffico di rete.
     • Porta di destinazione: la porta di destinazione del traffico di rete.
     • IP di origine: l'IP di origine del traffico di rete.
     • Porta di origine: la porta di origine del traffico di rete.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il progetto contenente la rete con la minaccia
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Cloud IDS Logging. Queste voci contengono le informazioni necessarie per eseguire ricerche nella Threat Vault di Palo Alto Networks
   • Servizio di rilevamento
     • Finding Category (Ricerca della categoria) Il nome della minaccia Cloud IDS

3. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: cerca i metodi di attacco e di risposta

Dopo aver esaminato i dettagli dell'esito, consulta la documentazione di Cloud IDS sull'analisi degli avvisi di minacce per determinare una risposta appropriata.

Puoi trovare ulteriori informazioni sull'evento rilevato nella voce di log originale facendo clic sul link nel campo URI di Cloud Logging nei dettagli del risultato.

Risposte di Container Threat Detection

Per saperne di più su Container Threat Detection, vedi Come funziona Container Threat Detection.

Added Binary Executed

È stato eseguito un programma binario che non faceva parte dell'immagine container originale. Di solito gli aggressori installano strumenti di exploit e malware dopo la compromissione iniziale. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Added Binary Executed come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del programma binario aggiunto.
     • Argomenti: gli argomenti forniti quando si richiama il programma binario aggiunto.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la località e il nome del cluster.

3. Fai clic su JSON e prendi nota dei seguenti campi:

   • resource:
     • project_display_name: il nome del progetto che contiene il cluster.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del container interessato.
     • Container_Image_Uri: nome dell'immagine container di cui è stato eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e, se necessario, lo spazio dei nomi del pod elencato in Pod_Namespace.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il programma binario aggiunto eseguendo:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso file locale per archiviare il programma binario aggiunto.

6. Connettiti all'ambiente del container eseguendo:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, API Native.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Added Library Loaded

È stata caricata una libreria che non faceva parte dell'immagine container originale. Gli aggressori potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni relative all'esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Added Library Loaded come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Binario del programma: il percorso completo del programma binario del processo che ha caricato la libreria.
     • Librerie: dettagli sulla raccolta aggiunta.
     • Argomenti: gli argomenti forniti quando si chiama il file binario del processo.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • resource:
     • project_display_name: il nome del progetto che contiene l'asset.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del container interessato.
     • Container_Image_Uri: nome dell'immagine container in esecuzione.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e, se necessario, lo spazio dei nomi del pod elencato in Pod_Namespace.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Recupera la libreria aggiunta eseguendo:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso file locale per archiviare la libreria aggiunta.

6. Connettiti all'ambiente del container eseguendo:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, Shared Modules.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Execution: Added Malicious Binary Executed

È stato eseguito un file binario dannoso che non faceva parte dell'immagine container originale. Di solito gli aggressori installano strumenti di exploit e malware dopo la compromissione iniziale. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Execution: Added Malicious Binary Executed come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del programma binario aggiunto.
     • Argomenti: gli argomenti forniti quando si richiama il programma binario aggiunto.
     • Container: il nome del container interessato.
     • URI dei container: il nome dell'immagine container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la località e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e, se necessario, lo spazio dei nomi del pod elencato in Pod_Namespace.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario dannoso aggiunto:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare il programma binario dannoso aggiunto.

6. Connettiti all'ambiente del container:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, API Native.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 del programma binario contrassegnato come dannoso su VirusTotal facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Execution: Added Malicious Library Loaded

È stata caricata una libreria dannosa che non faceva parte dell'immagine container originale. Gli aggressori potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni relative all'esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Execution: Added Malicious Library Loaded come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Binario del programma: il percorso completo del programma binario del processo che ha caricato la libreria.
     • Librerie: dettagli sulla raccolta aggiunta.
     • Argomenti: gli argomenti forniti quando si chiama il file binario del processo.
     • Container: il nome del container interessato.
     • URI dei container: il nome dell'immagine container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e, se necessario, lo spazio dei nomi del pod elencato in Pod_Namespace.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Recupera la libreria dannosa aggiunta:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare la libreria dannosa aggiunta.

6. Connettiti all'ambiente del container:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, Shared Modules.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 della libreria segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Execution: Built in Malicious Binary Executed

Un programma binario eseguito, con il codice binario:

• Incluso nell'immagine container originale.
• Identificati come dannosi sulla base delle informazioni sulle minacce.

L'aggressore ha il controllo del repository di immagini container o della pipeline di creazione, in cui il programma binario dannoso viene inserito nell'immagine del container. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Execution: Built in Malicious Binary Executed come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del programma binario integrato.
     • Argomenti: gli argomenti forniti quando si chiama il programma binario integrato.
     • Container: il nome del container interessato.
     • URI dei container: il nome dell'immagine container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la località e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic su JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e, se necessario, lo spazio dei nomi del pod elencato in Pod_Namespace.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario dannoso integrato:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare il file binario dannoso integrato.

6. Connettiti all'ambiente del container:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, API Native.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 del programma binario contrassegnato come dannoso su VirusTotal facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Execution: Modified Malicious Binary Executed

Un programma binario eseguito, con il codice binario:

• Incluso nell'immagine container originale.
• Modificata durante il runtime del container.
• Identificati come dannosi sulla base delle informazioni sulle minacce.

Di solito gli aggressori installano strumenti di exploit e malware dopo la compromissione iniziale. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Execution: Modified Malicious Binary Executed come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del programma binario modificato.
     • Argomenti: gli argomenti forniti quando viene richiamato il programma binario modificato.
     • Container: il nome del container interessato.
     • URI dei container: il nome dell'immagine container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la località e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic su JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e, se necessario, lo spazio dei nomi del pod elencato in Pod_Namespace.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario dannoso modificato:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare il programma binario dannoso modificato.

6. Connettiti all'ambiente del container:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, API Native.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 del programma binario contrassegnato come dannoso su VirusTotal facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Execution: Modified Malicious Library Loaded

Una libreria che è stata caricata, con la libreria:

• Incluso nell'immagine container originale.
• Modificata durante il runtime del container.
• Identificati come dannosi sulla base delle informazioni sulle minacce.

Gli aggressori potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni relative all'esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Execution: Modified Malicious Library Loaded come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Binario del programma: il percorso completo del programma binario del processo che ha caricato la libreria.
     • Librerie: dettagli della libreria modificata.
     • Argomenti: gli argomenti forniti quando si chiama il file binario del processo.
     • Container: il nome del container interessato.
     • URI dei container: il nome dell'immagine container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e, se necessario, lo spazio dei nomi del pod elencato in Pod_Namespace.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Recuperare la libreria dannosa modificata:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare la libreria dannosa modificata.

6. Connettiti all'ambiente del container:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, Shared Modules.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 della libreria segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Malicious Script Executed

Un modello di machine learning ha identificato uno script bash eseguito come dannoso. Gli aggressori possono utilizzare bash per trasferire strumenti ed eseguire comandi senza file binari.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Malicious Script Executed come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: dettagli sull'interprete che ha richiamato lo script.
     • Script: percorso assoluto del nome dello script su disco. Questo attributo viene visualizzato solo per gli script scritti su disco, non per l'esecuzione di script letterali, ad esempio bash -c.
     • Argomenti: gli argomenti forniti quando si richiama lo script.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, compresi numero del progetto, località e nome del cluster

3. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.

4. Nel file JSON, nota i seguenti campi.

   • finding:
     • processes:
     • script:
       • contents: prefisso dei contenuti del file dello script eseguito, che può aiutarti nella tua indagine; i contenuti potrebbero essere troncati per motivi di prestazioni
       • sha256: l'hash SHA-256 di script.contents
   • resource:
     • project_display_name: il nome del progetto che contiene l'asset.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del container interessato.
     • Container_Image_Uri: nome dell'immagine container in esecuzione.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato in resource.name e allo spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster mostrato in resource.labels.cluster_name.

3. Nella pagina Cluster, fai clic su Connetti e poi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge comandi per il cluster nel terminale.

4. Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.

5. Esegui la connessione all'ambiente del container eseguendo questo comando:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script, Trasferimento degli strumenti di ingresso.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Malicious URL Observed

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Container Threat Detection ha osservato un URL dannoso nell'elenco di argomenti di un processo eseguibile. Gli aggressori possono caricare malware o librerie dannose tramite URL dannosi.

Per rispondere a questo risultato, svolgi i passaggi che seguono.

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Malicious URL Observed come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • URI: l'URI dannoso osservato.
     • File binario aggiunto: il percorso completo del programma binario del processo che ha ricevuto gli argomenti che contengono l'URL dannoso.
     • Argomenti: gli argomenti forniti quando si chiama il programma binario del processo.
     • Variabili di ambiente: le variabili di ambiente che erano in vigore quando è stato richiamato il programma binario del processo.
     • Contenitori: il nome del contenitore.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il nome della risorsa interessata.
     • Nome completo della risorsa: il nome completo della risorsa del cluster. Il nome completo della risorsa include le seguenti informazioni:
       • Il progetto che contiene il cluster: projects/PROJECT_ID
       • La località in cui si trova il cluster: zone/ZONE o locations/LOCATION
       • Nome del cluster: projects/CLUSTER_NAME

3. Nella scheda JSON, nell'attributo sourceProperties, prendi nota del valore della proprietà VM_Instance_Name.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto visualizzato in Nome completo risorsa (resource.name), se necessario. Il nome del progetto viene visualizzato dopo /projects/ nel nome completo della risorsa.

3. Fai clic sul nome del cluster che hai annotato in Nome visualizzato della risorsa (resource.display_name) nel riepilogo dei risultati. Si apre la pagina Cluster.

4. Nella sezione Metadati della pagina **Dettagli cluster, prendi nota delle informazioni definite dall'utente che potrebbero essere utili per risolvere la minaccia, ad esempio quelle che identificano il proprietario del cluster.

5. Fai clic sulla scheda Nodi.

6. Tra i nodi elencati, seleziona il nodo che corrisponde al valore di VM_Instance_Name che hai annotato in precedenza nel codice JSON dei risultati.

7. Nella sezione Annotazioni della scheda Dettagli della pagina Dettagli nodo, prendi nota del valore dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato nel nome completo della risorsa (resource.name) del cluster nel riepilogo dei risultati, se necessario.

3. Fai clic su Mostra carichi di lavoro di sistema.

4. Filtra l'elenco dei carichi di lavoro in base al nome del cluster che hai annotato in Nome completo risorsa (resource.name) del riepilogo dei risultati e, se necessario, lo spazio dei nomi (kubernetes.pods.ns) del pod che hai annotato.

5. Fai clic sul nome del carico di lavoro che corrisponde al valore della proprietà VM_Instance_Name che hai annotato in precedenza nel risultato JSON. Si apre la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota del pod che potrebbe aiutarti a risolvere la minaccia.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto visualizzato in Nome completo risorsa (resource.name), se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per il tuo pod (kubernetes.pods.name) utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • POD_NAME
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: analizza il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster mostrato in resource.labels.cluster_name.

3. Nella pagina Cluster, fai clic su Connetti e poi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge comandi per il cluster nel terminale.

4. Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.

5. Esegui la connessione all'ambiente del container eseguendo questo comando:

     kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
   

   Sostituisci CONTAINER_NAME con il nome del container che hai annotato nel riepilogo dei risultati in precedenza.

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Controlla lo stato dei siti segnalato dalla funzione Navigazione sicura per avere informazioni dettagliate sul motivo per cui l'URL è classificato come dannoso.
2. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Trasferimento degli strumenti di ingresso.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Reverse Shell

Processo avviato con il reindirizzamento del flusso a un socket connesso remoto. La generazione di una shell connessa alla rete può consentire a un utente malintenzionato di eseguire azioni arbitrarie dopo una compromissione iniziale limitata. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Reverse Shell come indicato in Risultati di revisione. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del processo avviato con il reindirizzamento del flusso a un socket remoto.
     • Argomenti: gli argomenti forniti quando si chiama il programma binario del processo.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster.
     • Nome completo del progetto:
   • Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   • Nel file JSON, nota i seguenti campi.
   • resource:
     • project_display_name: il nome del progetto che contiene l'asset.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del container interessato.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.
     • Reverse_Shell_Stdin_Redirection_Dst_Ip: l'indirizzo IP remoto della connessione
     • Reverse_Shell_Stdin_Redirection_Dst_Port: la porta remota
     • Reverse_Shell_Stdin_Redirection_Src_Ip: l'indirizzo IP locale della connessione
     • Reverse_Shell_Stdin_Redirection_Src_Port: la porta locale
     • Container_Image_Uri: nome dell'immagine container in esecuzione.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato in resource.name e allo spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Avvia una shell all'interno dell'ambiente del container eseguendo:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

   Per visualizzare tutti i processi in esecuzione nel container, esegui questo comando nella shell del container:

     ps axjf
   

   Questo comando richiede che nel container sia installato /bin/ps.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script, Trasferimento degli strumenti di ingresso.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Unexpected Child Shell

Container Threat Detection ha osservato un processo che ha generato inaspettatamente un processo shell figlio. Questo evento potrebbe indicare che un utente malintenzionato sta tentando di utilizzare in modo illecito i comandi e gli script della shell.

Per rispondere a questo risultato, svolgi i passaggi che seguono.

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Unexpected Child Shell come indicato in Analisi dei risultati. Il riquadro dei dettagli relativo alla ricerca si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Processo padre: il processo che ha creato inaspettatamente il processo shell secondario.
     • Processo figlio: il processo della shell secondaria.
     • Argomenti: gli argomenti forniti al programma binario del processo della shell secondaria.
     • Variabili di ambiente: le variabili di ambiente del programma binario del processo della shell secondaria.
     • Contenitori: il nome del contenitore.
     • URI dei container: l'URI dell'immagine del container.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il nome della risorsa interessata.
     • Nome completo della risorsa: il nome completo della risorsa del cluster. Il nome completo della risorsa include le seguenti informazioni:
       • Il progetto che contiene il cluster: projects/PROJECT_ID
       • La località in cui si trova il cluster: zone/ZONE o locations/LOCATION
       • Nome del cluster: projects/CLUSTER_NAME

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

+processes: un array contenente tutti i processi correlati al risultato. Questo array include il processo shell secondario e il processo padre. +resource: +project_display_name: il nome del progetto che contiene gli asset. +sourceProperties: +VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina cluster e nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di tutti i metadati relativi al cluster e al suo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: esamina il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai ai carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato nel nome completo della risorsa (resource.name) del cluster nel riepilogo dei risultati, se necessario.

3. Fai clic su Mostra carichi di lavoro di sistema.

4. Filtra l'elenco dei carichi di lavoro in base al nome del cluster che hai annotato in Nome completo risorsa (resource.name) del riepilogo dei risultati e, se necessario, lo spazio dei nomi (kubernetes.pods.ns) del pod che hai annotato.

5. Fai clic sul nome del carico di lavoro che corrisponde al valore della proprietà VM_Instance_Name che hai annotato in precedenza nel codice JSON dei risultati. Si apre la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota del pod che potrebbe aiutarti a risolvere la minaccia.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina caricata, procedi nel seguente modo:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova gli audit log del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: analizza il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del container.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo questi comandi.

   Per i cluster di zona, esegui questo comando:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione, esegui questo comando:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Per avviare una shell nell'ambiente del container, esegui questo comando:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel container sia installata una shell in /bin/sh.

   Per visualizzare tutti i processi in esecuzione nel container, esegui questo comando nella shell del container:

     ps axjf
   

   Questo comando richiede che nel container sia installato /bin/ps.

Passaggio 6: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Command and Scripting Interpreter: Unix Shell.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

• Contatta il proprietario del progetto con il container compromesso.
• Interrompi o elimina il container compromesso e sostituiscilo con un nuovo container.

Risposta di VM Threat Detection

Per saperne di più su VM Threat Detection, consulta Panoramica di VM Threat Detection.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection ha rilevato attività di mining di criptovalute abbinando gli hash della memoria dei programmi in esecuzione con gli hash della memoria del software di mining di criptovalute noto.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Execution: Cryptocurrency Mining Hash Match, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • Famiglia binaria: l'applicazione di criptovaluta rilevata.
     • Programma binario: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti quando si chiama il programma binario del processo.
     • Nomi dei processi: il nome del processo in esecuzione nell'istanza VM associata alle corrispondenze della firma rilevate.

     VM Threat Detection può riconoscere le build del kernel dalle principali distribuzioni Linux. Se riesce a riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo processes del risultato. Se VM Threat Detection non può riconoscere il kernel, ad esempio se il kernel è creato in modo personalizzato, il campo processes del risultato non viene compilato.

   • Risorsa interessata, in particolare i seguenti campi:

     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

3. Per vedere il JSON completo di questo risultato, fai clic sulla scheda JSON nella visualizzazione dettagliata del risultato.

   • indicator
     • signatures:
       • memory_hash_signature: una firma corrispondente agli hash delle pagine di memoria.
       • detections
         • binary: il nome del file binario dell'applicazione di criptovaluta, ad esempio linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0.
         • percent_pages_matched: la percentuale di pagine in memoria che corrispondono a pagine in applicazioni di criptovaluta note nel database con hash delle pagine.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato.

3. Controlla i log per verificare la presenza di segni di intrusione sull'istanza VM interessata. Ad esempio, verifica la presenza di attività sospette o sconosciute e segni di credenziali compromesse.

Passaggio 3: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina Dashboard.

   Vai alla dashboard

2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, seleziona il progetto identificato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM corrispondente al progetto identificato nel Nome completo della risorsa. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per Esecuzione.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.

1. Contatta il proprietario della VM.

2. Conferma se l'applicazione è un'applicazione di mining:

   • Se sono disponibili il nome del processo e il percorso binario dell'applicazione rilevata, prendi in considerazione i valori alle righe Binario del programma, Argomenti e Nomi dei processi nella scheda Riepilogo dei dettagli dei risultati nell'indagine.

   • Se i dettagli del processo non sono disponibili, controlla se il nome del programma binario della firma dell'hash della memoria può fornire degli indizi. Considera un programma binario chiamato linux-x86-64_xmrig_2.14.1. Puoi utilizzare il comando grep per cercare file importanti nello spazio di archiviazione. Utilizza una parte significativa del nome del programma binario nel tuo pattern di ricerca, in questo caso xmrig. Esamina i risultati di ricerca.

   • Esamina i processi in esecuzione, in particolare quelli con un elevato utilizzo della CPU, per vedere se non li riconosci. Determinare se le applicazioni associate sono applicazioni per miner.

   • Cerca nei file nello spazio di archiviazione le stringhe comuni utilizzate dalle applicazioni di mining, come btc.com, ethminer, xmrig, cpuminer e randomx. Per altri esempi di stringhe che puoi cercare, consulta Nomi di software e regole YARA e la relativa documentazione per ciascun software elencato.

3. Se determini che l'applicazione è un'applicazione miner e che il suo processo è ancora in esecuzione, interrompi il processo. Individua il file binario eseguibile dell'applicazione nello spazio di archiviazione della VM ed eliminalo.

4. Se necessario, arresta l'istanza compromessa e sostituiscila con una nuova istanza.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection ha rilevato attività di mining di criptovalute abbinando pattern di memoria, come le costanti di proof of work, note per essere utilizzate dal software di mining di criptovalute.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Execution: Cryptocurrency Mining YARA Rule, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • Nome regola YARA: la regola attivata per i rilevatori YARA.
     • Programma binario: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti quando si chiama il programma binario del processo.
     • Nomi dei processi: il nome dei processi in esecuzione nell'istanza VM associata alle corrispondenze della firma rilevata.

     VM Threat Detection può riconoscere le build del kernel dalle principali distribuzioni Linux. Se riesce a riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo processes del risultato. Se VM Threat Detection non può riconoscere il kernel, ad esempio se il kernel è creato in modo personalizzato, il campo processes del risultato non viene compilato.

   • Risorsa interessata, in particolare i seguenti campi:

     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link ai risultati correlati.
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: link a Chronicle.

3. Per vedere il JSON completo di questo risultato, fai clic sulla scheda JSON nella visualizzazione dettagliata del risultato.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato.

3. Controlla i log per verificare la presenza di segni di intrusione sull'istanza VM interessata. Ad esempio, verifica la presenza di attività sospette o sconosciute e segni di credenziali compromesse.

Passaggio 3: esamina autorizzazioni e impostazioni

1. Nella console Google Cloud, vai alla pagina Dashboard.

   Vai alla dashboard

2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, seleziona il progetto incluso nel nome della risorsa elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM che corrisponde a resourceName. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

Passaggio 4: ricerca sui metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per Esecuzione.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche avere un impatto sulle operazioni. Valuta attentamente le informazioni raccolte durante la tua indagine per determinare il modo migliore per risolvere gli esiti.

Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.

1. Contatta il proprietario della VM.

2. Conferma se l'applicazione è un'applicazione di mining:

   • Se sono disponibili il nome del processo e il percorso binario dell'applicazione rilevata, prendi in considerazione i valori alle righe Binario del programma, Argomenti e Nomi dei processi nella scheda Riepilogo dei dettagli dei risultati nell'indagine.

   • Esamina i processi in esecuzione, in particolare quelli con un elevato utilizzo della CPU, per vedere se non li riconosci. Determinare se le applicazioni associate sono applicazioni per miner.

   • Cerca nei file nello spazio di archiviazione le stringhe comuni utilizzate dalle applicazioni di mining, come btc.com, ethminer, xmrig, cpuminer e randomx. Per altri esempi di stringhe che puoi cercare, consulta Nomi di software e regole YARA e la relativa documentazione per ciascun software elencato.

3. Se determini che l'applicazione è un'applicazione miner e che il suo processo è ancora in esecuzione, interrompi il processo. Individua il file binario eseguibile dell'applicazione nello spazio di archiviazione della VM ed eliminalo.

4. Se necessario, arresta l'istanza compromessa e sostituiscila con una nuova istanza.

Execution: cryptocurrency mining combined detection

VM Threat Detection ha rilevato più categorie di risultati in un solo giorno da un'unica fonte. Una singola applicazione può attivare contemporaneamente Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings.

Per rispondere a un risultato combinato, segui le istruzioni di risposta per Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings.

Correggi le vulnerabilità correlate

Per evitare che le minacce si ripetano, esamina e correggi i risultati relativi a vulnerabilità ed errori di configurazione.

Per trovare eventuali risultati correlati, segui questi passaggi:

1. Nella console Google Cloud, vai alla pagina Risultati di Security Command Center.

   Vai a Risultati

2. Esamina la ricerca delle minacce e copia il valore di un attributo che potrebbe apparire in eventuali vulnerabilità o errori di configurazione correlati, come l'indirizzo email principale o il nome della risorsa interessata.

3. Nella pagina Risultati, apri l'Editor query facendo clic su Modifica query.

4. Fai clic su Aggiungi filtro. Si apre il menu Seleziona filtro.

5. Nell'elenco delle categorie di filtri sul lato sinistro del menu, seleziona la categoria contenente l'attributo che hai indicato nella ricerca delle minacce.

   Ad esempio, se hai annotato il nome completo della risorsa interessata, seleziona Risorsa. I tipi di attributo della categoria Risorsa sono visualizzati nella colonna a destra, incluso l'attributo Nome completo.

6. Tra gli attributi visualizzati, seleziona il tipo di attributo che hai indicato nella ricerca della minaccia. A destra si apre un riquadro di ricerca dei valori degli attributi che mostra tutti i valori trovati del tipo di attributo selezionato.

7. Nel campo Filtro, incolla il valore dell'attributo che hai copiato dal rilevamento della minaccia. L'elenco di valori visualizzato viene aggiornato con solo i valori corrispondenti al valore incollato.

8. Nell'elenco dei valori visualizzati, seleziona uno o più valori e fai clic su Applica. Il riquadro Risultati delle query dei risultati si aggiorna per mostrare solo i risultati corrispondenti.

9. Se nei risultati sono presenti molti risultati, filtrali selezionando filtri aggiuntivi nel riquadro Filtri rapidi.

   Ad esempio, per mostrare solo i risultati delle classi Vulnerability e Misconfiguration che contengono i valori degli attributi selezionati, scorri verso il basso fino alla sezione Ricerca della classe del riquadro Filtri rapidi e seleziona Vulnerabilità e Configurazione errata.

Oltre agli indicatori di compromissione forniti da Google, gli utenti che sono clienti di Palo Alto Networks possono integrare AutoFocus Threat Intelligence di Palo Alto Networks con Event Threat Detection. AutoFocus è un servizio di intelligence sulle minacce che fornisce informazioni sulle minacce di rete. Per saperne di più, visita la pagina AutoFocus nella console Google Cloud.

Risolvere le minacce

La correzione dei risultati di Event Threat Detection e Container Threat Detection non è semplice come la correzione degli errori di configurazione e delle vulnerabilità identificate da Security Command Center.

Le configurazioni errate e le violazioni della conformità identificano i punti deboli delle risorse che potrebbero essere sfruttate. In genere, per le configurazioni errate sono previste correzioni note e facilmente implementabili, come l'abilitazione di un firewall o la rotazione di una chiave di crittografia.

Le minacce differiscono dalle vulnerabilità in quanto dinamiche e indicano un possibile exploit attivo contro una o più risorse. Un consiglio di correzione potrebbe non essere efficace per proteggere le risorse perché i metodi esatti utilizzati per raggiungere l'exploit potrebbero non essere noti.

Ad esempio, un risultato Added Binary Executed indica che un file binario non autorizzato è stato avviato in un container. Un suggerimento di correzione di base potrebbe consigliarti di mettere in quarantena il container ed eliminare il programma binario, ma ciò potrebbe non risolvere la causa principale che ha consentito all'utente malintenzionato di accedere per eseguire il programma binario. Devi scoprire come l'immagine container è stata danneggiata per correggere l'exploit. Determinare se il file è stato aggiunto tramite una porta configurata in modo errato o con altri mezzi richiede un'indagine approfondita. Un analista con una conoscenza di livello esperto del tuo sistema potrebbe dover esaminare il sistema per individuare eventuali punti deboli.

I malintenzionati attaccano le risorse utilizzando tecniche diverse, quindi l'applicazione di una correzione per un exploit specifico potrebbe non essere efficace contro le varianti dell'attacco. Ad esempio, in risposta a un risultato di Brute Force: SSH, potresti ridurre i livelli di autorizzazione per alcuni account utente al fine di limitare l'accesso alle risorse. Tuttavia, le password inefficaci potrebbero comunque fornire un percorso di attacco.

L'ampiezza dei vettori di attacco rende difficile fornire passaggi correttivi in grado di funzionare in tutte le situazioni. Il ruolo di Security Command Center nel tuo piano di sicurezza cloud è identificare le risorse interessate quasi in tempo reale, comunicarti le minacce che stai affrontando e fornire prove e contesto per agevolare le tue indagini. Tuttavia, il personale addetto alla sicurezza deve utilizzare le informazioni dettagliate disponibili nei risultati di Security Command Center per determinare i modi migliori per risolvere i problemi e proteggere le risorse da attacchi futuri.

Passaggi successivi

• Consulta la panoramica di Event Threat Detection per saperne di più sul servizio e sulle minacce che rileva.

• Consulta la panoramica di Container Threat Detection per scoprire come funziona il servizio.

• Per saperne di più sul servizio e sulle minacce che rileva, consulta la panoramica su VM Threat Detection.