Analisi e risposta alle minacce

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

Non è garantito che le tecniche riportate in questa pagina siano efficaci contro le minacce precedenti, attuali o future che dovete affrontare. Consulta la sezione Risoluzione dei problemi. per capire perché Security Command Center non forniscono indicazioni ufficiali di correzione per le minacce.

Prima di iniziare

Per visualizzare o modificare risultati e log e modificare le risorse Google Cloud, devi disporre di ruoli di gestione 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. IoC, sviluppati da sviluppatori interni Le origini della sicurezza 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 Livello Premium di Security Command Center a livello di organizzazione, Event Threat Detection può anche analizzare i log di Google Workspace.

Rilevamento delle minacce di container genera risultati raccogliendo e analizzando i comportamenti osservati di basso livello il 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. Per Ad esempio, se selezioni Event Threat Detection o Container Threat Detection nella sottosezione Nome visualizzato origine, solo i risultati della e il servizio selezionato vengono visualizzati nei risultati.

   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 risultato, fai clic sulla scheda JSON.

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

Per aiutarti nella tua indagine, i risultati delle minacce contengono anche link alle le seguenti risorse esterne:

• Le voci del framework MITRE ATT&CK. Il framework spiega le tecniche per gli attacchi al cloud risorse e fornisce indicazioni sulla correzione.
• VirusTotal un servizio di proprietà di Alphabet che fornisce il contesto sulle minacce file, URL, domini e indirizzi IP.

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

Disattivazione dei risultati relativi alle minacce

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

Per un falso positivo, valuta la possibilità di lasciare lo stato del risultato ACTIVE e disattiva invece il 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 necessari da gestire, il che rende più facile identificare una vera minaccia quando si verifica.

Per una minaccia reale, prima di impostare lo stato del risultato su INACTIVE, eliminare la minaccia e completare un'indagine approfondita rilevata la minaccia, la portata dell'intrusione e qualsiasi altro risultato correlato e problemi.

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 gli audit log di Cloud per verificare la presenza di modifiche ai servizi Google Cloud originate da indirizzi IP proxy anonimi, come gli indirizzi IP di Tor.

Per rispondere a questi risultati, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Evasion: Access from Anonymizing Proxy, come indicato in Analisi dei risultati. Il riquadro per il risultato dei dettagli, in cui è visualizzata la scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche (un account compromesso).
     • IP: l'indirizzo IP del proxy dove vengono condotte le modifiche. da cui proviene.
   • 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: collega 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 il MITRE ricerca.

Defense Evasion: Breakglass Workload Deployment Created

Anteprima

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

Breakglass Workload Deployment Created viene rilevato esaminando gli audit log di Cloud per verificare se sono presenti deployment in carichi di lavoro 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 per i 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 entità: l'account che ha eseguito la modifica.
     • Nome metodo: il metodo chiamato.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui in cui è stato eseguito il deployment.
   • Link correlati:
     • 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 risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI 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 nell'attributo Campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i metodi di attacco e di risposta

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

Defense Evasion: Breakglass Workload Deployment Updated

Anteprima

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

La metrica Breakglass Workload Deployment Updated viene rilevata esaminando Cloud Audit Logs per vedere se ci sono aggiornamenti ai carichi di lavoro che usano il flag di deployment di emergenza per eseguire l'override. Controlli di Autorizzazione binaria.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email entità: l'account che ha eseguito la modifica.
     • Nome metodo: il metodo chiamato.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui è stato eseguito l'aggiornamento.
   • Link correlati:
     • 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 risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI 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 nell'attributo Campo Email entità nei dettagli del risultato.

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 carico di lavoro.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli.
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)

Anteprima

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

Qualcuno ha eliminato manualmente una richiesta di firma di certificato (CSR). I CSR sono rimossi automaticamente da un controller di garbage collection, ma i malintenzionati potrebbe eliminarli manualmente per eludere il rilevamento. Se il CSR eliminato riguardava un approvato e rilasciato, l’aggressore 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 i certificati revoca. Per maggiori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina gli audit log in Cloud Logging e avvisi aggiuntivi per altri eventi correlati a questa CSR per determinare se la richiesta di vendita era approved e se Era prevista un'attività di creazione CSR da parte dell'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. Rivedi 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 risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Defense Evasion: Modify VPC Service Control, come indicato in Analisi dei 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 risorsa: il nome del perimetro dei Controlli di servizio VPC che è stato modificato.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione 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 seguono le restrizioni di su questo perimetro. La protezione viene ridotta se rimuovi un progetto
       • restricted_services: i servizi la cui esecuzione è vietata dalle limitazioni di questo perimetro. La protezione viene 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 configurate per consentire l'accesso alle risorse all'interno del perimetro. Se aggiungi altri livelli di accesso, la protezione viene ridotta

Passaggio 2: controlla i log

1. Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
2. Trova i log delle attività di amministrazione relativi alle modifiche dei Controlli di servizio VPC utilizzando 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 segnalazione: 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 del criterio e del perimetro dei Controlli di servizio VPC.
• Valuta la possibilità di ripristinare le modifiche apportate al perimetro finché l'indagine completata.
• 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

Anteprima

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

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, vedi il messaggio di log per 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), contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identificare 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 carico di lavoro e che ne hanno consentito la creazione.

Discovery: Can get sensitive Kubernetes object check

Un utente potenzialmente malintenzionato ha tentato di determinare quali oggetti sensibili GKE su cui possono eseguire query utilizzando il comando kubectl auth can-i get. In particolare, 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 risultato Discovery: Can get sensitive Kubernetes object check come di cui alla sezione Analisi dei risultati.

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 viene eseguita l'azione si è verificato un errore.
   • In Link correlati:
     • URI Cloud Logging: link alle voci di Logging.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del 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 nell'attributo Campo Email entità nei dettagli del risultato.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Rilevamento
2. Confermare la sensibilità dell'oggetto sottoposto a query e determinare se sono presenti 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 service account (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 ricerca MITRE.

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Anteprima

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

Qualcuno ha creato un pod contenente comandi o argomenti comunemente associati a una shell inversa. Aggressori e utilizzare le shell inverse per espandere o mantenere l'accesso iniziale a un cluster per eseguire comandi arbitrari. Per ulteriori 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 segnali di attività dannosa dal pod o nell'audit log di 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), identificare la legittimità di ciò che ha provocato l'esecuzione di questa operazione da parte dell'account di servizio azione
5. Se il pod non è legittimo, rimuovilo, insieme a eventuali RBAC associati e account di servizio utilizzati dal carico di lavoro e che ne hanno consentito per la creazione di contenuti.

Execution: Suspicious Exec or Attach to a System Pod

Anteprima

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

Qualcuno ha utilizzato i comandi exec o attach per ottenere una shell o eseguire un comando su un container in esecuzione nello spazio dei nomi kube-system. Questi metodi sono utilizzate per scopi legittimi di debug. 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.

Consulta le linee guida per l'utilizzo del principio del privilegio minimo per i ruoli RBAC e i ruoli dei 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 gravità diversa:

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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 le elencati i valori 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 state esfiltrate sono stati archiviati.
   • 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: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
     • Chronicle: esegui il collegamento a Google SecOps.

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

   • detectionCategory:
     • subRuleName: exfil_to_external_table o vpc_perimeter_violation.
   • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • properties
     • dataExfiltrationAttempt
       • jobLink: il link al job BigQuery che ha 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 il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indaga sulle minacce e passa attraverso le entità correlate in un 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 si compila con i risultati di Event Threat Detection.

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

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

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

Utilizza le seguenti guide per condurre indagini in Google SecOps:

• Analisi di un utente
• Analisi di una risorsa

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nella alla ricerca di JSON.

3. Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencate in Email entità e controlla quali autorizzazioni sono 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: ricerca i metodi di attacco e di 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 in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono dello stesso tipo di risultati 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 risultati.

