Analisi e risposta alle minacce

Questo documento fornisce indicazioni informali per aiutarti a esaminare i risultati di attività sospette nel tuo ambiente Google Cloud da parte di soggetti potenzialmente malintenzionati. Questo documento fornisce anche risorse aggiuntive per aggiungere contesto ai risultati di Security Command Center. Seguire questi passaggi ti aiuta a capire cosa è successo durante un potenziale attacco e a sviluppare possibili risposte per le risorse interessate.

Non è garantito che le tecniche riportate in questa pagina siano efficaci contro le minacce precedenti, attuali o future che dovete affrontare. Consulta la sezione 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 Google Cloud, devi disporre di ruoli di Identity and Access Management (IAM) adeguati. Se riscontri errori di accesso nel Security Command Center, chiedi assistenza all'amministratore e consulta la sezione Controllo dell'accesso per saperne di più sui ruoli. Per risolvere gli errori relativi alle risorse, leggi la documentazione dei prodotti interessati.

Informazioni sui risultati relativi alle minacce

Event Threat Detection produce risultati di sicurezza abbinando gli eventi negli stream di log di Cloud Logging agli 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 le minacce anche identificando tattiche, tecniche e procedure di attacco note nello stream di log 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 a basso livello nel kernel guest dei container.

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

Esaminare i risultati

Per esaminare i risultati relativi alle 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 progetto, la cartella o l'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 della sorgente, nei risultati vengono visualizzati solo i risultati del servizio selezionato.

   La tabella viene compilata con i risultati relativi all'origine selezionata.

4. Per visualizzare i dettagli di un determinato rilevamento, fai clic sul nome del rilevamento in Category. Il riquadro dei dettagli del risultato si espande per visualizzare un riepilogo dei dettagli del risultato.

5. Per visualizzare la definizione JSON del rilevamento, 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à delle risorse. Puoi utilizzare queste informazioni per isolare rapidamente le risorse interessate e determinare l'ambito potenziale di un evento.

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

• Le voci del framework MITRE ATT&CK. Il framework spiega le tecniche per gli attacchi alle risorse cloud e fornisce indicazioni per la correzione.

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

  VirusTotal è un'offerta con un prezzo separato con funzionalità e limiti di utilizzo diversi. È tua responsabilità comprendere e rispettare le norme di utilizzo dell'API di VirusTotal e gli eventuali costi associati. Per ulteriori informazioni, consulta la documentazione di VirusTotal.

Le sezioni seguenti descrivono le potenziali risposte ai risultati relativi alle minacce.

Disattivazione dei risultati relativi alle minacce

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

Per un falso positivo, ti consigliamo di lasciare lo stato del risultato su ACTIVE e di disattivare l'audio 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 vera minaccia quando si verifica.

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

Per disattivare l'audio di un rilevamento o modificarne lo stato, consulta i seguenti argomenti:

• Disattivare i risultati
• Modificare lo stato di un rilevamento

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.

Evasion: Access from Anonymizing Proxy

L'accesso anomalo da un proxy anonimo viene rilevato esaminando Cloud Audit Logs per verificare la presenza di modifiche ai servizi Google Cloud originate da indirizzi IP di proxy anonimi, come gli indirizzi IP di Tor.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Evasion: Access from Anonymizing Proxy rilevamento, come indicato in Esaminare i rilevamenti. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Indirizzo 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 Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

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

Passaggio 2: cerca metodi di attacco e risposta

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

Defense Evasion: Breakglass Workload Deployment Created

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Defense Evasion: Breakglass Workload Deployment Createdrisultato, come indicato in Esaminare i risultati. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

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

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

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer 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 se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Evasione della difesa: deployment di emergenza del workload.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 emergenza per eseguire l'override dei controlli di Autorizzazione binaria.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Defense Evasion: Breakglass Workload Deployment Updatedrisultato, come indicato in Esaminare i risultati. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

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

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

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer 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 se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Evasione della difesa: deployment di emergenza del workload.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

Qualcuno ha eliminato manualmente una richiesta di firma del certificato (CSR). I CSR vengono rimossi automaticamente da un controller di garbage collection, ma gli utenti malintenzionati potrebbero eliminarli manualmente per eludere il rilevamento. Se la richiesta 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 molto privilegiate. Kubernetes non supporta la revoca del certificato. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina gli audit log in Cloud Logging e gli avvisi aggiuntivi per altri eventi correlati a questa CSR per determinare se la CSR era approved e se la creazione della CSR era un'attività prevista dall'entità.
2. Determina se esistono altri indicatori di attività dannose 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 le modifiche ai perimetri dei Controlli di servizio VPC che potrebbero portare a una riduzione della protezione offerta da quel perimetro. Ecco alcuni esempi:

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Defense Evasion: Modify VPC Service Control, come indicato in Esaminare i risultati. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare il seguente campo:
     • Email principale: l'account che ha eseguito la modifica.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome completo della risorsa: il nome del perimetro dei Controlli di servizio VPC che è stato modificato.
   • Link correlati:
     • URI Cloud Logging: il link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di 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 al criterio di accesso che controlla il perimetro
       • delta: le modifiche, REMOVE o ADD, a un perimetro che ha ridotto la sua protezione
       • restricted_resources: i progetti che rispettano le limitazioni di questo perimetro. La protezione è ridotta se rimuovi un progetto
       • restricted_services: i servizi la cui esecuzione è vietata dalle limitazioni di questo perimetro. La protezione è ridotta se rimuovi un servizio limitato
       • allowed_services: i servizi che possono essere eseguiti in base alle limitazioni di questo perimetro. La protezione è 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 è ridotta se aggiungi altri livelli di accesso

Passaggio 2: controlla i log

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

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Evasione della difesa: modifica della procedura di autenticazione.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• 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 Gestore contesto accesso all'entità che ha modificato il perimetro fino al completamento dell'indagine.
• Scopri 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 relativo a questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannose 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.

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 rilevamento

1. Apri il rilevamento Discovery: Can get sensitive Kubernetes object check come indicato in Esaminare i rilevamenti.

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

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

Passaggio 2: controlla i log

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

2. Nella pagina che viene caricata, controlla se sono state intraprese altre azioni dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: 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 della tua indagine con la ricerca MITRE.

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 di attacchi utilizzano le shell inverse per espandere o mantenere il proprio accesso iniziale a un cluster e per 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 argumenti.
2. Determina se esistono altri indicatori di attività dannose 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), identificate la legittimità del motivo per cui il account di servizio 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 contenitore in esecuzione nello spazio dei nomi kube-system. Questi metodi vengono talvolta utilizzati per scopi di debug legittimi. Tuttavia, kube-system namespace è destinato agli oggetti di sistema creati da Kubernetes e deve essere esaminata l'esecuzione di comandi o la creazione di shell impreviste. Per maggiori dettagli, consulta il messaggio di log relativo a 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à dannose 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.

