Analisi e risposta alle minacce

Questo documento offre una guida informale per aiutarti a esaminare i risultati di attività sospette nel tuo ambiente Google Cloud da parte di attori potenzialmente dannosi. Questo documento fornisce anche risorse aggiuntive per aggiungere contesto ai risultati di Security Command Center. Seguendo questi passaggi, puoi capire cosa è successo durante un potenziale attacco e sviluppare possibili risposte per le risorse interessate.

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

Prima di iniziare

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

Informazioni sui risultati della minaccia

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

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

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

Esaminare i risultati

Per esaminare i risultati delle minacce nella console Google Cloud :

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

   Vai a Risultati

2. Se necessario, seleziona il tuo progetto, la tua cartella o la tua organizzazione. Google Cloud

3. Nella sezione Filtri rapidi, fai clic su un filtro appropriato per visualizzare il risultato che ti serve nella tabella Risultati della query sui 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 compilata con i risultati per l'origine selezionata.

4. Per visualizzare i dettagli di un problema specifico, fai clic sul nome del problema 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 problema, fai clic sulla scheda JSON.

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

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

• Voci del framework MITRE ATT&CK. Il framework spiega le tecniche di attacco alle risorse cloud e fornisce indicazioni per la correzione.

• VirusTotal, un servizio di proprietà di Alphabet che fornisce il contesto di file, URL, domini e indirizzi IP potenzialmente dannosi. Se disponibile, il campo Indicatore VirusTotal fornisce un link a VirusTotal per aiutarti a esaminare ulteriormente i potenziali problemi di sicurezza.

  VirusTotal è un'offerta con prezzi separati, limiti di utilizzo e funzionalità diversi. È tua responsabilità comprendere e rispettare le norme di utilizzo dell'API VirusTotal e tutti i costi associati. Per saperne di più, consulta la documentazione di VirusTotal.

Le sezioni seguenti descrivono le potenziali risposte ai risultati 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 minaccia rimane ACTIVE a meno che tu non imposti manualmente la proprietà state su INACTIVE.

Per un falso positivo, valuta la possibilità di lasciare lo stato del risultato come ACTIVE e disattivare la notifica del risultato.

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

Per una minaccia reale, prima di impostare lo stato del risultato su INACTIVE, elimina la minaccia e completa un'indagine approfondita sulla minaccia rilevata, sull'entità dell'intrusione e su eventuali altri risultati e problemi correlati.

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 scoprire di più su Event Threat Detection, consulta come funziona Event Threat Detection.

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

Active Scan: Log4j Vulnerable to RCE

Gli scanner di vulnerabilità Log4j supportati inseriscono ricerche JNDI offuscate in parametri HTTP, URL e campi di testo con callback ai domini controllati dagli scanner. Questo risultato viene generato quando vengono trovate query DNS per i domini non offuscati. Queste query si verificano solo se una ricerca JNDI è andata a buon fine, il che indica una vulnerabilità Log4j attiva. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Active Scan: Log4j Vulnerable to RCE come indicato in Revisione dei 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 Compute Engine vulnerabile all'esecuzione di codice remoto Log4j.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

4. Nel JSON, prendi nota dei seguenti campi.

   • properties
     • scannerDomain: il dominio utilizzato dallo scanner nell'ambito della ricerca JNDI. Indica lo scanner che ha identificato la vulnerabilità.
     • sourceIp: l'indirizzo IP utilizzato per eseguire la query DNS
     • vpcName: il nome della rete sull'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 del passaggio 1.

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

   Consulta CVE-2021-44228: rilevamento di exploit Log4Shell nella documentazione di Logging per esempi di stringhe da cercare e per un esempio di query.

Passaggio 3: ricerca di metodi di attacco e 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 nella sezione Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo e della stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 consigli di Google Cloudper esaminare e risolvere la vulnerabilità "Apache Log4j 2".
• Implementa le tecniche di mitigazione consigliate in Vulnerabilità di sicurezza di Apache Log4j.
• Se utilizzi Google Cloud Armor, implementa cve-canary rule in un criterio di sicurezza di Google Cloud Armor nuovo o esistente. Per saperne di più, vedi Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j.

Brute Force: SSH

Rilevamento di attacco Brute Force riuscito di SSH su un host. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Brute Force: SSH come indicato in 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 con cui è stato eseguito l'accesso.

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

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

3. Fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId: l'ID progetto e il timestamp per identificare la voce di log
       • projectId: il progetto che contiene il problema
     • 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: rivedi 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 disabilita le regole firewall eccessivamente permissive sulla porta 22.

Passaggio 3: controlla i log

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

Passaggio 4: ricerca di metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 tentativo di attacco di tipo brute force riuscito.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Valuta la possibilità di disabilitare l'accesso SSH alla VM. Per informazioni sulla disattivazione delle chiavi SSH, consulta Limita le chiavi SSH dalle VM. Questo passaggio potrebbe interrompere l'accesso autorizzato alla VM, quindi valuta 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: CloudDB Failed login from Anonymizing Proxy IP

Rileva un accesso non riuscito nell'istanza del database da un indirizzo IP di anonimizzazione noto. Questi indirizzi di anonimizzazione sono nodi Tor. Ciò potrebbe indicare che un utente malintenzionato sta tentando di accedere alla tua istanza senza autorizzazione.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Credential Access: CloudDB Failed login from Anonymizing Proxy IP 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:
   • Indirizzo IP indicatore, l'indirizzo IP di anonimizzazione.
   • Nome visualizzato del database: il nome del database nell'istanza Cloud SQL PostgreSQL, MySQL o AlloyDB interessata.
   • Nome utente database: l'utente.
   • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL.

Passaggio 2: ricerca di metodi di attacco e risposta

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

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.

• Esamina gli utenti autorizzati a connettersi al database.

  • Per PostgreSQL, consulta Creare e gestire gli utenti
  • Per MySQL, vedi Gestisci gli utenti con l'autenticazione integrata

• Valuta la possibilità di modificare la password dell'utente.

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

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

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

• Controllare l'accesso di rete all'istanza

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

Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

Qualcuno ha tentato di approvare manualmente una richiesta di firma del certificato (CSR), ma l'azione non è riuscita. La creazione di un certificato per l'autenticazione del cluster è un metodo comune per gli autori degli attacchi per creare un accesso persistente a un cluster compromesso. Le autorizzazioni associate al certificato variano a seconda del soggetto incluso, ma possono essere altamente privilegiate. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina gli audit log in Cloud Logging e gli avvisi aggiuntivi per altri eventi correlati alle CSR per determinare se una CSR è stata approved ed emessa e se le azioni correlate alle CSR sono attività previste dall'entità.
2. Determina se esistono altri indicatori di attività dannosa da parte dell'entità negli audit log in Cloud Logging. Ad esempio:
   • L'entità che ha tentato di approvare la CSR era diversa da quella che l'ha creata?
   • L'entità ha provato a richiedere, creare, approvare o eliminare altre CSR?
3. Se non era prevista l'approvazione di una CSR o se è stata determinata come essere dannosa, il cluster richiederà una rotazione delle credenziali per invalidare il certificato. Consulta le indicazioni per eseguire una rotazione delle credenziali del cluster.

Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)

Qualcuno ha approvato manualmente una richiesta di firma del certificato (CSR). La creazione di un certificato per l'autenticazione del cluster è un metodo comune per gli autori di attacchi per creare un accesso persistente a un cluster compromesso. Le autorizzazioni associate al certificato variano a seconda dell'oggetto incluso, ma possono essere altamente privilegiate. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina gli audit log in Cloud Logging e gli avvisi aggiuntivi per altri eventi correlati alle CSR per determinare se le azioni correlate alle CSR sono attività previste dall'entità.
2. Determina se esistono altri indicatori di attività dannosa da parte dell'entità negli audit log in Cloud Logging. Ad esempio:
   • L'entità che ha approvato la CSR era diversa da quella che l'ha creata?
   • La CSR ha specificato un signer integrato, ma alla fine ha dovuto essere approvata manualmente perché non soddisfaceva i criteri del signer?
   • L'entità ha provato a richiedere, creare, approvare o eliminare altre CSR?
3. Se non era prevista l'approvazione di una CSR o se è stata determinata come essere dannosa, il cluster richiederà una rotazione delle credenziali per invalidare il certificato. Consulta le indicazioni per eseguire una rotazione delle credenziali del cluster.

Credential Access: Secrets Accessed in Kubernetes Namespace

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.

Defense Evasion: Breakglass Workload Deployment Created

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Defense Evasion: Breakglass Workload Deployment Created, come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato, che mostra la 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 che ha eseguito la modifica.
     • Nome metodo: il metodo chiamato.
     • Pod Kubernetes: il nome e lo spazio dei nomi del pod.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato risorsa: lo spazio dei nomi GKE in cui è stato eseguito il deployment.
   • Link correlati:
     • URI Cloud Logging: link alle voci di logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

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

3. Controlla altre azioni intraprese dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

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

Passaggio 3: ricerca di metodi di attacco e 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 nella sezione Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Defense Evasion: Breakglass Workload Deployment Updated

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Defense Evasion: Breakglass Workload Deployment Updated, come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato, che mostra la 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 che ha eseguito la modifica.
     • Nome metodo: il metodo chiamato.
     • Pod Kubernetes: il nome e lo spazio dei nomi del pod.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato risorsa: lo spazio dei nomi GKE in cui si è verificato l'aggiornamento.
   • Link correlati:
     • URI Cloud Logging: link alle voci di logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

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

3. Controlla altre azioni intraprese dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

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

Passaggio 3: ricerca di metodi di attacco e 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 nella sezione Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Defense Evasion: GCS Bucket IP Filtering Modified

Event Threat Detection esamina i log di controllo per rilevare se la configurazione del filtro IP è stata aggiornata in un bucket Cloud Storage.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Defense Evasion: GCS Bucket IP Filtering Modified risultato, come descritto in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 utente o un account di servizio che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato risorsa: il bucket in cui è stata aggiornata la configurazione.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio o dell'account utente nel campo Soggetto entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

Qualcuno ha eliminato manualmente una richiesta di firma del certificato (CSR). Le richieste CSR vengono rimosse automaticamente da un controller di garbage collection, ma gli utenti malintenzionati potrebbero eliminarle manualmente per evitare il rilevamento. Se la CSR eliminata riguardava un certificato approvato ed emesso, l'utente potenzialmente malintenzionato ora dispone di un metodo di autenticazione aggiuntivo per accedere al cluster. Le autorizzazioni associate al certificato variano a seconda dell'oggetto incluso, ma possono essere altamente privilegiate. Kubernetes non supporta la revoca dei certificati. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina gli audit log in Cloud Logging e gli avvisi aggiuntivi per altri eventi relativi a questa CSR per determinare se la CSR è stata approved e se la creazione della CSR era un'attività prevista dall'entità.
2. Determina se esistono altri indicatori di attività dannosa da parte dell'entità negli audit log in Cloud Logging. Ad esempio:
   • L'entità che ha eliminato la CSR era diversa da quella che l'ha creata o approvata?
   • L'entità ha provato a richiedere, creare, approvare o eliminare altre CSR?
3. Se non era prevista l'approvazione di una CSR o se è stata determinata come essere dannosa, il cluster richiederà una rotazione delle credenziali per invalidare il certificato. Consulta le indicazioni per eseguire una rotazione delle credenziali del cluster.

Defense Evasion: Modify VPC Service Control

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