• 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 un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi agli elementi interessati Set di dati BigQuery (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. In base alla 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 l'audit 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 Premium di Security Command Center: questo risultato è disponibile solo se il livello Standard è abilitato nella dell'organizzazione principale.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli dei risultati

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 le elencati i valori 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 state esfiltrate sono stati archiviati.
   • 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: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

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

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
     • properties:
       • extractionAttempt:
       • jobLink: il link al job BigQuery che ha 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 nella trovare JSON (dal Passaggio 1).

3. Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencato in Email principale (dal Passaggio 1) e controllare quali autorizzazioni sono 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: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
2. Esamina i risultati correlati facendo clic sul link della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. 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 il MITRE ricerca.

Passaggio 5: implementa la risposta

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

• Contatta il proprietario del progetto con i dati 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 fermare un'ulteriore esfiltrazione, aggiungere criteri IAM restrittivi ai set di dati BigQuery interessati, identificati nel campo Origini di esfiltrazione della scheda Riepilogo della trovare i dettagli.
• 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. In base alla 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 Motore per suggerimenti.

Exfiltration: BigQuery Data to Google Drive

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

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, tra cui:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli su BigQuery tabella 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: 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 file JSON, tieni presente i seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
     • properties:
       • extractionAttempt:
       • jobLink: il link al job BigQuery che è stato esfiltrato 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 rilevamento (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: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono dello stesso tipo di risultati nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

Passaggio 5: implementa la risposta

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

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per il principale nel campo access.principalEmail fino al completamento dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi agli elementi interessati Set di dati BigQuery (exfiltration.sources).
• Per scansionare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i dati di Sensitive Data Protection a Security Command Center. In base alla 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 Motore per suggerimenti.

Exfiltration: Cloud SQL Data Exfiltration

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

• Dati dell'istanza live esportati in un bucket Cloud Storage all'esterno all'interno dell'organizzazione.
• I dati dell'istanza in tempo reale esportati in un bucket Cloud Storage di proprietà dell'organizzazione ed è 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 di Exfiltration: Cloud SQL Data Exfiltration, come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sull'API Cloud SQL i cui dati sono stati esfiltrati.
     • Destinatari dell'esfiltrazione: dettagli sul bucket Cloud Storage in cui sono stati esportati i dati.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa Cloud SQL i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il progetto Google Cloud che contiene i dati di Cloud SQL di origine.
   • Link correlati, tra cui:
     • 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. 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: 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 nella projectId nel file JSON del risultato (da Passaggio 1).

3. Nella pagina visualizzata, nella casella Filtro, inserisci l'indirizzo email elencato nella riga Indirizzo email principale della scheda Riepilogo dei dettagli del rilevamento (dal passaggio 1). Controlla cosa autorizzazioni assegnate all'account.

Passaggio 3: controlla i log

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

Passaggio 4: cerca metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati. descritta nel Passaggio 1). Correlate i risultati hanno lo stesso tipo di risultato sullo stesso Cloud SQL in esecuzione in un'istanza Compute Engine.
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 risultati.

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

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 come indicato in Revisione dei risultati.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account utilizzato per 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 risorsa: il nome della risorsa del backup che è stata 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 nella Campo projectId nel JSON del risultato (dal Passaggio 1).

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

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
2. Per esaminare i risultati correlati, fai clic sul link nella riga Risultati correlati. (dal passaggio 1). I risultati correlati hanno lo stesso tipo di risultato su per la 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 risultati.

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

Exfiltration: Cloud SQL Over-Privileged Grant

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri Exfiltration: Cloud SQL Over-Privileged Grant come indicato in Revisione dei 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 ai privilegiati.
     • Beneficiari database: i beneficiari dei privilegi eccessivamente ampi.
   • 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: collega a eventuali risultati correlati.

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

Passaggio 2: esamina i privilegi del database

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

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link 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 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 necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.

Passaggio 5: implementa la risposta

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

• Contatta il proprietario dell'istanza con concessioni con privilegi in eccesso.
• Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari database fino al termine dell'indagine.
• Per limitare l'accesso al database (da Nome visualizzato del database di Passaggio 1, revoca non necessario delle autorizzazioni dei beneficiari (da Beneficiari database 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. Il super user (un ruolo con un accesso molto ampio) in genere non dovrebbe utilizzato per scrivere nelle tabelle degli utenti. È necessario utilizzare un account utente con accesso più limitato per la normale attività quotidiana. Quando un superutente scrive in una tabella 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 normale, pratiche 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 come indicato in Revisione dei 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 Cloud SQL in esecuzione in un'istanza Compute Engine.
     • Nome completo del progetto: il progetto Google Cloud che contiene per 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: collega 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 su il 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 necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.

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 degli accessi e gestione dell'account

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

Initial Access: Anonymous GKE resource created from the internet

Anteprima

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

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

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

Questi utenti e gruppi sono effettivamente anonimi. Un accesso basato sui ruoli l'associazione di controllo (RBAC) nel tuo cluster ha concesso all'utente l'autorizzazione a creare a queste risorse nel cluster.

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

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

Initial Access: GKE resource modified anonymously from the internet

Anteprima

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

Rileva quando un 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 accesso basato sui ruoli l'associazione di controllo (RBAC) nel tuo cluster ha concesso all'utente l'autorizzazione di modifica a queste risorse nel cluster.

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

Per risolvere il problema, consulta Evita ruoli e gruppi predefiniti.

Initial Access: Dormant Service Account Action

Rileva gli eventi in cui un servizio gestito dall'utente inattivo account ha attivato un'azione. In questo contesto, un account di servizio viene considerata inattiva se è rimasta inattiva 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.

   Nella sezione Che cosa è stato rilevato:

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

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Utilizza l'account di servizio di Google, come Attività Analizzatore, 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
• Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Initial Access: Dormant Service Account Key Created

Rileva gli eventi in cui un servizio gestito dall'utente inattivo dell'account. 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.

   Nella sezione Che cosa è stato rilevato:

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

   In Risorsa interessata:

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

Passaggio 2: cerca metodi di attacco e risposta

1. Utilizza l'account di servizio di Google, come Attività Analizzatore, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• 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 e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare le 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 qualsiasi notifica dall'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 dell'account di servizio divulgata è quella che è stata pubblicata nella rete internet pubblica. Ad esempio, spesso le chiavi degli account di servizio vengono pubblicate nel repository pubblico GitHub.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli dei risultati

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 ha 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 sulla rete internet pubblica in cui è possibile trovare la chiave dell'account di servizio

   In Risorsa interessata:

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

Passaggio 2: controlla i log

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

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

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

   Sostituisci PRINCIPAL_EMAIL con il valore che hai annotato nella Campo Email entità nei dettagli del risultato. 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 e collaborare con i proprietari delle applicazioni 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 qualsiasi notifica dall'assistenza clienti Google Cloud.

Initial Access: Excessive Permission Denied Actions

Rileva gli eventi in cui un'entità attiva ripetutamente l'autorizzazione Autorizzazione negata in vari metodi e servizi.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   In Che cosa è stato rilevato:

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

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

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

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

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

   Sostituisci PRINCIPAL_EMAIL con il valore che hai annotato nella Campo Email entità nei dettagli del risultato.

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 il MITRE ricerca.

Passaggio 4: implementa la risposta

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

• Contatta il proprietario dell'account nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
• Elimina le risorse del progetto create da quell'account, ad esempio istanze Compute Engine, snapshot, service account e utenti IAM sconosciuti e così via.
• Contatta il proprietario del progetto con l'account ed eventualmente eliminarlo o disattivarlo 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 dei risultati

1. Apri un Brute Force: SSHrisultato 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: collega a eventuali risultati correlati.
     • Chronicle: esegui il collegamento a Google SecOps.

3. Fai clic sulla scheda JSON.

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

   • sourceProperties:
     • evidence:
       • sourceLogId: l'ID progetto e il timestamp per identificare la voce di log
       • projectId: il progetto 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: esamina 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 ai 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 completata con i risultati per il tipo di origine selezionato.

4. Nella tabella, fai clic su un Brute Force: SSH 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 indagini in Chronicle.

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

Utilizza le seguenti guide per condurre indagini in Google SecOps:

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

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla Dashboard.

   Vai alla Dashboard

2. Seleziona il progetto specificato projectId.

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

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

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

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'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 risultato: Account validi: account locali.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

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 quelle rilevate malware. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.
• Valuta la possibilità di disabilitare l'accesso SSH alla VM. Per informazioni sulla disattivazione delle chiavi SSH, consulta Limitare le chiavi SSH dalle VM. Questo passaggio potrebbe interrompere l'accesso autorizzato alla VM, quindi considera le esigenze della tua organizzazione prima di procedere.
• Usa l'autenticazione SSH solo con indirizzi autorizzati chiave.
• Blocca gli indirizzi IP dannosi aggiornando il firewall oppure 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 significativo. 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 l'aggiunta di un membro esterno a un gruppo Google con privilegi (un gruppo concessi autorizzazioni o ruoli sensibili). Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche.
   • 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: collega a eventuali risultati correlati.

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

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

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

Passaggio 2: 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 Rimuovi membro o 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 ulteriori informazioni, vedi Assegnare ruoli ai membri di un gruppo.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di 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)

Anteprima

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

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 metodo utilizzato dagli hacker 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 maggiori 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 altri 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)

Anteprima

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

Qualcuno ha approvato manualmente una richiesta di firma del certificato (CSR). La creazione di un per l'autenticazione del cluster è un metodo comune per consentire a utenti malintenzionati di creano un accesso permanente a un cluster compromesso. Le autorizzazioni associate certificati variano a seconda dell'argomento trattato, ma possono essere privilegiati. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina gli audit log in Cloud Logging e altri avvisi per altri CSR per determinare se le azioni relative a CSR sono attività previste l'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 con privilegi (un gruppo a cui sono stati concessi ruoli sensibili o autorizzazioni) è diventano accessibili al pubblico. 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 file JSON, tieni presente i seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • sensitiveRoles: i ruoli sensibili associati a questo gruppo
   • whoCanJoin: l'impostazione relativa alla partecipazione del gruppo

Passaggio 2: esamina le impostazioni di accesso ai gruppi

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

   Vai alla Console di amministrazione

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

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

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

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di 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 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 MITRE.

Credential Access: Secrets Accessed in Kubernetes Namespace

