Analisi e risposta alle minacce

Questo argomento offre indicazioni informali per aiutarti a indagare e rispondere alle minacce e a utilizzare risorse aggiuntive per aggiungere contesto ai risultati di Security Command Center. Questi passaggi ti aiutano a capire cosa è successo durante un potenziale attacco e a sviluppare possibili risposte per le risorse interessate.

Non è garantito che le tecniche utilizzate 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 linee guida ufficiali per la correzione delle minacce.

Prima di iniziare

Devi disporre di ruoli IAM (Identity and Access Management) adeguati per visualizzare o modificare i risultati e i log e 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 informazioni sui ruoli. Per risolvere gli errori delle risorse, leggi la documentazione relativa ai prodotti interessati.

Comprensione dei risultati delle minacce

Event Threat Detection genera risultati sulla sicurezza associando gli eventi nei flussi di log di Cloud Logging agli indicatori di compromissione noti (IoC). Gli IoC, sviluppati da fonti interne di sicurezza di Google, identificano potenziali vulnerabilità e attacchi. Event Threat Detection rileva anche le minacce identificando tattiche, tecniche e procedure avversarie note nel flusso di logging e rilevando le 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 eseguire la scansione dei log di Google Workspace.

Container Threat Detection genera risultati raccogliendo e analizzando il comportamento osservato di basso livello nel kernel dei container guest.

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 in modo che vengano scritti in Cloud Logging.

Esame dei risultati

Per esaminare i risultati relativi alle 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 origine, nei risultati vengono visualizzati solo i risultati del servizio selezionato.

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

4. Per visualizzare i dettagli di un risultato specifico, fai clic sul nome del risultato in 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, oltre a variabili di ambiente e proprietà degli asset. Puoi utilizzare queste informazioni per isolare rapidamente le risorse interessate e determinare il potenziale ambito di un evento.

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

• MITRE ATT&CK del framework. Il framework spiega le tecniche per gli attacchi alle risorse cloud e fornisce indicazioni per porvi rimedio.
• VirusTotal, un servizio di proprietà di Alphabet che fornisce il contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Le sezioni seguenti descrivono le potenziali risposte alle scoperte delle minacce.

Disattivazione dei risultati delle minacce

Dopo aver risolto un problema che ha attivato un risultato di minaccia, Security Command Center non imposta automaticamente lo stato del risultato su INACTIVE. Lo stato di un risultato di minacce rimane ACTIVE, a meno che non imposti manualmente la proprietà state su INACTIVE.

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

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

Per una minaccia reale, prima di impostare lo stato del risultato su INACTIVE, elimina la minaccia e completa un'indagine approfondita della minaccia rilevata, l'entità dell'intrusione e qualsiasi altro risultato e problema correlato.

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

• Disattiva risultati.
• Modificare lo stato di un risultato

Risposte di Event Threat Detection

Per ulteriori informazioni 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 rilevare le modifiche del servizio Google Cloud che hanno avuto origine da indirizzi IP proxy anonimi, come gli indirizzi IP Tor.

Per rispondere a questi risultati, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

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 del proxy da cui vengono condotte 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: collega a eventuali risultati correlati.

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

Passaggio 2: ricerca i 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. Conferma se l'azione è stata condotta dal legittimo proprietario.
3. Per sviluppare un piano di risposta, combina i risultati della tua 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.

Il valore Breakglass Workload Deployment Created viene rilevato esaminando Cloud Audit Logs per vedere se sono presenti deployment su 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Defense Evasion: Breakglass Workload Deployment Created, come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli trovati 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.
     • 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: collega a eventuali risultati correlati.

Passaggio 2: controlla i log

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

3. Verifica 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 annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i 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 in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati.
3. Per sviluppare un piano di risposta, combina i risultati della tua 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.

Il valore Breakglass Workload Deployment Updated viene rilevato esaminando Cloud Audit Logs per vedere se ci sono 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Defense Evasion: Breakglass Workload Deployment Updated, come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli trovati 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.
     • 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: collega a eventuali risultati correlati.

Passaggio 2: controlla i log

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

3. Verifica 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 annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i 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 in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati.
3. Per sviluppare un piano di risposta, combina i risultati della tua 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. Di seguito sono riportati 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Defense Evasion: Modify VPC Service Control, come indicato in Revisione 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 della risorsa: il nome del perimetro dei Controlli di servizio VPC modificato.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel file JSON, tieni presente i seguenti campi.

   • sourceProperties
     • properties
       • name: il nome del perimetro 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 ha ridotto la sua protezione
       • restricted_resources: i progetti che seguono le restrizioni di questo perimetro. Se rimuovi un progetto, la protezione viene ridotta
       • restricted_services: i servizi a cui è vietato l'esecuzione in base alle restrizioni di questo perimetro. La protezione viene ridotta se rimuovi un servizio limitato
       • allowed_services: i servizi che possono essere eseguiti in base alle restrizioni di questo perimetro. La protezione si riduce se aggiungi un servizio consentito
       • access_levels: i livelli di accesso configurati per consentire l'accesso alle risorse all'interno del perimetro. Se aggiungi altri livelli di accesso, la protezione viene ridotta

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. Per trovare i log delle attività di amministrazione relativi alle modifiche dei Controlli di servizio VPC, utilizza i seguenti filtri:
   • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
   • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Passaggio 3: ricerca i metodi di attacco e di risposta

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

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del criterio e del perimetro dei Controlli di servizio VPC.
• Valuta la possibilità di annullare le modifiche per il perimetro fino al termine 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.
• Analizzare come sono state utilizzate le protezioni ridotte. Ad esempio, se l'"API BigQuery Data Transfer Service" è abilitata o aggiunta come servizio consentito, verifica 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 su 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 dei risultati

1. Apri il risultato Discovery: Can get sensitive Kubernetes object check 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:
     • Revisioni degli accessi a Kubernetes: informazioni richieste per la revisione degli accessi, in base alla risorsa k8s di 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.
   • In 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 visualizzata, verifica le altre azioni intraprese 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 annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i 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 sottoposto a query e determina se ci sono altri indicatori di attività dannose da parte dell'entità nei log.

3. Se l'account che hai annotato nella riga Email entità nei dettagli nella ricerca non è un account di servizio, contatta il proprietario dell'account per verificare se l'azione è stata eseguita dal legittimo proprietario.

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

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

Exfiltration: BigQuery Data Exfiltration

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

• Regola secondaria exfil_to_external_table con gravità = HIGH:
  • Una risorsa è stata salvata all'esterno dell'organizzazione o del 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, 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 secondariavpc_perimeter_violation.
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli delle tabelle da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli sulle tabelle in cui erano 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: collega a eventuali risultati correlati.
     • Chronicle: link a Google SecOps.

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 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: esamina in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di analizzare le minacce e di utilizzare le entità correlate in una sequenza temporale unificata. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare gli indicatori di interesse e semplificare le indagini.

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

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

   Vai ai risultati

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

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

   La tabella si compila con i risultati di Event Threat Detection.

4. Nella tabella, sotto categoria, 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 Google SecOps.

Utilizza le seguenti guide per condurre indagini in Google SecOps:

• Analisi di un utente
• Analisi di una risorsa

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel file JSON del risultato.

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 i metodi di attacco e di risposta

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

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 i 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 tenere 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 a livello di progetto del livello Premium di Security Command Center, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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

   • Che cosa è stato rilevato:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli delle tabelle da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli sulle tabelle in cui erano archiviati i dati esfiltrati.
   • Risorsa interessata:
     • Nome completo della 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: collega a eventuali risultati correlati.

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