Exfiltration: BigQuery Data Exfiltration

I risultati restituiti da Exfiltration: BigQuery Data Exfiltration contengono una di due possibili sottoregole. Ogni regola secondaria ha un'intensità diversa:

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Exfiltration: BigQuery Data Exfiltration come indicato in Esaminare i rilevamenti.

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 secondariaexfil_to_external_table o LOW per la regola secondariavpc_perimeter_violation.
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui sono stati esfiltrati 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 esfiltrati i dati.
   • Link correlati:
     • URI Cloud Logging: il link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Google Security Operations: link a Google SecOps.

3. Fai clic sulla scheda Proprietà dell'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 eseguito la fuoriuscita di dati.
       • query: la query SQL eseguita sul set di dati BigQuery.

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

Passaggio 2: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'unica sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

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

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

   Vai a Risultati

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

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

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

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

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui accertamenti in Google Security Operations.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire un'indagine su un utente
• Esaminare un asset

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

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

3. Nella pagina visualizzata, nella casella Filtra, inserisci l'indirizzo email elencato in Indirizzo email principale e controlla le autorizzazioni assegnate all'account.

Passaggio 4: controlla i log

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

2. Per trovare i log delle attività di amministrazione relativi ai job BigQuery, utilizza i seguenti filtri:

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

Passaggio 5: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• 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 eseguire la scansione dei 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 mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza 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 esterno alla 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

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

3. Nel riquadro dei dettagli del rilevamento, 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 eseguito la compromissione dei dati

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel JSON del risultato (dal passaggio 1).

3. Nella pagina visualizzata, nella casella Filtra, inserisci l'indirizzo email elencato in Indirizzo email principale (dal passaggio 1) e controlla le autorizzazioni assegnate all'account.

Passaggio 3: controlla i log

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

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in 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 dello stesso tipo nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni per il principale indicato nella riga Email principale 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 della scheda Riepilogo dei dettagli del ritrovato.
• Per eseguire la scansione dei 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 mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Se sei il proprietario del bucket, valuta la possibilità di revocare le autorizzazioni di accesso pubblico.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: BigQuery Data to Google Drive

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

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, tra cui:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulla tabella BigQuery da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli sulla destinazione in Google Drive.
   • Risorsa interessata, tra cui:
     • Nome completo della risorsa: il nome della risorsa BigQuery di cui sono stati estratti i dati.
     • Nome completo del progetto: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • Link correlati, tra cui:
     • URI Cloud Logging: il link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di 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: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel JSON del risultato (dal passaggio 1).

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

Passaggio 3: controlla i log

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

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni per il principale 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 eseguire la scansione dei 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 mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza 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 delle istanze attive esportati in un bucket Cloud Storage al di fuori dell'organizzazione.
• Dati delle istanze in tempo reale 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Exfiltration: Cloud SQL Data Exfiltration, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

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

3. Fai clic sulla scheda JSON.

4. Nel file JSON del rilevamento, prendi nota dei seguenti campi:

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene l'istanza Cloud SQL di origine.
     • properties
     • bucketAccess: indica se il bucket Cloud Storage è pubblicamente accessibile 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: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

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

3. Nella pagina visualizzata, inserisci l'indirizzo email elencato nella riga Indirizzo email principale della scheda Riepilogo dei dettagli del rilevamento (dal passaggio 1) nella casella Filtro. 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 Logs Explorer include tutti i log relativi all'istanza Cloud SQL pertinente.

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati descritta nel passaggio 1. I risultati correlati hanno lo stesso tipo di risultato nella stessa istanza Cloud SQL.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Exfiltration: Cloud SQL Restore Backup to External Organization

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Exfiltration: Cloud SQL Restore Backup to External Organization risultato come indicato in Esaminare i risultati.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sull'istanza Cloud SQL da cui è stato creato il backup.
     • Destinatari 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 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 di 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 ripristinata

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

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

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

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in 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 della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni dell'entità elencata nella riga Email principale della scheda Riepilogo dei dettagli del risultato fino al completamento dell'indagine.
• Per interrompere l'esfiltrazione, aggiungi criteri IAM restrittivi alle istanze Cloud SQL interessate.
  • MySQL
  • PostgreSQL
  • SQL Server
• Per limitare l'accesso all'API Cloud SQL Admin, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Exfiltration: Cloud SQL Over-Privileged Grant risultato come indicato in Esaminare i risultati.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza PostgreSQL Cloud SQL interessata.
     • Nome utente del database: l'utente PostgreSQL che ha concesso privilegi in eccesso.
     • Query sul 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 PostgreSQL Cloud SQL interessata.
     • Nome completo della risorsa padre: il nome della risorsa dell'istanza PostgreSQL Cloud SQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza PostgreSQL Cloud SQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Per visualizzare il JSON completo del rilevamento, 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 per le funzioni o le procedure nel database elencato in Nome visualizzato del database (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 Esploratore dei log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. In Esplora log, controlla i log pgaudit di PostgreSQL, che registrano le query eseguite nel database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• 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 (da Nome visualizzato del database del Passaggio 1, revoca le autorizzazioni non necessarie ai beneficiari (da Beneficiari del database del Passaggio 1.

Initial Access: Database Superuser Writes to User Tables

Rileva quando l'account superutente del database Cloud SQL (postgres per PostgreSQL e root per MySQL) scrive nelle tabelle degli utenti. In genere, il super user (un ruolo con accesso molto ampio) 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, potrebbe indicare che un 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Initial Access: Database Superuser Writes to User Tables risultato come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, 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 MySQL o PostgreSQL Cloud SQL interessata.
     • Nome utente del database: il superutente.
     • Query sul database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa dell'istanza Cloud SQL interessata.
     • Nome completo padre: il nome della risorsa dell'istanza Cloud SQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Per visualizzare il JSON completo del rilevamento, 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 Esploratore dei log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. Controlla i log pgaudit di PostgreSQL o i log di controllo di Cloud SQL per MySQL, che contengono le query eseguite dal superutente, utilizzando i seguenti filtri:
   • protoPayload.request.user="SUPERUSER"

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Controlla gli utenti autorizzati a connettersi al database.

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

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

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

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

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

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

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

Initial Access: Anonymous GKE resource created from the internet

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

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

Questi utenti e gruppi sono effettivamente anonimi. Un'associazione 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 l'associazione RBAC associata per assicurarti che l'associazione sia necessaria. Se la associazione non è necessaria, rimuovila. Per maggiori dettagli, consulta il messaggio di log relativo a questo rilevamento.

Per attenuare il problema, consulta Evitare ruoli e gruppi predefiniti.

Initial Access: GKE resource modified anonymously from the internet

Rileva quando un attore potenzialmente malintenzionato ha utilizzato uno dei seguenti gruppi di utenti o 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'associazione del controllo degli accessi basato su 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 la associazione non è necessaria, rimuovila. Per maggiori dettagli, consulta il messaggio di log relativo a questo rilevamento.