Anteprima

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

Rileva quando un default account di servizio Kubernetes di un pod è stato utilizzato per accedere agli oggetti Secret nel cluster. Il cluster default di Kubernetes l'account di servizio non deve avere accesso agli oggetti Secret a meno che non ha concesso l'accesso con un oggetto Role o un oggetto 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 dei risultati

1. Apri un Credential Access: Sensitive Role Granted To Hybrid Group come indicato in Revisione dei risultati. Il riquadro dei dettagli per 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 file JSON, tieni presente i seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • bindingDeltas: i ruoli sensibili appena concessi a questo gruppo.

Passaggio 2: esamina le autorizzazioni del gruppo

1. Vai alla pagina IAM nella console Google Cloud.

   Vai a IAM

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

3. Esamina i ruoli sensibili concessi al gruppo.

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

   Per gestire i ruoli nella tua organizzazione o nel tuo progetto, devi disporre di autorizzazioni specifiche. Per Per saperne di più, consulta la sezione Autorizzazioni obbligatorie.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di 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: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi.
2. Per determinare se sono necessarie ulteriori azioni correttive, combina il tuo i risultati dell'indagine con la ricerca MITRE.

Malware: Cryptomining Bad IP

Il malware viene rilevato esaminando i log di flusso VPC e i log 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 di Malware: Cryptomining Bad IP, come indicato in Analisi dei risultati. Il riquadro dei dettagli per 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 disponibili.
     • Protocollo: IANA di indirizzi IP associati alla connessione.
   • Risorsa interessata
   • Link correlati, inclusi i seguenti campi:
     • URI di Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

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

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

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

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

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato in properties_project_id.

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

4. Fai clic sull'istanza VM corrispondente a properties_sourceInstance. Indaga l'istanza potenzialmente compromessa per malware.

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

Passaggio 3: controlla i log

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

   Vai a Esplora log

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

3. Nella pagina 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 metodi di attacco e risposta

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

Passaggio 5: implementa la risposta

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

• Contatta il proprietario del progetto che contiene malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi quelle rilevate malware. 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 significativo. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.

Initial Access: Log4j Compromise Attempt

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

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato di Initial Access: Log4j Compromise Attempt, come indicato in Revisione dei dettagli dei risultati. I 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 su il 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: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Sfruttare un'applicazione pubblica.
2. Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. 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 il MITRE ricerca.

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 all'ultima versione di Log4j2.
• Segui i suggerimenti di Google Cloud per indagare e rispondere su "Apache Log4j 2" vulnerabilità.
• Implementare le tecniche di mitigazione consigliate Vulnerabilità di sicurezza di Apache Log4j.
• Se utilizzi Google Cloud Armor, esegui il deployment di cve-canary rule in una nuova o un criterio di sicurezza di Google Cloud Armor 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 in parametri HTTP, URL e campi di testo con callback ai domini controllati dagli scanner. Questo risultato viene generato quando vengono trovate query DNS per i domini non offuscati. Queste query si verificano solo se una ricerca JNDI ha avuto esito positivo, indicando è presente 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 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, in particolare il seguente campo:
     • Nome completo 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 file JSON, tieni presente i seguenti campi.

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

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI Cloud Logging 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: ricerca i metodi di attacco e di 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 il MITRE ricerca.

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 suggerimenti di Google Cloud per indagare e rispondere su "Apache Log4j 2" vulnerabilità.
• 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, vedi Regola WAF di Google Cloud Armor per contribuire a mitigare la vulnerabilità di Apache Log4j.

Leaked credentials

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

Questo risultato viene generato quando si utilizzano le credenziali dell'account di servizio Google Cloud sono trapelati accidentalmente online o compromessi. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un rilevamento account_has_leaked_credentials, come indicato in Rivedere i dettagli del rilevamento. Riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

• Che cosa è stato rilevato
• Risorsa interessata

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

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

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

Passaggio 2: 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 del compromesso l'account di servizio e controlla le chiavi e la chiave date di creazione.

Passaggio 3: controlla i log

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

   Vai a Esplora log

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

3. Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate. alle risorse IAM utilizzando i seguenti filtri:

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

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di 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 credenziali divulgate.
• 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 team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. 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 divulgate. 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 domini e indirizzi IP 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.

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato di malware pertinente. I passaggi che seguono utilizzano il Malware: Bad IP risultato, come indicato in Esamina i risultati. Il riquadro dei dettagli per 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 Bad domain risultati, il dominio che ha attivato il risultato.
     • IP indicatore: per i risultati Bad IP, l'indirizzo IP che ha attivato il risultato.
     • IP di origine: per i risultati Bad IP, un indirizzo IP di controllo e un comando di malware noto.
     • Porta di origine: per Bad IP risultati, la porta di origine della connessione.
     • IP di destinazione: per Bad IP risultati, l'indirizzo IP di destinazione del malware.
     • Porta di destinazione: per i risultati Bad IP, la porta di destinazione della connessione.
     • Protocollo: per Bad IP risultati, il valore Protocollo IANA associato alla connessione.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa interessata di Compute Engine.
     • Nome completo del progetto: il nome completo della risorsa del progetto che che contiene il risultato.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
     • Chronicle: esegui il collegamento a Google SecOps.
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

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

      • evidence:
      • sourceLogId:
        • projectID: l'ID del progetto in cui è stato rilevato il problema.
      • properties:
      • InstanceDetails: indirizzo della risorsa per Compute Engine in esecuzione in un'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 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 ai 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 completata con i risultati per il tipo di origine selezionato.

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

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

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

Utilizza le seguenti guide per condurre 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 con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.

2. Nella pagina visualizzata, trova i log di flusso VPC correlati all'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 indicato nella riga IP di origine della scheda Riepilogo dei dettagli del rilevamento.

Passaggio 5: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Dynamic Risoluzione e Comando e controllo.
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 potenzialmente dannosi, URL, domini e indirizzi IP.
4. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

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 che contiene malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
• Per tenere traccia delle attività e delle vulnerabilità che hanno consentito l’inserimento di malware, e controllare gli audit log e i syslog associati all'istanza compromessa.
• Se necessario, interrompi l'account compromesso un'istanza e sostituirla con nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando il firewall oppure utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.
• Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza Shielded VM e Trusted IAM delle immagini .

Malware: Outgoing DoS

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un rilevamento Malware: Outgoing DoS come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato
     • IP di origine: l'indirizzo IP di origine dell'attività DoS.
     • Porta di origine: la porta di origine della connessione.
     • IP di destinazione: l'indirizzo IP target dell'attività DoS.
     • Porta di destinazione: la porta di destinazione della connessione.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione 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.
   • sourceInstanceDetails: l'istanza VM di Compute Engine interessata

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai alla Dashboard

2. Seleziona il progetto specificato sourceInstanceDetails.

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

4. Fai clic sull'istanza VM corrispondente al nome e alla zona dell'istanza in sourceInstanceDetails. Rivedi i dettagli dell'istanza, inclusa la rete e accedere alle impostazioni.

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.

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

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

     Sostituisci quanto segue:

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

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Negoziazione di Denial of Service.
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 lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca 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 che sta riscontrando traffico DoS in uscita.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
• 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'account compromesso un'istanza e sostituirla con nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando il firewall oppure utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.
• Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza Shielded VM e Trusted IAM delle immagini .

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 risultato IAM Anomalous Grant è unico in quanto include regole secondarie che forniscono informazioni più specifiche su ciascuna istanza di questo risultato. La classificazione della gravità di questo risultato dipende dalla regola secondaria. Ogni regola secondaria potrebbe richiedere una risposta diversa.

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

• external_service_account_added_to_policy:
  • HIGH, se è stato concesso un ruolo 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.
• 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, vedi Ruoli a sensibilità media.
• custom_role_given_sensitive_permissions: MEDIUM
• service_account_granted_sensitive_role_to_member: HIGH
• policy_modified_by_default_compute_service_account: HIGH

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • 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 di VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: 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 sottoregola determina la classificazione della gravità di questo risultato.
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il risultato.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: l'azione intrapresa dall'utente.
       • Role: il ruolo assegnato all'utente.
       • member: l'indirizzo email dell'utente che ha ricevuto il ruolo.

Passaggio 2: esamina in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di 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.

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

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

   Vai ai risultati

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

3. Nella sezione Nome visualizzato 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. Il riquadro dei dettagli per si apre il risultato.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui indagini in Chronicle.

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
• Analisi di una risorsa

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 visualizzata, cerca i ruoli IAM nuovi o aggiornati. di risorse mediante i seguenti filtri:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"

Passaggio 4: cerca 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 in Risultati correlati. riga nella scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e la 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 a tutte le chiavi di accesso degli account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso.
• Elimina le risorse di progetto create da account non autorizzati, ad esempio quelli sconosciuti di Compute Engine, istanze, snapshot, account di servizio per gli utenti IAM.
• 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 a un'entità viene concesso un ruolo di rappresentazione che consente che l'entità si spaccia per un servizio gestito dall'utente inattivo Google Cloud. 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 dei risultati