4. Nel file JSON, tieni presente 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: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel JSON dei risultati (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 scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Per trovare i log delle attività di amministrazione relativi ai job BigQuery, utilizza i seguenti filtri:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per 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 dei risultati. I risultati correlati sono lo stesso tipo di risultato nella stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per l'entità elencata nella riga Email entità nella scheda Riepilogo dei dettagli dei risultati fino al completamento dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati che sono identificati nel campo Origini esfiltrazione della scheda Riepilogo dei dettagli nella ricerca.
• Per analizzare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i 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 tenere 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 rilevare il seguente scenario:

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Exfiltration: BigQuery Data to Google Drive, come 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 della tabella BigQuery da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli della destinazione su Google Drive.
   • Risorsa interessata, tra cui:
     • Nome completo della 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: collega a eventuali risultati correlati.

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

4. Nel file JSON, tieni presente 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: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel JSON dei risultati (dal Passaggio 1).

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato nel 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. Per trovare i log delle attività di amministrazione relativi ai job BigQuery, utilizza i seguenti filtri:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 4: ricerca i metodi di attacco e di risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 i 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 tenere 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 in tempo reale esportati in un bucket Cloud Storage al di fuori dell'organizzazione.
• Dati delle istanze live esportati in un bucket Cloud Storage di proprietà dell'organizzazione e accessibile pubblicamente.

Sono supportati tutti i tipi di istanza Cloud SQL.

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Exfiltration: Cloud SQL Data Exfiltration, come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il progetto Google Cloud che contiene i dati 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: collega a eventuali risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel JSON per il risultato, tieni presente 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: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

2. Se necessario, seleziona il progetto dell'istanza elencata nel campo projectId nel file JSON dei risultati (dal 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 (vedi Passaggio 1). Verifica 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 i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per 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 descritta 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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per access.principalEmail fino al termine dell'indagine.
• Per arrestare 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 backup e di istanza Cloud SQL.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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 dell'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: collega a eventuali risultati correlati.

4. Fai clic sulla scheda JSON.

5. Nel file JSON, tieni presente i seguenti campi.

   • resource:
     • parent_name: il nome della 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: controlla le autorizzazioni e le 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 file JSON dei risultati (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 in URI Cloud Logging (dal Passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza Cloud SQL pertinente.

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
2. Per esaminare i risultati correlati, fai clic sul link nella riga Risultati correlati. (dal 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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per l'entità elencata nella riga Email entità nella scheda Riepilogo dei dettagli dei risultati fino al completamento dell'indagine.
• Per arrestare 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 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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 Cloud SQL PostgreSQL interessata.
     • Nome utente database: l'utente PostgreSQL che ha concesso i privilegi in eccesso.
     • Query sul database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari database: i beneficiari dei privilegi overbroad.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa dell'istanza PostgreSQL di Cloud SQL 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: collega a eventuali risultati correlati.

3. Per visualizzare il file JSON completo per il 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 verifica quali privilegi sono assegnati al database elencato in Nome visualizzato del database (dal Passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e controlla quali privilegi sono assegnati per funzioni o 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 in URI 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 PostgreSQL pgaudit, che registrano le query eseguite sul database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessarie ulteriori misure 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 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 dai beneficiari (da Beneficiari 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. Il super user (un ruolo con accesso molto ampio) in genere non dovrebbe essere utilizzato per scrivere nelle tabelle degli utenti. Un account utente con accesso più limitato deve essere utilizzato per la normale attività quotidiana. Quando 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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 database: il super user.
     • Query sul database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della 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: collega a eventuali risultati correlati.

3. Per visualizzare il file JSON completo per il 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 i log pgaudit PostgreSQL o gli audit log Cloud SQL per MySQL, che contengono le query eseguite dal super user, utilizzando i seguenti filtri:
   • protoPayload.request.user="SUPERUSER"

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessarie ulteriori misure 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Controlla gli utenti autorizzati a connettersi al database.

  • Per PostgreSQL, consulta Creare e gestire gli utenti
  • Per MySQL, vedi Gestire gli utenti con autenticazione integrata

• Valuta la possibilità di cambiare la password del super user.

  • 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 utente potenzialmente malintenzionato 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 generalmente anonimi. Un'associazione del controllo degli accessi basato su ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione per creare quelle 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, consulta il messaggio di log per questo risultato.

Per limitare il 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 malintenzionato ha utilizzato uno dei seguenti utenti o gruppi di utenti predefiniti di Kubernetes per modificare una risorsa Kubernetes nel cluster:

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

Questi utenti e gruppi sono generalmente anonimi. Un'associazione di controllo degli accessi basato su ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione per modificare quelle 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, consulta il messaggio di log per questo risultato.

Per limitare il 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione Che cosa è stato rilevato:

   • Email entità: 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.
   • Nome metodo: il metodo chiamato

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Utilizzare gli strumenti dell'account di servizio, come Analisi attività, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario dell'account di servizio nel campo Email 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, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 perderanno l'accesso. Prima di procedere, 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 tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica 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.

Initial Access: Dormant Service Account Key Created

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione Che cosa è stato rilevato:

   • Email entità: 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 i metodi di attacco e di risposta

1. Utilizzare gli strumenti dell'account di servizio, come Analisi attività, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Email 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, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Annulla la validità della chiave dell'account di servizio appena creata nella pagina Account di servizio.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 perderanno l'accesso. Prima di procedere, 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 tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'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 strumento 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 pubblicata sulla rete internet pubblica. Ad esempio, le chiavi degli account di servizio vengono pubblicate per errore nel repository GitHub pubblico.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione 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.
   • Nome 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 coinvolta 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 tuo progetto o la tua organizzazione.

3. Nella pagina visualizzata, 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 annotato nel campo Email entità nei dettagli del risultato. Sostituisci SERVICE_ACCOUNT_KEY_NAME con il valore annotato nel campo Nome chiave 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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.
• Potresti 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 perderanno 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 tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'assistenza clienti Google Cloud.

Initial Access: Excessive Permission Denied Actions

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione Che cosa è stato rilevato:

   • Email entità: l'entità che ha generato più errori di autorizzazione negata.
   • Nome servizio: il nome dell'API del servizio Google Cloud in cui si è verificato l'ultimo errore di autorizzazione negata.
   • Nome metodo: il metodo chiamato 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 file JSON:

   • properties.failedActions: gli errori relativi ad autorizzazioni negate 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 la data e l'ora dell'ultimo errore. Vengono 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 visualizzata, trova i log correlati utilizzando il seguente filtro:

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

   Sostituisci PRINCIPAL_EMAIL con il valore annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i metodi di attacco e di risposta

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

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario dell'account nel campo Email entità. Confermare se l'azione è stata eseguita dal legittimo proprietario.
• Elimina le risorse di progetto create da quell'account, ad esempio istanze Compute Engine, snapshot, account di servizio, utenti IAM sconosciuti ecc.
• Contatta il proprietario del progetto con l'account ed eventualmente elimina o disattiva l'account.

Brute Force: SSH

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Brute Force: SSH, come indicato in Revisione 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: collega a eventuali risultati correlati.
     • Chronicle: link a Google SecOps.

3. Fai clic sulla scheda JSON.

4. Nel file JSON, tieni presente i seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId: l'ID progetto e il timestamp per identificare la voce di log
       • projectId: il progetto contenente 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: il risultato dell'autenticazione SSH

Passaggio 2: esamina in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di analizzare le minacce e di utilizzare le entità correlate in una sequenza temporale di facile utilizzo. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare gli indicatori di interesse e semplificare le indagini.

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

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

   Vai ai risultati

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

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

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

4. Nella tabella, sotto categoria, 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 Google SecOps.

Utilizza le seguenti guide per condurre indagini in Google SecOps:

• Analisi di un utente
• Analisi di un indirizzo IP
• Analisi di una risorsa

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla Dashboard.

   Vai alla dashboard

2. Seleziona il progetto specificato 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 disattiva 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 visualizzata, trova i log di flusso VPC relativi all'indirizzo IP elencato nella riga Email principale nella scheda Riepilogo dei dettagli dei risultati utilizzando il seguente filtro:
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Passaggio 5: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per trovare questo tipo di risultato: Account validi: account locali.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati. 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 della tua indagine con la ricerca MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto a cui è stato eseguito il tentativo di forza bruta riuscito.
• Indaga sull'istanza potenzialmente compromessa e rimuovi eventuale malware rilevato. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Valuta la possibilità di disabilitare l'accesso SSH alla VM. Per informazioni sulla disabilitazione delle chiavi SSH, consulta Limitare le chiavi SSH dalle VM. Questo passaggio potrebbe interrompere l'accesso autorizzato alla VM, quindi considera le esigenze della tua organizzazione prima di procedere.
• Utilizza l'autenticazione SSH solo 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 dei risultati

1. Apri un risultato 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: collega a eventuali risultati correlati.

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

4. Nel file JSON, tieni presente 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 che vuoi esaminare.

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

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

   Per rimuovere i membri, devi essere un amministratore di Google Workspace oppure devi avere il 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 progetto.

   

3. Nella pagina visualizzata, controlla i log per verificare le modifiche 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 i 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 necessarie ulteriori misure 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 (un gruppo a cui sono stati assegnati autorizzazioni o ruoli sensibili) viene modificato per essere accessibile al pubblico. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato 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 potrebbero essere compromesse.
   • 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: collega a eventuali risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente 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 relativa alla partecipazione del gruppo

Passaggio 2: esamina le impostazioni di accesso ai gruppi

1. Vai alla Console di amministrazione di Google Gruppi. Per accedere alla console devi essere un amministratore di Google Workspace.

   Vai alla Console di amministrazione

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

3. Fai clic sul nome del gruppo che vuoi esaminare.

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

5. Nel menu a discesa, se necessario, modifica l'impostazione di 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 progetto.

   

3. Nella pagina visualizzata, controlla i log per verificare la presenza di modifiche alle impostazioni del gruppo Google utilizzando i seguenti filtri:

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

Passaggio 4: ricerca i 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 necessarie ulteriori misure 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'account di servizio Kubernetes default di un pod è stato utilizzato per accedere agli oggetti Secret nel cluster. L'account di servizio Kubernetes default non deve avere accesso agli oggetti Secret, a meno che tu non abbia concesso esplicitamente l'accesso con un oggetto Role o un oggetto ClusterRole.

Credential Access: Sensitive Role Granted To Hybrid Group

Rileva la concessione di autorizzazioni o ruoli sensibili a un gruppo Google con membri esterni. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Credential Access: Sensitive Role Granted To Hybrid Group, come indicato in Analisi dei risultati. Il riquadro dei dettagli dei risultati 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 potrebbero essere compromesse.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo 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: collega a eventuali risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente 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 maggiori informazioni, consulta la sezione Autorizzazioni obbligatorie.

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 progetto.

   

3. Nella pagina visualizzata, controlla i log per verificare la presenza di modifiche alle impostazioni del gruppo Google utilizzando i seguenti filtri:

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

Passaggio 4: ricerca i 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 necessarie ulteriori misure 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 i log di Cloud DNS per individuare le connessioni a domini e indirizzi IP di comando e controllo noti. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Malware: Cryptomining Bad IP, come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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: il sospetto indirizzo IP del cryptomining.
     • 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, inclusi i seguenti campi:
     • URI di Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali 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 campo seguente:

   • 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 file JSON completo per il risultato, fai clic sulla scheda JSON.

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato 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 l'istanza potenzialmente compromessa per verificare la presenza di malware.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disattiva 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 i 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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto che contiene malware.
• Indaga sull'istanza potenzialmente compromessa e rimuovi eventuale malware rilevato. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Se necessario, arresta l'istanza compromessa e sostituiscila con una nuova.
• 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 di 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 le 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Initial Access: Log4j Compromise Attempt, come indicato in Esaminare i dettagli 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
   • 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: collega a eventuali risultati correlati.
   • Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.

   • Nel file JSON, tieni presente i seguenti campi.

   • properties

     • loadBalancerName: il 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 Cloud Logging visualizzato nel passaggio 1.

2. Nella pagina visualizzata, verifica la presenza nei campi httpRequest di token di stringa come ${jndi:ldap:// che potrebbero indicare possibili tentativi di sfruttamento.

   Vedi CVE-2021-44228: rilevamento dell'exploit Log4Shell nella documentazione di Logging per esempi di stringhe da cercare e per una query di esempio.

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Exploit Public-Facing Application.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati. 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 della tua indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Esegui l'upgrade all'ultima versione di Log4j2.
• Segui i suggerimenti di Google Cloud per indagare 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 nuovo o esistente di Google Cloud Armor. Per maggiori informazioni, consulta Regola WAF di Google Cloud Armor per contribuire a mitigare la vulnerabilità di Apache Log4j

Active Scan: Log4j Vulnerable to RCE

Gli scanner di vulnerabilità di Log4j supportati inseriscono ricerche JNDI offuscate nei parametri HTTP, negli URL e nei 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à Log4j attiva. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Active Scan: Log4j Vulnerable to RCE, come indicato in Esaminare i dettagli 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
   • Risorsa interessata, in particolare il seguente campo:
     • Nome completo della risorsa: il nome completo della risorsa dell'istanza di Compute Engine vulnerabile a RCE di Log4j.
   • 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: collega a eventuali risultati correlati.

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

4. Nel file JSON, tieni presente i seguenti campi.

   • properties
     • scannerDomain: il dominio utilizzato dallo scanner come parte della ricerca JNDI. Indica quale scanner ha identificato la vulnerabilità.
     • sourceIp: l'indirizzo IP utilizzato per eseguire 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 Cloud Logging visualizzato nel passaggio 1.

2. Nella pagina visualizzata, verifica la presenza nei campi httpRequest di token di stringa come ${jndi:ldap:// che potrebbero indicare possibili tentativi di sfruttamento.

   Vedi CVE-2021-44228: rilevamento dell'exploit Log4Shell nella documentazione di Logging per esempi di stringhe da cercare e per una query di esempio.

Passaggio 3: ricerca i 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 in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati. 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 della tua indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Esegui l'upgrade all'ultima versione di Log4j2.
• Segui i suggerimenti di Google Cloud per indagare 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 nuovo o esistente di Google Cloud Armor. Per maggiori informazioni, consulta Regola WAF di Google Cloud Armor per contribuire a 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 per errore online o compromesse. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di account_has_leaked_credentials, come indicato in Esaminare i dettagli 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
• 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 che contiene le credenziali dell'account potenzialmente divulgate
   • URL: il link al repository GitHub

2. Per visualizzare il file JSON completo per il 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, nella casella Filtro, inserisci il nome dell'account di servizio compromesso e controlla le chiavi e le date di creazione delle chiavi 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 visualizzata, controlla i log per 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 i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Valid Accounts: Cloud Accounts.
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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con credenziali divulgate.
• Valuta la possibilità di eliminare l'account di servizio compromesso, quindi ruota ed elimina tutte le chiavi di accesso degli account di servizio del progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. 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 individuare le connessioni a domini e indirizzi IP di comando e controllo noti. Attualmente, Event Threat Detection offre funzioni di rilevamento generale del malware (Malware: Bad IP e Malware: Bad Domain) e rilevatori, in particolare per il malware correlato a Log4j (Log4j Malware: Bad IP e Log4j Malware: Bad Domain).

I passaggi seguenti spiegano come indagare e rispondere ai risultati basati sull'IP. I passaggi per la correzione sono simili per i risultati basati sul dominio.

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato di malware pertinente. I passaggi seguenti utilizzano il risultato Malware: Bad IP, come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 Bad IP risultati, l'indirizzo IP che ha attivato il risultato.
     • IP di origine: per i risultati Bad IP, un comando e un indirizzo IP di controllo noti di malware.
     • Porta di origine: per Bad IP risultati, la porta di origine della connessione.
     • IP di destinazione: per Bad IP risultati, l'indirizzo IP di destinazione del malware.
     • Porta di destinazione: per Bad IP risultati, la porta di destinazione della connessione.
     • Protocollo: per Bad IP risultati, 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 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: collega a eventuali risultati correlati.
     • Chronicle: link a Google SecOps.
     • 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: esamina in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di analizzare le minacce e di utilizzare le entità correlate in una sequenza temporale di facile utilizzo. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare gli indicatori di interesse e semplificare le indagini.

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

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

   Vai ai risultati

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

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

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

4. Nella tabella, sotto categoria, fai clic sul risultato Malware: Bad IP. Si apre il riquadro dei dettagli per il 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 Google SecOps.

Utilizza le seguenti guide per condurre indagini in Google SecOps:

• Analisi di un indirizzo IP
• Analisi di una risorsa

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato 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 disattiva 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 visualizzata, 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 selezionando 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 i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Dynamic Resolution e Command and Control.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati. 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 della tua indagine con la ricerca MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto che contiene malware.
• Indaga sull'istanza potenzialmente compromessa e rimuovi eventuale malware rilevato. 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, arresta l'istanza compromessa e sostituiscila con una nuova.
• 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 di 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 i criteri IAM Shielded VM e Trusted Immagini.

Malware: Outgoing DoS

Event Threat Detection rileva il potenziale utilizzo di un'istanza per avviare 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 dei risultati

1. Apri un risultato Malware: Outgoing DoS come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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: collega a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente i seguenti campi.
   • sourceInstanceDetails: l'istanza VM di Compute Engine interessata

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato 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, tra cui le impostazioni di rete e di accesso.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disattiva 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 visualizzata, 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 file JSON del risultato.
     • DESTINATION_IP con l'indirizzo IP elencato nel campo destIp nel file JSON del risultato.

Passaggio 4: ricerca i 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 in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati. 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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto che sta riscontrando traffico DoS in uscita.
• Indaga sull'istanza potenzialmente compromessa e rimuovi eventuale malware rilevato. 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, arresta l'istanza compromessa e sostituiscila con una nuova.
• 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 di 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 i criteri 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 di 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 ciascuna istanza di questo 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 a sensibilità media a livello di organizzazione. Per maggiori informazioni, consulta la pagina Ruoli altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo di sensibilità media. Per maggiori informazioni, vedi 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 a sensibilità media a livello di organizzazione. Per maggiori informazioni, consulta la pagina Ruoli altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo di sensibilità media. Per maggiori informazioni, vedi 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Persistence: IAM Anomalous Grant come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 entità: l'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: collega a eventuali risultati correlati.
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: link a Google SecOps.

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

4. Nel JSON per il risultato, tieni presente i seguenti campi:

   • detectionCategory:
     • subRuleName: informazioni più specifiche sul tipo di concessione anomala che si è 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: esamina in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di analizzare le minacce e di utilizzare le entità correlate in una sequenza temporale di facile utilizzo. Google SecOps 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 ai risultati

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

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

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

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

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 Google SecOps.

Utilizza le seguenti guide per condurre indagini in Google SecOps:

• Analisi di un utente
• Analisi di 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 i metodi di attacco e di risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 di progetto create da account non autorizzati, come istanze Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare l'aggiunta di utenti gmail.com, utilizza i Criteri 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 un ruolo di rappresentazione viene concesso a un'entità che consente a quest'ultima di impersonare un account di servizio gestito dall'utente inattivo. In questo risultato, l'account di servizio inattivo è la risorsa interessata, mentre un account di servizio viene considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione.
   • Offending access grants.Principal name: 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 i metodi di attacco e di risposta

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, in 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Rimuovi il ruolo di rappresentazione appena concesso dal membro di destinazione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 perderanno l'accesso. Prima di procedere, 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 tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'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 strumento 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 un ruolo sensibile viene concesso a un account non gestito. Gli account non gestiti non possono essere controllati dagli amministratori di sistema. Ad esempio, se il dipendente corrispondente ha lasciato l'azienda, l'amministratore non può eliminare l'account. Di conseguenza, la concessione di ruoli sensibili agli account non gestiti crea un potenziale rischio per la sicurezza per l'organizzazione.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione.
   • Offending access grants.Principal name (Nome entità dell'accesso con accesso con problemi): l'account non gestito che riceve la concessione
   • Concessione di accesso con accesso con problemi.Role concesso: il ruolo sensibile concesso.

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario del campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Verifica con il proprietario del campo Offending access grants.Principal name (Nome entità) per scoprire l'origine dell'account non gestito.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, in 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Rimuovi il ruolo sensibile appena concesso dall'account non gestito.
• Valuta la possibilità di convertire l'account non gestito in account gestito utilizzando lo strumento di trasferimento e di spostare questo account sotto il controllo degli amministratori di sistema.

Persistence: New API Method

È stata rilevata un'attività di amministrazione anomala da parte di un utente potenzialmente malintenzionato in un'organizzazione, una cartella o un progetto. Le attività anomale possono essere:

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

Passaggio 1: esamina i dettagli dei risultati

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
     • Nome metodo: il metodo chiamato
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il nome della risorsa interessata, che potrebbe corrispondere a quello dell'organizzazione, della cartella o del progetto.
     • Percorso della risorsa: la posizione nella gerarchia delle risorse in cui si è verificata l'attività

Passaggio 2: ricerca i 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 era 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 sono visualizzati nella riga Percorso risorsa, mentre l'account è visualizzato nella riga Email entità.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Persistence: New Geography

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

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

Passaggio 1: esamina i dettagli dei risultati

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: collega a eventuali risultati correlati.

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

2. Nel file JSON, tieni presente 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: indirizzo IP esterno.
     • notSeenInLast: il periodo di tempo utilizzato per stabilire una base di riferimento per il comportamento normale.
     • typicalGeolocations: le località da cui l'utente accede solitamente alle risorse Google Cloud.

Passaggio 2: rivedi 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 file JSON del risultato.

3. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato in Email entità 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 progetto.
3. Nella pagina visualizzata, controlla i log per 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 i metodi di attacco e di risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 di progetto create da account non autorizzati, come istanze 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 sta accedendo a Google Cloud tramite software sospetto, come indicato da uno user agent anomalo.

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Persistence: New User Agent, come indicato in 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: collega a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente 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 una base di riferimento per il normale comportamento.

Passaggio 2: rivedi 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 indicato nella riga Email principale nella scheda Riepilogo dei dettagli del risultato e controlla 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 indicato nella riga Email principale nella 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 progetto.
3. Nella pagina visualizzata, controlla i log per 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 i metodi di attacco e di risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 di progetto create da account non autorizzati, come istanze 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 eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha tentato di modificare un oggetto con controllo degli accessi basato su ruoli (RBAC) ClusterRole, RoleBinding o ClusterRoleBinding del ruolo cluster-admin sensibile utilizzando una richiesta PUT o PATCH.

Passaggio 1: esamina i dettagli dei risultati

1. Apri la ricerca 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.
     • Nome metodo: il metodo chiamato.
     • Associazioni Kubernetes: l'associazione Kubernetes sensibile o ClusterRoleBinding che è stato modificato.
   • 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: collega a eventuali risultati correlati.

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

4. Prendi nota dei relativi dettagli nell'associazione visualizzata.

Passaggio 2: controlla i log

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

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

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

3. Verifica 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 annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i 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 ha bisogno del ruolo a cui è associato.
4. Determina se esistono altri indicatori di attività dannosa da parte dell'entità nei log.

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

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

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

Privilege Escalation: Create Kubernetes CSR for master cert

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha creato una richiesta di firma del certificato (CSR) master Kubernetes, che concede l'accesso cluster-admin.

Passaggio 1: esamina i dettagli dei risultati

1. Apri la ricerca Privilege Escalation: Create Kubernetes CSR for master cert come indicato in Analisi dei risultati. Il riquadro dei dettagli dei risultati 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.
     • 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: collega a eventuali risultati correlati.

Passaggio 2: controlla i log

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

3. Verifica 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 annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i 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'accesso a cluster-admin era garantito.

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

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

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

Privilege Escalation: Creation of sensitive Kubernetes bindings

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha tentato di creare un nuovo oggetto RoleBinding o ClusterRoleBinding per il ruolo cluster-admin.

Passaggio 1: esamina i dettagli dei risultati

1. Apri la ricerca 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 Kubernetes sensibile o ClusterRoleBinding creata.
   • 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: collega a eventuali risultati correlati.

Passaggio 2: controlla i log

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

2. Verifica 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 annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i 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 gli oggetti.
3. Per le associazioni, puoi controllare l'oggetto e verificare se ha bisogno del ruolo a cui è associato.
4. Determina se esistono altri indicatori di attività dannosa da parte dell'entità nei log.

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

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

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

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha eseguito una query per ottenere una richiesta di firma del certificato (CSR) con il comando kubectl utilizzando 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 dei risultati

1. Apri la ricerca 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.
     • 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: collega a eventuali risultati correlati.

Passaggio 2: controlla i log

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

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

Passaggio 3: ricerca i 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, analizza la sensibilità del certificato e se l'azione è giustificata.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

Un utente potenzialmente malintenzionato ha creato un pod contenente container con privilegi o con funzionalità di escalation dei privilegi.

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri la ricerca 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: collega a eventuali risultati correlati.

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

   • findings.kubernetes.pods[].containers: il container con privilegi attivato all'interno del pod.

Passaggio 2: controlla i log

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

2. Verifica 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 annotato nel campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i 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 dell'host e alle funzionalità del kernel.
3. Determina se esistono altri indicatori di attività dannosa da parte dell'entità nei log.

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

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

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

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Rileva gli eventi in cui un ruolo IAM sensibile viene concesso 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione.
   • Offending access grants.Principal name: l'account di servizio inattivo che ha ricevuto il ruolo sensibile.
   • Concedi accesso con problemi. Ruolo concesso: il ruolo IAM sensibile assegnato.

   In Risorsa interessata:

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, in 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Rimuovi il ruolo IAM sensibile appena assegnato dall'account di servizio inattivo.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi ruota ed elimina 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 perderanno l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dall'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 strumento per suggerimenti IAM.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

La rappresentazione anomala dell'account di servizio viene rilevata esaminando gli audit log delle attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di impersonificazione di un account di servizio.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 entità: 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.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla 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: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi ruota ed elimina 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 perderanno l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica 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.

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 sono verificate anomalie in una richiesta di impersonificazione di un account di servizio.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, come indicato in Revisione 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 entità: 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.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla 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: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi ruota ed elimina 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 perderanno l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica 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.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 entità: 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
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla 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: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi ruota ed elimina 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 perderanno l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica 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.

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 sono verificate anomalie in una richiesta di impersonificazione di un account di servizio.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 entità: 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
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla 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: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi ruota ed elimina 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 perderanno l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica 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.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

L'identità anomala dell'account di servizio viene rilevata esaminando gli audit log di accesso ai dati per verificare se si sono verificate anomalie in una richiesta di rappresentazione degli account di servizio.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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.

   Nella sezione Che cosa è stato rilevato:

   • Email entità: 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
   • Nome metodo: il metodo chiamato
   • Informazioni relative alla 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 i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi ruota ed elimina 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 perderanno l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica 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.

Service account self-investigation

Le credenziali di un account di servizio vengono utilizzate per esaminare ruoli e autorizzazioni associati allo stesso account di servizio. Questo risultato indica che le credenziali dell'account di servizio potrebbero essere compromesse e che dovrebbero essere intraprese azioni immediate.

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Discovery: Service Account Self-Investigation, come indicato in 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 al risultato. La gravità è HIGH se la chiamata API che ha attivato questo risultato non era autorizzata: l'account di servizio non dispone dell'autorizzazione per eseguire query sulle proprie autorizzazioni IAM con l'API projects.getIamPolicy.
     • Email principale: l'account di servizio potenzialmente compromesso.
     • IP chiamante: indirizzo IP interno o esterno
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo 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: collega a eventuali risultati correlati.
   1. Per visualizzare il file JSON completo per il 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 file JSON dei risultati.

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, nella casella Filtro, inserisci il nome dell'account di servizio compromesso e 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 progetto.
3. Nella pagina visualizzata, controlla i log per 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 i 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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 di progetto create dall'account compromesso, ad esempio istanze 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 di 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, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Inhibit System Recovery: Deleted Google Cloud Backup and DR host, come descritto in dettaglio 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:
     • Nome applicazione: il nome di un database o di una VM connessa a Backup &RE
     • Nome host: il nome di un host connesso a Backup &RE
     • Oggetto entità: un utente che ha eseguito 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 MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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ù nell'elenco degli host di Backup & RE.
3. Seleziona l'opzione Aggiungi host per aggiungere nuovamente 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 i criteri di backup a un'applicazione.

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR remove plan, come descritto in dettaglio 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:
     • Nome applicazione: il nome di un database o di una VM connessa a Backup &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, la pianificazione e il tempo di conservazione del backup
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il piano
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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 ed esamina i criteri di backup per ognuna.

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 dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete template, come descritto in dettaglio 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:
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il modello
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'indagine per determinare il modo migliore per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, accedi alla console di gestione.
2. Nella scheda Gestione app, trova le applicazioni interessate che non sono più protette ed esamina i criteri di backup per ognuna.
3. Per aggiungere nuovamente un modello, vai alla scheda Piani di backup, seleziona Modelli, poi seleziona 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 sua posizione di archiviazione.

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete policy, come descritto in dettaglio 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:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza, la pianificazione e il tempo di conservazione del backup
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il criterio
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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, seleziona l'applicazione interessata ed esamina le impostazioni dei criteri applicate all'applicazione.

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 dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete profile, come descritto in dettaglio 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:
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il profilo
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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 Piani di backup, seleziona Profili per visualizzare 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 le destinazioni di archiviazione per le appliance di Backup &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 &RE.

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, come descritto in dettaglio 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:
     • Nome pool di archiviazione: il nome dei bucket di archiviazione in cui sono archiviati i backup
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il pool di archiviazione
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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 Gestisci, seleziona Pool di archiviazione per un elenco di tutti i pool di archiviazione. 3. Esamina le associazioni del 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 aggiungerlo nuovamente.

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 dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR expire image, come descritto in dettaglio 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:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza, la pianificazione e il tempo di conservazione del backup
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'immagine di backup
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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. Vai alla scheda Monitoraggio e seleziona Job per esaminare lo stato del job di eliminazione del 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 dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR expire all images, come descritto in dettaglio 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:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza, la pianificazione e il tempo di conservazione del backup
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui sono state eliminate le immagini di backup
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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. Vai alla scheda Monitoraggio e seleziona Job per esaminare lo stato del job di eliminazione del 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 dei risultati

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR remove appliance, come descritto in dettaglio 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:
     • Nome appliance: il nome di un database o di una VM connessa a Backup &RE
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'appliance
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca i metodi di attacco e di risposta

Contatta il proprietario dell'account di servizio nel campo Email 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 durante l'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 ed esamina i criteri di backup per ciascuna. 3. Per creare una nuova appliance e applicare nuovamente le protezioni alle app non protette, vai a Backup & RE nella console Google Cloud e seleziona l'opzione Esegui il deployment di un'altra appliance di backup o ripristino. 4. Nel menu Archiviazione, configura ogni nuova appliance con una destinazione 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 Backup & DR è stata ridotta.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Impact: Google Cloud Backup and DR reduced backup expiration, come descritto in dettaglio 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:
     • Descrizione: informazioni sul rilevamento
     • Oggetto entità: un account utente o di servizio che ha eseguito un'azione correttamente
   • 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 MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca i 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 durante l'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 l'applicazione interessata per la quale la scadenza del backup è stata ridotta 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 al fine di ridurre la frequenza dei backup.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Impact: Google Cloud Backup and DR reduced backup frequency, come descritto in dettaglio 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:
     • Descrizione: informazioni sul rilevamento
     • Oggetto entità: un account utente o di servizio che ha eseguito un'azione correttamente
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata ridotta la frequenza del backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca i 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 durante l'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 l'applicazione interessata per la quale è stata ridotta la frequenza del 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 di dischi tra le risorse delle istanze Compute Engine. Un disco di avvio potenzialmente modificato è stato collegato al tuo Compute Engine.

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Lateral Movement: Modify Boot Disk Attaching to Instance, come descritto in dettaglio 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.

   Nella sezione Che cosa è stato rilevato:

   • Email entità: 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.
   • Nome metodo: il metodo chiamato

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Utilizzare gli strumenti dell'account di servizio, come Analizzatore attività, per esaminare l'attività dell'account di servizio associato.
2. Contatta il proprietario dell'account di servizio nel campo Email 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, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta l'utilizzo dell'avvio protetto per Compute Engine
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 perderanno l'accesso. Prima di procedere, 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 tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dell'assistenza Google Cloud.

Privilege Escalation: AlloyDB Over-Privileged Grant

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato 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 i privilegi in eccesso.
     • Query sul database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari database: i beneficiari dei privilegi overbroad.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della 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 file JSON completo per il 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 verifica quali privilegi sono assegnati al database elencato in Nome visualizzato del database (dal Passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e controlla quali privilegi sono assegnati per funzioni o 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 in URI 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 PostgreSQL pgaudit, che registrano le query eseguite sul database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessarie ulteriori misure 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• 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 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 dai beneficiari (da Beneficiari database del Passaggio 1).

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Rileva quando l'account super user del database AlloyDB per PostgreSQL (postgres) scrive nelle tabelle utente. Il super user (un ruolo con accesso molto ampio) in genere non deve essere utilizzato per scrivere nelle tabelle degli utenti. Un account utente con accesso più limitato dovrebbe essere utilizzato per la normale attività quotidiana. 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 del database predefinito e sta modificando i dati. Potrebbe anche indicare pratiche normali ma non sicure.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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 database: il super user.
     • Query sul database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della 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 file JSON completo per il 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 correlati all'istanza AlloyDB per PostgreSQL pertinente.
2. Controlla i log per i log pgaudit PostgreSQL, che contengono le query eseguite dal superutente, utilizzando i seguenti filtri:
   • protoPayload.request.user="postgres"

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Exfiltration Over Web Service.
2. Per determinare se sono necessarie ulteriori misure 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Esamina gli utenti autorizzati a connettersi al database.
• Valuta la possibilità di cambiare la password del super user.
• 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.
  • Aggiorna le credenziali per i client che si connettono all'istanza AlloyDB per PostgreSQL

Rilevamenti dei metadati amministrativi 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 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 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 per Google Workspace, le voci MITRE ATT&CK pertinenti 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 a causa di 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 della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli dell'evento Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disable_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 utenti malintenzionati. Assicurati che l'account utente rispetti le linee guida di sicurezza della tua organizzazione per password efficaci e 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 della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli degli eventi 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 invita 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 della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli degli eventi Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disable_hijacked

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 intendeva 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 della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1562/ Dettagli degli eventi 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
Gli hacker supportati da governi potrebbero aver tentato di compromettere un account membro o un computer.	Questo account potrebbe essere preso di mira da utenti malintenzionati. Assicurati che l'account utente rispetti le linee guida di sicurezza della tua organizzazione per password efficaci e 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 della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli degli eventi 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 degli eventi 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 dell'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 degli eventi 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 di un criterio da parte di un amministratore o se si tratta di un tentativo da parte di un avversario 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 della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRE: https://attack.mitre.org/techniques/T1562/ Dettagli dell'evento Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_WE_AUTHENTICATION

Rispondere alle minacce relative a Google Workspace

I risultati per Google Workspace sono disponibili solo per le attivazioni di Security Command Center a livello di organizzazione. I log di Google Workspace non possono essere scansionati 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

Gli strumenti includono avvisi, una dashboard per la sicurezza e suggerimenti per la sicurezza e possono aiutarti a indagare e a risolvere le minacce.

Se non sei un amministratore di Google Workspace, segui questi passaggi:

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

Rilevamenti delle minacce di 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 risorse Google Cloud per rilevare eventuali minacce. Quando Cloud IDS rileva una minaccia, invia informazioni sulla minaccia, come l'indirizzo IP di origine, l'indirizzo di destinazione e il numero di porta, a Event Threat Detection, che invia un risultato di minaccia.

Passaggio 1: esamina i dettagli dei risultati

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

2. Nei dettagli dei risultati, 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à: la 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 Logging di Cloud IDS. Queste voci contengono le informazioni necessarie per eseguire ricerche in Threat Vault di Palo Alto Networks
   • Servizio di rilevamento
     • Finding Category (Trova categoria) Il nome della minaccia Cloud IDS

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

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

Risposte di Container Threat Detection

Per ulteriori informazioni su Container Threat Detection, consulta come funziona Container Threat Detection.

Added Binary Executed

È stato eseguito un programma binario che non faceva parte dell'immagine container originale. Gli aggressori di solito installano strumenti di sfruttamento e malware dopo la compromissione iniziale. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del programma binario aggiunto.
     • Argomenti: gli argomenti forniti durante la chiamata del 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: il 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 il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo della 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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e dello 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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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. Per ottenere le credenziali GKE per il tuo cluster, esegui 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à elencata 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 file binario aggiunto.

6. Connettiti all'ambiente dei 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 i 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 della tua indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con il container compromesso.
• Arresta 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 utenti malintenzionati potrebbero caricare librerie dannose nei programmi esistenti al fine di aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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:
     • File binario del programma: il percorso completo del programma binario del processo che ha caricato la libreria.
     • Librerie: dettagli sulla libreria aggiunta.
     • Argomenti: gli argomenti forniti durante la chiamata al 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: il nome dell'immagine container che viene eseguita.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e dello 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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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:

     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 dei 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 i 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 della tua indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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

Execution: Added Malicious Binary Executed

È stato eseguito un programma binario dannoso che non faceva parte dell'immagine container originale. Gli aggressori di solito installano strumenti di sfruttamento e malware dopo la compromissione iniziale. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del programma binario aggiunto.
     • Argomenti: gli argomenti forniti durante la chiamata del programma binario aggiunto.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue 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 il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo della 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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e dello 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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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. Per ottenere le credenziali GKE per il tuo cluster, esegui 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à elencata 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 file binario dannoso aggiunto.

6. Connettiti all'ambiente dei 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 i 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 della tua indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 del file binario 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con il container compromesso.
• Arresta 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 utenti malintenzionati potrebbero caricare librerie dannose nei programmi esistenti al fine di aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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:
     • File binario del programma: il percorso completo del programma binario del processo che ha caricato la libreria.
     • Librerie: dettagli sulla libreria aggiunta.
     • Argomenti: gli argomenti forniti durante la chiamata al file binario del processo.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue 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 il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo della 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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e dello 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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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:

     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 dei 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 i 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 della tua indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 per la libreria contrassegnata come dannosa 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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

Execution: Built in Malicious Binary Executed

Un programma binario eseguito con questo codice:

• Incluso nell'immagine container originale.
• Identificati come dannosi in base alle informazioni sulle minacce.

L'aggressore ha il controllo del repository delle immagini container o della pipeline di creazione, in cui il file binario dannoso viene iniettato nell'immagine container. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Execution: Built in Malicious Binary Executed come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del programma binario integrato.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario integrato.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue 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 il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo della 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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e dello 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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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. Per ottenere le credenziali GKE per il tuo cluster, esegui 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à elencata 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 dei 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 i 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 della tua indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 del file binario 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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

Execution: Modified Malicious Binary Executed

Un programma binario eseguito con questo codice:

• Incluso nell'immagine container originale.
• Modificato durante il runtime del container.
• Identificati come dannosi in base alle informazioni sulle minacce.

Gli aggressori di solito installano strumenti di sfruttamento e malware dopo la compromissione iniziale. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Execution: Modified Malicious Binary Executed come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del programma binario modificato.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario modificato.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue 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 il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo della 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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e dello 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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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. Per ottenere le credenziali GKE per il tuo cluster, esegui 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à elencata 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 file binario dannoso modificato.

6. Connettiti all'ambiente dei 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 i 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 della tua indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 del file binario 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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

Execution: Modified Malicious Library Loaded

Una libreria che è stata caricata, con la libreria in questione:

• Incluso nell'immagine container originale.
• Modificato durante il runtime del container.
• Identificati come dannosi in base alle informazioni sulle minacce.

Gli utenti malintenzionati potrebbero caricare librerie dannose nei programmi esistenti al fine di aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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:
     • File binario del programma: il percorso completo del programma binario del processo che ha caricato la libreria.
     • Librerie: dettagli sulla libreria modificata.
     • Argomenti: gli argomenti forniti durante la chiamata al file binario del processo.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue 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 il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del risultato e dello 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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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:

     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 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 dei 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 i 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 della tua indagine con la ricerca MITRE.
3. Controlla il valore hash SHA-256 per la libreria contrassegnata come dannosa 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 influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con il container compromesso.
• Arresta 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 usare bash per trasferire strumenti ed eseguire comandi senza programmi binari.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Malicious Script Executed come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: 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 letterale, ad esempio bash -c.
     • Argomenti: gli argomenti forniti durante la chiamata dello script.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e nome del cluster.

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

4. Nel file JSON, tieni presente 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 ragioni 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: il nome dell'immagine container che viene eseguita.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo della 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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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 quindi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge i 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. Connettiti all'ambiente dei 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 i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Command and Scripting Interpreter, Ingress Tool Transfer.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con il container compromesso.
• Arresta 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 rilevato 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, segui questi passaggi.

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Malicious URL Observed come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 contenenti l'URL dannoso.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
     • Variabili di ambiente: le variabili di ambiente che sono state efficate quando è stato richiamato il programma binario del processo.
     • Container: il nome 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
       • Il nome del cluster: projects/CLUSTER_NAME

3. Nella scheda JSON, nell'attributo sourceProperties, nota il valore della proprietà VM_Instance_Name.

Passaggio 2: esamina il cluster e il 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, annota tutte le informazioni definite dall'utente che potrebbero essere utili per risolvere la minaccia, ad esempio le informazioni che identificano il proprietario del cluster.

5. Fai clic sulla scheda Nodi.

6. Tra i nodi elencati, seleziona quello che corrisponde al valore di VM_Instance_Name che hai annotato in precedenza nel file JSON dei risultati.

7. Nella scheda Dettagli della pagina Dettagli nodo, nella sezione Annotazioni, prendi nota del valore dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

2. Se necessario, nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato in Nome completo risorsa (resource.name) del cluster nel riepilogo dei risultati.

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) nel riepilogo dei risultati e, se necessario, allo spazio dei nomi del pod (kubernetes.pods.ns) 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 file JSON dei risultati. Si apre la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota delle informazioni sul pod che potrebbero 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 visualizzata, 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 filtro seguente:
      • 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 quindi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge i 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. Connettiti all'ambiente dei 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 i metodi di attacco e di risposta

1. Controlla lo stato dei siti segnalato dalla funzione Navigazione sicura per 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: Ingress Tool Transfer.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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

Reverse Shell

Processo avviato con il reindirizzamento dello stream a un socket connesso remoto. La generazione di una shell connessa in rete può consentire a un utente malintenzionato di eseguire azioni arbitrarie dopo una compromissione iniziale limitata. Per rispondere a questo risultato, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Reverse Shell come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del processo avviato con il reindirizzamento del flusso a un socket remoto.
     • Argomenti: gli argomenti forniti durante la chiamata al 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, tieni presente 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: porta locale
     • Container_Image_Uri: il nome dell'immagine container che viene eseguita.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

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. Se necessario, 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 visualizzata, 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 filtro seguente:
      • 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. Se necessario, 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:

     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 nell'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 i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Command and Scripting Interpreter, Ingress Tool Transfer.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

• Contatta il proprietario del progetto con il container compromesso.
• Arresta 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 abusare di comandi e script di shell.

Per rispondere a questo risultato, segui questi passaggi.

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Unexpected Child Shell come indicato in Revisione dei risultati. Il riquadro dei dettagli dei risultati 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 della shell secondaria.
     • Processo figlio: il processo shell figlio.
     • Argomenti: gli argomenti forniti al file binario del processo della shell secondaria.
     • Variabili di ambiente: le variabili di ambiente del programma binario dei processi della shell figlio.
     • Container: il nome del container.
     • URI 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
       • Il 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 figlio 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 il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

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: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

2. Se necessario, nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato in Nome completo risorsa (resource.name) del cluster nel riepilogo dei risultati.

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) nel riepilogo dei risultati e, se necessario, allo spazio dei nomi del pod (kubernetes.pods.ns) 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 JSON dei risultati. Si apre la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota delle informazioni sul pod che potrebbero 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 visualizzata, 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 filtro seguente:
      • 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 i 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 della tua indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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

Risposta di VM Threat Detection

Per ulteriori informazioni su VM Threat Detection, consulta Panoramica di VM Threat Detection.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection ha rilevato attività di mining di criptovaluta abbinando gli hash di memoria dei programmi in esecuzione con gli hash di memoria del software di mining di criptovaluta noto.

Per rispondere a questi risultati, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Execution: Cryptocurrency Mining Hash Match, come indicato in Esamina 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.
     • File binario del programma: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
     • Nomi processi: il nome del processo in esecuzione nell'istanza VM associato alle corrispondenze della firma rilevate.

     VM Threat Detection può riconoscere le build del kernel dalle principali distribuzioni Linux. Se può riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e completare il campo processes del risultato. Se VM Threat Detection non è in grado di riconoscere il kernel, ad esempio se il kernel è 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 visualizzare il file JSON completo per questo risultato, fai clic sulla scheda JSON nella visualizzazione dettagliata del risultato.

   • indicator
     • signatures:
       • memory_hash_signature: una firma corrispondente agli hash delle pagine della 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 alle pagine nelle applicazioni di criptovaluta note nel database page-hash.

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 nell'istanza VM interessata. Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato 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 in Nome completo risorsa. Esamina i dettagli dell'istanza, tra cui le impostazioni di rete e di accesso.

Passaggio 4: ricerca i 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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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 si tratta di un'applicazione di mining:

   • Se il nome del processo e il percorso binario dell'applicazione rilevata sono disponibili, considera i valori nelle righe File binario del programma, Argomenti e Nomi processi nella scheda Riepilogo dei dettagli del risultato nell'indagine.

   • Se i dettagli del processo non sono disponibili, controlla se il nome binario della firma hash in memoria può fornire indizi. Considera un programma binario chiamato linux-x86-64_xmrig_2.14.1. Puoi utilizzare il comando grep per cercare file di rilievo nello spazio di archiviazione. Utilizza una parte significativa del nome binario nel 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 ce ne sono che non riconosci. Determina se le applicazioni associate sono applicazioni miner.

   • Cerca tra i file nello spazio di archiviazione le stringhe comuni utilizzate dalle applicazioni di mining, come btc.com, ethminer, xmrig, cpuminer e randomx. Per ulteriori esempi di stringhe che è possibile cercare, consulta Nomi software e regole YARA e la relativa documentazione per ciascun software elencato.

3. Se stabilisci che si tratta di un'applicazione miner e il suo processo è ancora in esecuzione, termina 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.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection ha rilevato attività di mining di criptovaluta abbinando pattern di memoria, come le costanti di proof of work, note per essere utilizzate dai software di criptovaluta.

Per rispondere a questi risultati, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato Execution: Cryptocurrency Mining YARA Rule, come indicato in Esamina 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.
     • File binario del programma: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
     • Nomi processi: il nome dei processi in esecuzione nell'istanza VM associato alle corrispondenze della firma rilevate.

     VM Threat Detection può riconoscere le build del kernel dalle principali distribuzioni Linux. Se può riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e completare il campo processes del risultato. Se VM Threat Detection non è in grado di riconoscere il kernel, ad esempio se il kernel è 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: collega a eventuali risultati correlati.
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: link a Google SecOps.

3. Per visualizzare il file JSON completo per 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 nell'istanza VM interessata. Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato nel nome della risorsa elencato nella riga Nome completo della 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, tra cui le impostazioni di rete e di accesso.

Passaggio 4: ricerca i 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 della tua indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

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 si tratta di un'applicazione di mining:

   • Se il nome del processo e il percorso binario dell'applicazione rilevata sono disponibili, considera i valori nelle righe File binario del programma, Argomenti e Nomi processi nella scheda Riepilogo dei dettagli del risultato nell'indagine.

   • Esamina i processi in esecuzione, in particolare quelli con un elevato utilizzo della CPU, per vedere se ce ne sono che non riconosci. Determina se le applicazioni associate sono applicazioni miner.

   • Cerca tra i file nello spazio di archiviazione le stringhe comuni utilizzate dalle applicazioni di mining, come btc.com, ethminer, xmrig, cpuminer e randomx. Per ulteriori esempi di stringhe che è possibile cercare, consulta Nomi software e regole YARA e la relativa documentazione per ciascun software elencato.

3. Se stabilisci che si tratta di un'applicazione miner e il suo processo è ancora in esecuzione, termina 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.

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 sia per Execution: Cryptocurrency Mining YARA Rule che per Execution: Cryptocurrency Mining Hash Match findings.

Malware: Malicious file on disk (YARA)

VM Threat Detection ha rilevato un file potenzialmente dannoso analizzando i dischi permanenti di una VM per individuare firme di malware note.

Per rispondere a questi risultati, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Malware: Malicious file on disk (YARA), 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 YARA corrispondente.
     • File: l'UUID della partizione e il percorso relativo del file potenzialmente dannoso rilevato.
   • 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 visualizzare il file JSON completo per questo risultato, fai clic sulla scheda JSON nella visualizzazione dettagliata del risultato.

4. Nel file JSON, tieni presente i seguenti campi:

   • indicator
     • signatures:
       • yaraRuleSignature: una firma corrispondente alla regola YARA corrispondente.

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 nell'istanza VM interessata. Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato nel nome della risorsa elencato nella riga Nome completo della 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, tra cui le impostazioni di rete e di accesso.

Passaggio 4: ricerca i metodi di attacco e di risposta

Controlla il valore hash SHA-256 per il file contrassegnato come dannoso su VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Nota: VirusTotal potrebbe non contenere hash per tutte le varianti di malware.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.

1. Contatta il proprietario della VM.

2. Se necessario, individua ed elimina il file potenzialmente dannoso. Per ottenere l'UUID della partizione e il percorso relativo del file, fai riferimento al campo File nella scheda Riepilogo dei dettagli del risultato. Per facilitare il rilevamento e la rimozione, usa una soluzione di rilevamento e risposta degli endpoint.

3. Se necessario, arresta l'istanza compromessa e sostituiscila con una nuova.

   Nota: con il livello Security Command Center Enterprise, puoi anche eseguire questa azione tramite un playbook di risposta alle minacce.

4. Per l'analisi forense, esegui il backup delle macchine virtuali e dei dischi permanenti. Per ulteriori informazioni, consulta le opzioni di protezione dei dati nella documentazione di Compute Engine.

5. Per ulteriori indagini, valuta la possibilità di utilizzare servizi di risposta agli incidenti come Mandiant.

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 il risultato della minaccia e copia il valore di un attributo che probabilmente verrà visualizzato nell'eventuale vulnerabilità o nel rilevamento di errori di configurazione correlati, come l'indirizzo email principale o il nome della risorsa interessata.

3. Nella pagina Risultati, apri l'Editor di query facendo clic su Modifica query.

4. Fai clic su Aggiungi filtro. Si apre il menu Seleziona filtro.

5. Dall'elenco delle categorie di filtro a sinistra del menu, seleziona la categoria contenente l'attributo che hai annotato nel rilevamento delle minacce.

   Ad esempio, se hai preso nota del 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 annotato nel risultato della minaccia. A destra si apre un riquadro di ricerca per i valori degli attributi che mostra tutti i valori trovati per il tipo di attributo selezionato.

7. Nel campo Filtro, incolla il valore dell'attributo che hai copiato dal risultato della minaccia. L'elenco di valori visualizzato viene aggiornato in modo da mostrare solo i valori corrispondenti al valore incollato.

8. Dall'elenco dei valori visualizzati, seleziona uno o più valori e fai clic su Applica. Il riquadro Risultati query dei risultati si aggiorna per mostrare solo i risultati corrispondenti.

9. Se ci sono molti risultati nei risultati, filtrali selezionando filtri aggiuntivi dal 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 Classe dei risultati del riquadro Filtri rapidi e seleziona Vulnerabilità e Configurazione errata.

Oltre agli indicatori di compromissione forniti da Google, gli utenti clienti di Palo Alto Networks possono integrare AutoFocus Threat Intelligence di Palo Alto Networks con Event Threat Detection. AutoFocus è un servizio di threat intelligence che fornisce informazioni sulle minacce di rete. Per saperne di più, visita la pagina AutoFocus nella console Google Cloud.

Correggere le minacce

La correzione dei risultati di Event Threat Detection e Container Threat Detection non è semplice come correggere gli errori di configurazione e le vulnerabilità identificate da Security Command Center.

Le configurazioni errate e le violazioni della conformità identificano i punti deboli nelle risorse che potrebbero essere sfruttate. In genere, gli errori di configurazione sono noti e facilmente implementabili, come l'abilitazione di un firewall o la rotazione di una chiave di crittografia.

Le minacce si differenziano dalle vulnerabilità in quanto sono dinamiche e indicano un possibile exploit attivo contro una o più risorse. Un suggerimento di correzione potrebbe non essere efficace per la protezione delle risorse perché i metodi esatti utilizzati per ottenere 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 sottostante che ha consentito all'utente malintenzionato di accedere all'esecuzione del programma binario. Per correggere l'exploit, devi scoprire il modo in cui l'immagine container è stata danneggiata. Per determinare se il file è stato aggiunto tramite una porta non configurata correttamente o con altri mezzi, è necessario un'indagine approfondita. Un analista con una conoscenza approfondita del sistema potrebbe aver bisogno di esaminarlo per individuare i punti deboli.

I malintenzionati attaccano le risorse utilizzando tecniche diverse, quindi applicare una correzione per un exploit specifico potrebbe non essere efficace contro le varianti di tale attacco. Ad esempio, in risposta a un risultato Brute Force: SSH, potresti abbassare i livelli di autorizzazione per alcuni account utente per 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 di correzione che funzionino in tutte le situazioni. Il ruolo di Security Command Center nel tuo piano di sicurezza cloud è identificare le risorse interessate quasi in tempo reale, indicare le minacce che devi affrontare e fornire prove e contesto a supporto delle indagini. Tuttavia, il personale addetto alla sicurezza deve utilizzare le informazioni esaustive nei risultati di Security Command Center per determinare i modi migliori per risolvere i problemi e proteggere le risorse da attacchi futuri.

Passaggi successivi

• Per ulteriori informazioni sul servizio e sulle minacce rilevate, vedi Panoramica di Event Threat Detection.

• Per scoprire come funziona il servizio, consulta la panoramica di Container Threat Detection.

• Consulta la panoramica di VM Threat Detection per ulteriori informazioni sul servizio e sulle minacce rilevate.