Per attenuare il problema, consulta Evitare ruoli e gruppi predefiniti.

Initial Access: Dormant Service Account Action

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Initial Access: Dormant Service Account Action risultato come indicato in Esaminare i 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 inattivo che ha eseguito l'azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui è stato eseguito l'accesso dall'account di servizio
   • Nome metodo: il metodo chiamato

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di 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 per 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Initial Access: Dormant Service Account Key Created risultato come indicato in Esaminare i 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 della risorsa: la chiave del account di servizio inattivo appena creata
   • Nome completo del progetto: il progetto in cui risiede l'account di servizio inattivo

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'indirizzo email principale se è compromesso.
• Annullare la chiave dell'account di servizio appena creata nella pagina Account di servizio.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il consigliere IAM.

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 che è stata pubblicata su internet pubblico. Ad esempio, le chiavi dei account di servizio vengono spesso pubblicate per errore sul repository pubblico di GitHub.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Initial Access: Leaked Service Account Key Used risultato come indicato in Esaminare i 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 è stato eseguito l'accesso dall'account di servizio
   • Nome metodo: il nome del metodo dell'azione
   • Nome chiave dell'account di servizio: la chiave dell'account di servizio divulgata utilizzata per autenticare questa azione
   • Descrizione: la descrizione di ciò che è stato rilevato, inclusa la posizione su internet pubblico in cui è possibile trovare la chiave dell'account di servizio

   In Risorsa interessata:

   • Nome visualizzato della risorsa: la risorsa coinvolta nell'azione

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella barra degli strumenti della console Google Cloud, seleziona il 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 annotato nel campo Email principale nei dettagli del rilevamento. Sostituisci SERVICE_ACCOUNT_KEY_NAME con il valore annotato nel campo Nome chiave dell'account di servizio nei dettagli del rilevamento.

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 problemi rilevati.

• 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 l'account di servizio compromesso.
• Esegui la rotazione ed elimina tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima dell'eliminazione, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.

Initial Access: Excessive Permission Denied Actions

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   In Che cosa è stato rilevato:

   • Indirizzo email dell'entità: l'entità che ha attivato 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 metodo: il metodo chiamato quando si è verificato l'ultimo errore di autorizzazione negata

3. Nei dettagli del rilevamento, nella scheda Proprietà di origine, prendi nota dei valori dei seguenti campi nel file 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 dell'ultima occorrenza dell'errore. Vengono visualizzate al massimo 10 voci.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella barra degli strumenti della console Google Cloud, seleziona il 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 annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario dell'account nel campo Indirizzo email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
• Elimina le risorse del progetto create dall'account, ad esempio istanze Compute Engine, snapshot, service account e utenti IAM sconosciuti e così via.
• Contatta il proprietario del progetto con l'account e, se necessario, elimina o disattiva l'account.

Brute Force: SSH

Rilevamento di un attacco di forza bruta SSH riuscito su un host. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Brute Force: SSH come indicato in Esaminare i risultati.

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

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

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

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Esegui accertamenti in Google Security Operations: esegui il collegamento a Google SecOps.

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 risultato
     • properties:
       • attempts:
       • Attempts: il numero di tentativi di accesso
         • username: l'account che ha eseguito l'accesso
         • vmName: il nome della macchina virtuale
         • authResult: il risultato dell'autenticazione SSH

Passaggio 2: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'utile cronologia. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

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

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

   Vai a Risultati

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

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

   La tabella viene compilata con i risultati relativi al tipo di origine selezionato.

4. Nella tabella, fai clic su un Brute Force: SSH risultato in category. Viene visualizzato il riquadro dei dettagli del risultato.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui accertamenti in Google Security Operations.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire un'indagine su un utente
• Eseguire indagini su un indirizzo IP
• Esaminare un asset

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai a 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 corrispondente al nome e alla zona in vmName. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

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

Passaggio 4: controlla i log

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

Passaggio 5: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Account validi: account locali.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con il tentativo di forza bruta riuscito.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.
• Valuta la possibilità di disattivare l'accesso SSH alla VM. Per informazioni su come disattivare le chiavi SSH, consulta Limitare 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 del firewall o utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda della quantità di informazioni, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.

Credential Access: External Member Added To Privileged Group

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

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

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di 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: controlla 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 seleziona remove_circle_outline Rimuovi membro o not_interested Banna membro.

   Per rimuovere o aggiungere membri, devi essere un amministratore di Google Workspace o disporre del ruolo Proprietario o Gestore nel gruppo Google. Per saperne di più, consulta Assegnare ruoli ai membri di un gruppo.

Passaggio 3: controlla i log

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

2. Se necessario, seleziona il progetto.

   

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

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

Passaggio 4: cerca i metodi di attacco e risposta

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

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 utilizzato dagli attaccanti per creare un accesso permanente a un cluster compromesso. Le autorizzazioni associate al certificato variano a seconda dell'oggetto incluso, ma possono essere molto 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à dannose 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 utilizzato dagli utenti malintenzionati per creare un accesso permanente a un cluster compromesso. Le autorizzazioni associate al certificato variano a seconda dell'oggetto incluso, ma possono essere molto privilegiate. Per ulteriori dettagli, consulta il messaggio di log relativo a 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à dannose 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 firmatario integrato, ma alla fine ha dovuto essere approvata manualmente perché non soddisfaceva i criteri del firmatario?
   • 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: Privileged Group Opened To Public

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

Rileva quando un gruppo Google privilegiato (un gruppo a cui sono stati concessi ruoli o autorizzazioni sensibili) viene modificato in modo da essere accessibile al pubblico in generale. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche, che potrebbe essere compromesso.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di 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 adesione al gruppo

Passaggio 2: controlla le impostazioni di accesso al gruppo

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

   Vai alla Console di amministrazione

2. Nel riquadro di navigazione, fai clic su Directory 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 adesione al gruppo.

5. Se necessario, modifica l'impostazione di unione nel menu a discesa.

Passaggio 3: controlla i log

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

2. Se necessario, seleziona il progetto.

   

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

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

Passaggio 4: cerca i metodi di attacco e risposta

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

Credential Access: Secrets Accessed in Kubernetes Namespace

Rileva quando un default account di servizio Kubernetes 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 non lo abbia concesso esplicitamente con un oggetto Role o ClusterRole.

Credential Access: Sensitive Role Granted To Hybrid Group

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

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Credential Access: Sensitive Role Granted To Hybrid Group risultato, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • 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 in cui è stato concesso il nuovo ruolo.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di 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 assegnati a questo gruppo.

Passaggio 2: esamina le autorizzazioni del gruppo

1. Vai alla pagina IAM nella console Google Cloud.

   Vai a IAM

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

3. Esamina i ruoli sensibili concessi al gruppo.

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

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

Passaggio 3: controlla i log

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