1. Apri Persistence: Impersonation Role Granted for Dormant Service Account come indicato in Revisione dei risultati.

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

   Nella sezione Che cosa è stato rilevato:

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

   In Risorsa interessata:

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

Passaggio 2: 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 risultati.

• 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza 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 le 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 IAM motore per suggerimenti.

Persistence: Unmanaged Account Granted Sensitive Role

Anteprima

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

Rileva gli eventi in cui un ruolo sensibile è stato 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. Di conseguenza, la concessione di ruoli sensibili agli account non gestiti crea una potenziale rischi 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.

   Nella sezione 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
   • Concessione di accesso con accesso con problemi.Role concesso: il ruolo sensibile concesso.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario del campo Email entità. 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 risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Rimuovi il ruolo sensibile appena concesso dall'account non gestito.
• Valuta la possibilità di convertire l'account non gestito in un account gestito utilizzando lo strumento di trasferimento. e spostare questo account 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 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: ricerca i metodi di attacco e di risposta

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

Persistence: New Geography

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

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

Passaggio 1: esamina i dettagli dei risultati

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 risultato, fai clic sulla scheda JSON.

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

   • affectedResources:
     • gcpResourceName: la risorsa interessata
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il rilevamento.
   • properties:
     • anomalousLocation:
     • anomalousLocation: la posizione attuale stimata dell'utente.
     • callerIp: indirizzo IP esterno.
     • notSeenInLast: il periodo di tempo utilizzato per stabilire una base di riferimento per un 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, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencati in Email principale e controlla i ruoli concessi.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il progetto.
3. Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate. alle risorse IAM 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 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 il MITRE ricerca.

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 Limitazione delle località delle risorse.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Persistence: New User Agent

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

Un account di servizio IAM 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 principale: l'account di servizio potenzialmente compromesso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo del progetto: il progetto che contiene l'account di servizio potenzialmente compromesso.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente i seguenti campi.
   • projectId: il progetto contenente l'account 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 con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il progetto.
3. Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate. alle risorse IAM utilizzando i seguenti filtri:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca i metodi di attacco e di risposta

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

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 anomalousSoftwareClassification, callerUserAgent e behaviorPeriod per verificare se l'accesso è anomalo e se dell'account è stato compromesso.
• Elimina le risorse di progetto create da account non autorizzati, ad esempio quelli sconosciuti di Compute Engine, istanze, snapshot, account di servizio per gli utenti IAM.
• 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 dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
     • Associazioni Kubernetes: i nodi Kubernetes sensibili associazione o ClusterRoleBinding modificata.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui viene eseguita l'azione si è verificato un errore.
   • 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 dell'associazione. nella riga Associazioni Kubernetes. Vengono visualizzati i dettagli dell'associazione.

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

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI 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 nel campo perché 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 nell'attributo Campo Email entità nei dettagli del risultato.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di segnalazione: 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), identificare l'origine della modifica per determinarne legittimità.

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

Privilege Escalation: Create Kubernetes CSR for master cert

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

Passaggio 1: esamina i dettagli dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui viene eseguita l'azione si è verificato un errore.
   • 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 risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI 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 nell'attributo Campo Email entità nei dettagli del risultato.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Aumento 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 legittimità.

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

Privilege Escalation: Creation of sensitive Kubernetes bindings

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri 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 Kubernetes o ClusterRoleBinding sensibile creata.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui viene eseguita l'azione si è verificato un errore.
   • 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 Esplora log facendo clic sul link nel campo URI di Cloud Logging.

2. Verifica altre azioni intraprese dall'entità utilizzando quanto segue 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 nell'attributo Campo Email entità nei dettagli del risultato.

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di segnalazione: 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 e deve avere il ruolo a cui è associato.
4. Determina se esistono altri segnali di attività dannosa da parte del 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 service account (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 ricerca MITRE.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Anteprima

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

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. Esamina il per garantirne la necessità. Se l'associazione non è necessaria, rimuovi li annotino. Per ulteriori dettagli, consulta il messaggio di log relativo a questo rilevamento.

1. Esamina le eventuali associazioni create che hanno concesso autorizzazioni agli system:anonymous utente, system:unauthenticated group o Gruppo system:authenticated.
2. Determina se esistono altri segnali di attività dannosa da parte del nell'audit log di 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 viene eseguita l'azione si è verificato un errore.
   • 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 risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta di firma del certificato specifica.

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Aumento 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 ricerca MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

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

Il campo privileged di un container con privilegi è impostato su true. Un container con funzionalità di escalation dei privilegi ha Campo allowPrivilegeEscalation 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 viene eseguita l'azione si è verificato un errore.
   • 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: collega a eventuali risultati correlati.

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

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

Passaggio 2: controlla i log

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

2. Verifica altre azioni intraprese dall'entità utilizzando quanto segue 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 nell'attributo Campo Email entità nei dettagli del risultato.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di segnalazione: Escalation dei privilegi.
2. Conferma che il container creato richieda l'accesso alle risorse dell'host e e le 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 legittimità.

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

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Rileva gli eventi in cui un ruolo IAM sensibile viene concesso a un servizio gestito dall'utente inattivo Google Cloud. 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 dei risultati

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

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

   Nella sezione Che cosa è stato rilevato:

   • 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 è stato concesso il ruolo IAM sensibile all'account di servizio inattivo.

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Utilizza l'account di servizio di Google, come Attività Analizzatore, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del 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 risultati.

• 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse 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 gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM motore per suggerimenti.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

La rappresentazione anomala dell'account di servizio viene rilevata esaminando l'amministratore Audit log delle attività per verificare se si è verificata un'anomalia in un account di servizio di impersonificazione.

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 per 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à: l'account di servizio finale nella richiesta di attacco di identità utilizzato per accedere a Google Cloud.
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di impersonificazione.
     • 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: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare le 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 gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.

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 dell'entità: l'account di servizio finale nella richiesta di attacco di identità utilizzato per accedere a Google Cloud.
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di impersonificazione.
     • 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 è il chiamante la richiesta di impersonificazione.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare le 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 gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation viene rilevato esaminando i dati Accedi agli audit log per vedere se si sono verificate anomalie in un account di servizio di impersonificazione.

Per rispondere a questo risultato, procedi nel seguente modo:

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:
     • Email entità: l'account di servizio finale nel furto d'identità utilizzata 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: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare le 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 gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Rilevamento di Anomalous Service Account Impersonator tramite l'esame dell'amministratore Audit log delle attività per verificare se si è verificata un'anomalia in un account di servizio di impersonificazione.

Per rispondere a questo risultato, procedi nel seguente modo:

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

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare le 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 qualsiasi notifica dell'assistenza Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.

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 risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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

   In Che cosa è stato rilevato:

   • 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 è il chiamante la richiesta di impersonificazione

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 le 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 qualsiasi notifica 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: ClusterRole with Privileged Verbs

Anteprima

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

Qualcuno ha creato un oggetto ClusterRole RBAC contenente l'elemento bind, escalate o impersonate verbi. Un soggetto associato a un ruolo con questi verbi può rappresentare altri utenti con privilegi superiori, associarsi a oggetti Role o ClusterRole aggiuntivi che contengono autorizzazioni aggiuntive o modificare le proprie autorizzazioni ClusterRole. Ciò potrebbe portare questi soggetti a ottenere i privilegicluster-admin. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina ClusterRole e ClusterRoleBindings associato per verificare se i soggetti hanno effettivamente bisogno di queste autorizzazioni.
2. Se possibile, evita di creare ruoli che coinvolgano bind, escalate o Verbi 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à. Utilizzo il principio del privilegio minimo riduce il potenziale di privilegio una escalation se il cluster è compromesso e riduce la probabilità un accesso eccessivo può causare un incidente di sicurezza.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Anteprima

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

Qualcuno ha creato un ClusterRoleBinding RBAC che fa riferimento al valore 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 riassegnazione 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. Rivedi eventuali modifiche 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

Anteprima

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

Qualcuno ha eseguito il deployment di un pod con una convenzione di denominazione simile a quella degli strumenti comuni utilizzati per le uscite dal contenitore o per eseguire altri attacchi sul cluster. Per ulteriori dettagli, vedi il messaggio di log per 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), contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identificare l'origine dell'azione per determinarne la legittimità.
5. Se il pod non è legittimo, rimuovilo, insieme a eventuali RBAC associati e account di servizio utilizzati dal carico di lavoro e che ne hanno consentito per la creazione di contenuti.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

Anteprima

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

Qualcuno ha creato un carico di lavoro contenente un montaggio del volume hostPath in una di un percorso sensibile nel 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. In caso affermativo, assicurati che il percorso sia una directory specifica. Ad esempio, /etc/myapp/myfiles anziché / o /etc.
2. Determina se esistono altri segnali di attività dannose correlati a questo per il carico di lavoro negli audit log di Cloud Logging.

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

Privilege Escalation: Workload with shareProcessNamespace enabled

Anteprima

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

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, come la gestione dei log di container collaterali o di debug. Per ulteriori dettagli, consulta il messaggio del log per questo avviso.