I log di controllo vengono esaminati per rilevare modifiche ai perimetri dei Controlli di servizio VPC che comporterebbero una riduzione della protezione offerta da quel perimetro. Di seguito sono riportati alcuni esempi:

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   • Che cosa è stato rilevato, in particolare il seguente campo:
     • Email entità: 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 che è stato modificato.
   • Link correlati:
     • URI Cloud Logging: link alle voci di logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • sourceProperties
     • properties
       • name: il nome del perimetro dei Controlli di servizio VPC modificato
       • policyLink: il link alla policy di accesso che controlla il perimetro
       • delta: le modifiche, REMOVE o ADD, a un perimetro che ne hanno ridotto la protezione
       • restricted_resources: i progetti che rispettano le limitazioni di questo perimetro. La protezione viene ridotta se rimuovi un progetto
       • restricted_services: i servizi a cui è vietato l'esecuzione a causa delle limitazioni di questo perimetro. La protezione viene ridotta se rimuovi un servizio limitato
       • allowed_services: i servizi autorizzati a essere eseguiti in base alle limitazioni di questo perimetro. La protezione viene ridotta se aggiungi un servizio consentito
       • access_levels: i livelli di accesso configurati per consentire l'accesso alle risorse all'interno del perimetro. La protezione viene ridotta se aggiungi più livelli di accesso

Passaggio 2: controlla i log

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

Passaggio 3: ricerca di metodi di attacco e risposta

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

Passaggio 4: implementa la risposta

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

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

Defense Evasion: Potential Kubernetes Pod Masquerading

Qualcuno ha eseguito il deployment di un pod con una convenzione di denominazione simile ai carichi di lavoro predefiniti che GKE crea per il normale funzionamento del cluster. Questa tecnica è chiamata mascheramento. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannosa da parte del pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Defense Evasion: Project HTTP Policy Block Disabled

Event Threat Detection esamina i log di controllo per rilevare se la policy constraints/storage.secureHttpTransport è stata aggiornata per disattivare il blocco della policy HTTP.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Defense Evasion: Project HTTP Policy Block Disabled risultato, come descritto in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 utente o un account di servizio che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto/la cartella/l'organizzazione in cui è stato aggiornato il criterio.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio o dell'account utente nel campo Soggetto entità. Conferma se l'azione per disattivare i vincoli/i criteri storage.secureHttpTransport è stata eseguita dal proprietario legittimo.

Defensive Evasion: Static Pod Created

Qualcuno ha creato un pod statico nel tuo cluster GKE. I pod statici vengono eseguiti direttamente sul nodo e bypassano il server API Kubernetes, il che li rende più difficili da monitorare e controllare. Questo potrebbe essere utilizzato da malintenzionati per eludere il rilevamento o mantenere la persistenza.

1. Esamina il file manifest del pod statico e il suo scopo. Verifica che sia legittima e necessaria.
2. Valuta se la funzionalità del pod statico può essere ottenuta tramite un pod normale gestito dal server API Kubernetes.
3. Se è necessario il pod statico, assicurati che segua le best practice di sicurezza e che disponga di privilegi minimi.
4. Monitora l'attività del pod statico e il suo impatto sul cluster.

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 del risultato

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

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

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

Passaggio 2: controlla i log

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

2. Nella pagina che viene caricata, verifica altre azioni intraprese dal soggetto utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

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

Passaggio 3: ricerca di metodi di attacco e 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 visto nella riga Email dell'entità nei dettagli del risultato non è un account di servizio, contatta il proprietario dell'account per confermare 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 dell'indagine con la ricerca MITRE.

Evasion: Access from Anonymizing Proxy

L'accesso anomalo da un proxy anonimo viene rilevato esaminando Cloud Audit Logs per le modifiche al servizio Google Cloud provenienti da un indirizzo IP associato alla rete Tor.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Evasion: Access from Anonymizing Proxy come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato, che mostra 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 apportate le modifiche.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. (Facoltativo) Fai clic sulla scheda JSON per visualizzare altri campi dei risultati.

Passaggio 2: ricerca di metodi di attacco e risposta

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

Execution: Cryptomining Docker Image

Rileva quando un servizio o un job Cloud Run viene creato o modificato aggiungendo un'immagine Docker dannosa nota in grado di eseguire il cryptomining.

Per rispondere a questo risultato:

1. Controlla l'immagine container per determinare se era previsto.
2. Elimina il container compromesso e sostituiscilo con uno nuovo.

Execution: GKE launch excessively capable container

Qualcuno ha eseguito il deployment di un container con una o più delle seguenti funzionalità in un cluster GKE con un contesto di sicurezza elevato:

• CAP_SYS_MODULE
• CAP_SYS_RAWIO
• CAP_SYS_PTRACE
• CAP_SYS_BOOT
• CAP_DAC_READ_SEARCH
• CAP_NET_ADMIN
• CAP_BPF

Queste funzionalità sono già state utilizzate per uscire dai container e devono essere sottoposte a provisioning con cautela.

1. Rivedi il contesto di sicurezza del container nella definizione del pod. Identifica le funzionalità non strettamente necessarie per il suo funzionamento.
2. Rimuovi o riduci le funzionalità eccessive, se possibile. Utilizza il principio del privilegio minimo.

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Qualcuno ha creato un pod contenente comandi o argomenti comunemente associati a una shell inversa. Gli autori degli attacchi utilizzano le reverse shell per espandere o mantenere l'accesso iniziale a un cluster ed eseguire comandi arbitrari. Per maggiori dettagli, consulta il messaggio di log per questo avviso.

1. Conferma che il Pod abbia un motivo legittimo per specificare questi comandi e argomenti.
2. Determina se esistono altri indicatori di attività dannosa da parte del pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica la legittimità del motivo per cui ilaccount di serviziot ha eseguito questa azione
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Execution: Suspicious Exec or Attach to a System Pod

Qualcuno ha utilizzato i comandi exec o attach per ottenere una shell o eseguire un comando su un container in esecuzione nello spazio dei nomi kube-system. Questi metodi vengono a volte utilizzati per scopi di debug legittimi. Tuttavia, kube-system namespace è destinato agli oggetti di sistema creati da Kubernetes e l'esecuzione imprevista di comandi o la creazione di shell deve essere esaminata. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina gli audit log in Cloud Logging per determinare se si trattava di un'attività prevista dall'entità.
2. Determina se esistono altri indicatori di attività dannosa da parte dell'entità nei log.

Esamina le indicazioni per l'utilizzo del principio del privilegio minimo per i ruoli RBAC e i ruoli del cluster che hanno consentito questo accesso.

Execution: Workload triggered in sensitive namespace

Qualcuno ha eseguito il deployment di un carico di lavoro (ad esempio un pod o un deployment) negli spazi dei nomi kube-system o kube-public. Questi spazi dei nomi sono fondamentali per le operazioni del cluster GKE e i carichi di lavoro non autorizzati potrebbero compromettere la stabilità o la sicurezza del cluster.

1. Identifica il workload di cui è stato eseguito il deployment e il suo scopo.
2. Se il carico di lavoro non è autorizzato, eliminalo e indaga sull'origine della distribuzione.

Exfiltration: BigQuery Data Exfiltration

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

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Exfiltration: BigQuery Data Exfiltration come indicato in 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 secondaria vpc_perimeter_violation.
     • Email principale: l'account utilizzato per estrarre i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui sono stati estratti i dati.
     • Target di esfiltrazione: dettagli sulle tabelle in cui sono stati archiviati i dati esfiltrati.
   • Risorsa interessata:
     • Nome completo della risorsa: il nome completo della risorsa del progetto, della cartella o dell'organizzazione da cui sono stati sottratti i dati.
   • Link correlati:
     • URI Cloud Logging: link alle voci di logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Fai clic sulla scheda Proprietà origine e controlla 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. (Facoltativo) Fai clic sulla scheda JSON per visualizzare l'elenco completo delle proprietà JSON del risultato.

Passaggio 2: rivedi 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 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 3: controlla i log

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

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

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

Passaggio 4: ricerca di metodi di attacco e 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 sezione Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato sulla stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 i dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per userEmail fino al completamento dell'indagine.
• Per interrompere l'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati (exfiltration.sources e exfiltration.targets).
• Per analizzare i set di dati interessati alla ricerca di 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 i Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: BigQuery Data Extraction

L'esfiltrazione di dati da BigQuery viene rilevata esaminando i log di controllo per due scenari:

• Una risorsa viene salvata in un bucket Cloud Storage al di fuori 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 Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: BigQuery Data Extraction come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 estrarre i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui sono stati estratti i dati.
     • Target di esfiltrazione: dettagli sulle tabelle in cui sono stati archiviati i dati esfiltrati.
   • Risorsa interessata:
     • Nome completo risorsa: il nome della risorsa BigQuery i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • Link correlati:
     • URI Cloud Logging: link alle voci di logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

4. Nel JSON, prendi nota dei 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: rivedi 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 del risultato (dal passaggio 1).

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

Passaggio 3: controlla i log

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

Passaggio 4: ricerca di metodi di attacco e 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 della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato sulla stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 i dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per il principal elencato nella riga Email principal della scheda Riepilogo dei dettagli del risultato fino al completamento dell'indagine.
• Per interrompere l'esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati identificati nel campo Origini di esfiltrazione nella scheda Riepilogo dei dettagli del problema.
• Per analizzare i set di dati interessati alla ricerca di 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 i 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 IAM Recommender.

Exfiltration: BigQuery Data to Google Drive

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

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: BigQuery Data to Google Drive, come indicato in Revisione 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 estrarre i dati.
     • Origini dell'esfiltrazione: dettagli sulla tabella BigQuery da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli sulla destinazione in 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 log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

4. Nel JSON, prendi nota dei 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: rivedi 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 del risultato (dal passaggio 1).

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

Passaggio 3: controlla i log

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

Passaggio 4: ricerca di metodi di attacco e 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 sezione Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato sulla stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 i dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per l'entità nel campo access.principalEmail fino al completamento dell'indagine.
• Per interrompere l'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati (exfiltration.sources).
• Per analizzare i set di dati interessati alla ricerca di 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 i Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: Cloud SQL Data Exfiltration

L'esfiltrazione dei dati da Cloud SQL viene rilevata esaminando i log di controllo per due scenari:

• Dati dell'istanza live esportati in un bucket Cloud Storage al di fuori dell'organizzazione.
• Dati dell'istanza live esportati in un bucket Cloud Storage di proprietà dell'organizzazione e accessibile pubblicamente.

Sono supportati tutti i tipi di istanze Cloud SQL.

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: Cloud SQL Data Exfiltration come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 estrarre i dati.
     • Origini dell'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 risorsa di Cloud SQL i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il Google Cloud progetto che contiene i dati Cloud SQL di origine.
   • Link correlati, tra cui:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel JSON per il risultato, prendi nota dei seguenti campi:

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: il Google Cloud progetto che contiene l'istanza Cloud SQL di origine.
     • properties
     • bucketAccess: indica se il bucket Cloud Storage è accessibile pubblicamente o esterno all'organizzazione
     • exportScope: la 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: rivedi 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 JSON del risultato (dal passaggio 1).

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato nella riga Email principale della scheda Riepilogo dei dettagli del risultato (dal passaggio 1). Controlla le autorizzazioni 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 di metodi di attacco e 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 sulla stessa istanza Cloud SQL.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 i dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per access.principalEmail fino al completamento dell'indagine.
• Per interrompere l'esfiltrazione, aggiungi policy IAM restrittive alle istanze Cloud SQL interessate.
  • MySQL
  • PostgreSQL
  • SQL Server