2. Se necessario, seleziona il progetto.

   

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

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

Passaggio 4: cerca i metodi di attacco e risposta

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

Malware: Cryptomining Bad IP

Il malware viene rilevato esaminando i log di flusso VPC e i log Cloud DNS per verificare la presenza di connessioni a indirizzi IP e domini di comando e controllo noti. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Malware: Cryptomining Bad IP, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • IP di origine: l'indirizzo IP sospetto 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 di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Flow Analyzer (anteprima): 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 rilevamento, fai clic sulla scheda Proprietà sorgente.

4. Espandi properties e prendi nota dei valori del progetto e dell'istanza nel seguente campo:

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

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

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

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato in properties_project_id.

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

4. Fai clic sull'istanza VM 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 disattiva le regole firewall eccessivamente permissive.

Passaggio 3: controlla i log

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

   Vai a Esplora log

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

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

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

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Rutto delle risorse.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• 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 agli endpoint.
• Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole del 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.

Initial Access: Log4j Compromise Attempt

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

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   • Nella visualizzazione dettagliata del rilevamento, 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 verificare la presenza di token di stringa come ${jndi:ldap:// che potrebbero indicare possibili tentativi di sfruttamento.

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

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Sfrutta un'applicazione rivolta al pubblico.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Esegui l'upgrade alla versione più recente di Log4j2.
• Segui i consigli di Google Cloud per esaminare e rispondere alla vulnerabilità "Apache Log4j 2".
• Implementa le tecniche di mitigazione consigliate in Vulnerabilità di sicurezza di Apache Log4j.
• Se utilizzi Google Cloud Armor, esegui il deployment di cve-canary rule in un criterio di sicurezza Google Cloud Armor nuovo o esistente. Per ulteriori informazioni, consulta Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j.

Active Scan: Log4j Vulnerable to RCE

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

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un rilevamento Active Scan: Log4j Vulnerable to RCE, come indicato in Rivedere i dettagli del rilevamento. 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'attacco RCE di Log4j.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Nella visualizzazione dettagliata del rilevamento, 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 nell'istanza in cui è stata eseguita la query DNS.

Passaggio 2: controlla i log

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

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

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

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Sfruttamento di servizi remoti.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Esegui l'upgrade alla versione più recente di Log4j2.
• Segui i consigli di Google Cloud per esaminare e rispondere alla vulnerabilità "Apache Log4j 2".
• Implementa le tecniche di mitigazione consigliate in Vulnerabilità di sicurezza di Apache Log4j.
• Se utilizzi Google Cloud Armor, esegui il deployment di cve-canary rule in un criterio di sicurezza Google Cloud Armor nuovo o esistente. Per ulteriori informazioni, consulta Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j.

Leaked credentials

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

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

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un rilevamento account_has_leaked_credentials, come indicato in Rivedere i dettagli del rilevamento. Il riquadro dei dettagli per il 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: l'account di servizio potenzialmente compromesso
   • Project_identifier: il progetto che contiene le credenziali dell'account potenzialmente divulgate
   • URL: il link al repository GitHub

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

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

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

   Vai a IAM

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

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

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

   Vai ad Account di servizio

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

Passaggio 3: controlla i log

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

   Vai a Esplora log

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

3. Nella pagina che si carica, controlla i log per verificare la presenza di attività provenienti da 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: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Esamina i risultati correlati facendo clic sul link in relatedFindingURI. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con le credenziali trapelate.
• Valuta la possibilità di eliminare l'account di servizio compromesso, nonché di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere alle notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.
• Apri il link URL ed elimina le credenziali compromesse. Raccogliere altre informazioni sull'account compromesso e contattare il proprietario.

Malware

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

I passaggi riportati di seguito descrivono come effettuare accertamenti e rispondere ai risultati basati su IP. I passaggi per la correzione sono simili per i risultati basati sul dominio.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento di malware pertinente. I passaggi che seguono utilizzano il risultato Malware: Bad IP, come indicato nella sezione Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • 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 controllo e un comando 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 del 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 rilevamento.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Esegui accertamenti in Google Security Operations: esegui il collegamento a Google SecOps.
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.
     • Flow Analyzer (anteprima): 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: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'utile sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

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

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

   Vai a Risultati

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

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

   La tabella viene compilata con i risultati relativi al tipo di origine selezionato.

4. Nella tabella, fai clic sul rilevamento Malware: Bad IP in category. Si apre il riquadro dei dettagli della ricerca.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui accertamenti in Google Security Operations.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire indagini su un indirizzo IP
• Esaminare un asset

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato nella riga Nome completo del progetto nella scheda Riepilogo.

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

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

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

Passaggio 4: controlla i log

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

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

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

     Sostituisci quanto segue:

     • PROJECT_ID con il progetto selezionato elencato in projectId.
     • SOURCE_IP con l'indirizzo IP elencato nella riga IP di origine della scheda Riepilogo dei dettagli del rilevamento.

Passaggio 5: controlla Flow Analyzer

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

1. Assicurati di aver eseguito l'upgrade del bucket di log per utilizzare Analisi dei log. Per istruzioni, consulta Eseguire l'upgrade di un bucket per utilizzare Analisi dei log. L'upgrade non comporta costi aggiuntivi.

2. Nella console Google Cloud, vai alla pagina Strumento di analisi dei flussi:

   Vai a Flow Analyzer

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

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 prima segnalazione del risultato. Ad esempio, se il rilevamento è stato segnalato nelle ultime 2 ore, puoi impostare il periodo di tempo su Ultime 6 ore. In questo modo, il periodo di tempo in Flow Analyzer include la data e l'ora in cui è stato registrato il rilevamento.

4. Filtra lo strumento di analisi del flusso per visualizzare i risultati appropriati per l'indirizzo IP associato al rilevamento di IP dannosi:

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

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

      Se Flow Analyzer non mostra risultati per l'indirizzo IP, elimina 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 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Dynamic Resolution e Command and Control.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa 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 contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
4. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• 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 agli endpoint.
• Per monitorare le attività e le vulnerabilità che hanno consentito l'inserimento di malware, controlla i log di controllo e i log syslog associati all'istanza compromessa.
• Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole del 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 la policy IAM Shielded VM e Immagini attendibili.

Persistence: IAM Anomalous Grant

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

Di seguito sono riportati alcuni esempi di concessioni anomale:

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

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

L'elenco seguente mostra tutte le possibili sottoregole e le relative gravità:

• external_service_account_added_to_policy:
  • HIGH, se è stato concesso un ruolo con elevata sensibilità o se è stato concesso un ruolo con media sensibilità a livello di organizzazione. Per ulteriori informazioni, consulta Ruoli altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo con sensibilità media. Per ulteriori informazioni, consulta Ruoli con livello di sensibilità medio.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, se è stato concesso un ruolo con elevata sensibilità o se è stato concesso un ruolo con media sensibilità a livello di organizzazione. Per ulteriori informazioni, consulta Ruoli con informazioni altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo con sensibilità media. Per ulteriori informazioni, consulta Ruoli con livello di sensibilità medio.
• 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Persistence: IAM Anomalous Grant come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Indirizzo 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 di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.
     • Esegui accertamenti in Google Security Operations: esegui il collegamento a Google SecOps.

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

4. Nel file JSON del rilevamento, prendi nota dei seguenti campi:

   • detectionCategory:
     • subRuleName: informazioni più specifiche sul tipo di assegnazione 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 rilevamento.
   • 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: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'utile sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

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

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

   Vai a Risultati

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

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

   La tabella viene compilata con i risultati relativi al tipo di origine selezionato.

4. Nella tabella, fai clic su un Persistence: IAM Anomalous Grant risultato in category. Si apre il riquadro dei dettagli della ricerca.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui accertamenti in Google Security Operations.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire un'indagine su un utente
• Esaminare un asset

Passaggio 3: controlla i log

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

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di segnalazione: 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, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Persistence: Impersonation Role Granted for Dormant Service Account

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Persistence: Impersonation Role Granted for Dormant Service Account risultato come indicato in Esaminare i 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: l'account di servizio inattivo come risorsa
   • Nome completo del progetto: il progetto in cui risiede l'account di servizio inattivo

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, 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 problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'indirizzo email principale se è compromesso.
• Rimuovi il ruolo di rappresentazione appena concesso dal membro di destinazione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il consigliere IAM.

Persistence: Unmanaged Account Granted Sensitive Role

Rileva gli eventi in cui un ruolo sensibile viene concesso a un account non gestito. Gli account non gestiti non possono essere controllati dagli amministratori di sistema. Ad esempio, quando il lavoratore 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Persistence: Unmanaged Account Granted Sensitive Role risultato come indicato in Esaminare i 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'account non gestito che riceve la concessione
   • Concessioni di accesso illecite.Ruolo concesso: il ruolo sensibile concesso

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario del campo Indirizzo email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Rivolgiti al proprietario del campo Concessioni di accesso non conformi.Nome principale per comprendere l'origine dell'account non gestito.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, 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 problemi rilevati.

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

Persistence: New API Method

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

• Nuova attività di un principale in un'organizzazione, una cartella o un progetto
• Attività che non vengono visualizzate da un po' di tempo da un amministratore in un'organizzazione, una cartella o un progetto

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Persistence: New API Method come indicato in Esaminare i rilevamenti.

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

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

Passaggio 2: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: 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 viene visualizzato nella riga Percorso risorsa e l'account nella riga Indirizzo email principale.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Persistence: New Geography

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

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

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Persistence: New Geographyrisultato come indicato nella sezione Esaminare i dettagli del risultato di questa pagina. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

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

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

2. Nel JSON, tieni presente i seguenti campi sourceProperties:

   • affectedResources:
     • gcpResourceName: la risorsa interessata
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il rilevamento.
   • 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 posizioni in cui l'utente accede solitamente alle risorse Google Cloud.

Passaggio 2: controlla 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 Indirizzo email principale e controlla i ruoli concessi.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, 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 verificare la presenza di attività provenienti da 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: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con l'account compromesso.
• Controlla i campi anomalousLocation, typicalGeolocations e notSeenInLast per verificare se l'accesso è anomalo e se l'account è stato compromesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitare le 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 accede a Google Cloud utilizzando software sospetto, come indicato da un agente utente anomalo.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Persistence: New User Agent risultato, come indicato nella sezione Esaminare i dettagli del risultato di 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 l'account di servizio potenzialmente compromesso.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.
   2. Nel JSON, prendi nota dei seguenti campi.
   • projectId: il progetto contenente 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: controlla 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 Filtra, inserisci il nome dell'account elencato nella riga Indirizzo email principale della scheda Riepilogo dei dettagli del risultato e controlla i ruoli concessi.

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

   Vai ad Account di servizio

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

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, 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 verificare la presenza di attività provenienti da 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: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Contatta il proprietario del progetto con l'account compromesso.
• Esamina i campi anomalousSoftwareClassification, callerUserAgent e behaviorPeriod per verificare se l'accesso è anomalo e se l'account è stato compromesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitare le località delle risorse.
• 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 rilevamento

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

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

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

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

4. Prendi nota dei dettagli dell'associazione visualizzata.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer 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, pertanto le modifiche non sono così chiare.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi
2. Conferma la sensibilità dell'oggetto sottoposto a query e se la modifica è giustificata.
3. Per le associazioni, puoi controllare l'oggetto e verificare se ha bisogno del ruolo a cui è associato.
4. Determina se esistono altri indicatori di attività dannose 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 della tua indagine con la ricerca MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha creato una richiesta di firma del certificato (CSR) master di Kubernetes, che gli consente di accedere con il ruolo cluster-admin.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Create Kubernetes CSR for master cert risultato come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

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

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer 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 se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi.
2. Esamina 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 della tua indagine con la ricerca MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

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

Passaggio 1: esamina i dettagli del rilevamento

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

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

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

Passaggio 2: controlla i log

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

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi.
2. Conferma la sensibilità dell'associazione creata e se i ruoli sono necessari per i soggetti.
3. Per le associazioni, puoi controllare l'oggetto e verificare se ha bisogno del ruolo a cui è associato.
4. Determina se esistono altri indicatori di attività dannose 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 della tua indagine con la ricerca MITRE.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Qualcuno ha creato un'associazione 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 si creano associazioni di ruoli o associazioni di ruoli del cluster a qualsiasi ruolo RBAC. Controlla la associazione per assicurarti che sia necessaria. Se il vincolo non è necessario, rimuovilo. Per ulteriori dettagli, consulta il messaggio di log relativo a questo rilevamento.

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à dannose 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: 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 rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di 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 rilevamento, è un metodo GET:

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer 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: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: 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 della tua indagine con la ricerca MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

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

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

Passaggio 1: esamina i dettagli del rilevamento

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

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

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

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

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

Passaggio 2: controlla i log

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

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

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

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi.
2. Conferma che il contenitore creato richieda l'accesso alle risorse dell'host e alle funzionalità del kernel.
3. Determina se esistono altri indicatori di attività dannose da parte dell'entità nei log.

4. 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à.

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

Privilege Escalation: Dormant Service Account Granted Sensitive Role

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Dormant Service Account Granted Sensitive Role risultato come indicato in Esaminare i 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: l'account di servizio inattivo che ha ricevuto il ruolo sensibile
   • Concessioni di accesso non conformi.Ruolo concesso: il ruolo IAM sensibile assegnato

   In Risorsa interessata:

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, 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 problemi rilevati.

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

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

La simulazione anomala dell'identità del service account viene rilevata esaminando i log di controllo dell'attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity come indicato in Esaminare i rilevamenti. 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:
     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud.
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità.
     • Nome metodo: il metodo chiamato.
     • Informazioni sulla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. L'entità in fondo all'elenco è l'autore della richiesta di simulazione dell'identità.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica 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 problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di 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 un account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity come indicato in Esaminare i rilevamenti. 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:
     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud.
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. L'entità in fondo all'elenco è l'autore della richiesta di simulazione dell'identità.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica 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 problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di 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 furto d'identità dell'account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access come indicato in Esaminare i rilevamenti. 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:
     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità
     • Nome metodo: il metodo chiamato
     • Informazioni sulla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. Il principale in fondo all'elenco è l'autore della richiesta di rappresentazione
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica 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 problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity come indicato in Esaminare i rilevamenti. 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:

     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità
     • Nome metodo: il metodo chiamato
     • Informazioni sulla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. Il principale in fondo all'elenco è l'autore della richiesta di rappresentazione

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

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

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica 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 problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Il simulatore anomalo dell'identità di un account di servizio viene rilevato esaminando i log di controllo dell'accesso ai dati per verificare se si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilievo Privilege Escalation: Anomalous Service Account Impersonator for Data Access, come indicato in Esaminare i risultati.

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

   In Che cosa è stato rilevato:

   • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud
   • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità
   • Nome metodo: il metodo chiamato
   • Informazioni sulla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. Il principale in fondo all'elenco è l'autore della richiesta di rappresentazione

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica 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 problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: ClusterRole with Privileged Verbs

Qualcuno ha creato un oggetto ClusterRole RBAC contenente i verbi bind, escalate o impersonate. Un soggetto associato a un ruolo con questi verbi può assumere l'identità di altri utenti con privilegi superiori, associarsi ad altri oggetti Role o ClusterRole contenenti autorizzazioni aggiuntive o modificare le proprie autorizzazioni ClusterRole. Ciò potrebbe portare questi soggetti a ottenere i privilegicluster-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à dannose 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 ClusterRoleBinding RBAC che fa riferimento al predefinito system:controller:clusterrole-aggregation-controller ClusterRole. Questo ClusterRole predefinito ha il verbo escalate, che consente ai soggetti di modificare i privilegi dei propri ruoli, consentendo la escalation dei privilegi. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

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

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Qualcuno ha eseguito il deployment di un pod con una convenzione di denominazione simile a quella degli strumenti comuni utilizzati per le uscite dai container o per eseguire altri attacchi sul cluster. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannose 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 in un percorso sensibile sul file system del nodo host. L'accesso a questi percorsi sul file system dell'host può essere utilizzato per accedere a informazioni privilegiate o sensibili sul nodo e per le uscite dal contenitore. Se possibile, non consentire volumi hostPath nel cluster. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina il carico di lavoro 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 anziché / o /etc.
2. Determina se esistono altri indicatori di attività dannose 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 carico di lavoro con l'opzione shareProcessNamespace impostata su true, consentendo a tutti i container di condividere lo stesso spazio dei nomi dei processi Linux. Ciò potrebbe consentire a un contenitore non attendibile o compromesso di eseguire la riassegnazione dei privilegi accedendo e controllando le variabili di ambiente, la memoria e altri dati sensibili dei processi in esecuzione in altri contenitori. Alcuni carichi di lavoro potrebbero richiedere il funzionamento di questa funzionalità per motivi legittimi, ad esempio la gestione dei log dei container sidecar o dei container di debug. Per ulteriori dettagli, consulta il messaggio del 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), identificate la legittimità del motivo per cui il account di servizio ha eseguito questa azione.

Service account self-investigation

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

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Discovery: Service Account Self-Investigationrisultato come indicato nella sezione Esaminare i dettagli del risultato di 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 rilevamento non è stata autorizzata: l'account di servizio non ha l'autorizzazione per eseguire query sulle 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 della risorsa:
     • Nome completo del progetto: il progetto che contiene le credenziali dell'account potenzialmente divulgate.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

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

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

   Vai a IAM

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

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

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

   Vai ad Account di servizio

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, 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 verificare la presenza di attività provenienti da 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: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Scoperta gruppi di autorizzazioni: gruppi cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection esamina i log di controllo per rilevare l'eliminazione di host su cui vengono eseguite 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

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 di host di backup e RE.
3. Seleziona l'opzione Aggiungi host per aggiungere nuovamente l'host eliminato.

Inhibit System Recovery: Google Cloud Backup and DR remove plan

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

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

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

Inhibit System Recovery: Google Cloud Backup and DR delete template

Security Command Center esamina 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 rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

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

Inhibit System Recovery: Google Cloud Backup and DR delete policy

Gli audit log vengono esaminati per rilevare l'eliminazione di un criterio. Un criterio definisce come viene eseguito un backup e dove viene archiviato.

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestione app, seleziona l'applicazione interessata e controlla le impostazioni dei Criteri applicate all'applicazione.

Inhibit System Recovery: Google Cloud Backup and DR delete profile

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

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Piani di backup, seleziona Profili per un elenco di tutti i profili. 3. Esamina i profili per verificare che siano presenti tutti i profili 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.

Inhibit System Recovery: 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 e RE.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome 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 della risorsa: il progetto in cui è stato eliminato il pool di archiviazione
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

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

Data Destruction: Google Cloud Backup and DR expire image

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

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

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

Data Destruction: Google Cloud Backup and DR expire all images

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

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

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

Data Destruction: Google Cloud Backup and DR remove appliance

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

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestore app, individua le applicazioni interessate che non sono più protette ed esamina i criteri di backup per ciascuna. 3. Per creare una nuova appliance e applicare nuovamente le protezioni alle app non protette, vai a Backup e RE nella console Google Cloud e seleziona l'opzione Esegui il deployment di un'altra appliance di backup o di recupero. 4. Nel menu Archiviazione, configura ogni nuovo appliance con una destinazione di archiviazione. Dopo aver configurato un'appliance, questa viene visualizzata come opzione quando crei un profilo per le tue applicazioni.

Impact: Google Cloud Backup and DR reduced backup expiration

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestione app, individua l'applicazione interessata per la quale è stata ridotta la scadenza del backup e verifica che la scadenza sia stata intenzionale da parte del principale.
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 dei backup.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestore app, individua l'applicazione interessata per la quale è stata ridotta la frequenza del backup e verifica che la modifica sia stata intenzionale da parte del principale.
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: Suspicious Kubernetes Container Names - Coin Mining

Qualcuno ha disegnato un pod con una convenzione di denominazione simile a quella dei comuni miner di monete virtuali. 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 relativo a questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannose 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.

Lateral Movement: Modified Boot Disk Attached to Instance

I log di controllo vengono esaminati per rilevare movimenti sospetti dei dischi tra le risorse delle istanze Compute Engine. Un disco di avvio potenzialmente modificato è stato collegato a Compute Engine.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Lateral Movement: Modify Boot Disk Attaching to Instance, come descritto in Esaminare i 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à: l'account di servizio che ha eseguito l'azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui è stato eseguito l'accesso dall'account di servizio
   • Nome metodo: il metodo chiamato

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di utilizzare Secure Boot per le tue istanze VM Compute Engine.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.

Privilege Escalation: AlloyDB Over-Privileged Grant

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

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: AlloyDB Over-Privileged Grant risultato come indicato in Esaminare i risultati.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza AlloyDB per PostgreSQL interessato.
     • Nome utente del database: l'utente PostgreSQL che ha concesso privilegi in eccesso.
     • Query sul 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 AlloyDB per PostgreSQL interessata.
     • Nome completo principale: il nome della risorsa dell'istanza AlloyDB per PostgreSQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza AlloyDB per PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.

3. Per visualizzare il JSON completo del rilevamento, 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 per le funzioni o le procedure nel database elencato in Nome visualizzato del database (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 Esploratore dei log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. In Esplora log, controlla i log pgaudit di PostgreSQL, che registrano le query eseguite nel database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• 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 (da Nome visualizzato del database del Passaggio 1, revoca le autorizzazioni non necessarie ai beneficiari (da Beneficiari del database del Passaggio 1.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Rileva quando l'account super user del database AlloyDB per PostgreSQL (postgres) scrive nelle tabelle utente. In genere, il super user (un ruolo con accesso molto esteso) 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 dell'utente, 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 riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Privilege Escalation: AlloyDB Database Superuser Writes to User Tables risultato come indicato in Esaminare i risultati.

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

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

3. Per visualizzare il JSON completo del rilevamento, 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 pgaudit di PostgreSQL, che contengono le query eseguite dal superutente, utilizzando i seguenti filtri:
   • protoPayload.request.user="postgres"

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Rilevamento dei metadati di amministrazione di Compute Engine

Persistence: GCE Admin Added SSH Key

Persistence: GCE Admin Added Startup Script

Rilevamento dei log di Google Workspace

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

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

I risultati per Google Workspace sono disponibili solo per le attivazioni di Security Command Center a livello di organizzazione. Non è possibile eseguire la scansione dei log di Google Workspace per verificare le attivazioni a livello di progetto.

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

• Centro notifiche di Google Workspace
• Centro per la sicurezza di Google Workspace

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

Se non sei un amministratore di Google Workspace, svolgi i seguenti passaggi:

• Se riesci ad accedere al tuo account, cambia 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.

Rilevamento di minacce Cloud IDS

Cloud IDS: THREAT_ID

I risultati di Cloud IDS vengono generati da Cloud IDS, che è un servizio di sicurezza che monitora il traffico verso e da le risorse Google Cloud per rilevare minacce. Quando Cloud IDS rileva una minaccia, invia informazioni sulla minaccia, ad esempio l'indirizzo IP di origine, l'indirizzo di destinazione e il numero di porta, a Event Threat Detection, che emette un rilevamento di minaccia.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri la verifica Cloud IDS: THREAT_ID, come indicato in Esaminare i risultati.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Protocollo: il protocollo di rete utilizzato
     • Ora evento: l'ora in cui si è verificato l'evento
     • Descrizione: ulteriori informazioni sul risultato
     • Gravità: la gravità dell'avviso
     • IP di destinazione: l'IP target del traffico di rete
     • Porta di destinazione: la porta di destinazione del traffico di rete
     • IP di origine: l'IP di origine del traffico di rete
     • Porta di origine: la porta di origine del traffico di rete
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il progetto contenente la rete con la minaccia
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di logging di Cloud IDS, che contengono le informazioni necessarie per eseguire ricerche nella Threat Vault di Palo Alto Networks
   • Detection Service
     • Categoria risultati Il nome della minaccia Cloud IDS

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

Passaggio 2: cerca i metodi di attacco e risposta

Dopo aver esaminato i dettagli del rilevamento, 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 del log originale facendo clic sul link nel campo URI Cloud Logging nei dettagli del rilevamento.

Risposte di Container Threat Detection

Per scoprire di più su Container Threat Detection, consulta come funziona Container Threat Detection.

Added Binary Executed

È stato eseguito un file binario che non faceva parte dell'immagine container originale. Gli aggressori installano comunemente malware e strumenti di sfruttamento dopo la compromissione iniziale. Garantire l'immutabilità dei contenitori è una best practice importante. Si tratta di un esito di bassa gravità, perché la tua organizzazione potrebbe non seguire questa best practice. Esistono risultati corrispondenteExecution: Added Malicious Binary Executed quando l'hash del codice binario è un indicatore di compromissione (IoC) noto. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del file binario aggiunto.
     • Argomenti: gli argomenti forniti quando viene chiamato il file binario aggiunto.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione 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 contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore 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 contenitore. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché un mancato rispetto delle best practice.

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai 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 della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

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

   Sostituisci quanto segue:

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

5. Recupera il file binario aggiunto eseguendo:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con il percorso di un file locale per memorizzare 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 contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

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

• Se il file binario doveva essere incluso nel contenitore, ricostruisci l'immagine del contenitore con il file binario incluso. In questo modo, il contenitore può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenitore.

Added Library Loaded

È stata caricata una libreria che non faceva parte dell'immagine contenitore originale. I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Garantire l'immutabilità dei contenitori è una best practice importante. Si tratta di un rilevamento di bassa gravità, 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 noto di compromissione (IoC). Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso completo del programma binario che ha caricato la biblioteca.
     • Raccolte: i dettagli della raccolta aggiunta.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della 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 la risorsa.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore 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 contenitore. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché un mancato rispetto delle best practice.

Passaggio 2: controlla 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 relativo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai 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 della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo 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 a livello di regione:

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

5. Recupera la libreria aggiunta eseguendo:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con il percorso di un 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 contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, Moduli condivisi.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Execution: Added Malicious Binary Executed

È stato eseguito un file binario dannoso che non faceva parte dell'immagine container originale. Gli aggressori installano comunemente malware e strumenti di sfruttamento dopo la compromissione iniziale. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del file binario aggiunto.
     • Argomenti: gli argomenti forniti quando viene chiamato il file binario aggiunto.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome 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:

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

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai 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 della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

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

   Sostituisci quanto segue:

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

5. Recupera il programma binario dannoso aggiunto:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per memorizzare il file binario dannoso aggiunto.

6. Connettiti all'ambiente del contenitore:

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

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

Passaggio 6: cerca metodi di attacco e risposta

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

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

Execution: Added Malicious Library Loaded

È stata caricata una libreria dannosa che non faceva parte dell'immagine del contenitore originale. I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Added Malicious Library Loaded come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso completo del programma binario che ha caricato la biblioteca.
     • Raccolte: i dettagli della raccolta aggiunta.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della 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:

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

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai 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 della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

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

5. Recupera la libreria dannosa aggiunta:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

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

6. Connettiti all'ambiente del contenitore:

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

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

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, Moduli condivisi.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Execution: Built in Malicious Binary Executed

Un file binario che è stato eseguito, con il file binario:

• Inclusi nell'immagine del contenitore originale.
• Identificato come dannoso in base alle informazioni di Threat Intelligence.

L'attaccante ha il controllo del repository delle immagini container o della pipeline di creazione, dove il codice binario dannoso viene inserito nell'immagine container. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del programma binario integrato.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario integrato.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione 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:

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

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai 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 della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

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

   Sostituisci quanto segue:

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

5. Recupera il file binario dannoso integrato:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare il file binario dannoso di Tin compilato.

6. Connettiti all'ambiente del contenitore:

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

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

Passaggio 6: cerca metodi di attacco e risposta

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

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

Execution: Container Escape

È stato eseguito uno strumento binario sospetto noto per attività di container escape. Ciò potrebbe indicare un tentativo di container escape, in cui un processo all'interno del contenitore tenta di uscire dall'isolamento e interagire con il sistema di hosting o con altri contenitori. Si tratta di un rilevamento di alta gravità, in quanto suggerisce che un malintenzionato potrebbe tentare di ottenere l'accesso oltre i confini del contenitore, potenzialmente compromettendo l'host o un'altra infrastruttura. Le uscite dal contenitore possono essere causate da configurazioni errate, vulnerabilità nei runtime dei container o sfruttamento di container con privilegi.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Container Escape come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

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

3. Nella visualizzazione dettagliata del rilevamento, 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 programma 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 contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore 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 contenitore. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'assenza di rispetto delle best practice.

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo 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'annotazionecontainer.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

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

Sostituisci quanto segue:

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

1. Recupera il file binario eseguito:

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

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

2. Connettiti all'ambiente del contenitore eseguendo il seguente comando:

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Evasione all'host.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Execution: Kubernetes Attack Tool Execution

All'interno del contenitore è stato eseguito uno strumento di attacco Kubernetes, il che indica un potenziale tentativo di sfruttare le vulnerabilità nell'ambiente Kubernetes. Questi strumenti vengono spesso utilizzati dagli aggressori per eseguire la riassegnazione dei privilegi, eseguire movimenti laterali o compromettere altre risorse all'interno del cluster. Si tratta di un esito di gravità critica, poiché l'esecuzione di questi strumenti suggerisce un tentativo deliberato di ottenere il controllo dei componenti di Kubernetes, come il server API, i nodi o i carichi di lavoro. Gli attaccanti potrebbero utilizzare questi strumenti per aggirare i controlli di sicurezza, manipolare le configurazioni o esfiltrare dati sensibili.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Kubernetes Attack Tool Execution come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

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

3. Nella visualizzazione dettagliata del rilevamento, 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 programma 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 contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore 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 contenitore. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'assenza di rispetto delle best practice.

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo 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'annotazionecontainer.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

   gcloud container clusters get-credentials CLUSTER_NAME --region LOCATION --project PROJECT_NAME
   

Sostituisci quanto segue:

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

1. Recupera il file binario eseguito:

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

   Sostituisci LOCAL_FILE con il percorso di un file locale in cui memorizzare il file binario eseguito.

2. Connettiti all'ambiente del contenitore eseguendo il seguente comando:

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Ottieni funzionalità: strumento.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Execution: Local Reconnaissance Tool Execution

È stato eseguito uno strumento di ricognizione locale all'interno del contenitore, il che suggerisce che un malintenzionato stia raccogliendo informazioni sull'ambiente del contenitore, ad esempio configurazioni di rete, processi attivi o file system montati. Questo tipo di strumento viene spesso utilizzato nelle prime fasi di un attacco per mappare i potenziali obiettivi e identificare le debolezze. Si tratta di un rilevamento di media gravità, in quanto indica che l'autore dell'attacco sta sondando attivamente il contenitore per trovare ulteriori opportunità di sfruttamento.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Local Reconnaissance Tool Execution come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

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

3. Nella visualizzazione dettagliata del rilevamento, 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 programma 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 contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore 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 contenitore. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'assenza di rispetto delle best practice.

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo 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'annotazionecontainer.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

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

Sostituisci quanto segue:

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

1. Recupera il file binario aggiunto:

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

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

2. Connettiti all'ambiente del contenitore eseguendo il seguente comando:

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Scansione attiva.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

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

Execution: Malicious Python executed

Un modello di machine learning ha identificato il codice Python eseguito come dannoso. Gli attaccanti possono utilizzare Python per trasferire strumenti ed eseguire comandi senza file binari. Garantire l'immutabilità dei contenitori è una best practice importante. L'utilizzo di script per il trasferimento di strumenti può imitare la tecnica di trasferimento di strumenti di ingresso dell'attaccante e comportare rilevamenti indesiderati.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Malicious Python executed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: dettagli sull'interprete che ha richiamato lo script.
     • Script: percorso assoluto del nome dello script sul disco. Questo attributo viene visualizzato solo per gli script scritti sul disco, non per l'esecuzione di script letterali, ad esempio python3 -c.
     • Argomenti: gli argomenti forniti al momento dell'invocazione dello script.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

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

4. Nel JSON, prendi nota dei seguenti campi.

   • finding:
     • processes:
     • script:
       • contents: i contenuti dello script eseguito, che potrebbero essere troncati per motivi di rendimento; questo può aiutarti nella tua indagine
       • sha256: l'hash SHA-256 di script.contents
   • resource:
     • project_display_name: il nome del progetto che contiene la risorsa.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore in esecuzione.
     • 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 contenitore. Ad esempio, se lo script inserisce un file binario, controlla se sono presenti risultati correlati al file binario.

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai 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 in resource.name e allo spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

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

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster mostrato in resource.labels.cluster_name.

3. Nella pagina Cluster, fai clic su Connetti e poi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge comandi per il cluster nel terminal.

4. Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.

5. Connettiti all'ambiente del contenitore eseguendo il seguente comando:

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

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

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Comando e scripting Interprete, Trasferimento di strumenti di ingresso.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di 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 problemi rilevati.

• Se Python stava apportando modifiche intenzionali al contenitore, ricostruisci l'immagine del contenitore in modo che non siano necessarie modifiche. In questo modo, il contenitore può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenitore.

Execution: Modified Malicious Binary Executed

Un file binario che è stato eseguito, con il file binario:

• Inclusi nell'immagine del contenitore originale.
• Modificati durante il runtime del container.
• Identificato come dannoso in base alle informazioni di Threat Intelligence.

Gli aggressori installano comunemente malware e strumenti di sfruttamento dopo la compromissione iniziale. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del file binario modificato.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario modificato.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione 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:

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

Passaggio 2: controlla 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 della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai 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 della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello 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 si apre, 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 del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"