1. Conferma che il carico di lavoro richieda effettivamente l'accesso a un processo condiviso per tutti i container nel carico di lavoro.
2. Controlla se esistono altri segnali di attività dannosa da parte dell’entità nel gli audit log di Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contattare il proprietario dell'account per verificare se è stata un'azione.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identificare la legittimità di ciò che ha provocato l'esecuzione di questa operazione da parte dell'account di servizio un'azione.

Service account self-investigation

Le credenziali di un account di servizio vengono utilizzate per esaminare i ruoli autorizzazioni associate 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 dei risultati

1. Apri un risultato di Discovery: Service Account Self-Investigation, come indicato in Esaminare i dettagli dei risultati in precedenza . 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 principale: l'account di servizio potenzialmente compromesso.
     • IP chiamante: l'indirizzo IP interno o esterno
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa:
     • Nome completo del progetto: il progetto che contiene la risorsa potenzialmente divulgata le credenziali dell'account.
   • 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: collega 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 del compromesso l'account di servizio e controlla le chiavi e la chiave date di creazione.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il progetto.
3. Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate. alle risorse IAM utilizzando i seguenti filtri:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di 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 a tutte le chiavi di accesso degli account di servizio per il progetto compromesso. Dopo l'eliminazione, Le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso.
• Elimina le risorse di progetto create dall'account compromesso, ad esempio quelle sconosciute di Compute Engine, istanze, snapshot, account di servizio per gli utenti IAM.

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection esamina gli audit log per rilevare l'eliminazione di host che sono delle applicazioni protette dal servizio Backup & DR. Una volta eliminato un host, non è possibile eseguire il backup delle applicazioni associate.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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 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 & 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 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 DR.
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 & DR utilizzato per applicare criteri di backup a un'applicazione.

Passaggio 1: esamina i dettagli dei risultati

1. Apri il Inhibit System Recovery: Google Cloud Backup and DR remove plan risultato, come descritto in Esaminare i risultati. I dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome applicazione: il nome di un database o di una VM connessa a Backup & RE
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati 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 del 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 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 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. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.

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

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 per applicazioni containerizzate.

Passaggio 1: esamina i dettagli dei risultati

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 del backup
     • Oggetto entità: un utente che ha eseguito un'azione.
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il modello
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.

1. Nel progetto in cui è stata intrapresa l'azione, vai alla console di gestione.
2. Nella scheda Gestione app, trova le applicazioni interessate che non sono più e di rivedere i criteri di backup per ognuna.
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 la modalità di esecuzione di un backup e la sua posizione di archiviazione.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri Inhibit System Recovery: Google Cloud Backup and DR delete policy di ricerca, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza, la pianificazione e il tempo di conservazione 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 ed esamina le impostazioni dei criteri applicate all'applicazione.

Inhibit System Recovery: Google Cloud Backup and DR delete profile

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

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete profile, come descritto in dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • 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 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 risultato. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Piani di backup, seleziona Profili per visualizzare un elenco di tutti i profili. 3. Esamina i profili per verificare che tutti i profili obbligatori siano presenti. 4. Se il profilo eliminato è stato rimosso per errore, seleziona Crea profilo per definire le destinazioni di archiviazione per le appliance di backup e DR.

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 & 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 dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome pool di archiviazione: il nome dei bucket di archiviazione in cui 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
   • Correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: 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 risultato. 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 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 del backup
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • 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 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 Monitoraggio e seleziona Job per esaminare lo stato del job di eliminazione del backup. 3. Se un job di eliminazione non è autorizzato, vai alle autorizzazioni IAM per esaminare gli utenti con accesso ai dati di backup.

Data Destruction: Google Cloud Backup and DR expire all images

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

Passaggio 1: esamina i dettagli 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 del backup
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
     • 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 risultato. 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 dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome dell'appliance: il nome di un database o di una VM collegata a Backup e DR
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'appliance
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione 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 risultato. 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, trova le applicazioni interessate che non sono più protette ed esamina i criteri di backup per ciascuna. 3. Per creare una nuova appliance e applicare nuovamente le protezioni alle app non protette, vai a Backup 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 nuova 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 dei risultati

1. Apri Impact: Google Cloud Backup and DR reduced backup expiration di ricerca, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Descrizione: informazioni sul rilevamento
     • Oggetto entità: un account utente o di servizio che ha eseguito 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 MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestione app, trova l'applicazione interessata per la quale è stato eseguito il backup. la scadenza è stata ridotta e verificare che la scadenza fosse prevista principale.
3. Per avviare un nuovo backup dell'applicazione, seleziona Gestisci le configurazioni di backup per creare un backup on demand o per pianificare un nuovo backup.

Impact: Google Cloud Backup and DR reduced backup frequency

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il Impact: Google Cloud Backup and DR reduced backup frequency risultato, come descritto in Esaminare i risultati. La 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 MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestione app, trova l'applicazione interessata per la quale è stato eseguito il backup. frequenza è stata ridotta e verificare che la modifica fosse intenzionale principale.
3. Per avviare un nuovo backup dell'applicazione, seleziona Gestisci le configurazioni di backup per creare un backup on demand o per pianificare un nuovo backup.

Impact: Suspicious Kubernetes Container Names - Coin Mining

Anteprima

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

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), contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identificare 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 carico di lavoro 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 al tuo Compute Engine.

Passaggio 1: esamina i dettagli del rilevamento

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

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

   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 ha eseguito l'accesso dall'account di servizio.
   • Nome metodo: il metodo chiamato