• Per limitare l'accesso e l'esportazione dall'API Cloud SQL Admin, utilizza i controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: Cloud SQL Over-Privileged Grant

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Exfiltration: Cloud SQL Over-Privileged Grant risultato 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:
     • Nome visualizzato database: il nome del database nell'istanza Cloud SQL PostgreSQL interessata.
     • Nome utente del database: l'utente PostgreSQL che ha concesso privilegi eccessivi.
     • Query del database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari database: i beneficiari dei privilegi eccessivi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa dell'istanza Cloud SQL PostgreSQL interessata.
     • Nome completo del parent: il nome della risorsa dell'istanza Cloud SQL PostgreSQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

Passaggio 2: esamina i privilegi del database

1. Connettiti al database PostgreSQL.
2. Elenca e mostra i privilegi di accesso per quanto segue:
   • Database. Utilizza il metacomando \l o \list e controlla quali privilegi sono assegnati per il database elencato in Nome visualizzato del database (dal passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e controlla quali privilegi sono assegnati alle funzioni o alle 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 Explorer 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 di metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 eccessivi.
• Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari del database fino al completamento dell'indagine.
• Per limitare l'accesso al database (dal Nome visualizzato del database del Passaggio 1, revoca le autorizzazioni non necessarie dai beneficiari (dal Beneficiari del database del Passaggio 1.

Exfiltration: Cloud SQL Restore Backup to External Organization

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Exfiltration: Cloud SQL Restore Backup to External Organization come indicato in 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:
     • Email principale: l'account utilizzato per estrarre i dati.
     • Origini dell'esfiltrazione: dettagli sull'istanza Cloud SQL da cui è stato creato il backup.
     • Destinazioni di esfiltrazione: dettagli sull'istanza Cloud SQL in cui sono stati ripristinati i dati di backup.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa del backup che è stato ripristinato.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza di Cloud SQL da cui è stato creato il backup.

3. Link correlati, in particolare i seguenti campi:

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

4. Fai clic sulla scheda JSON.

5. Nel JSON, prendi nota dei 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 ripristinato

Passaggio 2: rivedi 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 del JSON del risultato (dal passaggio 1).

3. Nella pagina visualizzata, inserisci l'indirizzo email elencato in Email principale (dal passaggio 1) nella casella Filtro 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 Explorer log include tutti i log relativi all'istanza Cloud SQL pertinente.

Passaggio 4: ricerca di metodi di attacco e 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. (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 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 del progetto con i dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni dell'entità elencata nella riga Email entità della scheda Riepilogo dei dettagli del risultato fino al completamento dell'indagine.
• Per interrompere l'esfiltrazione, aggiungi policy IAM restrittive alle istanze Cloud SQL interessate.
  • MySQL
  • PostgreSQL
  • SQL Server
• Per limitare l'accesso all'API Cloud SQL Admin, utilizza i Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Impact: Cryptomining Commands

Rileva quando i comandi di cryptomining noti vengono passati ai job Cloud Run come punti di ingresso che verranno eseguiti quando il job viene eseguito.

Per rispondere a questo risultato:

1. Controlla il job, il comando e il container per determinare se era previsto.
2. Elimina il job e il container compromessi.

Impact: Deleted Google Cloud Backup and DR Backup

Event Threat Detection esamina gli audit log per rilevare se un backup archiviato in un vault di backup è stato eliminato.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Impact: Deleted Google Cloud Backup and DR Backup risultato, come descritto in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 utente o un account di servizio che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stata ridotta la frequenza di backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario del account di servizio nel campo Oggetto entità e conferma se ha eseguito l'azione.

Impact: Deleted Google Cloud Backup and DR host

Event Threat Detection esamina i log di controllo per rilevare l'eliminazione degli host che eseguono applicazioni protette dal servizio di backup e DR. Una volta eliminato un host, non è possibile eseguire il backup delle applicazioni associate.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Impact: Deleted Google Cloud Backup and DR host risultato, come descritto 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:
     • Nome applicazione: il nome di un database o di una VM connessa a Backup and RE
     • Nome host: il nome di un host connesso a Backup and RE
     • Soggetto principale: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stato eliminato l'host
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Verifica che l'host eliminato non sia più presente nell'elenco degli host di Backup e RE.
3. Seleziona l'opzione Aggiungi host per aggiungere nuovamente l'host eliminato.

Impact: Deleted Google Cloud Backup and DR plan association

Event Threat Detection esamina i log di controllo per rilevare se un'associazione di piani è stata eliminata.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Impact: Deleted Google Cloud Backup and DR plan association risultato, come descritto in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 utente o un account di servizio che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stata ridotta la frequenza di backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario del account di servizio nel campo Oggetto entità e conferma se ha eseguito l'azione.

Impact: Deleted Google Cloud Backup and DR Vault

Event Threat Detection esamina i log di controllo per rilevare se il vault di backup è stato eliminato.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

Passaggio 2: ricerca di metodi di attacco e risposta

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

Impact: GKE kube-dns modification detected

Qualcuno ha modificato la configurazione di kube-dns nel tuo cluster GKE. kube-dns di GKE è un componente fondamentale del networking del cluster e la sua errata configurazione potrebbe portare a una violazione della sicurezza.

1. Esamina la configurazione kube-dns del cluster per identificare eventuali modifiche sospette.

Impact: Google Cloud Backup and DR delete policy

I log di controllo vengono esaminati per rilevare l'eliminazione di una policy. Un criterio definisce come viene eseguito un backup e dove viene archiviato.

Passaggio 1: esamina i dettagli del risultato

1. Apri il Impact: Google Cloud Backup and DR delete policy risultato, come descritto 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:
     • Nome norma: il nome di una singola norma, che definisce la frequenza, la pianificazione e il periodo di conservazione del backup
     • Soggetto principale: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stata eliminata la norma
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestione app, seleziona l'applicazione interessata e rivedi le impostazioni dei criteri applicati.

Impact: Google Cloud Backup and DR delete profile

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

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Impact: Google Cloud Backup and DR delete profile, come descritto 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:
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati di applicazioni e VM
     • Soggetto principale: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stato eliminato il profilo
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati. 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 siano presenti tutti quelli richiesti. 4. Se il profilo eliminato è stato rimosso per errore, seleziona Crea profilo per definire le destinazioni di archiviazione per le appliance di backup e RE.

Impact: Google Cloud Backup and DR delete template

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

Passaggio 1: esamina i dettagli del risultato

1. Apri il Impact: Google Cloud Backup and DR delete template risultato, come descritto 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:
     • Nome modello: il nome di un insieme di norme che definiscono la frequenza, la pianificazione e il periodo di conservazione dei backup
     • Soggetto principale: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stato eliminato il modello
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati.

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

Impact: Google Cloud Backup and DR delete storage pool

I log di controllo vengono esaminati per rilevare l'eliminazione di un pool di archiviazione. Un pool di archiviazione associa un bucket Cloud Storage a Backup and RE.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Impact: Google Cloud Backup and DR delete storage pool, come descritto 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:
     • Nome del pool di archiviazione: il nome dei bucket di archiviazione in cui vengono archiviati i backup
     • Soggetto principale: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stato eliminato il pool di archiviazione
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestisci, seleziona Pool di archiviazione per visualizzare un elenco di tutti i pool di archiviazione. 3. Esamina le associazioni del pool di archiviazione con le appliance di backup. 4. Se un'appliance attiva non ha un pool di archiviazione associato, seleziona Aggiungi pool OnVault per aggiungerlo di nuovo.

Impact: Google Cloud Backup and DR expire all images

Un attore potenzialmente dannoso ha richiesto l'eliminazione di tutte le immagini di backup associate a un'applicazione.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Impact: Google Cloud Backup and DR expire all images, come descritto 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:
     • Nome della norma: il nome di una singola norma, che definisce la frequenza, la pianificazione e il periodo di conservazione del backup
     • Nome modello: il nome di un insieme di norme che definiscono la frequenza, la pianificazione e il periodo di conservazione dei backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati di applicazioni e VM
     • Soggetto principale: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui sono state eliminate le immagini di backup
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitora 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.

Impact: Google Cloud Backup and DR expire image

Un malintenzionato ha richiesto l'eliminazione di un'immagine di backup.

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR expire image, come descritto in 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:
     • Nome della norma: il nome di una singola norma, che definisce la frequenza, la pianificazione e il periodo di conservazione del backup
     • Nome modello: il nome di un insieme di norme che definiscono la frequenza, la pianificazione e il periodo di conservazione dei backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati di applicazioni e VM
     • Soggetto principale: un utente che ha eseguito correttamente un'azione.
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stata eliminata l'immagine di backup
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitora 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.

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection esamina i log di controllo per rilevare se la data di scadenza di un backup su un'appliance Backup and DR Service è stata ridotta.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Impact: Google Cloud Backup and DR reduced backup expiration risultato, come descritto in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 utente o un account di servizio che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stata ridotta la scadenza del backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario del account di servizio nel campo Oggetto entità. Conferma 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 problemi riscontrati.

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 scadenza del backup e verifica che la scadenza sia stata voluta dal principal.
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 i log di controllo per rilevare se il piano di backup è stato modificato per ridurre la frequenza di backup.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario del account di servizio nel campo Oggetto entità. Conferma 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 problemi riscontrati.

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 di backup e verifica che la modifica sia stata voluta dal principal.
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 remove appliance

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

Passaggio 1: esamina i dettagli del risultato

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

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda App Manager, individua le applicazioni interessate che non sono più protette ed esamina le norme di backup per ciascuna. 3. Per creare una nuova appliance e riapplicare le protezioni alle app non protette, vai a Backup e RE nella console Google Cloud e seleziona l'opzione Esegui il deployment di un'altra appliance di backup o ripristino. 4. Nel menu Storage, configura ogni nuovo appliance con una destinazione di archiviazione. Dopo aver configurato un elettrodomestico, questo viene visualizzato come opzione quando crei un profilo per le tue applicazioni.

Impact: Google Cloud Backup and DR remove plan

Security Command Center esamina i log di controllo per rilevare l'eliminazione anomala di un piano di backup del servizio di Backup e DR utilizzato per applicare le norme di backup a un'applicazione.

Passaggio 1: esamina i dettagli del risultato

1. Apri il Impact: Google Cloud Backup and DR remove plan risultato, come descritto 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:
     • Nome applicazione: il nome di un database o di una VM connessa a Backup and RE
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati di applicazioni e VM
     • Nome modello: il nome di un insieme di norme che definiscono la frequenza, la pianificazione e il periodo di conservazione dei backup
   • Risorsa interessata
     • Nome visualizzato risorsa: il progetto in cui è stato eliminato il piano
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: ricerca di metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 problemi riscontrati.

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

Impact: Suspicious Kubernetes Container Names - Cryptocurrency Mining

Qualcuno ha eseguito il deployment di un pod con una convenzione di denominazione simile a quella dei miner di criptovalute comuni. Potrebbe trattarsi di un tentativo da parte di un malintenzionato che ha ottenuto l'accesso iniziale al cluster di utilizzare le risorse del cluster per il mining di criptovaluta. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannosa da parte del pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Initial Access: Anonymous GKE resource created from the internet

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

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

Questi utenti e gruppi sono effettivamente anonimi. Un binding del controllo dell'accesso basato sui ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione per creare queste risorse nel cluster.

Esamina la risorsa creata e il binding RBAC associato per assicurarti che il binding sia necessario. Se l'associazione non è necessaria, rimuovila. Per ulteriori dettagli, consulta il messaggio di log per questo risultato.

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

Initial Access: CloudDB Successful login from Anonymizing Proxy IP

Rileva un accesso riuscito nell'istanza del database da un indirizzo IP di anonimizzazione noto. Questi indirizzi di anonimizzazione sono nodi Tor. Ciò potrebbe indicare che un utente malintenzionato ha ottenuto l'accesso iniziale alla tua istanza.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Initial Access: CloudDB Successful login from Anonymizing Proxy IP 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:
   • Indirizzo IP indicatore, l'indirizzo IP di anonimizzazione.
   • Nome visualizzato del database: il nome del database nell'istanza Cloud SQL PostgreSQL, MySQL o AlloyDB interessata.
   • Nome utente database: l'utente.
   • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL.

Passaggio 2: ricerca di metodi di attacco e risposta

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

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.

• Esamina gli utenti autorizzati a connettersi al database.

  • Per PostgreSQL, consulta Creare e gestire gli utenti
  • Per MySQL, vedi Gestisci gli utenti con l'autenticazione integrata

• Valuta la possibilità di modificare la password dell'utente.

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

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

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

Initial Access: Database Superuser Writes to User Tables

Rileva quando l'account superuser del database Cloud SQL (postgres per PostgreSQL e root per MySQL) scrive nelle tabelle utente. Il superuser (un ruolo con accesso molto esteso) in genere non deve essere utilizzato per scrivere nelle tabelle utente. Per le normali attività quotidiane deve essere utilizzato un account utente con accesso più limitato. Quando un superutente scrive in una tabella utente, ciò potrebbe indicare che un utente malintenzionato ha eseguito l'escalation dei privilegi o ha compromesso l'utente del database predefinito e sta modificando i dati. Potrebbe anche indicare pratiche normali ma non sicure.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Initial Access: Database Superuser Writes to User Tables 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:
     • Nome visualizzato del database: il nome del database nell'istanza Cloud SQL PostgreSQL o MySQL interessata.
     • Nome utente database: il superutente.
     • Query del database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza Cloud SQL interessata.
     • Nome completo padre: il nome della risorsa dell'istanza Cloud SQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza di Cloud SQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

Passaggio 2: controlla i log

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

Passaggio 3: ricerca di metodi di attacco e risposta

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

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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.

  • Per PostgreSQL, consulta Creare e gestire gli utenti
  • Per MySQL, vedi Gestisci gli utenti con l'autenticazione integrata

• Valuta la possibilità di modificare la password del superutente.

  • Per PostgreSQL, vedi Impostare la password per l'utente predefinito
  • Per MySQL, vedi 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 query.

    • Per PostgreSQL, vedi Grant (comando)
    • Per MySQL, vedi Controllo dell'accesso e gestione degli account

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

Initial Access: Dormant Service Account Action

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

   • Email entità: il account di servizio inattivo che ha eseguito l'azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui ha avuto accesso il account di servizio
   • Nome metodo: il metodo chiamato

Passaggio 2: ricerca di metodi di attacco e risposta

1. Utilizza gli strumenti per i service account, come Activity Analyzer, per esaminare l'attività del account di servizio inattivo.
2. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell' Google Cloud assistenza.
• Per limitare gli utenti che possono creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Initial Access: Dormant Service Account Activity in AI Service

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Initial Access: Dormant Service Account Activity in AI Service risultato come indicato in Revisione dei risultati.

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

   In Che cosa è stato rilevato:

   • Email entità: il account di servizio inattivo che ha eseguito l'azione
   • Nome metodo: il metodo chiamato
   • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Utilizza gli strumenti per i service account, come Activity Analyzer, per esaminare l'attività account di servizioount inattivo.
2. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Initial Access: Dormant Service Account Key Created

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

   • Email entità: l'utente che ha creato la chiave dell'account di servizio

   In Risorsa interessata:

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

Passaggio 2: ricerca di metodi di attacco e risposta

1. Utilizza gli strumenti per i service account, come Activity Analyzer, per esaminare l'attività del account di servizio inattivo.
2. Contatta il proprietario del campo Email entità. Conferma 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 eseguita l'azione.
• Rimuovi l'accesso del proprietario dell'email principale se è compromessa.
• Invalida la chiave del account di servizio appena creata nella pagina Service Accounts.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Initial Access: Excessive Permission Denied Actions

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

   • Email dell'entità: l'entità che ha generato più errori di autorizzazione negata
   • Nome del servizio: il nome dell'API del servizio Google Cloud in cui si è verificato l'ultimo errore di autorizzazione negata
   • Nome del metodo: il metodo chiamato quando si è verificato l'ultimo errore di autorizzazione negata

3. Nei dettagli del problema, nella scheda Proprietà origine, prendi nota dei valori dei seguenti campi nel JSON:

   • properties.failedActions: gli errori di autorizzazione negata che si sono verificati. Per ogni voce, i dettagli includono il nome del servizio, il nome del metodo, il numero di tentativi non riusciti e l'ora in cui si è verificato l'ultimo errore. Vengono visualizzate un massimo di 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 progetto.

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

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

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

Passaggio 3: ricerca di metodi di attacco e risposta

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

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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à. Conferma se l'azione è stata eseguita dal legittimo proprietario.
• Elimina le risorse del progetto create da quell'account, come istanze Compute Engine, snapshot, service account e utenti IAM sconosciuti e così via.
• Contatta il proprietario del progetto con l'account ed eventualmente elimina o disattiva l'account.

Initial Access: GKE NodePort service created

Qualcuno ha creato un servizio NodePort. I servizi NodePort espongono i pod direttamente sull'indirizzo IP e sulla porta statica di un nodo, il che rende i pod accessibili dall'esterno del cluster. Ciò può introdurre un rischio per la sicurezza significativo perché potrebbe consentire a un malintenzionato di sfruttare le vulnerabilità del servizio esposto per ottenere l'accesso al cluster o a dati sensibili.

1. Esamina la configurazione del servizio per determinarne lo scopo.
2. Valuta la possibilità di limitare le policy di rete per proteggere il servizio.

Initial Access: GKE resource modified anonymously from the internet

Rileva quando un attore potenzialmente dannoso 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 effettivamente anonimi. Un binding del controllo dell'accesso basato sui ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione a modificare queste 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 risolvere questo problema, vedi Evitare ruoli e gruppi predefiniti.

Initial Access: Leaked Service Account Key Used

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

   • Email entità: l'account di servizio utilizzato in questa azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui ha avuto accesso il account di servizio
   • Nome metodo: il nome del metodo dell'azione
   • Nome chiave service account: la chiave account di servizio divulgata utilizzata per autenticare questa azione
   • Descrizione: la descrizione di ciò che è stato rilevato, inclusa la posizione su internet pubblica in cui è possibile trovare la chiave del account di servizio

   In Risorsa interessata:

   • Nome visualizzato 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 progetto o l'organizzazione.

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

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

   Sostituisci PRINCIPAL_EMAIL con il valore che hai annotato nel campo Email principale nei dettagli del risultato. Sostituisci SERVICE_ACCOUNT_KEY_NAME con il valore annotato nel campo Nome chiave service account 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 immediatamente la chiave dell'account di servizio nella pagina Account di servizio.
• Rimuovi la pagina web o il repository GitHub in cui è pubblicata la chiave dell'account di servizio.
• Valuta la possibilità di eliminare il service account compromesso.
• Esegui la rotazione ed elimina tutte le chiavi di accesso del account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima dell'eliminazione, il tuo team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.

Initial Access: Log4j Compromise Attempt

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

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Initial Access: Log4j Compromise Attempt come indicato in Rivedere i dettagli dei risultati. Si apre il riquadro dei dettagli del risultato 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 log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   • Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.

   • Nel JSON, prendi nota dei 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 del passaggio 1.

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

   Consulta CVE-2021-44228: rilevamento di exploit Log4Shell nella documentazione di Logging per esempi di stringhe da cercare e per un esempio di query.

Passaggio 3: ricerca di metodi di attacco e risposta

1. Consulta 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 nella sezione Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo e della stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 consigli di Google Cloudper esaminare e risolvere la vulnerabilità "Apache Log4j 2".
• Implementa le tecniche di mitigazione consigliate in Vulnerabilità di sicurezza di Apache Log4j.
• Se utilizzi Google Cloud Armor, implementa cve-canary rule in un criterio di sicurezza di Google Cloud Armor nuovo o esistente. Per saperne di più, vedi Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j.

Initial Access: Successful API call made from a TOR proxy IP

È stata effettuata una chiamata API riuscita al tuo cluster GKE da un indirizzo IP associato alla rete Tor. Tor offre l'anonimato, che gli autori degli attacchi sfruttano spesso per nascondere la propria identità.

1. Esamina la natura della chiamata API e le risorse a cui è stato eseguito l'accesso.
2. Esamina i criteri di rete e le regole firewall per bloccare l'accesso dagli indirizzi IP proxy Tor.

Lateral Movement: Modified Boot Disk Attached to Instance

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

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

   • Email entità: il account di servizio che ha eseguito l'azione
   • Nome servizio: il nome API del servizio Google Cloud a cui ha avuto accesso l'account di servizio
   • Nome metodo: il metodo chiamato

Passaggio 2: ricerca di metodi di attacco e risposta

1. Utilizza gli strumenti per i service account, come Activity Analyzer, per esaminare l'attività account di servizioount associato.
2. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma 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 eseguita l'azione.
• Valuta la possibilità di utilizzare Secure Boot per le tue istanze VM di Compute Engine.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell' Google Cloud assistenza.

Leaked credentials

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

Questo risultato viene generato quando le credenziali del service account vengono divulgate accidentalmente online o compromesse. Google Cloud Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato account_has_leaked_credentials come indicato in Revisione dei 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à origine e prendi nota dei seguenti campi:

   • Compromised_account: il account di servizio potenzialmente compromesso
   • Project_identifier: il progetto che contiene le credenziali dell'account potenzialmente compromesse
   • URL: il link al repository GitHub

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

Passaggio 2: esamina le autorizzazioni del progetto e del 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 controlla le autorizzazioni assegnate.

4. Nella console Google Cloud , vai alla pagina Service Accounts.

   Vai a Service account

5. Nella pagina visualizzata, nella casella Filtro, inserisci il nome del account di servizio compromesso e controlla le chiavi e le date di creazione delle chiavi del 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 progetto.

3. Nella pagina che si carica, controlla i log per l'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 di metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 le credenziali compromesse.
• Valuta la possibilità di eliminare il service account compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano ilaccount di serviziot per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account 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 service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.
• Apri il link URL ed elimina le credenziali compromesse. Raccogli ulteriori informazioni sull'account compromesso e contatta il proprietario.

Malware

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

I seguenti passaggi descrivono come esaminare 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 del risultato

1. Apri il risultato di ricerca del malware pertinente. I passaggi seguenti utilizzano il risultato Malware: Bad IP, come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 i risultati Bad domain, il dominio che ha attivato il risultato.
     • IP indicatore: per i risultati Bad IP, l'indirizzo IP che ha attivato il risultato.
     • IP di origine: per i risultati Bad IP, un indirizzo IP di comando e controllo di malware noto.
     • Porta di origine: per i risultati Bad IP, la porta di origine della connessione.
     • IP di destinazione: per i risultati Bad IP, l'indirizzo IP di destinazione del malware.
     • Porta di destinazione: per i risultati Bad IP, la porta di destinazione della connessione.
     • Protocollo: per i risultati Bad IP, il numero di protocollo IANA associato alla connessione.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della 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 log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.
     • Flow Analyzer: link alla funzionalità Flow Analyzer di Network Intelligence Center. Questo campo viene visualizzato solo quando i log di flusso VPC sono abilitati.

   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 Compute Engine.

Passaggio 2: rivedi 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 nella scheda Riepilogo.

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

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

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

Passaggio 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 che viene caricata, trova i log di flusso VPC correlati all'indirizzo IP in IP di origine utilizzando il seguente filtro:

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

     Sostituisci quanto segue:

     • PROJECT_ID con la selezione del progetto elencato in projectId.
     • SOURCE_IP con l'indirizzo IP elencato nella riga IP di origine nella scheda Riepilogo dei dettagli del problema.

Passaggio 4: controlla Flow Analyzer

Per eseguire la procedura seguente, devi abilitare i log di flusso VPC.

1. Assicurati di aver eseguito l'upgrade del bucket di log per utilizzare Analisi dei log. Per istruzioni, vedi Eseguire l'upgrade di un bucket per utilizzare Analisi dei log. Non è previsto alcun costo aggiuntivo per l'upgrade.

2. Nella console Google Cloud , vai alla pagina Analizzatore di flusso:

   Vai a Flow Analyzer

   Puoi accedere a Flow Analyzer anche tramite il link URL di Flow Analyzer nella sezione Link correlati della scheda Riepilogo del riquadro Dettagli del risultato.

3. Per esaminare ulteriormente le informazioni relative al risultato di Event Threat Detection, utilizza il selettore dell'intervallo di tempo nella barra delle azioni per modificare il periodo di tempo. Il periodo di tempo deve riflettere la data della prima segnalazione del risultato. Ad esempio, se il problema è stato segnalato nelle ultime 2 ore, puoi impostare il periodo di tempo su Ultime 6 ore. In questo modo, il periodo di tempo in Analizzatore di flusso include il momento in cui è stato segnalato il problema.

4. Filtra Flow Analyzer per visualizzare i risultati appropriati per l'indirizzo IP associato al risultato IP dannoso:

   1. Nel menu Filtro nella riga Origine della sezione Query, seleziona IP.

   2. Nel campo Valore, inserisci l'indirizzo IP associato al risultato e fai clic su Esegui nuova query.

      Se Flow Analyzer non mostra risultati per l'indirizzo IP, cancella il filtro dalla riga Origine ed esegui di nuovo la query con lo stesso filtro nella riga Destinazione.

5. Analizza i risultati. Per ulteriori informazioni su un flusso specifico, fai clic su Dettagli nella tabella Tutti i flussi di dati per aprire il riquadro Dettagli flusso.

Passaggio 5: ricerca di metodi di attacco e risposta

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

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 contenente malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Per monitorare l'attività e le vulnerabilità che hanno consentito l'inserimento di malware, controlla i log di controllo e i syslog associati all'istanza compromessa.
• Se necessario, arresta l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole firewall o utilizzando Google Cloud Armor. Puoi attivare 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 Shielded VM e Trusted Images IAM policy.

Malware: Cryptomining Bad IP

Il malware viene rilevato esaminando i log di flusso VPC e Cloud DNS per le connessioni a domini e indirizzi IP command and control noti. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Malware: Cryptomining Bad IP come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • IP di origine: l'indirizzo IP sospettato di attività di criptomining.
     • 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: link a eventuali risultati correlati.
     • Flow Analyzer: link alla funzionalità Flow Analyzer di Network Intelligence Center. Questo campo viene visualizzato solo quando i log di flusso VPC sono abilitati.

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

4. Espandi properties e annota i valori di progetto e istanza nel seguente campo:

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

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

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

Passaggio 2: rivedi 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 corrispondente a properties_sourceInstance. Esamina l'istanza potenzialmente compromessa per rilevare la presenza di malware.

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

Passaggio 3: controlla i log

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

   Vai a Esplora log

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

3. Nella pagina caricata, trova i log di flusso VPC correlati 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 di metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 contenente malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.
• Se necessario, arresta l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole firewall o utilizzando Google Cloud Armor. Puoi attivare 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.

Persistence: GKE Webhook Configuration Detected

È stata rilevata una configurazione webhook nel tuo cluster GKE. I webhook possono intercettare e modificare le richieste API Kubernetes, il che potenzialmente consente agli autori degli attacchi di persistere all'interno del cluster o manipolare le risorse.

1. Identifica lo scopo e l'origine della configurazione del webhook. Verifica che provenga da una fonte attendibile e serva a uno scopo legittimo.
2. Esamina la configurazione del webhook per comprenderne l'ambito e i tipi di richieste che intercetta.
3. Monitora l'attività del webhook per rilevare eventuali azioni sospette o non autorizzate.
4. Se il webhook non è necessario o il suo comportamento è preoccupante, valuta la possibilità di rimuoverlo o disattivarlo.

Persistence: IAM Anomalous Grant

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

Di seguito sono riportati alcuni esempi di concessioni anomale:

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

Il risultato IAM Anomalous Grant è unico in quanto include sotto-regole che forniscono informazioni più specifiche su ogni istanza di questo risultato. La classificazione della gravità di questo risultato dipende dalla regola secondaria. Ogni sotto-regola 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 con sensibilità elevata o se è stato concesso un ruolo con sensibilità media a livello di organizzazione. Per ulteriori informazioni, vedi Ruoli altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo con sensibilità media. Per ulteriori informazioni, vedi Ruoli con sensibilità media.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, se è stato concesso un ruolo con sensibilità elevata o se è stato concesso un ruolo con sensibilità media a livello di organizzazione. Per ulteriori informazioni, vedi Ruoli altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo con sensibilità media. Per ulteriori informazioni, vedi Ruoli con sensibilità media.
• custom_role_given_sensitive_permissions: MEDIUM
• service_account_granted_sensitive_role_to_member: HIGH
• policy_modified_by_default_compute_service_account: HIGH

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Persistence: IAM Anomalous Grant come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

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

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

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

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

4. Nel JSON per il risultato, prendi nota dei 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: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del risultato, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Nella pagina caricata, cerca 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 3: ricerca di metodi di attacco e risposta

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

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 il service account compromesso e ruota ed elimina tutte le chiavi di accesso delaccount di serviziot per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano ilaccount di serviziot per l'autenticazione perdono l'accesso.
• Elimina le risorse del progetto create da account non autorizzati, come istanze di Compute Engine, snapshot, service account 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 IAM Recommender.

Persistence: New AI API Method

In un'organizzazione, una cartella o un progetto è stata rilevata un'attività di amministrazione anomala per i servizi di AI da parte di un attore potenzialmente dannoso. L'attività anomala può essere una delle seguenti:

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

Passaggio 1: esamina i dettagli del risultato

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

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

   • Nella sezione Che cosa è stato rilevato:
     • Email principale: l'account che ha effettuato la chiamata
     • Nome metodo: il metodo chiamato
     • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.
   • In Risorsa interessata:
     • Nome visualizzato risorsa: il nome della risorsa interessata, che può essere uguale al nome dell'organizzazione, della cartella o del progetto
     • Percorso risorsa: la posizione nella gerarchia delle risorse in cui si è svolta l'attività

Passaggio 2: ricerca di metodi di attacco e risposta

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

Persistence: New API Method

È stata rilevata un'attività amministrativa anomala da parte di un soggetto potenzialmente dannoso in un'organizzazione, una cartella o un progetto. L'attività anomala può essere una delle seguenti:

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

Passaggio 1: esamina i dettagli del risultato

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

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

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

Passaggio 2: ricerca di metodi di attacco e risposta

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

Persistence: New Geography

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

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

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Persistence: New Geography 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 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 log.
  • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
  • Risultati correlati: link a eventuali risultati correlati.

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

2. Nel JSON, prendi nota dei seguenti campi sourceProperties:

   • affectedResources:
     • gcpResourceName: la risorsa interessata
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il problema.
   • properties:
     • anomalousLocation:
     • anomalousLocation: la posizione attuale stimata dell'utente.
     • callerIp: l'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 di solito alle risorseGoogle 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 JSON del risultato.

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

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 del progetto create da account non autorizzati, come istanze di Compute Engine, snapshot, service account 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 IAM Recommender.

Persistence: New Geography for AI Service

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

Un utente o un account di servizio IAM accede ai servizi AI da una posizione anomala, in base alla geolocalizzazione dell'indirizzo IP della richiesta. Google Cloud

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Persistence: New Geography for AI Service 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 utente potenzialmente compromesso.
  • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.
• 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 log.
  • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
  • Risultati correlati: link a eventuali risultati correlati.

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

2. Nel JSON, prendi nota dei seguenti campi sourceProperties:

   • affectedResources:
     • gcpResourceName: la risorsa interessata
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il risultato.
   • properties:
     • anomalousLocation:
     • anomalousLocation: la posizione attuale stimata dell'utente.
     • callerIp: l'indirizzo IP esterno.
     • notSeenInLast: il periodo di tempo utilizzato per stabilire una base di riferimento per il comportamento normale.
     • typicalGeolocations: le località da cui l'utente accede di solito alle risorseGoogle Cloud .
   • aiModel:
     • name: l'AI interessata Model
   • vertexAi:
     • datasets: i set di dati Vertex AI interessati
     • pipelines: le pipeline di addestramento Vertex AI interessate

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 JSON del risultato.

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

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 del progetto create da account non autorizzati, come istanze di Compute Engine, snapshot, service account 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 IAM Recommender.

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 utilizzando software sospetto, come indicato da uno user agent anomalo.

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Persistence: New User Agent come indicato 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 entità: l'account di servizio potenzialmente compromesso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo del progetto: il progetto che contiene il account di servizio potenzialmente compromesso.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   2. Nel JSON, prendi nota dei seguenti campi.
   • projectId: il progetto che contiene l'account di servizio potenzialmente compromesso.
   • callerUserAgent: l'user agent anomalo.
   • anomalousSoftwareClassification: il tipo di software.
   • notSeenInLast: il periodo di tempo utilizzato per stabilire una base di riferimento per il comportamento normale.

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 elencato nella riga Email principale della scheda Riepilogo dei dettagli del risultato e controlla i ruoli concessi.

4. Nella console Google Cloud , vai alla pagina Service Accounts.

   Vai a Service account

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

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

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 che si carica, controlla i log per l'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 di metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 del progetto create da account non autorizzati, come istanze di Compute Engine, snapshot, service account 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 IAM Recommender.

Persistence: Service Account Created in sensitive namespace

Qualcuno ha creato un account di servizio in uno spazio dei nomi sensibile. Gli spazi dei nomi kube-system e kube-public sono fondamentali per le operazioni del cluster GKE e i service account non autorizzati potrebbero compromettere la stabilità e la sicurezza del cluster. 1. Se il account di servizio non è autorizzato, eliminalo e analizza il metodo di creazione.

Persistence: Unmanaged Account Granted Sensitive Role

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

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

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario del campo Email entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Contatta il proprietario del campo Offending access grants.Principal name, comprendi l'origine dell'account non gestito.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del problema, fai clic sul link URI Cloud Logging in Link correlati 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 eseguita l'azione.
• Rimuovi l'accesso del proprietario dell'email principale se è 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.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Rileva quando l'account superuser del database AlloyDB per PostgreSQL (postgres) scrive nelle tabelle utente. Il super user (un ruolo con accesso molto esteso) in genere non deve essere utilizzato per scrivere nelle tabelle utente. Per le normali attività quotidiane, è necessario utilizzare un account utente con accesso più limitato. Quando un superutente scrive in una tabella utente, ciò potrebbe indicare che un utente malintenzionato ha eseguito l'escalation dei privilegi o ha compromesso l'utente del database predefinito e sta modificando i dati. Potrebbe anche indicare pratiche normali ma non sicure.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Privilege Escalation: AlloyDB Database Superuser Writes to User Tables come indicato in 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:
     • Nome visualizzato database: il nome del database nell'istanza AlloyDB per PostgreSQL interessata.
     • Nome utente database: il superutente.
     • Query del database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza AlloyDB per PostgreSQL interessata.
     • Nome completo del genitore: il nome della risorsa dell'istanza AlloyDB per PostgreSQL.
     • Nome completo del progetto: il Google Cloud progetto che contiene l'istanza AlloyDB per PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.

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

Passaggio 2: controlla i log

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

Passaggio 3: ricerca di metodi di attacco e risposta

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

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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.
• Valuta la possibilità di modificare la password del superutente.
• 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 query.
  • Aggiorna le credenziali per i client che si connettono all'istanza AlloyDB per PostgreSQL

Privilege Escalation: AlloyDB Over-Privileged Grant

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Privilege Escalation: AlloyDB Over-Privileged Grant risultato 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:
     • Nome visualizzato database: il nome del database nell'istanza AlloyDB per PostgreSQL interessata.
     • Nome utente del database: l'utente PostgreSQL che ha concesso privilegi eccessivi.
     • Query del database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari database: i beneficiari dei privilegi eccessivi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza AlloyDB per PostgreSQL interessata.
     • Nome completo del genitore: il nome della risorsa dell'istanza AlloyDB per PostgreSQL.
     • Nome completo del progetto: il Google Cloud progetto che contiene l'istanza AlloyDB per PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.

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

Passaggio 2: esamina i privilegi del database

1. Connettiti all'istanza AlloyDB per PostgreSQL.
2. Elenca e mostra i privilegi di accesso per quanto segue:
   • Database. Utilizza il metacomando \l o \list e controlla quali privilegi sono assegnati per il database elencato in Nome visualizzato del database (dal passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e controlla quali privilegi sono assegnati alle funzioni o alle 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 Explorer 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 di metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 eccessivi.
• Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari del database fino al completamento dell'indagine.
• Per limitare l'accesso al database (dal Nome visualizzato del database del Passaggio 1, revoca le autorizzazioni non necessarie dai beneficiari (dal Beneficiari del database del Passaggio 1.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

Anomalous Impersonation of Service Account viene rilevata esaminando i log di controllo dell'attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di rappresentazione dell'identità di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: il account di servizio finale nella richiesta di simulazione dell'identità utilizzata per accedere a Google Cloud.
     • Nome del servizio: il nome API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. L'entità nella parte inferiore dell'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 log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell' Google Cloud assistenza.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity

Anomalous Impersonation of Service Account viene rilevato quando i log di controllo dell'attività di amministrazione di un servizio AI mostrano che si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: il account di servizio finale nella richiesta di simulazione dell'identità utilizzata per accedere a Google Cloud.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principale in fondo all'elenco è il chiamante della richiesta di rappresentazione.
     • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.
   • 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 log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation viene rilevato esaminando i log di controllo dell'attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di simulazione dell'identità di uaccount di serviziont.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity come indicato in 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 principale: il account di servizio finale nella richiesta di simulazione dell'identità utilizzata per accedere a Google Cloud.
     • Nome del servizio: il nome API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. L'entità nella parte inferiore dell'elenco è il chiamante della richiesta di rappresentazione.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza Google Cloud .
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Admin Activity

Anomalous Multistep Service Account Delegation viene rilevato quando i log di controllo dell'attività di amministrazione di un servizio AI mostrano che si è verificata un'anomalia in una richiesta di simulazione dell'identità di un service account.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for AI 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 principale: il account di servizio finale nella richiesta di simulazione dell'identità utilizzata per accedere a Google Cloud.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principal in fondo all'elenco è il chiamante della richiesta di rappresentazione.
     • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access

Anomalous Multistep Service Account Delegation viene rilevato quando i log di controllo dell'attività di amministrazione di un servizio AI mostrano che si è verificata un'anomalia in una richiesta di simulazione dell'identità di un service account.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email dell'entità: il account di servizio finale nella richiesta di simulazione dell'identità utilizzato per accedere a Google Cloud
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principale in fondo all'elenco è il richiedente della richiesta di rappresentazione
     • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

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

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email dell'entità: il account di servizio finale nella richiesta di simulazione dell'identità utilizzato per accedere a Google Cloud
     • Nome servizio: il nome API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principal in fondo all'elenco è il chiamante della richiesta di impersonificazione.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza Google Cloud .
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator viene rilevata esaminando i log di controllo dell'attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di rappresentazione dell'identità di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

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

     • Email principale: l'account di servizio finale nella richiesta di rappresentazione utilizzato per accedere a Google Cloud
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principal in fondo all'elenco è il chiamante della richiesta di impersonificazione.

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

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

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell' Google Cloud assistenza.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity

Anomalous Service Account Impersonator viene rilevato quando i log di controllo dell'attività di amministrazione di un servizio AI mostrano che si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il risultato Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email dell'entità: il account di servizio finale nella richiesta di simulazione dell'identità utilizzato per accedere a Google Cloud
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principale in fondo all'elenco è il richiedente della richiesta di rappresentazione
     • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access

Anomalous Service Account Impersonator viene rilevato quando i log di controllo dell'attività di amministrazione di un servizio AI mostrano che si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

   • Email dell'entità: il account di servizio finale nella richiesta di simulazione dell'identità utilizzato per accedere a Google Cloud
   • Nome metodo: il metodo chiamato
   • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principale in fondo all'elenco è il chiamante della richiesta di rappresentazione
   • Risorse AI: le risorse AI potenzialmente interessate, come le risorse Vertex AI e il modello AI.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Anomalous Service Account Impersonator viene rilevato esaminando i log di controllo dell'accesso ai dati per verificare se si è verificata un'anomalia in una richiesta di rappresentazione di un account di servizio.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

   • Email principale: l'account di servizio finale nella richiesta di rappresentazione utilizzato per accedere a Google Cloud
   • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
   • Nome metodo: il metodo chiamato
   • Informazioni relative alla delega per il service account: dettagli dei service account nella catena di delega. Il principal in fondo all'elenco è il chiamante della richiesta di impersonificazione.

Passaggio 2: ricerca di metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se qualche account è stato compromesso.
3. Contatta il proprietario del chiamante di rappresentazione nell'elenco Informazioni sulla delega dell'account di servizio. Conferma se l'azione è stata eseguita dal proprietario legittimo.

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 eseguita l'azione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell' Google Cloud assistenza.
• Per limitare chi può creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

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 sensibile cluster-admin utilizzando una richiesta PUT o PATCH.

Passaggio 1: esamina i dettagli del risultato

1. Apri il Privilege Escalation: Changes to sensitive Kubernetes RBAC objects risultato 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 che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
     • Associazioni Kubernetes: l'associazione Kubernetes sensibile o ClusterRoleBinding che è stata modificata.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

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

Passaggio 2: controlla i log

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

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

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

3. Controlla altre azioni intraprese dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

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

Passaggio 3: ricerca di metodi di attacco e 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 il soggetto 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 legittimo proprietario.

   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 dell'indagine con la ricerca MITRE.

Privilege Escalation: ClusterRole with Privileged Verbs

Qualcuno ha creato un oggetto RBAC ClusterRole che contiene i verbi bind, escalate o impersonate. Un soggetto associato a un ruolo con questi verbi può rappresentare altri utenti con privilegi più elevati, associarsi ad altri oggetti Role o ClusterRole che contengono autorizzazioni aggiuntive o modificare le proprie autorizzazioni ClusterRole. Ciò potrebbe portare a ottenere privilegi cluster-admin. Per maggiori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina il ClusterRole e il ClusterRoleBindings associato per verificare se i soggetti richiedono effettivamente queste autorizzazioni.
2. Se possibile, evita di creare ruoli che coinvolgano i verbi bind, escalate o impersonate.
3. Determina se esistono altri indicatori di attività dannosa da parte dell'entità negli audit log in Cloud Logging.
4. Quando si assegnano le autorizzazioni in un ruolo RBAC, utilizza il principio del privilegio minimo e concedi le autorizzazioni minime necessarie per eseguire un'attività. L'utilizzo del principio del privilegio minimo riduce il rischio di escalation dei privilegi qualora il cluster venga compromesso, nonché la probabilità che un accesso eccessivo causi un incidente di sicurezza.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Qualcuno ha creato un RBAC ClusterRoleBinding che fa riferimento a system:controller:clusterrole-aggregation-controller ClusterRole predefinito. Questo ClusterRole predefinito ha il verbo escalate, che consente ai soggetti di modificare i privilegi dei propri ruoli, consentendo l'escalation dei privilegi. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina eventuali ClusterRoleBinding che fanno riferimento a system:controller:clusterrole-aggregation-controller ClusterRole.
2. Esamina le modifiche apportate al system:controller:clusterrole-aggregation-controller ClusterRole.
3. Determina se esistono altri indicatori di attività dannosa da parte dell'entità che ha creato ClusterRoleBinding negli audit log in Cloud Logging.

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 di Kubernetes, che concede l'accesso cluster-admin.

Passaggio 1: esamina i dettagli del risultato

1. Apri il Privilege Escalation: Create Kubernetes CSR for master cert risultato come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato 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 che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

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

3. Controlla altre azioni intraprese dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

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

Passaggio 3: ricerca di metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Verifica se la concessione dell'accesso a cluster-admin era giustificata.

3. Se l'email dell'entità non è un account di servizio, contatta il proprietario dell'account per confermare 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à.

4. Per sviluppare un piano di risposta, combina i risultati dell'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 del risultato

1. Apri il Privilege Escalation: Creation of sensitive Kubernetes bindings risultato 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 che ha effettuato la chiamata.
     • Associazioni Kubernetes: l'associazione Kubernetes sensibile o ClusterRoleBinding che è stata creata.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

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

2. Controlla altre azioni intraprese dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

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

Passaggio 3: ricerca di metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Conferma la sensibilità dell'associazione creata e se i ruoli sono necessari per i soggetti.
3. Per le associazioni, puoi controllare il soggetto 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 legittimo proprietario.

   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 dell'indagine con la ricerca MITRE.

Privilege Escalation: Default Compute Engine Service Account SetIAMPolicy

Rileva quando il account di servizio Compute Engine predefinito viene utilizzato per impostare il criterio IAM per un servizio Cloud Run. Si tratta di un'azione potenziale post-exploit quando un token Compute Engine viene compromesso da un servizio serverless.

Per rispondere a questo risultato:

1. Esamina gli audit log in Cloud Logging per determinare se si trattava di un'attività prevista dall'entità.
2. Determina se esistono altri indicatori di attività dannosa da parte dell'entità nei log.

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 è considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

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

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

   In Che cosa è stato rilevato:

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

   In Risorsa interessata:

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

Passaggio 2: ricerca di metodi di attacco e risposta

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del problema, fai clic sul link URI Cloud Logging in Link correlati 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 eseguita l'azione.
• Rimuovi l'accesso del proprietario dell'email principale se è compromessa.
• Rimuovi il ruolo IAM sensibile appena assegnato dall'account di servizio inattivo.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Qualcuno ha creato un binding RBAC che fa riferimento a uno dei seguenti utenti o gruppi:

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

Questi utenti e gruppi sono effettivamente anonimi e devono essere evitati quando vengono create associazioni di ruoli o associazioni di ruoli del cluster a qualsiasi ruolo RBAC. Esamina il vincolo per assicurarti che sia necessario. Se l'associazione non è necessaria, rimuovila. Per maggiori dettagli, consulta il messaggio di log per questo risultato.

1. Esamina le eventuali associazioni create che hanno concesso le autorizzazioni all'utente system:anonymous, al gruppo system:unauthenticated group o al gruppo system:authenticated.
2. Determina se esistono altri indicatori di attività dannosa da parte dell'entità negli audit log in Cloud Logging.

Se ci sono segni di attività dannose, consulta le indicazioni per indagare e rimuovere le associazioni che hanno consentito questo accesso.

Privilege Escalation: External Member Added To Privileged Group

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

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

Passaggio 1: esamina i dettagli del risultato

1. Apri un Privilege Escalation: External Member Added To Privileged Group risultato, 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 che ha apportato le modifiche.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

4. Nel JSON, prendi nota dei 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: rivedi 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 far parte di questo gruppo, fai clic sulla casella di controllo accanto al nome del membro e poi seleziona remove_circle_outline Rimuovi membro o not_interested Banna membro.

   Per rimuovere o aggiungere membri, devi essere un amministratore Google Workspace o disporre del ruolo Proprietario o Gestore nel gruppo Google. Per saperne di più, 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 relativi alle modifiche all'appartenenza al gruppo Google utilizzando i seguenti filtri:

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

Passaggio 4: ricerca di metodi di attacco e risposta

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

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 del risultato

1. Apri il Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials risultato 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 che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
   • In Risorsa interessata:
     • Nome visualizzato risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

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

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

Passaggio 3: ricerca di metodi di attacco e risposta

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

Privilege Escalation: Impersonation Role Granted for Dormant Service Account

Rileva gli eventi in cui viene concesso a un'entità un ruolo di rappresentazione che le consente di rappresentare un service account gestito dall'utente inattivo. In questo risultato, il account di servizio inattivo è la risorsa interessata e unaccount di serviziot è considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri il Privilege Escalation: Impersonation Role Granted for Dormant Service Account risultato come indicato in Revisione dei risultati.

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

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione
   • Offending access grants.Principal name: l'entità a cui è stato concesso il ruolo di rappresentazione

   In Risorsa interessata:

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

Passaggio 2: ricerca di metodi di attacco e risposta

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del problema, fai clic sul link URI Cloud Logging in Link correlati 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 eseguita l'azione.
• Rimuovi l'accesso del proprietario dell'email principale se è compromessa.
• Rimuovi il ruolo di rappresentazione appena concesso dal membro di destinazione.
• Valuta la possibilità di eliminare il service account potenzialmente compromesso e ruotare ed eliminare tutte le chiavi di accesso delaccount di serviziot per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il tuo team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i proprietari delle applicazioni per garantire la continuità operativa.
• Collabora con il tuo team di sicurezza per identificare le risorse sconosciute, tra cui istanze di Compute Engine, snapshot, service account e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare service account, utilizza il servizio criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

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 dell'API principale SecurityContext v1 nella documentazione di Kubernetes.

Passaggio 1: esamina i dettagli del risultato

1. Apri il Privilege Escalation: Launch of privileged Kubernetes container risultato 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 che ha effettuato la chiamata.
     • Pod Kubernetes: il pod appena creato con container con privilegi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

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

Passaggio 2: controlla i log

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

2. Controlla altre azioni intraprese dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

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

Passaggio 3: ricerca di metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Escalation dei privilegi.
2. Conferma 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 service account, contatta il proprietario dell'account per confermare 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 dell'indagine con la ricerca MITRE.

Privilege Escalation: 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 concessi ruoli o autorizzazioni sensibili) viene modificato in modo da essere accessibile al pubblico. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un Privilege Escalation: Privileged Group Opened To Public risultato, 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 principale: l'account che ha apportato le modifiche, che potrebbe essere compromesso.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel JSON, prendi nota dei seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • sensitiveRoles: i ruoli sensibili associati a questo gruppo
   • whoCanJoin: l'impostazione di partecipazione del gruppo

Passaggio 2: rivedi le impostazioni di accesso al gruppo

1. Vai alla Console di amministrazione per 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 e poi seleziona Gruppi.

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

4. Fai clic su Impostazioni di accesso e poi, in Chi può iscriversi al gruppo, esamina l'impostazione di iscrizione 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 delle modifiche alle impostazioni di Google Gruppi utilizzando i seguenti filtri:

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

Passaggio 4: ricerca di metodi di attacco e risposta

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

Privilege Escalation: Sensitive Role Granted To Hybrid Group

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

Passaggio 1: esamina i dettagli del risultato

1. Apri un Privilege Escalation: Sensitive Role Granted To Hybrid Group risultato, come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

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

Passaggio 2: rivedi 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 elencato in groupName.

3. Esamina i ruoli sensibili concessi al gruppo.

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

   Per gestire i ruoli nella tua organizzazione o nel tuo progetto, devi disporre di autorizzazioni specifiche. Per maggiori informazioni, consulta Autorizzazioni richieste.

Passaggio 3: controlla i log

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

2. Se necessario, seleziona il progetto.

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

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

Passaggio 4: ricerca di metodi di attacco e risposta

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

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Qualcuno ha eseguito il deployment di un pod con una convenzione di denominazione simile a strumenti comuni utilizzati per l'escape dai container o per eseguire altri attacchi al cluster. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannosa da parte del pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

Qualcuno ha creato un workload che contiene un montaggio del volume hostPath a un percorso sensibile nel file system del nodo host. L'accesso a questi percorsi nel file system host può essere utilizzato per accedere a informazioni privilegiate o sensibili sul nodo e per le uscite dal container. Se possibile, non consentire volumi hostPath nel cluster. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina il workload per determinare se questo volume hostPath è necessario per la funzionalità prevista. Se la risposta è "Sì", assicurati che il percorso sia relativo alla directory più specifica possibile. Ad esempio, /etc/myapp/myfiles invece di / o /etc.
2. Determina se esistono altri indicatori di attività dannosa relativi a questo workload negli audit log in Cloud Logging.

Per bloccare i montaggi dei volumi hostPath nel cluster, consulta le indicazioni per l'applicazione degli standard di sicurezza dei pod.

Privilege Escalation: Workload with shareProcessNamespace enabled

Qualcuno ha eseguito il deployment di un workload con l'opzione shareProcessNamespace impostata su true, consentendo a tutti i container di condividere lo stesso spazio dei nomi di processo Linux. Ciò potrebbe consentire a un container non attendibile o compromesso di aumentare i privilegi accedendo e controllando le variabili di ambiente, la memoria e altri dati sensibili dei processi in esecuzione in altri container. Alcuni carichi di lavoro potrebbero richiedere questa funzionalità per funzionare per motivi legittimi, ad esempio container collaterali per la gestione dei log o container di debug. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Conferma che il workload richiede effettivamente l'accesso a uno spazio dei nomi di processo condiviso per tutti i container nel workload.
2. Verifica se esistono altri indicatori di attività dannose da parte dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se ha eseguito l'azione.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica la legittimità del motivo per cui ilaccount di serviziot ha eseguito questa azione.

Service account self-investigation

Viene utilizzata una credenziale del account di servizio per esaminare i ruoli e le autorizzazioni associati allo stessoaccount di serviziot. Questo risultato indica che le credenziali delaccount di serviziot potrebbero essere compromesse e che è necessario intervenire immediatamente.

Passaggio 1: esamina i dettagli del risultato

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 autorizzata: il account di servizio non dispone dell'autorizzazione per interrogare le proprie autorizzazioni IAM con l'API projects.getIamPolicy.
     • Email entità: l'account di servizio potenzialmente compromesso.
     • IP chiamante: l'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 compromesse.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Per visualizzare il JSON completo del risultato, fai clic sulla scheda JSON.

Passaggio 2: esamina le autorizzazioni del progetto e del 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 JSON del risultato.

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

4. Nella console Google Cloud , vai alla pagina Service Accounts.

   Vai a Service account

5. Nella pagina visualizzata, nella casella Filtro, inserisci il nome del account di servizio compromesso e controlla le chiavi e le date di creazione delle chiavi del 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 che si carica, controlla i log per l'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 di metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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 il service account compromesso e ruota ed elimina tutte le chiavi di accesso delaccount di serviziot per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano ilaccount di serviziot per l'autenticazione perdono l'accesso.
• Elimina le risorse del progetto create dall'account compromesso, come istanze Compute Engine, snapshot, service account e utenti IAM sconosciuti.

Rilevamenti di metadati di amministrazione di Compute Engine

Persistence: GCE Admin Added SSH Key

Persistence: GCE Admin Added Startup Script

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 si trovano 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 di log e scrive i risultati in Security Command Center. La tabella seguente contiene le minacce di Google Workspace, le voci del framework 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.

Initial Access: Suspicious Login Blocked

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

Initial Access: Account Disabled Hijacked

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

Impair Defenses: Two Step Verification Disabled

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

Initial Access: Government Based Attack

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

Persistence: SSO Enablement Toggle

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

Persistence: SSO Settings Changed

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

Impair Defenses: Strong Authentication Disabled

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

Rispondere alle minacce di 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 le attivazioni a livello di progetto.

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

• Centro avvisi Google Workspace
• Centro sicurezza Google Workspace

Gli strumenti includono avvisi, una dashboard per la sicurezza, consigli per la sicurezza e possono aiutarti a esaminare e correggere le minacce.

Se non sei un amministratore Google Workspace, procedi nel seguente modo:

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

Rilevamenti delle minacce Cloud IDS

Cloud IDS: THREAT_ID

I risultati di Cloud IDS sono generati da Cloud IDS, un servizio di sicurezza che monitora il traffico da e verso le tue risorseGoogle Cloud alla ricerca di 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 genera un risultato di minaccia.

Passaggio 1: esamina i dettagli del risultato

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Protocollo: il protocollo di rete utilizzato
     • Ora dell'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 risorsa: il progetto contenente la rete con la minaccia
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di log di Cloud IDS. Queste voci contengono le informazioni necessarie per cercare nel Threat Vault di Palo Alto Networks.
   • Detection Service
     • Categoria risultato: il nome della minaccia Cloud IDS

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

Passaggio 2: cerca metodi di attacco e risposta

Dopo aver esaminato i dettagli del risultato, consulta la documentazione di Cloud IDS sull'analisi degli avvisi di minaccia per determinare una risposta appropriata.

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

Risposte di Container Threat Detection

Per scoprire di più su Container Threat Detection, consulta la sezione Come funziona Container Threat Detection.

Added Binary Executed

È stato eseguito un binario che non faceva parte dell'immagine container originale. Dopo la compromissione iniziale, gli aggressori installano comunemente strumenti di sfruttamento e malware. Assicurarsi che i contenitori siano immutabili è una best practice importante. Questo è un risultato di gravità bassa, perché la tua organizzazione potrebbe non seguire questa best practice. Esistono risultati Execution: Added Malicious Binary Executed corrispondenti quando l'hash del file binario è un indicatore di compromissione (IoC) noto. Per rispondere a questo risultato, svolgi questi passaggi:

Passaggio 1: esamina i dettagli del risultato

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del binario aggiunto.
     • Argomenti: gli argomenti forniti durante la chiamata al binario aggiunto.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi il numero di progetto, la località e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

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 viene eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

4. Identifica altri risultati che si sono verificati in un momento simile per questo container. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché un mancato rispetto delle best practice.

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 elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema. Prendi nota di eventuali 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 Workload Kubernetes.

   Vai a Carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

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

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che viene caricata, segui questi passaggi:

   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 i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console dei nodi GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla Google Cloud console.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

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

   Per i cluster regionali:

     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 posizione elencata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario aggiunto eseguendo:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

6. Connettiti all'ambiente del contenitore 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 di metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Trasferimento di strumenti di ingresso, API nativa.
2. Controlla il valore hash SHA-256 del file binario contrassegnato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce il contesto di file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE e l'analisi di VirusTotal.

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.

• Se il file binario doveva essere incluso nel container, ricrea l'immagine del container con il file binario incluso. In questo modo, il container può essere immutabile.
• In caso contrario, 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. I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere codice dannoso. Assicurarsi che i contenitori siano immutabili è una best practice importante. Si tratta di un risultato di gravità bassa perché la tua organizzazione potrebbe non seguire questa best practice. Esistono risultati Execution: Added Malicious Library Loaded corrispondenti quando l'hash del file binario è un indicatore di compromissione (IOC) noto. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Added Library Loaded come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso completo del binario del processo che ha caricato la libreria.
     • Raccolte: dettagli sulla raccolta aggiunta.
     • Argomenti: gli argomenti forniti durante la chiamata del binario del processo.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo risorsa del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

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 in esecuzione.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

4. Identifica altri risultati che si sono verificati in un momento simile per questo container. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché un mancato rispetto delle best practice.

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 elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di eventuali 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 Workload Kubernetes.

   Vai a Carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

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

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che viene caricata, segui questi passaggi:

   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 i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console dei nodi GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla Google Cloud console.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

   Per i cluster di zona:

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

   Per i cluster regionali:

     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 di file locale per archiviare la libreria aggiunta.

6. Connettiti all'ambiente del contenitore 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 di metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Ingress Tool Transfer, Shared Modules.
2. Controlla il valore hash SHA-256 del file binario contrassegnato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce il contesto di file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE e l'analisi di VirusTotal.

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.

• Se la libreria doveva essere inclusa nel container, ricompila l'immagine container con la libreria inclusa. In questo modo, il container può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il container compromesso.
• Arresta o elimina il container compromesso e sostituiscilo con un nuovo container.

Command and Control: Steganography Tool Detected

È stato rilevato un processo che utilizza strumenti di steganografia comunemente presenti nelle distribuzioni di tipo Unix per nascondere potenzialmente la comunicazione. Questo comportamento suggerisce un tentativo di nascondere il traffico di comando e controllo (C2) o i dati sensibili all'interno di messaggi digitali apparentemente innocui scambiati con un'entità esterna. Gli avversari utilizzano spesso la steganografia per eludere il monitoraggio della rete e rendere l'attività dannosa meno evidente. La presenza di questi strumenti suggerisce un tentativo deliberato di offuscare il trasferimento illecito di dati. Questo comportamento può portare a un'ulteriore compromissione o esfiltrazione di informazioni sensibili. Identificare i contenuti nascosti è essenziale per valutare con precisione i rischi coinvolti.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Command and Control: Steganography Tool Detected come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del binario eseguito.
     • Arguments: gli argomenti passati durante l'esecuzione del file binario.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi il numero di progetto, la località e il nome del cluster.

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

4. Nel JSON, prendi nota dei seguenti campi.

   • resource:
     • project_display_name: il nome del progetto che contiene il cluster.
   • finding:
     • processes:
     • binary:
       • path: il percorso completo del file binario eseguito.
     • args: gli argomenti forniti durante l'esecuzione del file binario.
   • 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 viene eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo container. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché una mancata osservanza delle best practice.

Passaggio 2: esamina il cluster e il nodo

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

   Vai a Cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema. Prendi nota di eventuali 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 Workload Kubernetes.

   Vai a Carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

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

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che viene caricata, segui questi passaggi:

   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 i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Trova i log della console dei nodi GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla Google Cloud console.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Per i cluster regionali:

   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 posizione elencata in resource.labels.location
   • PROJECT_NAME: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario eseguito:

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   Sostituisci local_file con un percorso di file locale in cui memorizzare il file binario aggiunto.

6. Connettiti all'ambiente 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 di metodi di attacco e risposta

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

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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.

Credential Access: Find Google Cloud Credentials

È stato rilevato un processo di ricerca delle credenziali Google Cloud . Questo comportamento suggerisce un tentativo di individuare ed estrarre i segreti archiviati che potrebbero essere utilizzati per aumentare i privilegi, accedere a risorse con limitazioni o spostarsi lateralmente all'interno dell'ambiente. Gli aggressori cercano spesso le credenziali per ottenere l'accesso non autorizzato alle risorse cloud al fine di aumentare i privilegi o eseguire comportamenti dannosi.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Credential Access: Find Google Cloud Credentials come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del binario eseguito.
     • Arguments: gli argomenti passati durante l'esecuzione del file binario.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi il numero di progetto, la località e il nome del cluster.

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

4. Nel JSON, prendi nota dei seguenti campi.

   • resource:
     • project_display_name: il nome del progetto che contiene il cluster.
   • finding:
     • processes:
     • binary:
       • path: il percorso completo del file binario eseguito.
     • args: gli argomenti forniti durante l'esecuzione del file binario.
   • 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 viene eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo container. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché una mancata osservanza delle best practice.

Passaggio 2: esamina il cluster e il nodo

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

   Vai a Cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema. Prendi nota di eventuali 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 Workload Kubernetes.

   Vai a Carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

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

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che viene caricata, segui questi passaggi:

   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 i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Trova i log della console dei nodi GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla Google Cloud console.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Per i cluster regionali:

   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 posizione elencata in resource.labels.location
   • PROJECT_NAME: il nome del progetto elencato in resource.project_display_name

5. Connettiti all'ambiente 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 di metodi di attacco e risposta

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

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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.

Credential Access: GPG Key Reconnaissance

È stato rilevato un processo di ricerca delle chiavi GPG. Questo comportamento suggerisce un tentativo di individuare ed estrarre le chiavi di sicurezza archiviate utilizzate per criptare e decriptare i documenti e autenticare i documenti con firme digitali. Le chiavi di sicurezza degli autori degli attacchi per ottenere l'accesso non autorizzato a informazioni e sistemi critici, il che rende questo rilevamento di gravità elevata che richiede un'indagine immediata.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Credential Access: GPG Key Reconnaissance come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del binario eseguito.
     • Arguments: gli argomenti passati durante l'esecuzione del file binario.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi il numero di progetto, la località e il nome del cluster.

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

4. Nel JSON, prendi nota dei seguenti campi.

   • resource:
     • project_display_name: il nome del progetto che contiene il cluster.
   • finding:
     • processes:
     • binary:
       • path: il percorso completo del file binario eseguito.
     • args: gli argomenti forniti durante l'esecuzione del file binario.
   • 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 viene eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo container. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché una mancata osservanza delle best practice.

Passaggio 2: esamina il cluster e il nodo

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

   Vai a Cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema. Prendi nota di eventuali 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 Workload Kubernetes.

   Vai a Carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

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

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che viene caricata, segui questi passaggi:

   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 i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Trova i log della console dei nodi GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla Google Cloud console.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Per i cluster regionali:

   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 posizione elencata in resource.labels.location
   • PROJECT_NAME: il nome del progetto elencato in resource.project_display_name

5. Connettiti all'ambiente 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 di metodi di attacco e risposta

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

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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.

Credential Access: Search Private Keys or Passwords

È stato rilevato un processo di ricerca di chiavi private, credenziali o altre informazioni di autenticazione sensibili all'interno del container. Questo comportamento suggerisce un tentativo di individuare ed estrarre i segreti archiviati che potrebbero essere utilizzati per aumentare i privilegi, accedere a risorse con limitazioni o spostarsi lateralmente all'interno dell'ambiente. Gli autori degli attacchi eseguono spesso scansioni alla ricerca di chiavi SSH, token API o credenziali di database per ottenere l'accesso non autorizzato a sistemi critici, il che rende questo rilevamento di gravità elevata che richiede un'indagine immediata.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Credential Access: Search Private Keys or Passwords come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del binario eseguito.
     • Arguments: gli argomenti passati durante l'esecuzione del file binario.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi il numero di progetto, la località e il nome del cluster.

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

4. Nel JSON, prendi nota dei seguenti campi.

   • resource:
     • project_display_name: il nome del progetto che contiene il cluster.
   • finding:
     • processes:
     • binary:
       • path: il percorso completo del file binario eseguito.
     • args: gli argomenti forniti durante l'esecuzione del file binario.
   • 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 viene eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo container. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché una mancata osservanza delle best practice.

Passaggio 2: esamina il cluster e il nodo

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

   Vai a Cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema. Prendi nota di eventuali 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 Workload Kubernetes.

   Vai a Carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

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

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che viene caricata, segui questi passaggi:

   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 i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Trova i log della console dei nodi GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla Google Cloud console.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Per i cluster regionali:

   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 posizione elencata in resource.labels.location
   • PROJECT_NAME: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario eseguito:

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   Sostituisci local_file con un percorso di file locale in cui memorizzare il file binario aggiunto.

6. Connettiti all'ambiente 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 di metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Credenziali non protette: credenziali nei file.
2. Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche 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.

Defense Evasion: Base64 ELF File Command Line

È stato eseguito un processo che contiene un argomento che è un file ELF (Executable and Linkable Format). Se viene rilevata l'esecuzione di un file ELF codificato, significa che un malintenzionato sta tentando di codificare dati binari per il trasferimento a righe di comando solo ASCII. Gli autori degli attacchi possono utilizzare questa tecnica per eludere il rilevamento ed eseguire codice dannoso incorporato in un file ELF.

Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del risultato

1. Apri un risultato Defense Evasion: Base64 ELF File Command Line come indicato in Revisione dei risultati. Si apre il riquadro dei dettagli del risultato nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del binario eseguito.
     • Arguments: gli argomenti passati durante l'esecuzione del file binario.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi il numero di progetto, la località e il nome del cluster.

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

4. Nel JSON, prendi nota dei seguenti campi.

   • resource:
     • project_display_name: il nome del progetto che contiene il cluster.
   • finding:
     • processes:
     • binary:
       • path: il percorso completo del file binario eseguito.
     • args: gli argomenti forniti durante l'esecuzione del file binario.
   • 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 viene eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo container. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché una mancata osservanza delle best practice.

Passaggio 2: esamina il cluster e il nodo

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

   Vai a Cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema. Prendi nota di eventuali 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 Workload Kubernetes.

   Vai a Carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda Riepilogo dei dettagli del problema e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

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

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che viene caricata, segui questi passaggi:

   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 i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Trova i log della console dei nodi GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla Google Cloud console.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il cluster eseguendo i comandi seguenti.

   Per i cluster di zona:

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Per i cluster regionali:

   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 posizione elencata in resource.labels.location
   • PROJECT_NAME: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario eseguito:

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   Sostituisci local_file con un percorso di file locale in cui memorizzare il file binario aggiunto.

6. Connettiti all'ambiente 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.