Passaggio 2: ricerca i metodi di attacco e di 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, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. 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 risultato, esamina le informazioni nelle sezioni seguenti:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato database: il nome del database nella Istanza AlloyDB per PostgreSQL interessata.
     • Nome utente database: l'utente PostgreSQL che ha concesso i privilegi in eccesso.
     • Query sul database: la query PostgreSQL eseguita che ha concesso ai privilegiati.
     • Beneficiari database: i beneficiari dei privilegi eccessivamente ampi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa dell'istanza AlloyDB per PostgreSQL interessata.
     • Nome completo padre: il nome della risorsa di AlloyDB per PostgreSQL in esecuzione in un'istanza Compute Engine.
     • 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: rivedi i privilegi del database

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

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging (da Passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL.
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 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 necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.

Passaggio 5: implementa la risposta

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

• Contatta il proprietario dell'istanza con concessioni con privilegi in eccesso.
• Valuta la possibilità di revocarlo tutte le autorizzazioni per i beneficiari elencati in Beneficiari database fino al termine dell'indagine.
• Per limitare l'accesso al database (da Nome visualizzato del database di Passaggio 1, revoca non necessario delle autorizzazioni dei beneficiari (da Beneficiari database 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. Un account utente con accesso più limitato. deve essere utilizzato per la normale attività quotidiana. Quando un super user scrive a un utente tabella, che potrebbe indicare che un aggressore ha aumentato i privilegi o ha 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 dei risultati

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 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 AlloyDB per PostgreSQL interessata.
     • Nome completo padre: il nome della risorsa di AlloyDB per PostgreSQL in esecuzione in un'istanza Compute Engine.
     • 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 file JSON completo per il risultato, fai clic sulla scheda JSON.

Passaggio 2: controlla i log

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

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: esfiltrazione da servizi web.
2. Per determinare se sono necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.

Passaggio 4: implementa la risposta

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

• Esamina gli utenti autorizzati a connettersi al database.
• Valuta la possibilità di cambiare la password del superutente.
• Potresti creare un nuovo utente con accesso limitato per i diversi tipi di query usati sull'istanza.
  • Concedere al nuovo utente solo le autorizzazioni necessarie per eseguire le query.
  • Aggiorna le credenziali per i client che si connettono all'istanza AlloyDB per PostgreSQL

Rilevamenti dei metadati amministrativi di Compute Engine

Persistence: GCE Admin Added SSH Key

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

Persistence: GCE Admin Added Startup Script

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

Rilevamento dei log di Google Workspace

Se condividi i log di Google Workspace con Cloud Logging, Event Threat Detection genera risultati per diversi account Google Workspace in modo proattivo. Poiché i log di Google Workspace sono a livello di organizzazione, Event Threat Detection può analizzarle 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.

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

Initial Access: Suspicious Login Blocked

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

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

Initial Access: Account Disabled Hijacked

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

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

Impair Defenses: Two Step Verification Disabled

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

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

Initial Access: Government Based Attack

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

Descrizione	Azioni
Gli aggressori sostenuti da un governo potrebbero aver tentato di compromettere un su un computer o un account membro.	Questo account potrebbe essere preso di mira da utenti malintenzionati. Assicurati che dell'account utente segue le linee guida di sicurezza della tua organizzazione per password e autenticazione a più fattori.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRO: https://attack.mitre.org/techniques/T1078/ Dettagli dell'evento Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

Persistence: SSO Enablement Toggle

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

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

Persistence: SSO Settings Changed

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

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

Impair Defenses: Strong Authentication Disabled

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

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

Rispondere alle minacce relative a Google Workspace

I risultati per Google Workspace sono disponibili solo per le attivazioni di Security Command Center a livello di organizzazione. Non è possibile eseguire la scansione dei log di Google Workspace per rilevare 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 sicurezza di Google Workspace

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

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

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

Rilevamenti delle minacce di Cloud IDS

Cloud IDS: THREAT_ID

Anteprima

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

I risultati di Cloud IDS sono generati da Cloud IDS, un servizio di sicurezza che monitora il traffico da e verso Risorse Google Cloud per le 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: quando 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 risorsa: il progetto contenente la rete con la minaccia
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link a Cloud IDS Logging voci : queste voci contengono le informazioni necessarie per la ricerca Palo Alto Networks Archivio delle minacce
   • Detection Service
     • Categoria risultati Il nome della minaccia Cloud IDS

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

Passaggio 2: ricerca i metodi di attacco e di risposta

Dopo aver esaminato i dettagli 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 saperne 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 che i container siano immutabili è una best practice importante. Questo è un risultato di bassa gravità, perché la tua organizzazione potrebbe non seguire best practice. Sono presenti Execution: Added Malicious Binary Executed risultati quando l'hash del binario è un indicatore noto di compromissione (IoC). Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un Added Binary Executed rilevamento 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:
     • File binario del programma: il percorso assoluto del programma binario aggiunto.
     • Argomenti: gli argomenti forniti quando viene chiamato il file binario aggiunto.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e nome del cluster.

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

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

4. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. Risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'inosservanza 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo 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 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 archiviare il file binario aggiunto.

6. Connettiti all'ambiente del contenitore eseguendo:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, API nativa.
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.

• Se il file binario doveva essere incluso nel container, ricrea l'immagine container includendo il file binario. 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 contenuto.

Added Library Loaded

È stata caricata una libreria che non faceva parte dell'immagine container originale. I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Garantire l'immutabilità dei contenitori è una best practice importante. Questo è un risultato 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 dei risultati

1. Apri un Added Library Loaded rilevamento 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:
     • File binario del programma: il percorso completo del file binario del processo che ha caricato libreria.
     • Librerie: dettagli sulla libreria aggiunta.
     • Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster.

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

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

4. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. Risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'inosservanza 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 ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

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

5. Recupera la libreria aggiunta eseguendo:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso file locale per archiviare l'elemento aggiunto libreria.

6. Connettiti all'ambiente del contenitore eseguendo:

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

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

Passaggio 6: 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. 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 risultati.

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

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 Execution: Added Malicious Binary Executed rilevamento 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:
     • File binario del programma: il percorso assoluto del programma binario aggiunto.
     • Argomenti: gli argomenti forniti durante la chiamata al programma 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 risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

6. Connettiti all'ambiente dei container:

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

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

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, API nativa.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
3. 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.

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 container compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

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 ricerca, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso completo del file binario del processo che ha caricato libreria.
     • Librerie: dettagli sulla libreria aggiunta.
     • Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
     • 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 nel 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 ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

     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 dei container:

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

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

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Trasferimento di strumenti in entrata, Moduli condivisi.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
3. Controlla il valore hash SHA-256 della libreria contrassegnata come dannosa su VirusTotal di facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Passaggio 7: implementa la risposta

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

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

Execution: Built in Malicious Binary Executed

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

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

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un Execution: Built in Malicious Binary Executed rilevamento come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli per 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 durante la chiamata al 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo 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 integrato.

6. Connettiti all'ambiente dei container:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

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

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 container compromesso.
• Interrompi o elimina compromesso e sostituirlo con un nuovo container.

Execution: Malicious Python executed

Anteprima

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

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 degli script per gli strumenti di trasferimento può imitare la tecnica del trasferimento degli strumenti in entrata e causare rilevamenti indesiderati.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato di Execution: Malicious Python executed come indicato in Analisi dei risultati. Il riquadro dei dettagli per 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 su disco. questo viene visualizzato solo per gli script scritti su disco, non per il valore letterale dell'esecuzione dello script, ad esempio python3 -c.
     • Argomenti: gli argomenti forniti durante la chiamata dello script.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e cluster nome

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

4. Nel JSON, prendi nota dei seguenti campi.

   • finding:
     • processes:
     • script:
       • contents: contenuti dello script eseguito, che potrebbero essere troncati per motivi delle prestazioni; può essere utile nella tua indagine
       • sha256: l'hash SHA-256 di script.contents
   • resource:
     • project_display_name: il nome del progetto che contiene per l'asset.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del container interessato.
     • Container_Image_Uri: il nome dell'immagine container che viene eseguita.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. Ad esempio, se lo script rilascia un file binario, controlla i risultati relativi a quel file.

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 risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

Passaggio 5: esamina il 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 quindi su Esegui in. in Cloud Shell.

   Cloud Shell avvia e aggiunge i comandi per il cluster nella o nel terminale.

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: ricerca i metodi di attacco e di 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. 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.

• Se Python ha apportato modifiche previste al container, ricrea l'immagine container 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 container compromesso.
• Interrompi o elimina compromesso e sostituirlo con un nuovo container.

Execution: Modified Malicious Binary Executed

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

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

Normalmente gli aggressori installano strumenti di exploit e malware dopo la compromissione iniziale. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del programma binario modificato.
     • Argomenti: gli argomenti forniti durante la chiamata al programma 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 risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell

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

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

6. Connettiti all'ambiente dei container:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

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

Passaggio 7: implementa la risposta

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

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

Execution: Modified Malicious Library Loaded

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

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

I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere ricerca, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un Execution: Modified Malicious Library Loaded rilevamento 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:
     • Programma binario: il percorso completo del programma binario che ha caricato la biblioteca.
     • Librerie: i dettagli della libreria modificata.
     • Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
     • 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 nel 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 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 ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare il file dannoso modificato libreria.

6. Connettiti all'ambiente dei container:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, Moduli condivisi.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.
3. Controlla il valore hash SHA-256 della libreria segnalata come dannosa 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.

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

Malicious Script Executed

Un modello di machine learning ha identificato il codice Bash eseguito come dannoso. Gli attaccanti possono utilizzare Bash per trasferire strumenti ed eseguire comandi senza binari. Garantire l'immutabilità dei contenitori è una best practice importante. L'utilizzo degli script per gli strumenti di trasferimento può imitare la tecnica del trasferimento degli strumenti in entrata e causare rilevamenti indesiderati.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un rilevamento Malicious Script Executed come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli per 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 bash -c.
     • Argomenti: gli argomenti forniti durante la chiamata dello script.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster

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

4. Nel JSON, prendi nota dei seguenti campi.

   • finding:
     • processes:
     • script:
       • contents: contenuti dello script eseguito, che potrebbero essere troncati per motivi delle prestazioni; può essere utile nella tua indagine
       • sha256: l'hash SHA-256 di script.contents
   • resource:
     • project_display_name: il nome del progetto che contiene per l'asset.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del container interessato.
     • Container_Image_Uri: il nome dell'immagine container che viene eseguita.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. Ad esempio, se lo script rilascia un file binario, controlla i risultati relativi a quel file.

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 risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.

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

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

Passaggio 3: rivedi il pod

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

   Vai ai carichi di lavoro Kubernetes

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

Passaggio 5: esamina il 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 quindi su Esegui in. 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 dei container eseguendo questo 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: Command and Scripting Interpreter, Ingress Tool Transfer.
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.

• Se lo script stava apportando modifiche previste al container, ricrea l'immagine container in modo che non siano necessarie modifiche. In questo modo, il container può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina compromesso e sostituirlo con un nuovo container.

Malicious URL Observed

Anteprima

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

Container Threat Detection ha rilevato un URL dannoso nell'elenco degli argomenti di un processo eseguibile. Gli aggressori possono caricare malware o librerie dannose tramite URL dannosi.

Per rispondere a questo risultato, segui questi passaggi.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato di Malicious URL Observed come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • URI: l'URI dannoso osservato.
     • File binario aggiunto: il percorso completo del file binario del processo che ha ricevuto gli argomenti contenenti l'URL dannoso.
     • Argomenti: gli argomenti forniti quando viene invocato il file binario del processo.
     • Variabili di ambiente: le variabili di ambiente presenti nella quando il programma binario del processo è stato richiamato.
     • Container: il nome del container.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il nome della risorsa interessata.
     • Nome completo risorsa: il nome completo della risorsa nel cluster. Il nome completo della risorsa include quanto segue: informazioni:
       • Il progetto che contiene il cluster: projects/PROJECT_ID
       • La località in cui si trova il cluster: zone/ZONE o locations/LOCATION
       • Il nome del cluster: projects/CLUSTER_NAME

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

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che viene visualizzato Nome completo risorsa (resource.name), se necessario. Il nome del progetto viene visualizzato dopo /projects/ nel nome completo della risorsa.

3. Fai clic sul nome del cluster che hai annotato in Nome visualizzato della risorsa. (resource.display_name) del riepilogo dei risultati. Si apre la pagina Cluster.

4. Nella sezione Metadati della pagina **Dettagli cluster, prendi nota di eventuali informazioni definite dall'utente che potrebbero essere utili per risolvere la minaccia, ad esempio informazioni che identificano il proprietario del cluster.

5. Fai clic sulla scheda Nodi.

6. Tra i nodi elencati, seleziona quello che corrisponde al valore di VM_Instance_Name che hai notato nel risultato JSON.

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

Passaggio 3: rivedi il pod

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

   Vai a Carichi di lavoro Kubernetes

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

3. Fai clic su Mostra carichi di lavoro del sistema.

4. Filtra l'elenco dei carichi di lavoro in base al nome del cluster che hai annotato in Nome completo della risorsa (resource.name) del riepilogo dei risultati e, se necessario, lo spazio dei nomi del pod (kubernetes.pods.ns) che hai annotato.

5. Fai clic sul nome del carico di lavoro che corrisponde al valore dell'VM_Instance_Name che hai notato nel file JSON dei risultati in precedenza. Viene visualizzata la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota delle eventuali informazioni sul pod può aiutarti a risolvere la minaccia.

Passaggio 4: controlla i log

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

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che viene visualizzato Nome completo risorsa (resource.name), se necessario.

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

4. Nella pagina visualizzata, procedi nel seguente modo:

   1. Trova i log dei pod per il tuo pod (kubernetes.pods.name) utilizzando seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
   2. Trova gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • POD_NAME
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: analizza il container in esecuzione

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

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

   Vai ai cluster Kubernetes

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

3. Nella pagina Cluster, fai clic su Connetti e quindi su Esegui in. 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 dei container eseguendo questo comando:

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

   Sostituisci CONTAINER_NAME con il nome del contenitore che hai annotato nel riepilogo del risultato in precedenza.

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

Passaggio 6: cerca metodi di attacco e risposta

1. Controlla lo stato del sito di Navigazione sicura per avere informazioni dettagliate sul motivo per cui l'URL è classificato come dannoso.
2. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Trasferimento di strumenti Ingress.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Passaggio 7: implementa la risposta

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

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

Reverse Shell

È stato avviato un processo con il reindirizzamento dello stream a una socket connessa da remoto. L'attivazione di una shell collegata alla rete può consentire a un malintenzionato di eseguire azioni arbitrarie dopo una compromissione iniziale limitata. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del processo iniziato con il reindirizzamento dei flussi a un socket remoto.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster.
     • Nome completo del progetto:
   • Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.
   • Nel JSON, prendi nota dei seguenti campi.
   • resource:
     • project_display_name: il nome del progetto che contiene per l'asset.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del container interessato.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.
     • Reverse_Shell_Stdin_Redirection_Dst_Ip: l'indirizzo IP remoto del connessione
     • Reverse_Shell_Stdin_Redirection_Dst_Port: la porta remota
     • Reverse_Shell_Stdin_Redirection_Src_Ip: l'indirizzo IP locale della connessione
     • Reverse_Shell_Stdin_Redirection_Src_Port: porta locale
     • Container_Image_Uri: il nome dell'immagine del contenitore in esecuzione.

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 ai carichi di lavoro Kubernetes

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

3. Filtra in base al cluster elencato in resource.name e allo spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di 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 carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

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

5. Avvia una shell nell'ambiente del container eseguendo:

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

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

   Per visualizzare tutti i processi in esecuzione nel container, esegui questo comando nella shell del container:

     ps axjf
   

   Questo comando richiede che nel contenitore sia installato /bin/ps.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script, Trasferimento di strumenti in entrata.
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 contenuto.

Unexpected Child Shell

Container Threat Detection ha osservato un processo che ha generato inaspettatamente un processo shell figlio. Questo evento potrebbe indicare che un utente malintenzionato sta tentando di abusare di comandi e script di shell.

Per rispondere a questo risultato, segui questi passaggi.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato di Unexpected Child Shell come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Processo principale: il processo che ha creato in modo imprevisto il processo shell secondario.
     • Procedura secondaria: il processo shell secondario.
     • Argomenti: gli argomenti forniti al file binario del processo della shell secondaria.
     • Variabili di ambiente: le variabili di ambiente del programma binario dei processi della shell figlio.
     • Containers: il nome del contenitore.
     • URI dei container: l'URI dell'immagine del container.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il nome della risorsa interessata.
     • Nome completo risorsa: il nome completo della risorsa del cluster. Il nome completo della risorsa include quanto segue: informazioni:
       • Il progetto che contiene il cluster: projects/PROJECT_ID
       • La località in cui si trova il cluster: zone/ZONE o locations/LOCATION
       • Il nome del cluster: projects/CLUSTER_NAME

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

+processes: un array contenente tutti i processi correlati al risultato. Questo array include il processo shell figlio e il processo padre. +resource: +project_display_name: il nome del progetto che contiene le risorse. +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 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 che hai annotato nel Nome completo risorsa (resource.name) del cluster nella un riepilogo dei risultati, se necessario.

3. Fai clic su Mostra carichi di lavoro del sistema.

4. Filtra l'elenco dei carichi di lavoro in base al nome del cluster che hai annotato in Nome completo della risorsa (resource.name) del riepilogo del rilevamento e, se necessario, nello Spazio dei nomi (kubernetes.pods.ns) del pod che hai annotato.

5. Fai clic sul nome del carico di lavoro che corrisponde al valore della proprietà VM_Instance_Name che hai annotato nel file JSON del rilevamento in precedenza. Viene visualizzata la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota delle eventuali informazioni sul pod può aiutarti a risolvere la minaccia.

Passaggio 4: controlla i log

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

   Vai a Esplora log

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

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

4. Nella pagina che si carica, 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 gli audit log del cluster utilizzando il filtro seguente:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: analizza il container in esecuzione

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

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

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

3. Fai clic su Attiva Cloud Shell.

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

   Per i cluster di zona, esegui questo comando:

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

   Per i cluster a livello di regione, esegui il seguente comando:

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

5. Per avviare una shell nell'ambiente del container, esegui questo comando:

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

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

   Per visualizzare tutti i processi in esecuzione nel container, esegui questo comando nella shell del container:

     ps axjf
   

   Questo comando richiede che nel contenitore sia installato /bin/ps.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Interprete di comandi e script: shell Unix.
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 contenuto.

Risposta di VM Threat Detection

Per scoprire di più su Virtual Machine Threat Detection, consulta la panoramica di Virtual Machine Threat Detection.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection ha rilevato attività di mining di criptovalute abbinando gli hash della memoria dei programmi in esecuzione agli hash della memoria di software di mining di criptovalute noti.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato di Execution: Cryptocurrency Mining Hash Match, come indicato in Esamina i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

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

     • Famiglia binaria: l'applicazione di criptovaluta rilevata.
     • Programma binario: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti quando viene invocato il file binario del processo.
     • Nomi processi: il nome del processo in esecuzione nell'istanza VM associato alle corrispondenze della firma rilevate.

     VM Threat Detection può riconoscere le build del kernel dai principali distribuibili. Se può riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo processes del risultato. Se il Rilevamento minacce VM non riesce a riconoscere il kernel, ad esempio se il kernel è personalizzato, il campo processes del rilevamento non viene compilato.

   • Risorsa interessata, in particolare i seguenti campi:

     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

3. Per visualizzare il JSON completo di questo rilevamento, fai clic sulla scheda JSON nella visualizzazione dettagliata del rilevamento.

   • indicator
     • signatures:
       • memory_hash_signature: una firma corrispondente agli hash delle pagine della memoria.
       • detections
         • binary: il nome del file binario dell'applicazione di criptovaluta, ad esempio linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0.
         • percent_pages_matched: la percentuale di pagine in memoria che corrispondono a pagine di applicazioni di criptovalute note nel database di hash di pagine.

Passaggio 2: controlla i log

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

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento.

3. Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Per Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla dashboard

2. Seleziona il progetto specificato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento.

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

4. Fai clic sull'istanza VM corrispondente al progetto identificato nel nome completo della risorsa. Rivedi istanza i dettagli, incluse le impostazioni di rete e accesso.

Passaggio 4: cerca i metodi di attacco e risposta

1. Rivedi le voci del framework MITRE ATT&CK per Esecuzione.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca 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 risultati.

Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.

1. Contatta il proprietario della VM.

2. Conferma se si tratta di un'applicazione di mining:

   • Se sono disponibili il nome del processo e il percorso binario dell'applicazione rilevata, considerare i valori su Programma binario, Argomenti e Righe Nomi processi nella scheda Riepilogo dei dettagli del risultato nella tua indagine.

   • Se i dettagli del processo non sono disponibili, controlla se il nome binario del file la firma hash della memoria può fornire degli indizi. Prendiamo in considerazione un file binario chiamato linux-x86-64_xmrig_2.14.1. Puoi utilizzare lo grep per cercare file importanti nello spazio di archiviazione. Utilizza una parte significativa del nome binario nel pattern di ricerca, in questo caso xmrig. Esamina i risultati di ricerca.

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

   • Cerca nei file archiviati le stringhe comuni utilizzate dalle applicazioni di estrazione, ad esempio btc.com, ethminer, xmrig, cpuminer e randomx. Per altri esempi di stringhe che puoi cercare, consulta Nomi di software e regole YARA e la documentazione relativa a ciascun software elencato.

3. Se ritieni che si tratti di un'applicazione di miner e la relativa procedura è ancora in esecuzione, termina il processo. Individuare l'eseguibile dell'applicazione binario nello spazio di archiviazione della VM e eliminarlo.

4. Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection ha rilevato attività di mining di criptovaluta mediante la corrispondenza della memoria schemi, come le costanti del proof of work, note per essere utilizzate dalle criptovalute di software di mining.

Per rispondere a questi risultati, segui questi passaggi:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Execution: Cryptocurrency Mining YARA Rule 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:

     • Nome regola YARA: la regola attivata per i rilevatori YARA.
     • Programma binario: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
     • Nomi dei processi: il nome dei processi in esecuzione nell'istanza VM associato alle corrispondenze delle firme rilevate.

     VM Threat Detection è in grado di riconoscere le build del kernel delle principali distribuzioni Linux. Se riesce a riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo processes del rilevamento. Se il Rilevamento minacce VM non riesce a riconoscere il kernel, ad esempio se il kernel è personalizzato, il campo processes del rilevamento non viene compilato.

   • Risorsa interessata, in particolare i seguenti campi:

     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: esegui il collegamento a Google SecOps.

3. Per vedere il JSON completo per questo risultato, nella visualizzazione dettagliata il risultato, fai clic sulla scheda JSON.

Passaggio 2: controlla i log

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

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento.

3. Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Ad esempio, controlla se ci sono attività sospette o sconosciute e segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla Dashboard

2. Seleziona il progetto specificato il nome della risorsa elencato nella Riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del risultato.

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

4. Fai clic sull'istanza VM che corrisponde a resourceName. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per Esecuzione.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

Passaggio 5: implementa la risposta

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

Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.

1. Contatta il proprietario della VM.

2. Conferma se si tratta di un'applicazione di mining:

   • Se sono disponibili il nome del processo e il percorso binario dell'applicazione rilevata, considerare i valori su Programma binario, Argomenti e Righe Nomi processi nella scheda Riepilogo dei dettagli del risultato nella tua indagine.

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

   • Cercare nei file nello spazio di archiviazione le stringhe comuni utilizzate dalle applicazioni di mining utilizzati, ad esempio btc.com, ethminer, xmrig, cpuminer e randomx. Per altri esempi di stringhe che puoi cercare, consulta Nomi di software e regole YARA e la documentazione relativa a ciascun software elencato.

3. Se ritieni che si tratti di un'applicazione di miner e la relativa procedura è ancora in esecuzione, termina il processo. Individuare l'eseguibile dell'applicazione binario nello spazio di archiviazione della VM e eliminarlo.

4. Se necessario, interrompi l'istanza compromessa e sostituirlo con una nuova istanza.

Execution: cryptocurrency mining combined detection

Il rilevamento delle minacce VM ha rilevato più categorie di risultati in un solo giorno da una singola origine. Una singola applicazione può attivare contemporaneamente Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings.

Per rispondere a un risultato combinato, segui le istruzioni di risposta per entrambi Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings.

Malware: Malicious file on disk (YARA)

VM Threat Detection ha rilevato un file potenzialmente dannoso analizzando il file dischi permanenti per le firme di malware note.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri la verifica Malware: Malicious file on disk (YARA) come indicato in Esaminare le verifiche. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome regola YARA: la regola YARA corrispondente.
     • Files: l'UUID della partizione e il percorso relativo del file potenzialmente dannoso rilevato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

3. Per visualizzare il JSON completo di questo rilevamento, fai clic sulla scheda JSON nella visualizzazione dettagliata del rilevamento.

4. Nel JSON, prendi nota dei seguenti campi:

   • indicator
     • signatures:
       • yaraRuleSignature: una firma corrispondente alla regola YARA che è stata trovata una corrispondenza.

Passaggio 2: controlla i log

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

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che sull'istanza VM, come specificato nella riga Nome completo risorsa in la scheda Riepilogo dei dettagli dei risultati.

3. Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Per Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla Dashboard

2. Seleziona il progetto specificato il nome della risorsa elencato nella Riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del risultato.

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

4. Fai clic sull'istanza VM che corrisponde a resourceName. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

Passaggio 4: cerca metodi di attacco e risposta

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

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

Passaggio 5: implementa la risposta

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

1. Contatta il proprietario della VM.

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

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

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

4. Per l'analisi forense, esegui il backup delle macchine virtuali dei dischi permanenti standard. Per ulteriori informazioni, consulta la sezione Protezione dei dati le opzioni di Compute Engine documentazione.

5. Per ulteriori indagini, prendere in considerazione l’utilizzo di servizi di risposta agli incidenti come Mandiant

Risolvere le vulnerabilità correlate

Per evitare che le minacce si ripetano, rivedi e correggi i risultati relativi a vulnerabilità ed errori di configurazione.

Per trovare eventuali risultati correlati, segui questi passaggi:

1. Nella console Google Cloud, vai a Security Command Center Pagina Risultati.

   Vai a Risultati

2. Esamina il rilevamento di minacce e copia il valore di un attributo che è probabile che venga visualizzato in qualsiasi rilevamento di vulnerabilità o di configurazione errata correlato, ad esempio l'indirizzo email principale o il nome della risorsa interessata.

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

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

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

   Ad esempio, se hai preso nota del nome completo della risorsa interessata, seleziona Risorsa. I tipi di attributi della categoria Risorsa sono visualizzato nella colonna a destra, incluso Nome completo .

6. Dagli attributi visualizzati, seleziona il tipo di attributo che hai rilevato nel rilevamento della minaccia. Si apre un riquadro di ricerca per i valori degli attributi a destra e vengono visualizzati tutti i valori trovati per il tipo di attributo selezionato.

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

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

9. Se i risultati sono numerosi, filtrali selezionando filtri aggiuntivi dal riquadro Filtri rapidi.

   Ad esempio, per visualizzare solo i risultati della classe Vulnerability e Misconfiguration che contengono i valori degli attributi selezionati, scorri verso il basso fino alla sezione Classe di risultati del riquadro Filtri rapidi e seleziona Vulnerabilità e Configurazione errata.

Oltre agli indicatori di compromissione forniti da Google, gli utenti che sono clienti di Palo Alto Networks può integrare il programma Minaccia di messa a fuoco automatica Intelligence con Event Threat Detection. AutoFocus è un servizio di intelligence sulle minacce che fornisce informazioni sulle minacce di rete. Per saperne di più, visita la AutoFocus nella console Google Cloud.

Risolvere le minacce

Correggere i risultati di Event Threat Detection e Container Threat Detection non è così semplice la correzione degli errori di configurazione e delle vulnerabilità identificate Security Command Center.

Gli errori di configurazione e le violazioni della conformità identificano i punti deboli delle risorse che potrebbero essere sfruttati. In genere, gli errori di configurazione hanno correzioni note e facilmente implementabili, come l'attivazione di un firewall o la rotazione di una chiave di crittografia.

Le minacce differiscono dalle vulnerabilità in quanto sono dinamiche e indicano un possibile exploit attivo contro una o più risorse. Un consiglio di rimedio potrebbe non essere efficace per proteggere le risorse perché i metodi esatti utilizzati per realizzare lo sfruttamento potrebbero non essere noti.

Ad esempio, un rilevamento Added Binary Executed indica che un file binario non autorizzato è stato avviato in un contenitore. Un consiglio di base per la correzione ti consiglia di mettere in quarantena il container ed eliminare il file binario, ma questa operazione potrebbe non risolvere la causa principale che ha consentito l’esecuzione dell’accesso malintenzionato il file binario. Per correggere l'exploit, devi scoprire in che modo l'immagine del container è stata danneggiata. Determinare se il file è stato aggiunto tramite una porta non configurata correttamente o in altro modo richiede un'indagine approfondita. Un analista con conoscenza approfondita del tuo sistema potrebbe dover esaminarlo per rilevare eventuali punti deboli.

I malintenzionati attaccano le risorse utilizzando tecniche diverse, quindi applicando una correzione a un exploit specifico potrebbe non essere efficace contro le varianti di quell'attacco. Ad esempio, in risposta a un Brute Force: SSH, potresti abbassare i livelli di autorizzazione per alcuni account utente per limitare l'accesso alle risorse. Tuttavia, le password deboli potrebbero comunque fornire un percorso di attacco.

L'ampiezza dei vettori di attacco rende difficile fornire passaggi di correzione che funzionino in tutte le situazioni. Il ruolo di Security Command Center nel tuo piano di sicurezza del cloud è identificare le risorse interessate quasi in tempo reale, indicarti le minacce che stai affrontando e fornire prove e contesto per aiutarti nelle indagini. Tuttavia, il personale addetto alla sicurezza deve utilizzare le informazioni dettagliate dei risultati di Security Command Center per determinare i modi migliori per risolvere i problemi e proteggere le risorse da attacchi futuri.

Passaggi successivi

• Consulta: Panoramica di Event Threat Detection per saperne di più sul servizio e sulle minacce che rileva.

• Consulta la panoramica di Container Threat Detection per scoprire come funziona il servizio.

• Consulta: Panoramica di VM Threat Detection per saperne di più sul servizio e sulle minacce che rileva.